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

4 of 10 comments (clear)

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