Just my $0.02 worth...
Coming from the WAN / telecommunications world, perhaps I can shed some
light here. The rule of thumb is that the MTU should be as large as possible
(NOTE1), with possible defined as no larger than the smallest MTU to be
encountered on any link (NOTE2), end to end. The MTU should NOT be larger
than the largest packet to be encountered, or "space" will be wasted
(NOTE3).
There are a few NOTES and caveats here......
(NOTE1) - Using the largest MTU possible prevents fragmentation and
re-assembly, a process that introduces processor overhead for every device
between each end and introduces latency. This assumes you have *stable
links* with *moderate contention*. Less stable / too busy links dictate a
smaller MTU, because a dropped packet is quicker to re-assemble and
re-transmit if it is small. On frame relay, smaller packets are less likely
to be dropped at all.
(NOTE2) - Most TDM links are comfortable with MTU's of 1500, but frame relay
really enjoys a smaller MTU, usually set to around 1024. When talking about
the Internet, you have no control over the links, so assume frame relay (or
worse, ATM) will be used (dictating a smaller MTU)
(NOTE3) - Many of us originate traffic from an Ethernet LAN, with Ethernet's
default MTU of 1500. This defines the largest packet to be encountered as
1500. If you are using Token Ring, or are using a serial protocol, this
changes things. The prevalence of Ethernet prompts software developers to
default the MTU to 1500.
An MTU smaller than the originating device is truly painful to throughput.
Because of the confluence of many issues stated above you won't see any/much
difference between 576 and 1500 when talking to the Internet. If you were
talking about a TDM circuit between two offices of a company, the difference
would be much too noticeable.
-----Original Message-----
From: Civileme [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 07, 2000 12:46 PM
To: [EMAIL PROTECTED]
Subject: Re: [expert] MTU length on dialup ISP's
The last time I used windows over a 56K modem (software type), I found
an even smaller MRU to be useful.� MTU doesn't have as much effect on
performance as MRU.� BAscially the scenario is this....
line error(rare) --> dropped frame --> discarded packet to be retransmitted
Software tied up(frequent)-->dropped frame-->discarded packet to be
retransmitted
So with 576 you lose less than with 1500 for retransmission.� I use 296
on Windoze for winmodems, 576 for hardware 56K modems.
On linux, with a slow modem, I use 296, 576 with a faster modem, and
1500 with a higher speed connection such as DSL.
I do note a few sites that freeze on MTU 1500 with modems and do not
with 1500 on DSL.� I puzzle at that behavior.� Packets do not carry
brand names or transmitting device types in them.� Perhaps the timing of
sending the longer packewt with a modem causes a problem on the transmit
end.
Civileme
Andrew Post wrote:
>
> I think that it's far from obvious that reducing the MTU really does
> improve performance. I have a 56K modem over a PPP connection (avg
> connection speed ~ 45K), and I didn't notice any performance change with
> an MTU of 576. I kept the change to 576 because I ran across a few buggy
> websites (www.adobe.com for example) that simply wouldn't load in Linux
> with an MTU of 1500, but would load with the lower MTU.
>
> Andrew
>
> vern wrote:
> >
> > I have wondered about the MTU value on
> > dialups, in windoze there is a big to do over
> > shorting your MTU from 1500 (default) to 576
> > for dialup networking. This is to reduce the
> > fragmenting of packets, errors, and retrys. I
> > have read no such concerns since being on
> > Linux it would seem that the same TCP/IP constraints
> > are there, can anyone enlighten this newbie??
> > Vern
> >
> > --
> >
> >
************************************************************************
> > * Vernon Stilwell [EMAIL PROTECTED],
[EMAIL PROTECTED]
> > * R.R.#3 Box 168 [EMAIL PROTECTED],
[EMAIL PROTECTED]
> > * Hardinsburg, Ky. 40143 "Happiness is a warm Penguin!"
> > * Registered User #165809
> >
************************************************************************
>
>
>
