Best practices of high-performance network applications

Question

While testing out a UDP multicast server that I've written on Windows 7 Ultimate x64, I came across a most curious thing. Playing music with foobar2000 in the background significantly improved the server's transmission rate yet also incurred minor packet loss. Turning the music off immediately dropped the transmission rate to below acceptable levels but also produced 0 packet loss. (I have a client application which talks to the server and reports back unacknowledged packets)

I am aware of Vista's (and up) throttling behavior to make media and network applications play well together, but I certainly did not expect that playing music would improve network performance, nor that turning it off degraded network performance so significantly.

What can I do about this from a code standpoint in my server application so that it performs consistently whether playing music or not on Vista and up? I would certainly like to avoid having to inform all my clients about how to tweak their registry to get acceptable transmission rates, and would also like to avoid having them simply "play music" in order to get acceptable transmission rates as well. The application should "just work" in my opinion.

I'm thinking the solution involves something along the lines of process priorities, MMCSS, or possibly some other obscure Windows API call to get it to do The Right Thing(TM) here.

Also, sorry but creating a reproducible test case is a non-trivial amount of work. The throttling behavior occurs only when the driver for the physical NIC is actively doing work and cannot be reproduced using the loopback interface. One would need a client implementation, a server implementation, and physical network hardware to test with.

Answer 1

Foobar got many plugins written by different people. These may be the cause of your issue. I propose you to come closer to the real reason. Try to switch off plugins one by one performing your test each time a plugin is disabled.

Hope the idea will help.

Answer 2

This sounds like TSP/IP managing throughput based on it's primitive algorithm. The white paper here should give more background. http://www.asperasoft.com/?gclid=CICSzMqD8Z0CFShGagod%5FltSMQ Their product is a UDP protocol that works very well.

Answer 3

It has been many years since I wrote network protocol related code, but I'll offer a guess.

I suspect this is an issue of throughput and latency. Playing music is introducing I/O contention and adding latency in transmitting the packets. However, the added latency is likely causing the packets to queue and thus batched increasing throughput.

To address this in your code, you might try sending the packets in batches yourself. I am assuming that you are sending each packet to the system for transmission as the data becomes ready. Group multiple packets and send them to the system at the same time. Even just a group of two or three packets could make a dramatic difference especially if you are introducing your own small delay between each system call.

I couldn't find any directly relevant links from a quick search on Google. However, you can see the concept in this discussion of network tuning for Linux or in this FAQ which describes techniques such as batching to improve throughput.

Answer 4

What you observe is the side-effect of your media player setting clock resolution of your machine to 1 ms.

This happens only during the play

The side-effect is - your app has smaller timeslices and this imporves your app because you probably had lot of CPU stolen from your app and with longer timeslices - for longer time.

To test it you can simply set the timer resolution within your app to 1ms and compare performance without media playing.

Should be the same as if with no clocres setting but with media playing.