Tests For Socket Performance at IBM DevelWorks

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

WSAStartup

[Anonymous Coward]

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

[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

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

Re:WSAStartup

[thelonious]

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

[km00re]

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

Re:Bogus Test

[ratboy666]

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.

why windows sockets?

[leuk_he]

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.