Tags:
Microsoft, Windows, Server Standard 2k3 x64, Intel, network card, Pro 1000 MT, c#, .net 2.0
I've conducted some basic multicast sending on different platforms, different languages, etc. C#, C++, and C on Windows, using built in .NET sockets and socket.Send(), as well as using DLLImports of the winsock library, it takes the Send() function about 15-20 microseconds to return.
C#(mono), C++ on Linux takes 1-3 microseconds to return.
This means that something inside of Windows (presumably winsock) is taking roughly 10 times as long as the same type of send method in Linux.
How do I bypass the winsock slowness and achieve similar speeds to linux inside of windows?
I've already attempted NDIS driver and kernel calls for writefile API to write bytes to the drive but that's slower than the much simpler .Net method.
I just tested multicast sending on server 2008 and in terms of latency on back to back UDP sends, Server 2008 performs precisely the same as Server 2003.
Have you tried varous values for the "flags" parameter in the send() function? Have you tried varying the options when you create the socket? Is it possible that you are comparing synchronous timing vs. asynchonous (non-blocking) timing?
I've tried all the flags I could find on their own an reran the tests to no performance increase avail.
I tried creating the sockets in all of the ways I could.
I am not comparing the blocking/non-blocking calls. I am doing only synchronous calls; Fast I/O with buffered sends should result faster than Asynchronous could hope to perform. I did build a similar UDP asynchronous sender and it was scales slower than the buffered sends.
I'll check out the "Get Closer to the Wire" article and see if it gives me any insight I didn't have previously.
The "Get Closer to the Wire" in unfortunately lacking in any real content. The whole async threading pool thing they advocate comes at great costs when you're doing straight UDP to one endpoint and you do not care about receiving any data.
I've tried googling for performance comparisons between Winsock and linux without much success. It seems to me that if Winsock was 5- to 20-times slower, then the Linux community would be laughing quite loudly.
One thing worth trying is to run the client and server on the same box. That would rule out a whole host of issues. Basically the entire result would be the overhead/latency of setting up the socket (the send itself would take virtually no time).
It occurs to me that your testing techinque might be important. If you are timing thousands of instances of sending small packets, then some underlying logic, such as the use of Nagel's Algorythm, might be at issue.
One suggestion is to look at the LSPs installed on your system. LSP is "layered service provider", and they are often installed as part of anti-virus and anti-spam software. Some LSPs are poorly written and very slow.
AFAIK, Linux does not have a counterpart to LSPs, so you might not be comparing apples to apples.
Maybe you have one of the poorly written LSPs. Try a program like LSP-Fix (see http://www.cexx.org/lspfix.htm ) to view the installed LSPs. Unistall them one by one, until you have a true apples-to-apples comparison.
