My company has a product that transmits large amounts of data over UDP. Some recent performance modifications have permitted us to generate more data, and thus in testing, it was observed that if the receiving end was running Linux, performance was perfectly fine, whereas under Windows, throughput suffered.
As a test, we set up 'iperf3' on a couple of machines connected to a switch. The packet sending side always ran Win10, and we dual-booted the receiver between Linux (Ubuntu 18.04) and Win10. (FWIW, the receiving device is a 4-core i5-7400, using the on-board Realtek gigabit NIC, with the latest drivers.)
With a linux receiver, I effectively get zero packet loss when iperf is instructed to send a flurry of 1400-byte UDP packets with a 2M window, and unlimited bandwidth ("-b 0"). The task manager reports the NIC is effectively saturated, and iperf displays throughput numbers in the high 900 Mbps. Everything's awesome -- no weird loss at the switch, no dodgy cabling.
Boot receiving device into Windows, repeat the same iperf test, and I get 70% packet loss reported at the application layer. Windows 'netstat -s' command shows the appropriate level of incoming packets such that there shouldn't be loss, but clearly something is underbuffered since those packets aren't making it to the iperf application to be decoded.
I have tried disabling power saving modes on the receiving NIC, adding 'DefaultReceiveWindow' and 'DefaultSendWindow' entries to the registry (set to 0x00200000), disabling the network throttling, disabling the firewall ... to no avail. I can't believe 'iperf' wouldn't itself have sufficient buffering via a 'setsockopt' call ... and I know our application has a large buffer for packets. Ultimately, I'm not getting much more than 300-350Mbps worth of UDP traffic into ANY application running on Win10, but the same code on Linux is quite happy. TCP flows do not seem to exhibit this issue, but that is not an option for us, so please don't ask :)
Thoughts? Things to tweak, features to enable/disable, settings to poke at?
If you're interested in more specific details, please ask away.
Many thanks for all suggestions!
No comments:
Post a Comment