Background

#

Home routers are now a staple in nearly every household. With high demand comes a flood of available models on the market. Currently, gigabit routers with shiny “300 Mbps” stickers are all the rage — and most users don’t look into the details: is it really a gigabit, 300 Mbps, or maybe just 100? In reality, around 80% of consumer devices fall short of these advertised numbers. That “gigabit” router likely won’t deliver a true gigabit between WAN and LAN under NAT, and you’ll never squeeze 300 Mbps out of a typical wireless connection in real-world conditions.

But there’s another, more specific issue: these numbers become critically important when it comes to streaming television. And what matters here isn’t just the quantity of megabits, but the quality of that throughput — for several reasons.

Many ISPs deliver streaming TV (IPTV) using multicast. This reduces load on the provider’s infrastructure, minimizes latency, eliminates buffering, and simplifies things for the end-user device, which just needs to show a picture. But this is also where all the downsides of UDP rear their heads: the provider has no way to know if the necessary packet actually reached the client, and the client has no way to request a missing packet again.

Sure, if a single frame is lost, the protocol may recover and you might not notice. But if several frames go missing, or worse — a keyframe — the viewer sees a corrupted image. The more lost packets, the worse the video quality. And in practice, the weakest link is often the home router: if the device’s CPU is overloaded, it’s the incoming UDP packets that get dropped first. Where an online game might just suffer from higher ping, IPTV becomes unwatchable.

Technology keeps evolving. These days, devices with hardware NAT are trending — where the connection tracking and address translation are offloaded to a dedicated chip, reducing CPU load. However, multicast traffic doesn’t benefit from this hardware offload and is still processed by the CPU — which becomes very apparent in certain tests.

Testing method

#

As practice has shown, simply launching a torrent client while watching IPTV isn’t enough to uncover the kinds of issues described above. That approach doesn’t reliably simulate the peak loads that stress consumer routers in a meaningful way.

What was really needed was a set of synthetic tests — controlled, repeatable conditions that could clearly demonstrate whether a device can handle peak multicast load while under pressure. These tests allow us to remove ambiguity and evaluate routers in a deterministic way: will the device drop packets when the CPU is under strain? Will IPTV remain smooth under real-world multitasking scenarios?

Only with such targeted testing can we confidently say whether a given router is up to the task — or if it’s going to let you down right when your favorite show airs.

Each test was designed as a 10-minute session divided into two logical phases.

At the start of the test, three multicast streams are initialized with bitrates of 3750 kbps, 5000 kbps, and 8000 kbps. Each stream simulates a full session: the client sends an IGMP join request, and the server responds with a UDP stream containing pseudo-MPEGTS packets. For the first 30 seconds, no additional load is introduced — this baseline period is used to measure packet delivery timing and ensure the device handles clean multicast traffic without issues.

Starting at the 30-second mark, stress testing begins: the client opens N concurrent connections (simulating torrent-like load) to introduce significant background traffic. These connections are meant to strain the router’s CPU and network stack, revealing whether it can handle real-world multitasking — IPTV plus heavy data traffic.

Throughout the entire test, the client also sends continuous ICMP pings to the server. These measurements are recorded and visualized in the resulting graphs to highlight latency spikes and dropped packets under load.

Test Types

#

By Physical Connection Type

#

LAN (Ethernet)

#

These tests were conducted using wired connections to the router’s Ethernet ports in order to simulate typical home usage: WAN port connected to the internet, and LAN ports connected to local clients. In this setup, the load-generating traffic passed through NAT, while multicast traffic utilized the router’s IGMP proxy capabilities. The expectation was that IGMP snooping would properly forward incoming UDP packets from the WAN interface to the correct LAN interface for the client.

This configuration closely mirrors real-world IPTV usage and provides insight into how well the router handles hardware acceleration (e.g., hardware NAT) versus CPU-based multicast processing.

WLAN (Wi-Fi)

#

This test mirrored the LAN setup, with one key difference: only the WAN port was physically connected, while the client device was connected via Wi-Fi. This test was intended to simulate IPTV over wireless, with the same stress traffic applied.

It’s worth noting that although these Wi-Fi tests were initially run across nearly all devices, they were later mostly phased out. The reason: if a router could handle the full load under Ethernet, it would almost always perform adequately over Wi-Fi as well — provided the wireless signal was strong. These tests tend to reveal issues with the radio link rather than the hardware or firmware, and the internet is already full of benchmarks for Wi-Fi performance in popular consumer routers.

As a result, Wi-Fi testing was de-emphasized in favor of more informative Ethernet-based scenarios.

By Load Type

#

Long-Connections

#

In this mode, when the load is initiated (see above), N connections are established from the client device to the server. For each connection, a buffer size of X is set. The client then starts sending M packets towards the server, and the server sends M packets towards the client, creating bidirectional traffic. The time spent on this cycle is recorded, after which the transmission repeats. The lifetime of each connection equals the duration of the entire test.

Short-Connections

#

As in the previous case, when the load is initiated, N connections are established from the client device to the server. For each connection, a buffer size of X is set. The client sends M packets towards the server, and the server sends M packets towards the client, after which the connection is closed. The time spent on a full cycle is recorded, and a new connection is established. The number of active connections is maintained at the level declared in the test.

By Buffer Size

#

64B

#

The reception/transmission buffer X (see above) is set to 64 bytes, and the number of packets M is 8. In this case, a full cycle consists of transmitting 512 bytes, first in one direction and then in the other.

64KB

#

The reception/transmission buffer X is set to 64 kilobytes, and the number of packets M is 1. In this case, a full cycle consists of transmitting a total of 128 KB of data (64 KB from the client to the server, and 64 KB from the server to the client).

By Number of Concurrent Connections

#

Each test was performed in 3 modes: 10, 100, and 1000 concurrent connections.

By Maximum Speed

#

It is also worth noting that some gigabit models were tested in two modes: initially, all tests were conducted with the physical ports enabled in 100-megabit mode, and then the ports were switched to gigabit mode, repeating the full set of tests. Why? First, it turned out that most subscribers are connected to 100-megabit ports on switches, so this mode of operation is the most relevant. Secondly, unfortunately, most home devices marketed as “gigabit routers” struggle with actual gigabit speeds. Many begin to lose packets with loads over 200 Mbps, and some, particularly successful models, can handle streams of 500-700 Mbps. Not to mention that during load testing with 1000 connections and a total stream of 1 gigabit, IPTV on these devices is virtually impossible. In any case, these tests are also presented in the table, where the device name is followed by “(GB).”

Results

#

All graphs are available in the main table; you can review them and draw your own conclusions.

Currently, the following models are presented in the table:

• Asus RT-AC66U
• D-Link DIR-300 (rev. B7)
• D-Link DIR-300 (rev. C1)
• D-Link DIR-615 (rev. K1)
• D-Link DIR-651 (rev. A2)
• D-Link DSR-1000N
• Huawei WS329
• TP-Link Archer C7
• TP-Link TL-WDR3500
• TP-Link TL-WDR3600 N600
• TP-Link TL-WDR3600 N600 (GB)
• TP-Link TL-WDR4300 N750
• TP-Link TL-WDR4300 N750 (GB)
• TP-Link TL-WR710N
• TP-Link TL-WR741N rev. 1.4
• TP-Link TL-WR741ND rev. 4.20
• TP-Link TL-WR840N
• TP-Link TL-WR840N rev. 1.0
• TP-Link TL-WR841N rev. 8.2
• TP-Link TL-WR841ND rev. 8.1
• Ubiquiti AirRouter
• Zyxel Keenetic — rev. A
• Zyxel Keenetic Giga
• Zyxel Keenetic Lite — rev. A
• Zyxel Keenetic Lite — rev. B