Han Boetes wrote:
per engelbrecht wrote:
recently had a problem with a NFS server. Lousy performance when
getting data (not putting) from most clients (but not all) until
they discovered diffs in size of the transmit/receive
bufferes. When fixed users felt like going from walking to
flying both ways.
They do not use OpenBSD but the have different arch and OS as
well i.e. might be a similar/related problem.
I read an article recently about the tux kernel hackers working
on a "auto sensing" feature for the upcomming 2.6.whatever
dealing with this. The test result was quite impressive with
performance gains x 10-20 and above.
I could be a victim of christmas-lag (too much food, dark strong
beer and snaps [danish strong alcoholic drink]) or it could be
related. Just a thought.
Sounds interesting. But searching on google doesn't show any
usefull links. Nor did I find out how to read/set the
transmit/receive buffers for either OS.
Can't find the article (typical!). Found this though;
http://dsd.lbl.gov/TCP-tuning/linux.html
It describe the topic yes, but it's not "spot on".
I know how to set them for nfs. But that was not related to my
problem since it occured for ftp and ssh as well. And changing the
sizes didn't change the behaviour at all.
From mount_nfs(8)
-r readsize
Set the read data size to the specified value. It should normal-
ly be a power of 2 greater than or equal to 1024. This should be
used for UDP mounts when the ``fragments dropped after timeout''
value is getting large while actively using a mount point. (Use
netstat(1) with the -s option to see what this value is.) See
the -w option as well.
-w writesize
Set the write data size to the specified value. Ditto the com-
ments w.r.t. the -r option, but using the ``fragments dropped
after timeout'' value on the server instead of the client. Note
that both the -r and -w options should only be used as a last
ditch effort at improving performance when mounting servers that
do not support TCP mounts.
Makes sense doesn't it? Anyway, replacing my Gigabit NIC with a
100Mbit nic helped. I bet the old pII400 couldn't handle that
little thing.
I'm sure some of our commiters can elaborate further/completly on the
gory details of why. I'm afraid I can not, sorry.
/per
[EMAIL PROTECTED]
# Han
