Subject: Re: NFS server ignoring writes?
To: Sean Doran <smd@ebone.net>
From: Brian C. Grayson <bgrayson@marvin.ece.utexas.edu>
List: current-users
Date: 11/18/1998 17:33:15
On Sat, Nov 14, 1998 at 07:49:29PM +0100, Sean Doran wrote:
> netstat -p ip
> 
> look for fragments received vs fragments dropped (especially those
> dropped after timeout).
> 
> It is quite possible that your NIC has insufficient buffering and
> is simply dropping from back-to-back line-rate bursts destined for it.
> This is likely the case if fragments dropped due to timeout is non-zero.

  Bingo!  This appears to be the culprit.  The machines are
connected to a 100Mb switch, and the 3c905 (in the server)
apparently uses programmed I/O, and thus drops every other
back-to-back 100Mb fragment blasted from the NFS client.
We're running -current from July on the server -- I'm not sure if
3c905 has DMA support in today's -current.

> If so, either reduce the readsize (client) or writesize (server)
> to 1024, or much better still, use NFS over TCP (but you probably
> want to set the client advertised MSS to 1460) and don't fiddle
> with the read/write sizes.

  With TCP mounts and no other options:
aulait# dd if=/dev/zero of=1mb count=1 bs=1048576
1048576 bytes transferred in 115.190308 secs (9103 bytes/sec)

  With TCP mounts, and the client mss set to 1460:
aulait# dd if=/dev/zero of=1mb count=1 bs=1048576
1048576 bytes transferred in 64.754914 secs (16193 bytes/sec)

  With UDP mounts, but wsize set to 1024:
aulait# dd if=/dev/zero of=1mb bs=1048576 count=1
1048576 bytes transferred in 2.410121 secs (435072 bytes/sec)

  So I think we'll be going with UDP and wsize=1024!

  Thanks for your help!

  Brian