From FRITZ!Box to TP-LinkBox 7: Measuring What Changes in a Home Network

I replaced the 1&1 FRITZ!Box that came with my DSL line with a TP-LinkBox 7, on the connection I use every day, with a desktop, a ZimaBoard running services and a handful of IoT devices hanging off it.

“Is the TP-LinkBox faster than the FRITZ!Box?” has a dull answer: with a gigabit endpoint both routers sit at the wire limit, so there is nothing to win. What I’m after is what the swap does in a home network with 2.5GbE, a homelab and IoT.

Specifications

There is exactly one 2.5 Gbit LAN port. The moment I want more than a single device on 2.5GbE, a switch stops being optional.

The support commitment until the end of 2031 matters too.

The setup

Before the switch:

• 1&1 FRITZ!Box as the main router, on a 1&1 DSL line
• A desktop with a Realtek Gaming 2.5GbE Family Controller
• A ZimaBoard as the local iperf3 server
• Various clients on 2.4 and 5 GHz Wi-Fi

The 2.5GbE side of this router isn’t really testable yet: every endpoint I can measure against is still gigabit.

Baseline: the FRITZ!Box in gigabit LAN

I took a baseline before changing anything. The old network used 192.168.178.0/24, with the ZimaBoard at 192.168.178.118. Both the desktop and the ZimaBoard were connected at 1 Gbit/s.

I ran the iperf3 server directly on the ZimaBoard:

iperf3 -s

And from the desktop:

iperf3 -c 192.168.178.118 -t 30

Over 30 seconds the single-stream test stayed at 930–950 Mbit/s essentially without dropping, the reverse test at 940–942 Mbit/s. That is practically the maximum of a 1-gigabit link.

The FRITZ!Box was not a bottleneck in gigabit LAN.

For reference, the Wi-Fi link rates the FRITZ!Box reported were 292–650 Mbit/s on 5 GHz and mostly 57–144 Mbit/s on 2.4 GHz. Those are negotiated PHY link rates, not throughput measurements, so they say little about real speed. Actual Wi-Fi throughput tests are on the list below.

Baseline: internet through the FRITZ!Box

Measured on 12 September 2026, around 15:19–15:21, with Ookla Speedtest against DNS:NET Internet Service GmbH, Berlin; the provider shows as 1&1 Versatel.

Internet through the TP-LinkBox 7

Same Ookla server as the baseline, DNS:NET Internet Service GmbH, Berlin. Measured 15 September 2026, around 10:38.

Against the baseline:

Download comes out 8.5% lower, upload 3% lower, and latency 6 ms better under download load.

Before anyone reads a verdict into the download number: the two sets weren’t taken under the same conditions. The FRITZ!Box runs were on 12 September in the afternoon, these on 15 September in the morning. VDSL rates move with line conditions and time of day, and a three-day gap between measurements is enough to account for a difference of this size on its own. This is not a controlled A/B on the DSL side, and I won’t present it as one.

The DSL sync rate is what would settle it, and both routers report it in their web interface. Same sync on both means the line; a lower sync on the TP-LinkBox means the modem. Until I’ve compared those, this table says something about my connection on two different mornings, not about the router.

After the switch

The network now runs on 192.168.1.0/24:

Router / DNS   192.168.1.1
Desktop        192.168.1.19
ZimaBoard      192.168.1.6

The hardware itself feels well made: solid, more substantial than the plastic box it replaces.

The desktop is now connected at 2.5 GbE. Windows reports an aggregated link speed of 2500/2500 Mbps on the Realtek Gaming 2.5GbE Family Controller, so that link works.

It doesn’t help yet, though, because the other end of every test is still a gigabit ZimaBoard.

TP-LinkBox 7 in gigabit LAN

Same tests, new router:

iperf3 -c 192.168.1.6 -t 30

Throughput-wise that is practically identical to the FRITZ!Box. The forward test stayed around 932–952 Mbit/s, the reverse test held 940–942 Mbit/s after the first second. Transfer volume was about 3.29 GB in both the single-stream and four-stream runs.

The four-stream retransmits split across streams as 265 / 397 / 385 / 438. Despite that, total throughput stayed at roughly 940 Mbit/s.

Side by side

On raw throughput there is no meaningful difference, and there can’t be: the ZimaBoard’s gigabit link is the limiting factor in every one of these tests.

The open question: those retransmits

The retransmit counts stand out.

The topology right now:

Desktop (Realtek 2.5GbE)
      │  2.5 Gbit/s
      ▼
TP-LinkBox 7
      │  1 Gbit/s
      ▼
ZimaBoard

My hypothesis is that the retransmits come from the 2.5GbE → 1GbE transition rather than from a fault in the router. The desktop can push data into the TP-LinkBox faster than the box can forward it over the gigabit link to the ZimaBoard, so packets queue and some get dropped and resent. Two observations point that way:

• 2.5G PC → 1G ZimaBoard produces many retransmits; 1G ZimaBoard → 2.5G PC produces zero.
• Four parallel streams produce far more retransmits than a single stream.

That is consistent with a speed-mismatch buffering effect. It is not proof, and at this stage I’m not claiming the TP-LinkBox 7 has packet loss or a network problem. Throughput was unaffected throughout: about 940 Mbit/s either way.

To test the hypothesis, three checks are planned. Rate-limit a single stream below the gigabit ceiling:

iperf3 -c 192.168.1.6 -b 900M -t 30

Rate-limit four streams so their sum stays under it:

iperf3 -c 192.168.1.6 -P 4 -b 225M -t 30

And force the desktop NIC down to 1.0 Gbps full duplex, then repeat the plain test:

iperf3 -c 192.168.1.6 -t 30

If the retransmits disappear in those runs, the 2.5G→1G transition is very likely the cause.

A 2.5GbE home network

Getting past that gigabit ceiling needs two things: a 2.5GbE endpoint to test against, and a switch to put it behind.

I haven’t settled on the size yet. The TL-SG105-M2 (5× 2.5GbE) covers the current build: one port to the router, one to the PC, and enough left for a couple of servers, with the slower gigabit devices hanging off the router directly instead of occupying 2.5G ports.

The argument for an 8-port version is that five ports fill up faster than you’d think once a homelab stops being two machines — a NAS, another server, and the spare port is gone. I’d rather decide that once I know what actually ends up in the rack than buy twice.

Either way the topology is the same shape:

TP-LinkBox 7
│
├── 2.5G → 2.5GbE switch
│           ├── PC
│           ├── 2.5G server
│           ├── further 2.5G device
│           └── spare
│
└── LAN → gigabit devices

With a 2.5GbE endpoint behind that switch, a 2.5GbE test becomes possible:

iperf3 -c <2.5G-host> -t 30

With clean 2.5GbE, real TCP throughput should land somewhere around 2.3–2.4 Gbit/s.

The IoT network

The TP-LinkBox 7 offers a separate IoT network, and I want to find out what it separates before describing it. I plan to test each direction:

IoT → LAN
IoT → internet
IoT → other IoT devices
main network → IoT

Homelab and rack

The longer-term plan is to get the homelab hardware and the switch into a 3D-printed OpenRack. I’m not going to claim the existing STLs fit any of it: the switch in particular needs measuring, and probably custom mounts. If that works out it’s its own article rather than part of this one.

Still to come

What’s outstanding, roughly in the order I’ll get to it:

Further measurements. The DSL sync rate on both routers, which decides whether that 8% download gap is the line or the modem. The retransmit experiment from above: the rate-limited runs plus the desktop forced down to 1 Gbit/s. The IoT network isolation checks. And power draw, since this thing runs around the clock.

Wi-Fi. Wi-Fi throughput measured with iperf3 at a few fixed positions on 2.4 and 5 GHz. MLO with the two Wi-Fi 7 clients I have here, an Olares One and an iPhone 16 Pro.

Homelab features and setup. The VPN server, port forwarding, and whether DNS can be pointed at my own resolver. Plus how the initial setup went on a 1&1 line.

2.5GbE. The 2.5GbE test, once there’s a switch and a 2.5GbE endpoint behind it.

Long-term stability, reboots and firmware updates aren’t a test so much as something that accumulates. I’ll note it if anything breaks.

Three things I’m not going to cover: DECT and the analogue phone port, because I don’t use a landline and never did; EasyMesh, because I have no second node; and USB storage, because a router’s USB port is a poor substitute for the ZimaBoard already sitting next to it.

I’ll update this page as the rest lands, and I’d rather hold off on a verdict until it’s in.