Date: Wed, 12 Feb 2003 03:25:39 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Atte Peltomaki <atte.peltomaki@iki.fi> Cc: freebsd-current@freebsd.org Subject: Re: NFS lagging Message-ID: <3E4A2F33.245C2148@mindspring.com> References: <20030212102523.GA45290@naama>
next in thread | previous in thread | raw e-mail | index | archive | help
Atte Peltomaki wrote:
> I'm running FreeBSD 5.0-RELEASE on a dual P3 800MHz/512MB/Tekram DC-390
> SCSI. Moved all my IDE disks on another 'puter to access via NFS. So I
> ended up putting up a Debian server, because some of the disks were
> already in ext2fs. Now I'm experiencing heavy lag on my desktop when I
> use the NFS intensively, like copy a large file over. I get these 1-3
> second pauses in everything, looks like ssh lag but it's local(!). Mouse
> pointer in X doesn't seem affected, but even console lags if you type
> in.
Run tcpdump on the wire, to determine if it's a delay in the FreeBSD
box sending a request, or a delay in the Linux box servicing it.
Doing a tcpdump will tell you for sure; anything else, and you are
just guessing where the problem is, and we would be just guessing
where the fix is.
> I'm using NFSv3, tried it over TCP too, but since it's LAN, i dropped
> back to UDP.
This is not a good reason to use UDP, unless you drop your read
and write size so that a full packet plus UDP and IP headers,
all fits in a single MTU. Using UDP with large read/write
sizes is the same thing as using a fixed window (a fixed window
of x = read_write_size/usable_MTU), instead of the sliding window
you get with TCP... and why in heck would you want to do that?
Particularly since UDP fragment reassembly is a bugger, and the
packets are not retransmitted on a drop, and UDP opens you up to
packets-without-the-response-bit-set attacks from outside, for
any holes in your firewall, whereas TCP doesn't.
> Here's dmesg:
[ ... some not useful stuff ... ]
FreeBSD 5.0-RELEASE #4: Fri Feb 7 01:39:20 EET 2003
root@naama:/usr/src/sys/i386/compile/NAAMA
[ ... lot's of not very useful stuff ... ]
> xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xe000-0xe07f mem 0xda002000-0xda00207f irq 15 at device 11.0 on pci0
> xl0: Ethernet address: 00:50:da:df:09:7b
> miibus0: <MII bus> on xl0
> xlphy0: <3c905C 10/100 internal PHY> on miibus0
> xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
This tells me that you've recompiled your kernel 4 times; it
would be nice to know why, and what the differences are between
the distribution kernel, and the kernel you are using, if this
thread continues.
The xl driver has been known to be problematic. It has had
several updates since 5.0-RELEASE. See:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_xl.c
for details. My suggestion is that you update the driver (the
if_xl.c file and the registers header file, if_xlreg.h) and try
compiling your kernel again.
You should also switch back to TCP, unless you are prepared to
rewrite the UDP fragment reassembly code.
If the problem persists, then you should contact the -questions
list with relevent differences between your kernel config file
and GENERIC (not your whole config file!), and go from there.
PS: This question should have been sent to -questions, since it
involves a -RELEASE version.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E4A2F33.245C2148>