> I did a quick test - sent large pings from a system with a fairly high
> performance 100Mbps ethernet to the wi device (via an AP on the 100Mb
> LAN of course).
> 
> I got no loss at all with anything up to 19 fragments generated.
> Go to the 20th fragment, and from that point on, no answers at all.
> 
> This means (I believe) that the wi driver (at least with Lucent silver
> cards, which is all I have available to test with easily) can handle
> 19 back to back fragments.

This is very symtomatic of NFS failures.  First saw this many many years
ago when our vmeBus ethernet card only used two buffers to relay IP
traffic into a unix host (it used most of its buffers for the on-board
ISO transport stack).  8k NFS transfers from fast systems didn't get through!

I've also seen problems with an NFS server on a wireless network, in this
case made worse by the target having a flash filesystem and delaying
some transactions for ~2 seconds while sector erases are done.  This
was enough for the (solaris) client to decide to send retransmissions
(then you get mkdir failing EXIST!).
(ftp to the flash was fine.)

It is also worth noting that copying a single file to an NFS filesystem
can (at least with some NFS implementations) lead to multiple concurrent
NFS write requests.  Thus it is very easy to overload the available
buffering in any device that has to do rate adaption.  Once you do
this with NFS/UDP and especially with transfer sizes greater than the
frame size, the failure mode is systematic and catestophic.

	David

-- 
David Laight: david@l8s.co.uk