Doug Crompton wrote:
> Watching my modem lights the packets seem to have delay - one packet sent,
> response is delayed, etc. The delay is in Ms. but significant.
> Communications to this same host using other TCP/IP services utilizes the
> modem bandwidth. The (NFS) communication is certainly channel friendly but
> when it takes 30 seconds to get a 20K file and the same to get directories
> it becomes a real drag.
Unlike TCP, NFS has no streaming (also called windowing, where you send
requests while there's still outstanding replies). This means
performance is strictly limited by the latency of your connection,
rather than by its throughput. Using larger blocksizes can help, but
using RPC over UDP over high-latency connections is never going to be
good. NFS's preference for UDP has been long regarded as dubious, at
best.
TCP also has congestion control, which helps limit dropped packets due
to congestion on the net. UDP has no such mechanism, and will just make
the problem worse while performance plummets.
Increasing the blocksize can definitely help throughput, so long as you
arn't getting any dropped packets - a dropped fragment of a large NFS
datagram will just drop the whole lot, which will waste masses of
bandwidth.
In theory NFS can be run over TCP connections, but I'm not sure that
Linux supports it yet.
The problem is very much in NFS's design, which is why there's been work
on WebNFS, which is designed to pack more into a request to try and
counter the latency problems. HTTP has been transformed in similar ways
for similar reasons.
If you can't tweak NFS into getting good performance, and you need the
filesystem interface, look at using CIFS/SMB instead. It's a ghastly
mess, but it does stream nicely over long-haul TCP connections.
J