Hmm. Could be. That's a good thing to try. The connection is a Full Duplex
100BaseT to a 3com switch (both alpha/freebsd && Solaris) so what you
suggest Just Didn't Occur To Me (tm). Thanks....
On Thu, 28 Oct 1999, Matthew Dillon wrote:
> :Okay- I went home and left a cvs update going on /usr/src - reading from
> :a local CVSUP repository NFS mounted on /home/ncvs. The server is a
> :Sun SS1000 Solaris 2.6 box. 6 hours later, the cvs update is still chugging
> :slowly along- top shows cvs as:
> :
> : PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
> : 275 mjacob 2 0 8704K 7616K sbwait 1:28 1.90% 1.90% cvs
> :
> :most of the time. Just to check that something wasn't broken for da5,
> :I did a test dd writing to a file just now and it happily munched along
> :at 4MB/s.
> :
> :The filesystem *is* a fat block fs:
> :
> : a: 4304896 0 4.2BSD 8192 32768 16 # (Cyl. 0 - 267*)
> :
> :I suppose the blockage could be at the ufs end... Anyone have a pointer
> :as to what try to narrow this down- mainly to save me the trouble of
> :actually thinking about it (got a lot else on mind)? Unacceptably bad
> :something or others here.....
>
> This kinda sounds like packet loss to me, causing the NFS link to
> back off. This would be true for both a udp or tcp nfs mount, but
> tcp tends to be more sensitive to packet loss.
>
> You should be able to tell by ktrace'ing the running cvs and then
> kdump -R'ing the resulting ktrace.out file to see if weird delays are
> occuring on nfs-related syscalls.
>
> -Matt
> Matthew Dillon
> <[EMAIL PROTECTED]>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
