🚀 go-pugleaf

In article <JP107.93Jan22121147@grus.cus.cam.ac.uk>, jp107@cus.cam.ac.uk (Jon Peatfield) writes:
> ...
>                          etherfind (great tool -- why don't SGI
> provide it?) ...


Why?  We have something far better, `netsnoop` and its more graphical
relatives.

If you want something free, I think `tcpdump` has been ported.
And people have written free imitations of `netvis`.


Vernon Schryver,  vjs@sgi.com

In article <JP107.93Jan22121147@grus.cus.cam.ac.uk>, jp107@cus.cam.ac.uk (Jon Peatfield) writes:
|> Ok, I've had a few nice chats with some of the readers of this group
|> and with our local SGI support line, who are currently off chasing the
|> fact that this has been reported to them before but they couldn't find
|> what had happened last time (what kind of help-desk software does the
|> support line use?)
|> 
|> Anyway it turns out that my SGI Indigos can only push files over NFS
|> at about 10 to 30 Kbytes/sec (after the patch mentioned below) while
|> all the rest of our machines (Sun/HP/Mac), can manage over
|> 110Kbytes/sec (I have a large number of figures if you want them.)  I
|> got a set of patches from SGI for general network performance (a new
|> ethernet device driver), which improved performance a good deal, but
|> still didn't put it in the acceptable range.  After hitting my head
|> for a while and replacing transceivers and moving machines etc, I
|> watched the network with etherfind (great tool -- why don't SGI
|> provide it?) and spotted that the SGIs are waiting after each NFS
|> write for an acknowledgement from the server.  Our servers don't
|> acknowledge 'til the block is on physical disk (like normal machines),
|> so there is a huge wait.  This is as if the biod daemons are not
|> working (but we have four (4) running.)  On all the other machines in
|> the dept, if I have N biods then I don't see blocking 'til N+1
|> requests are outstanding.  The delays get worse when one is over a
|> high latency netwrok while other machines just cope.  What is worse is
|> that if the Acknowledgement reply is lost (as sometimes happens on
|> ethernets (it is UDP after all)), the SGI waits for 4.5 SECONDS before
|> retrying the send.  A few of those and the time really adds up.

it almost sounds like you are hard mounting the nfs mount points...are you
doing that?




-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Miguel (Michael) J. Sanchez
miguel@csd.sgi.com			
Member Technical Staff, Silicon Graphics, Inc.         

In article <1993Jan22.221447.10697@odin.corp.sgi.com>  miguel@boytoy.csd.sgi.com  (Michael/Miguel Sanchez) writes:
> In article <JP107.93Jan22121147@grus.cus.cam.ac.uk>, jp107@cus.cam.ac.uk (Jon Peatfield) writes:
> |> Ok, I've had a few nice chats with some of the readers of this group
> |> and with our local SGI support line, who are currently off chasing the
> |> fact that this has been reported to them before but they couldn't find
> |> what had happened last time (what kind of help-desk software does the
> |> support line use?)
> |> 
> |> Anyway it turns out that my SGI Indigos can only push files over NFS
> |> at about 10 to 30 Kbytes/sec (after the patch mentioned below) while
> |> all the rest of our machines (Sun/HP/Mac), can manage over
> |> 110Kbytes/sec (I have a large number of figures if you want them.)  I
> |> got a set of patches from SGI for general network performance (a new
> |> ethernet device driver), which improved performance a good deal, but
> |> still didn't put it in the acceptable range.  After hitting my head
> |> for a while and replacing transceivers and moving machines etc, I
> |> watched the network with etherfind (great tool -- why don't SGI
> |> provide it?) and spotted that the SGIs are waiting after each NFS
> |> write for an acknowledgement from the server.  Our servers don't
> |> acknowledge 'til the block is on physical disk (like normal machines),
> |> so there is a huge wait.  This is as if the biod daemons are not
> |> working (but we have four (4) running.)  On all the other machines in
> |> the dept, if I have N biods then I don't see blocking 'til N+1
> |> requests are outstanding.  The delays get worse when one is over a
> |> high latency netwrok while other machines just cope.  What is worse is
> |> that if the Acknowledgement reply is lost (as sometimes happens on
> |> ethernets (it is UDP after all)), the SGI waits for 4.5 SECONDS before
> |> retrying the send.  A few of those and the time really adds up.
> 
> it almost sounds like you are hard mounting the nfs mount points...are you
> doing that?
> 

Umm, have you tried reading the manual?  (I don't want to be rude, but...)

It isn't clear what part you are replying to here, sorry about the
bandwidth guys!

The only difference that hard/soft mounting makes is that with soft
mounting after RETRANS retransmissions a soft mount will give up and
return an error, while a hard mount will repeat the call forever.

To quote the SGI manual (as that would disagree with any other NFS manual):

    Once the filesystem is mounted, each NFS request waits timeo=n tenths of
    a second for a response.  If no response arrives, the time-out is multi-
    plied by 2 and the request is retransmitted.  When retrans=n retransmis-
    sions have been sent with no reply a soft mounted filesystem returns an
    error on the request and a hard mounted filesystem retries the request.
    Filesystems that are mounted rw (read-write) should use the hard option.
    The number of bytes in a read or write request can be set with the rsize
    and wsize options.

The default timeno is 7, so it should only wait 0.7 sec before
retrying!  I will admit that the 4.5 sec delays were not measured by
myself but by another person a mile down the road who is also unhappy
about the NFS performance so I can't say with hand on heat tht I know
what his setup was... perhaps I should start a club ;-)

In fact all the mounts I've been doing are soft mounts if that did
make any difference!

-- Jon
--
Jon Peatfield, Computer Officer, the DAMTP, University of Cambridge
Telephone: (+44 223) 3-37852     Mail: J.S.Peatfield@amtp.cam.ac.uk

To be consistent with DNS domain ordering, shouldn't news groups have
names like "admin.sun.sys.comp" not "comp.sys.sun.admin" ?  EMWTK

Hmm, well this evening having nothing better to do (well I could
reinstall perl, xdvi, xfig, gs ghostview, etc like I've been promising
for weeks, but this SGI problem really has me hooked ;-), I decided to
try playing with one of our SGIs.  I'm really new to SGI machines, so
I was still learning about them, playing with "inst" etc, and pushing
in random CDs and seeign what "inst" made of them.  Anyway I put the
4.0.5F maintenance CD in and typed list.  Off it popped and gave me a
list of stuff, including the 4.0.5E nfs maintenance changes, which it
told me were NOT installed.  Now this machine was factory installed
with 4.0.5F, so I kind of assumed that they had put the 4.0.4E patches
in but...

I went away and read the manual, and found that "versions" was the
command I needed to check what was installed (like pkginfo on
Solaris-2 I suppose), and behold only 4.0.1 NFS was installed.  Aha!
Anyway I then had a crash course in how to boot to the miniroot and
installed it from there, (since it refuses to install from inst
running normally.)  After I reboot and check what is going on (hey why
does "inst" in this case build a new kernel for me, but when I
installed the 4.0.1 on the other machine it didn't?), I measured the
performance as about 37Kbytes/sec which is what I measured on the
other SGI all along (doubled the speed.)  However, the other SGI is
only running the 4.0.1NFS code since I didn't have chance to get round
to installing the 4.0.5E patch, and the people on the SGI helpdesk
said it didn't matter since I saw the problem on a machine with and
without -- well I do now.

Does this jog anyone's memory about that level of performance?

I'll try installing the 4.0.5E patch on the IP12 tomorrow and see if
that performs any better.  37Kbytes/sec isn't TOO bad, I can live with
it for a while, but I wouldn't want my sister to marry it.  (As her
husband probably wouldn't aprove.)

I'd also like to appologise for being rude in reply to the reply from
the person who suggested that it was a hard/soft mount problem.  I'd
just spent several hours watching the network and it was very late at
night and I was tired and cross.  I'm less cross now though it is
almost as late.  I'll phone SGI's support desk in the morning (well
afternoon probably), and see if they have come up with anything.

(At lest they are helpful, I've got a problem with one of our other
machines and the hardware maintenance people have been sending stuff
to the wrong address, and today they sent us a keyboard which
generates junk characters as you type as a swap for one with a broken
spacebar.  I'm not sure which keyboard I'll keep 'til they get us a
working one... but I'm not cruel enough to name them.)

-- Jon Peatfield  (Unix network admin)

--
Jon Peatfield, Computer Officer, the DAMTP, University of Cambridge
Telephone: (+44 223) 3-37852     Mail: J.S.Peatfield@amtp.cam.ac.uk

To be consistent with DNS domain ordering, shouldn't news groups have
names like "admin.sun.sys.comp" not "comp.sys.sun.admin" ?  EMWTK