I have a multicast file transfer program which seems to be having some issues with speed on particular versions of Windows.
I had a user of the software email me saying he was unable to get efficient file transfer speeds when running the sender under Vista SP2 or XP SP3, but good speeds on XP SP1 as well as Linux. I ran a test on my end between two boxes, one running XP SP2 and the other running XP SP3, connected via 100Mbps Ethernet. With the SP2 box as the sender, configured with no delay between sends, I'm able to run at about 90% line speed. The average time between sends is about .120 ms (optimal being .111 ms), and a Wireshark trace indicates this to be pretty consistent. When I switch it around so the SP3 box is the sender, again with no delay between packets, it only runs at about 53% line speed. In this case we're looking at around .210 ms between sends, again with Wireshark showing it to be consistent.
So the question here is what in SP3 could be causing this slowdown? I took a peek at the SP3 Overview documents and nothing's jumping out at me. All the network code is Berkley sockets, as it need to compile on multiple OS's.
I reproduced this issue with some shortened sample programs, which are attached (the transmitter takes an IP and port as the first two args). As before, SP2 -> SP3 ran close to the full 100Mbps, while SP3 -> SP2 ran 55%-60% at best.
Try re-running your tests with different sizes for your message. The size of the message is now hard-coded at 1400. Try to re-run at the following message sizes:
1023
1024
1025
1026
If you see a large change from 1024 to 1025, then you are dealing with a known issue involving registry entries respectively called FastSendDatagramThreshold and FastCopyReceiveThreshold. The issue affects only Windows machines (naturally, since it's a registry entry) and not Linux etc. See, for example, these two links
I ran with different message sizes, and found that 1024 bytes packets did indeed move faster than 1025 bytes packets on the SP3 box. I tried setting FastSendDatagramThreshold to 1500, but it didn't have any effect. Rebooting didn't help either. This parameter also has no effect on the SP2 box. Setting it to 1024 doesn't slow it down.
* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.