🚀 go-pugleaf

David G. Bell (dbell@zhochaka.demon.co.uk) wrote:
) In article <3380810A.91FFD1F@no.spam.ncl.ac.uk>
)            w.j.p.slater@no.spam.ncl.ac.uk "Will Slater" writes:
) 
) > Lee Maguire wrote:
) > 
) > > mine is the same except:
) > > mru 576
) > > mtu 576
) > > (not because i know anything about them - but because thats what is 
) > 
) > they are the maximum receive/transmit unit size, you might as well have
) > them as large as possible, 1500 I think. It will generally save on
) > bandwidth, as files are not broken up into so many peices especially if
) > you do a lot of ftping.
) 
) AFAIK this is recommended if you connect mostly to Demon, but there is a 
) penalty for connections to the rest of the Internet.  So the 1500 figure 
) is fin for news, e-mail, and ftp.demon.co.uk but not so good for web 
) browsing and other off-Demon traffic.

"It's not quite as simple as that minister"...

If you've a mixture of traffic going on at the same time, telnet, web,
mail, news etc then the smaller MRU/MTU might be better since alternate
packets of data can be for the different streams of data going on. if
you're running a slowish connection 1500 bytes in one packet is ~ 0.83
seconds@14.4kbps if you've several streams and you're trying to telnet to a
remote site the link may appear sluggish.

[when I use the amd automounter to mount remote filesystems the kernel logs
NFS timeouts due to the round-trip delays]

On the other hand if you have a larger MTU/MRU then there is less overhead
on a per-packet basis.

the IP specification requires all hosts and gateways can handle datagrams
of upto 576 packets. Because of this some implementations automatically
change the MTU to 576 bytes when transferring data to hosts on a remote
network (eg a non-demon site to a demon node). Modern hosts use Path-MTU
discovery to see if the path to the remote machine can cope with larger IP
datagrams without fragmentation.

If you're an end-node you can reduce the MRU/MTU to below 576 bytes if
ou've lots of parallel streams, however this will be at the expense of
the per-packet overhead. most people shouldn't fiddle with this, and
leaving at the defalt is probably best.

RjL
+----------------------------+
| richard@illuin.demon.co.uk | Aut viam inveniam aut faciam
+----------------------------+