lkml.org 
[lkml]   [1998]   [Dec]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subjectlynx <-> linux tcp suckage.

    The short story:

    In some of our testing, we've found phenominally bad TCP performance
    between a LynxOS box and our Linux boxes. This problem is not found
    in Sun<->Lynx TCP.

    The longer story: (from Mark Frazer)

    tcprx and tcptx are two little utilities I use to ship stuff around
    the network. I'll send the code to you shortly, along with the test
    file, "paper1.ps". Below are some problems I've had with the tcp
    stack on lynx.

    Our current lan is such that all the linux boxes are on a 100baseT
    switched ethernet hub. There is a 10baseT repeater hanging off one
    of the ports on the hub with a sun, a lynx pc and a qnx pc on that hub.

    Transmitting a 115551 byte paper from my linux box to other machines
    using tcprx on the remote machine an tcptx on my machine, which is on
    the 100baseT switch:

    To another linux box also on the 100baseT switch:
    [mjfrazer@jimmy mjfrazer]$ time tcptx prodigo 9999 < paper1.ps
    0.00user 0.00system 0:01.34elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
    0inputs+0outputs (126major+23minor)pagefaults 0swaps
    [mjfrazer@jimmy mjfrazer]$ time tcptx prodigo 9999 < paper1.ps
    0.00user 0.00system 0:01.34elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
    0inputs+0outputs (126major+23minor)pagefaults 0swaps
    [mjfrazer@jimmy mjfrazer]$ time tcptx prodigo 9999 < paper1.ps
    0.00user 0.00system 0:01.35elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
    0inputs+0outputs (126major+23minor)pagefaults 0swaps

    fairly consistent, although a bit slow (<100 kB/s).


    To the sun behind a 10baseT repeater:
    [mjfrazer@jimmy mjfrazer]$ time tcptx sun 9998 < paper1.ps
    0.01user 0.01system 0:00.50elapsed 3%CPU (0avgtext+0avgdata 0maxresident)k
    0inputs+0outputs (126major+23minor)pagefaults 0swaps
    [mjfrazer@jimmy mjfrazer]$ time tcptx sun 9998 < paper1.ps
    0.01user 0.02system 0:00.49elapsed 6%CPU (0avgtext+0avgdata 0maxresident)k
    0inputs+0outputs (126major+23minor)pagefaults 0swaps
    [mjfrazer@jimmy mjfrazer]$ time tcptx sun 9998 < paper1.ps
    0.00user 0.05system 0:00.50elapsed 9%CPU (0avgtext+0avgdata 0maxresident)k
    0inputs+0outputs (126major+23minor)pagefaults 0swaps
    [mjfrazer@jimmy mjfrazer]$ time tcptx sun 9998 < paper1.ps
    0.00user 0.03system 0:00.79elapsed 3%CPU (0avgtext+0avgdata 0maxresident)k
    0inputs+0outputs (126major+23minor)pagefaults 0swaps
    [mjfrazer@jimmy mjfrazer]$ time tcptx sun 9998 < paper1.ps
    0.00user 0.03system 0:00.50elapsed 5%CPU (0avgtext+0avgdata 0maxresident)k
    0inputs+0outputs (126major+23minor)pagefaults 0swaps

    fairly consistent (except for the 0.79 secs), but still slow at 200 kB/s.


    and to the lynx box behind a 10baseT repeater:
    [mjfrazer@jimmy mjfrazer]$ time tcptx lynx 9999 < paper1.ps
    0.00user 0.01system 0:34.58elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
    0inputs+0outputs (126major+23minor)pagefaults 0swaps
    [mjfrazer@jimmy mjfrazer]$ time tcptx lynx 9999 < paper1.ps
    0.01user 0.00system 0:33.18elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
    0inputs+0outputs (126major+23minor)pagefaults 0swaps
    [mjfrazer@jimmy mjfrazer]$ time tcptx lynx 9999 < paper1.ps
    0.01user 0.00system 0:36.85elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
    0inputs+0outputs (126major+23minor)pagefaults 0swaps

    uh, I think my modem is faster.

    Between two sparcs (one SS5 and one ultra 170) on the same 10baseT at UW:
    [203]tyrant:~/netpipes% time ./tcptx despot 9999 < paper1.ps
    0.05u 0.06s 0:00.16 68.7%
    [204]tyrant:~/netpipes% time ./tcptx despot 9999 < paper1.ps
    0.04u 0.06s 0:00.15 66.6%
    [205]tyrant:~/netpipes% time ./tcptx despot 9999 < paper1.ps
    0.05u 0.05s 0:00.17 58.8%
    [206]tyrant:~/netpipes% time ./tcptx despot 9999 < paper1.ps
    0.04u 0.04s 0:00.17 47.0%
    [207]tyrant:~/netpipes% time ./tcptx despot 9999 < paper1.ps
    0.03u 0.08s 0:00.15 73.3%

    Sun - sun is by far the fastest.

    From the sun to the lynx box:
    [atlantic 210]~% time tcptx lynx 9999 < paper1.ps
    0.06u 0.55s 0:00.76 80.2%
    [atlantic 211]~% time tcptx lynx 9999 < paper1.ps
    0.06u 0.54s 0:00.76 78.9%
    [atlantic 212]~% time tcptx lynx 9999 < paper1.ps
    0.07u 0.53s 0:00.69 86.9%
    [atlantic 213]~% time tcptx lynx 9999 < paper1.ps
    0.06u 0.59s 0:00.67 97.0%
    [atlantic 214]~% time tcptx lynx 9999 < paper1.ps
    0.06u 0.55s 0:00.63 96.8%

    better than linux to linux!

    The remote command in all cases was 'tcprx 9999 > /dev/null'.

    One more weird thing: It's faster to tx the file across the ethernet
    between two linux boxes than it is to tx to localhost.
    (I only have one lynx pc, so I can't to a lynx-to-lynx test).

    txing to localhost:
    linux: 2.25 secs (on a 350 MHz PII)
    sun : 1.08 secs (on a 110 MHz microSparc 2)
    lynx : 1.57 secs (on a 250 MHz PII)

    So, lynx can rock, sort of. But it doesn't seem to like the code
    in the tcprx utility when talking to the linux box, which runs fine
    between the linux box and the sun.

    Note that I don't get bad performance from rcp, I can rcp the same
    file in 0.717 seconds from a linux box.

    Any ideas as to what's in the code that the lynx box isn't liking?


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:45    [W:0.033 / U:59.348 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site