USB Ethernet autosetting strange MTU - Hardware

This is a discussion on USB Ethernet autosetting strange MTU - Hardware ; I have a linksys usb100tx adapter on my 2.6.20 box, and when the device is connected (or the system boots) the MTU is oddly set to 576 and not the usual 1500 for ethernet. I don't know if this is ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: USB Ethernet autosetting strange MTU

  1. USB Ethernet autosetting strange MTU

    I have a linksys usb100tx adapter on my 2.6.20 box, and when the
    device is connected (or the system boots) the MTU is oddly set to 576
    and not the usual 1500 for ethernet. I don't know if this is actually
    slowing the connection or its my imagination but why would it
    establish such an odd number?

    thanks
    Pat


  2. Re: USB Ethernet autosetting strange MTU

    On 14 Mar 2007, in the Usenet newsgroup comp.os.linux.hardware, in article
    <1173936472.754368.22020@p15g2000hsd.googlegroups.c om>, pzaloum@gmail.com wrote:

    >I have a linksys usb100tx adapter on my 2.6.20 box, and when the
    >device is connected (or the system boots) the MTU is oddly set to 576
    >and not the usual 1500 for ethernet.


    Strange - is this something set in the network scripts of your unnamed
    distribution, or is it a default of the unnamed driver?

    >I don't know if this is actually slowing the connection or its my
    >imagination but why would it establish such an odd number?


    It's probably not your imagination. Assuming you are gauging performance
    by timing how fast a web page comes up, or how fast an FTP file transfer
    occurs, then you will see a performance hit. Assuming the data is large
    enough to fill many packets - let's use a one million byte file as an
    example, and no TCP or IP options in the headers, then you will need

    MTU IP Header TCP header "data" headers/data packets/MB
    576 20 20 536 7.4% 1866
    1500 20 20 1460 2.7% 685

    to carry the data. You'll have some similar relationship of packets
    going in the opposite direction (ACKs) unless your network stack is
    only sending an ACK packet after so many bytes. This also ignores
    any dropped packets, and how that may effect retransmissions.

    Why would it establish such a strange number? Very good question.
    In theory, this is an old X.25 standard value, and RFC1191 points
    back to RFC1122, where in Section 3.3.3, we find

    It is generally desirable to avoid local fragmentation and to
    choose EMTU_S low enough to avoid fragmentation in any gateway
    along the path. In the absence of actual knowledge of the
    minimum MTU along the path, the IP layer SHOULD use
    EMTU_S <= 576 whenever the destination address is not on a
    connected network, and otherwise use the connected network's
    MTU.

    You can find the RFCs using any search engine. The rfc-index says

    1122 Requirements for Internet Hosts - Communication Layers. R.
    Braden, Ed.. October 1989. (Format: TXT=295992 bytes) (Updated by
    RFC1349, RFC4379) (Also STD0003) (Status: STANDARD)

    1191 Path MTU discovery. J.C. Mogul, S.E. Deering. November 1990.
    (Format: TXT=47936 bytes) (Obsoletes RFC1063) (Status: DRAFT
    STANDARD)

    Neither RFC1349 or RFC4379 mention MTU.

    I'd suggest looking through your boot scripts - no information on which
    distribution you are using, so I can't tell you where they might be. If
    you are using DHCP, this _could_ be coming from the DHCP server.

    Old guy


+ Reply to Thread