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.
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.
# Han
