Performance degradation in different setups whit PerfTest

Home Forums Discussions General Performance degradation in different setups whit PerfTest

Tagged: ,

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
  • #13556

      Hi all,

      I’m testing the performance of ndisapi on my Windows 10 Laptop (HostDevice) using PerfTest project described in “”.

      I used a second laptop(GuestDevice) for traffic generation.

      I installed “Windows Packet Filter v3.4.8” on HostDevice. I connect Gigabit ethernets of HostDevice and GuestDevice with cross cable set up. Additionally both devices connect to same Wi-Fi adapter to access the Internet.

      I have two questions for my trials:

      1. When PerfTest runs with single thread on Ethernet adapter; Both (HostDevice=client —-> GuestDevice=server ) and (GuestDevice=client —> HostDevice=server ) directions generates good results ( about 950 Mbit/sec). But when I run PerfTest with 2 threads, the bandwidth for (HostDevice=client —> GuestDevice=server) degrages about 100 Mbit/sec, while bandwith of other direction remains same. Checksum offloading and LSO features are disabled on the ethernet adapter.

      Why does uploading bandwidth fall drastically in case of multiple threads ?

      2. Without PerfTest running, iperf on Wi-Fi adapter results in about 20 Mbit/sec for both directions, downloading and uploading.  My internet provider’s internet speed test shows 12 Mbit/sec DOWNLOAD; and 2 Mbit/sec UPLOAD speed. When I run PerfTest with single thread, iperf test for download direction (GuestDevice=client —> HostDevice=server) results in 1.5 Mbit/sec; and similarly internet provider’s speed test results in 0.1 Mbit/sec for Downloading.

      Why does downloading performance fall drastically when PerfTest runs on Wi-Fi adapter?


      Vadim Smirnov

        PerfTest, being an outdated example, is not recommended for current use. The post you’re referring to briefly explains how using multiple threads in its architecture might lead to reduced throughput. In essence, improper use of multiple threads can cause TCP packet reordering, which in turn can degrade bandwidth.

        To see a modern multi-threaded approach in action, take a look at the queued_packet_filter C++ class in ProxiFyre project source code. This model uses one thread for packet reading, another for processing, and additional threads to inject the processed packets throughout the network stack, both upstream and downstream. Such a framework is conducive to developing robust filtering solutions, even for high-capacity 10 Gigabit networks. Worth noting that I’ve also used this C++ class in the WireSock VPN Client.


          Thanks for the quick reply, I will follow to-day implementation details as you mention for my 1. question.

          What about my 2.question having no concern with multiple-threads?

          Do you have any different recommendation for the 2.question where a single  thread involved in the PerfTest trial regarding Wi-Fi adapter? Is the outdated PerfTest responsible alone for the reduced download speed ( 12 Mbit/sec —> 0.1 Mbit/sec ) on Wi-Fi adapter?

          Vadim Smirnov

            Is the outdated PerfTest responsible alone for the reduced download speed ( 12 Mbit/sec —> 0.1 Mbit/sec ) on Wi-Fi adapter?

            Could you conduct the test again, this time utilizing more modern example like dnstrace? It provides a limited console output, exclusively parsing DNS packets, and is unlikely to adversely affect network performance.


              I conducted the test again using “dnstrace” example without modifying the source code. When  the WinpkFilter is loaded but not any interface is selected; my internet provider’s speed test results in

              Download: ~ 14.5 Mbit/sec

              Upload: ~2.5 Mbit /sec

              After I selected Wi-Fi interface in “dnstrace”; bandwidth became:

              Download: ~ 3 Mbit/sec

              Upload: ~2.3 Mbit /sec

              Download speed is about one fifth of the speed without running dnstrace. Do you have any idea about this result ? How can I deploy winpacketfilter without any performance degredation on Wi-Fi adapter ?

              Vadim Smirnov

                I lack sufficient information about your setup and the tools you use for measurements. The issue could stem from various sources, such as incorrect measuring software or conflicts with low-level software installations. To troubleshoot effectively, I recommend conducting tests on a fresh system. Alternatively, consider disabling any virtual bridges or software switches from virtualization software like Hyper-V, VirtualBox, or VMWare.

                Out of curiosity, I conducted a similar test on my LG Gram Windows 11 laptop equipped with an Intel(R) Wi-Fi 6E AX211 adapter, using the Speedtest website. Here are the results: without dnstrace active and with it enabled.


                  OS: Win 10 Pro 64-bit (10.0, Build 19045)
                  Processor: Intel(R) Core(TM) i5-6300U CPU  2.40GHz (4 CPUs)
                  Memory: 20480MB RAM

                  Wi-Fi Adapter: Intel(R) Dual Band Wireless-AC 8260
                  Protocol: Wi-Fi 4 (802.11n)
                  Link Speed(Receive/Transmit): 65/65 (Mbps)

                  Vadim Smirnov

                    What method do you employ to measure throughput? Although it’s commonly acceptable to gauge bandwidth using or, relying solely on internet-based services for throughput testing may lack precision. For more accurate results, I suggest setting up another device within your network, ideally connected directly to your wireless router via cable. Configure this device to run iperf3 in server mode. Then, on your laptop, utilize iperf3 in client mode, conducting tests in both direct and reverse orders with a minimum of 8 simultaneous TCP sessions. This approach will yield more reliable and trustworthy results.

                  Viewing 8 posts - 1 through 8 (of 8 total)
                  • You must be logged in to reply to this topic.