Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Linux Software

Tests For Socket Performance at IBM DevelWorks 10

fsoft writes: "In this interesting article at IBM develWorks, Dr. Edward G. Bradford explains sockets and does some benchmark between Linux and (various flavours of) Windows. Quite interesting results."
This discussion has been archived. No new comments can be posted.

Tests For Socket Performance at IBM DevelWorks

Comments Filter:
  • WSAStartup (Score:3, Interesting)

    by Anonymous Coward on Thursday December 06, 2001 @11:13PM (#2669162)
    I'm finding this hard to take seriously when the first bit of code he comments on is wrong.

    The first parameter to WSAStarup [microsoft.com] isn't a simple version number - it's a high and low byte packed into a word. And 'using any non-zero number' is not guarenteed to work.
    • Re:WSAStartup (Score:2, Insightful)

      by Anonymous Coward
      later on

      It is hard for me to understand how even a substantial subset of these parameterizations can be tested or verified.

      Then you don't know how to test software, or understand what these parameters mean.

      This person is an idiot - or an anti-MS zealot.

      For example ....

      memcpy takes 3 parameters 2 pointers and a size.

      On a 32-bit system my back of the envelope calculation shows there are 2^96 combinations of calls possible. It is hard for me to understand how even a substantial subset of these parameterizations can be tested or verified.
      • Re:WSAStartup (Score:1, Insightful)

        by Anonymous Coward
        Finally ... it's a shame he doesn't know how to graph data or take multiple readings to get an average result.

        I really don't doubt linux is faster, but this is a very amateur attempt to prove it.
        • I agree that this is not the best test, but the types of arguments he is talking about not knowing how to test is not based on his inability to calculate math. He is talking about the flags that can be used, and the fact that if all of these flags are legit, then there should be a reason for them and kernel code that would cause different results, etc. etc.
          The comparison to the number of possible memory locations to pass to memcpy , awww hell, why am I even trying to respond to that
  • Bogus Test (Score:5, Informative)

    by km00re ( 470624 ) on Friday December 07, 2001 @02:31AM (#2669609) Homepage
    Mr. Bradford's tests demonstrate inefficiencies in Win2K/XP's TCP/IP loopback implementation, not the Winsock implementation. The loopback interface is implemented down deep in the IP stack. Just before a packet is about to hit the net, it is checked to see if it should be "looped back". If so, it is queued off to a worker thread that does the grunt work. The end result is you get at least two thread context switches for each loopback packet (in each direction).

    Don't get me wrong -- I'm not trying to make excuses for the loopback implementation, it sucks. I just think it's important to note what is actually getting measured. I have not studied the Linux loopback implementation, so I don't know how it compares with Win2K/XP.

    I would like to see the tests run with the client & server applications on separate machines. Also, his sockspeedp6.cpp test is naive at best. On Win2K/XP at least, a properly written app can easily saturate a 100MB ethernet. At this point, the most meaningful performance metric becomes not "how fast is data transferred" but "how much CPU load is required to saturate the network".
    • Sockets are an interprocess communications
      mechanism. Now, a 100MB ethernet can transfer
      10 megabytes per second. From my reading of
      Dr. Bradford's results, that would seem to
      support 3 100MB ethernets on a windows OS,
      and around 7 under linux. Still, the test
      was for interprocess communication. Of course
      two thread context switches are needed (at least)
      because there are two processes involved.
  • he writes:

    The necessity for the Windows sockets interface versus the vanilla
    Berkeley sockets interface is not clear to me.


    They are a leftover from windows 3.0.

    The windows socket interface was invented during windows 3.x
    It was add-on therefor it was not integrated with the BSD-file like sockets.

    This was done because a blocking process (waiting for connection) was not acceptable for a non multithreated environment in windows 3.x

    Windows sockets seems
    to support other transport protocols.


    BSD sockets also seem to support other transport mechanism.....at first.

Ummm, well, OK. The network's the network, the computer's the computer. Sorry for the confusion. -- Sun Microsystems

Working...