Network program locks for MTU 9000 - Unix

This is a discussion on Network program locks for MTU 9000 - Unix ; I was doing some network testing and found that one of my programs locks when the MTU is 9000 at 100baseT. However the exact same test works fine with an MTU of 9000 at 1000baseT. The program is just C ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Network program locks for MTU 9000

  1. Network program locks for MTU 9000

    I was doing some network testing and found that one of my programs locks
    when the MTU is 9000 at 100baseT. However the exact same test works fine
    with an MTU of 9000 at 1000baseT. The program is just C using sockets -
    it has no idea of the speed or, as far as I can tell, the MTU size. Can
    anybody suggest a reason why an MTU of 9000 might be fatal at the slower
    speed and ok at the faster one? MTU 1500 works at both speeds.

    Next week I'll make a debug version of the program and try to figure out
    where it is hanging up.

    Thanks,

    David Mathog

  2. Re: Network program locks for MTU 9000

    David Mathog wrote:

    > I was doing some network testing and found that one of my programs locks
    > when the MTU is 9000 at 100baseT. However the exact same test works fine
    > with an MTU of 9000 at 1000baseT. The program is just C using sockets -
    > it has no idea of the speed or, as far as I can tell, the MTU size. Can
    > anybody suggest a reason why an MTU of 9000 might be fatal at the slower
    > speed and ok at the faster one? MTU 1500 works at both speeds.


    Hardware or driver problem perhaps?

    AFAIU, jumbo frames are rarely supported by 100BASE-T hardware.

    Could setting your NIC to 100BASE-T break jumbo frame support?

    http://en.wikipedia.org/wiki/Jumbo_frame

  3. Re: Network program locks for MTU 9000

    Boon wrote:
    > David Mathog wrote:
    >
    >> I was doing some network testing and found that one of my programs locks
    >> when the MTU is 9000 at 100baseT. However the exact same test works
    >> fine with an MTU of 9000 at 1000baseT. The program is just C using
    >> sockets - it has no idea of the speed or, as far as I can tell, the
    >> MTU size. Can anybody suggest a reason why an MTU of 9000 might be
    >> fatal at the slower speed and ok at the faster one? MTU 1500 works at
    >> both speeds.

    >
    > Hardware or driver problem perhaps?
    >
    > AFAIU, jumbo frames are rarely supported by 100BASE-T hardware.
    >
    > Could setting your NIC to 100BASE-T break jumbo frame support?
    >
    > http://en.wikipedia.org/wiki/Jumbo_frame


    That's pretty much what I'm thinking. The machines in question have
    10/100/1000baseT NICs, and the test code was originally run with two
    machines directly cabled to each other, where they autonegotiated up to
    1000baseT and the Jumbo frames worked fine. When plugged back into the
    campus net, which is only 100baseT, the program successfully set up the
    first part of the communication protocol, which only sends packets of a
    few bytes back and forth. Then when it hit the data transmission stage,
    allowing it to send a real jumbo packet, the code froze. It could be an
    issue with the forcedeth linux driver at 100baseT, or the campus switch.
    I guess I could figure out which by using a crossover cable direct
    connection and forcing the two machines to 100baseT. Probably it isn't
    worth the effort though, since this looks like a case where "just don't
    do that" is the best solution.

    Thanks,

    David Mathog

  4. Re: Network program locks for MTU 9000

    David Mathog wrote:
    > That's pretty much what I'm thinking. The machines in question have
    > 10/100/1000baseT NICs, and the test code was originally run with two
    > machines directly cabled to each other, where they autonegotiated up
    > to 1000baseT and the Jumbo frames worked fine. When plugged back
    > into the campus net, which is only 100baseT, the program
    > successfully set up the first part of the communication protocol,
    > which only sends packets of a few bytes back and forth. Then when
    > it hit the data transmission stage, allowing it to send a real jumbo
    > packet, the code froze. It could be an issue with the forcedeth
    > linux driver at 100baseT, or the campus switch. I guess I could
    > figure out which by using a crossover cable direct connection and
    > forcing the two machines to 100baseT. Probably it isn't worth the
    > effort though, since this looks like a case where "just don't do
    > that" is the best solution.


    My guess would be the switch. If it isn't negotiating 1000BaseT it is
    _probably_ old enough to not support JumboFrames.

    rick jones
    --
    No need to believe in either side, or any side. There is no cause.
    There's only yourself. The belief is in your own precision. - Jobert
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

+ Reply to Thread