@Asmodeus83 

Interestting. My isp has its own speedtest website on the same fast server kpn . com / internet / speedtest

Wi-Fi 7:

6 GHz 160 MHz 802.11be: 2132 / 2013 Mbps

6 GHz 320 MHz 802.11be: 3276 / 1313 Mbps

Seems the updates have broken the 320 MHz mode on upload. As you already explain, its overflowing.

@Joseph-TP testing with old firmware below.

When i first bought it all the speedtests did 3800 / 3800 Mbps.

Archer BE800_V1_1.0.6_230706 firmware:

6 GHz 320 MHz 802.11be: 2687 / 2716 Mbps

Archer BE800_V1_1.0.9_230914 firmware:

6 GHz 320 MHz 802.11be: 2816 / 2900 Mbps

Long story short: Someone buy the BE800 developers a Samsung S24/S25/S26 Ultra so they can properly code the Wi-Fi driver.

  @5Guru 

I've been closely following your tests and I completely get where you're coming from.

I want to share some thoughts regarding official support and why waiting for a "miracle firmware" that will fix everything is no longer worth it. Just the other day, I finally closed my six-month-old ticket with TP-Link engineers, and they basically admitted what we had already figured out.

Here are a few points so you don't waste your time waiting for nothing:

 - TP-Link doesn't write the wireless driver. They receive a ready-made SDK from Qualcomm with a binary driver. TP-Link engineers physically cannot change the buffer management logic at the chip's microcode level, even if they really wanted to.
- The new 1.4.1 firmware is a workaround in favor of stability. They clearly updated the Qualcomm driver in this latest release. Judging by your tests, Qualcomm took the easiest path: instead of deep optimization, they simply capped the queue limits strictly to keep the router from crashing. Previously, I had to reboot the router regularly after heavy testing, but now it holds up like a rock under tons of traffic. In other words, they sacrificed peak speeds on the 320 MHz band just to keep the hardware from freezing.
- If the chip itself incorrectly handles the degradation of wireless queues when the buffer overflows at the microcode level, TP-Link is powerless. They can only report the bug to Qualcomm and wait for the next SDK release.
- QoS works differently now. They managed to make QoS play nice with Hardware NAT (I verified this personally, and support confirmed it). The fact that enabling QoS eliminates the bottleneck at the 10G/1G junction isn't magic—it's just software shaping that smooths out micro-queues before they overflow the shallow hardware buffers. And it’s great that you can now apply QoS selectively to a single device.

All in all, Qualcomm has delivered everything they were capable of over the past year. Your rollback to older firmware versions proves that this is a pure software regression on the chip manufacturer's side. TP-Link has squeezed the absolute maximum out of this platform, making it at least stable under load. Chasing a perfect speed balance beyond this point is just going to waste your nerves because TP-Link can't fix the driver, and Qualcomm doesn't care anymore. 

On top of that, Wi-Fi 8 is going to be announced very soon, and it's highly likely that all the manufacturers' R&D resources have already been shifted to the new standard.