🚀 go-pugleaf

>Can NFS over FDDI work properly?  Certainly.

Perhaps it should have been 
"Can NFS over FDDI-Ethernet work properly thru a bridge?"

>
>The most obviously distinctive thing about NFS traffic is that it
>usually contains many 4 or 8KByte UDP/IP datagrams.   These packets are
>divided into about 4K Byte** or 1500 Byte IP fragments (for FDDI or
>ethernet respectively), and commonly come from their source "back to
>back."
>
>You might use 1500 Byte IP fragments on FDDI if you're stupid or you're
>working around stupid FDDI-ethernet bridges or routers that can't
>fragment at all or cannot fragment at full speed.  There are such
>bridges and routers.  Since the problem is intermittent, it cannot be
>caused by a bridge or router that cannot fragment at all.  Perhaps the
>bridge cannot fragment at full speed, like many PC ethernet boards
>cannot receive the back-to-back 1500 byte IP fragments of NFS traffic.
>
>If this is the problem, you might expect such observations with
>etherfind on the ethernet side of the bridge.
>
>If this is the problem, reducing the NFS block sizes on the clients to
>something less than or equal to 1400 should make it go away, although
>that will make NFS a lot slower.

Experiment (I):
                      FDDI                         Ether
DEC500 NFS server <--------> 3com NetBuilder II <-------> Sun ELC NFS Client

We have tried that on our Sun machines by setting rsize and wsize to
1400, the problem didn't go away unfortunately.
When we run nfsstat on the Sun, 
it shows that there are a lot of RPC timeout and badcalls
on the client statistics.
When we run nfsstat on the NFS server (DEC 5000), the server statistics
is clean, ie no RPC timeout and badcalls.

We tried another experiment as follows:

Experiment(II):
                     Ether                 FDDI 
DEC5000 NFS server <--------> 3com NB II <--------> IBM R6000/560 NFS Client

We connect the DEC5000 NFS server now to the bridge via the Ethernet port.
We use a IBM R6000 connected to the bridge via a FDDI to run as a NFS client.
We encounter intermittent NFS problem too.

We then change the FDDI MTU of the IBM R6000/560 from 4352 to 1500, and
everything works! (It seems to me that if we change the FDDI MTU of
the DEC5000, experiment (I) should work fine too! -- Refer to VJS's remark.
Unfortunately, we don't know how to change the MTU value yet in Ultrix)

It certainly looks like the 3com bridge is dropping packets
and it is very likely that, as vjs@sgi.com has pointed out,
the bridge is not fast enough to fragment IP packets:
ie to break a 4325-byte fragment to several 1500-byte fragments.

Just wonder what we can do now? Any suggestion pls?

--
Ann-Kian Yeo
yeoak@iscs.nus.sg