What would happen if you used tcp in the nfs mount?

		David/absolute

	 -=-  "There will not be a send-off, a funeral or mass"  -=-

On Fri, 27 Aug 1999, Ignatios Souvatzis wrote:

> On Fri, Aug 27, 1999 at 02:28:15AM +0200, Stefan Hensen wrote:
> 
> [About the ed0: warning - receiver ring buffer overrun messages]
> > I have the same sort of ethernet board in my Amiga 4000 and I also get the
> > above mentioned messages. But surprisingly, this happens only if the Amiga
> > acts as NFS client and then only while reading data from the NFS server. It
> > does not occur during write access to the NFS server and it also does not
> > occur if the Amiga itself acts as NFS server, neither with read nor with
> > write accesses. FTP file transfers also work without any error messages in
> > both directions and with the Amiga acting either as client or as server.
> > Also things like remote tape access work without any problems. (The machine
> > "on the other side" was a Pentium II/Linux system in all cases.)
> > 
> > Therefore, I suspect that the problem does perhaps not really come from the
> > driver for the AmigaNet board but from the NFS client part. (But I do not
> > know enough about the kernel internals to be sure about this.)
> 
> You are right, sort of. But the culprit ist the idiotically designed chip.
> 
> NFS, with standard parameters, likes to send 8 kBytes of data + rpc headers
> at once. Such a packet gets split up into 6 fragments on Ethernet. When the
> receiver chip can't buffer them all, and the receiving cpu isn't fast enough
> to read them off the chip fast enough, some get lost, or overwrite earlier
> packets, depending on the Ethernet chipset used. The latter is what happens
> to the Amiga ed users.
> 
> Set the "nfs read size" and "nfs write size" (nfs_mount: -r / -w options) to
> 1 kByte on the client machine.
> 
> FTP, rcp etc.  don't stuffer from this problem because they operate over
> TCP, which knows about the packet size on (e.g.) Ethernet and only sends 
> (on average) 2 packets before waiting for an ACK packet from the peer.
> 
> Regards,
> 	-is
>