Slashdot Mirror

← Back to Stories (view on slashdot.org)

Tests For Socket Performance at IBM DevelWorks

Posted by timothy on from the ball-and-socket dept.

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."

10 comments

  1. WSAStartup by Anonymous Coward · · Score: 3, Interesting

    I'm finding this hard to take seriously when the first bit of code he comments on is wrong.

    The first parameter to WSAStarup 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.

    1. Re:WSAStartup by Anonymous Coward · · Score: 2, Insightful

      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.

    2. Re:WSAStartup by Anonymous Coward · · Score: 1, Insightful

      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.

    3. Re:WSAStartup by thelonious · · Score: 1

      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

  2. Bogus Test by km00re · · Score: 5, Informative

    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".

    --


    KM
    1. Re:Bogus Test by ratboy666 · · Score: 1

      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.

      --
      Just another "Cubible(sic) Joe" 2 17 3061
  3. why windows sockets? by leuk_he · · Score: 2

    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.