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

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

  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