Home › Forums › Discussions › General › Performance degradation in different setups whit PerfTest
Tagged: performance, wi-fi
- This topic has 8 replies, 2 voices, and was last updated 10 months, 1 week ago by Vadim Smirnov.
-
AuthorPosts
-
February 20, 2024 at 11:24 pm #13556
Hi all,
I’m testing the performance of ndisapi on my Windows 10 Laptop (HostDevice) using PerfTest project described in “https://www.ntkernel.com/windows-packet-filter-and-gigabit-networks/”.
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?
Thanks.
February 21, 2024 at 12:09 am #13557PerfTest, 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.
February 21, 2024 at 7:17 am #13558Thanks 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?
February 21, 2024 at 8:49 am #13559Is 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.
February 22, 2024 at 2:30 pm #13560I 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 ?
February 23, 2024 at 5:04 pm #13562I 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: https://www.speedtest.net/result/15925878463 without dnstrace active and https://www.speedtest.net/result/15925874186 with it enabled.
February 26, 2024 at 12:30 pm #13571OS: Win 10 Pro 64-bit (10.0, Build 19045)
Processor: Intel(R) Core(TM) i5-6300U CPU 2.40GHz (4 CPUs)
Memory: 20480MB RAMWi-Fi Adapter: Intel(R) Dual Band Wireless-AC 8260
Protocol: Wi-Fi 4 (802.11n)
Link Speed(Receive/Transmit): 65/65 (Mbps)February 26, 2024 at 1:35 pm #13574What method do you employ to measure throughput? Although it’s commonly acceptable to gauge bandwidth using Speedtest.net or Fast.com, 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.
-
AuthorPosts
- You must be logged in to reply to this topic.