3

I'm using Interix on Windows XP to port my C++ Linux application more readily to port to Windows XP. My application sends and receives packets over a socket to and from a nearby machine running Linux. When sending, I'm only getting throughput of around 180 KB/sec and when receiving I'm getting around 525 KB/sec. The same code running on Linux gets closer to 2,500 KB/sec.

When I attempt to send at a higher rate than 180 KB/sec, packets get dropped to bring the rate back down to about that level.

I feel like I should be able to get better throughput on sending than 180 KB/sec but am not sure how to go about determining what is the cause of the dropped packets.

How might I go about investigating this slowness in the hopes of improving throughput?

--Some More History--

To reach the above numbers, I have already improved the throughput a bit by doing the following (that made no difference on Linux, but help throughput on Interix):

  • I changed SO_RCVBUF and SO_SNDBUF from 256KB to 25MB, this improved throughput about 20%
  • I ran optimized instead of debug, this improved throughput about 15%
  • I turned off all logging messages going to stdout and a log file, this doubled throughput.

So it would seem that CPU is a limiting factor on Interix, but not on Linux. Further, I am running on a Virtual Machine hosted in a hypervisor. The Windows XP is given 2 cores and 2 GB of memory.

I notice that the profiler shows the cpu on the two cores never exceeding 50% utilization on average. This even occurs when I have two instances of my application running, still it hovers around 50% on both cores. Perhaps my application, which is multi-threaded, with a dedicated thread to read from UDP socket and a dedicated thread to write to UDP socket (only one is active at any given time) is not being scheduled well on Interix and thus my packets are dropping?

WilliamKF
  • 41,123
  • 68
  • 193
  • 295
  • If the bottleneck is caused by your program use a profile to isolate what functions are using the most cpu time. If it's network latency a network monitoring tool may be appropriate. – Captain Obvlious Jun 02 '13 at 23:10

1 Answers1

1

In answering your question, I am making the following assumptions based on your description of the problem:

(1) You are using the exact same program in Linux when achieving the throughput of 2,500 KB/sec, other than the socket library, which is of course, going to be different between Windows and Linux. If this assumption is correct, we probably shouldn't have to worry about other pieces of your code affecting the throughput.

(2) When using Linux to achieve 2,500 KB/sec throughput, the node is in the exact same location in the network. If this assumption is correct, we don't have to worry about network issues affecting your throughput.

Given these two assumptions, I would say that you likely have a problem in your socket settings on the Windows side. I would suggest checking the size of the send-buffer first. The size of the send-buffer is 8192 bytes by default. If you increase this, you should see an increase in throughput. Use setsockopt() to change this. Here is the usage manual: http://msdn.microsoft.com/en-us/library/windows/desktop/ms740476(v=vs.85).aspx

EDIT: It looks like I misread your post going through it too quickly the first time. I just noticed you're using Interix, which means you're probably not using a different socket library. Nevertheless, I suggest checking the send buffer size first.

2to1mux
  • 773
  • 5
  • 7
  • I previously upped the SO_RCVBUF and SO_SNDBUF from 256KB to 25MB and that did improve the throughput about 20% to get to the numbers I report above. The other thing I noticed was that optimized code was needed as well on Interix, whereas on Linux running debug had no significant impact on performance. – WilliamKF Jun 03 '13 at 13:34
  • I agree! Way to go 2to1mux! your a shining star! – 75inchpianist Jun 03 '13 at 18:24