[Nottingham] Odd behaviour in KDE

[Robert Davies]

On Thursday 21 Aug 2003 13:27, Lee wrote:
> > NFS has options for controlling packet size, if you have an MTU of 2346,
> > try settings for rsize and wsize in your mount options. 
> > rsize=2048,wsize=2048 are likely to be sensible.  It might also for a
> > wireless LAN be a good idea to try using tcp/ip mounts with the tcp
> > option, as it has tried and tested error recovery and flow control.

> Probably for wireless, depending on how much interference you getting ,
> using a smaller mtu is probably a better idea, and if yopu have a lot of
> machines competing for airtime, then a small mtu is a good idea...
> you'll have to 'play' with it, to get the setting that works for you.

My suggestion was based on a common NFS tweak where there are problems.  Main 
idea was bringing the NFS packet size to down below the MTU.  If a packet is 
dropped, then only that one needs retransmission, whilst with 8KiB size and 
1500 ethernet MTU, then 6 packets will be retransmitted.

I think Iain should actually still consider applying it, once things settle 
down, if he uses NFS much at all, as a performance optimisation.

> I'd did'nt know you could run nfs mounts over tcp, that's
> brilliant......is that new, or should have RTFM?? does that mean the
> port mapper/rpc works tcp too?

I think support for TCP/IP NFS server is fairly new feature to Linux kernel 
NFS implementation, but ...

there's nothing new under the Sun (excuse bad pun), when WAN use became more 
common in the early 90's, issues with NFS outside of the LAN setting it was 
designed for became more and more apparent.

I am reasonably sure the older user space NFS daemon supported TCP/IP, that 
was the only option in 2.0, and was included in distro's still as an option 
with 2.2 kernel.

So I know of TCP/IP based NFS implementations in the mid-90's and IIRC Solaris 
2.4/5 offered it as an option.  It was appreciated by many, though I found 
using an X.25 based corporate network, that NFS was robust, even with speeds 
as low as 9,600 Baud, so long as small 1KiB packet sizes were used.

530rob@ash$ netstat -tulp | egrep sun
tcp        0      0 *:sunrpc                *:*                     LISTEN      
-
udp        0      0 *:sunrpc                *:*

For NFS to work over TCP/IP, RPC *must* be implemented over TCP/IP to, as NFS 
operates by remote procedure calls, using XDR data marshalling to define the 
bit stream over the wire ie network byte order.

As for the port mapper part, I am not sure, but it would not be critical, 
that's used to register each RPC call type with a particular port number, in 
a dynamic way.  I think it would only be accessed on an NFS mount, rather 
than per RPC call which would be hopelessly inefficient.

> I think
> this case just goes to show the tcp will work over two cups and bit of
> string where as stuff that relies on udp you have to have much 'cleaner'
> connection......interesting problem ....interesting indeed.

TCP/IP doesn't work very well if you have significant packet loss, that kills 
throughput, with 50% it falls to 0.  Even with 20% you will spend all your 
time backing off, and gradually trying to increase bandwidth consumption.  
This is a consequence of assumption, that packets are dropped due to 
congestion, that's built into flow control algorithm of TCP/IP.

NFS likes a cleaner connection, because each transaction 8KiB maps to 6 UDP/IP 
packets, and as the application is responsible for retransmission, it can 
only retry the whole block.

If you look at SNMP  you'll see it's designed to be robust in face of much 
less clean networks than TCP/IP would require.  NTP servers will not care if 
3/4 of the packets are dropped either, just so long as some of them get 
through, they can always reduce the polling period.

Rob