Title: Ookla Speedtest is unstable + bufferbloat spikes (VDSL2 Super Vectoring / PPPoE)

[Sergejs Kotovs]

Hi guys,

I’m using a NetDuma R3 on VDSL2 Super Vectoring (Annex with PPPoE. My line is stable (no disconnects), but I’m struggling with unstable download speeds in browser Speedtests and bufferbloat spikes, and my games still feel laggy.

Setup / QoS

• Ping Optimizer enabled

• Download cap: 95%

• Upload cap: 90%

• Bandwidth in R3 is set around 250 Mbps down (my plan is ~250/40).

What I see

• R3 built-in Speedtest (inside router UI):
  Results are stable and consistent almost every run.

• Ookla Speedtest in browser (same PC, wired):
  Download speed is very unstable, even within the same test:

  • fluctuates around 170–180 Mbps, then goes up to 200–210, then drops again, etc.

  • I would expect about ~237 Mbps with a 95% cap, but it never holds steady.

• Bufferbloat / latency under load:
  During download load, latency sometimes spikes up to +100 ms.
  Upload seems mostly okay.

Notes

• MTU: I tested path MTU with Windows ping:

  • ping 1.1.1.1 -f -l 1464 works

  • ping 1.1.1.1 -f -l 1472 fails (“fragmentation needed, DF set”)
    So it looks like MTU 1492 (PPPoE) is correct.

Question

Why would the R3 internal Speedtest be stable, but Ookla browser Speedtest fluctuates heavily and I still get bufferbloat spikes on download even with Ping Optimizer and only a small bandwidth reduction?

What should I check/change on the R3 (QoS settings, congestion control behavior, traffic prioritization rules, speedtest method/servers, PPPoE overhead, etc.) to get stable throughput and low latency under load?

Thanks!

[Netduma Fraser]

Is the R3 handling PPPoE or your ISP modem/router? For Bufferbloat it's just the Congestion Control percentages you need to change, don't rely on what Ping Optimizer says is the best as it's not always 100% reliable - it's also a direct test from the router itself so unaffected by other devices

[Sergejs Kotovs]

Hi Fraser, thanks.

Yes, the R3 is doing the PPPoE login — my ISP username/password are entered on the R3 (R3 = main router / NAT / DHCP).
Upstream I use a pure modem/ONT in bridge mode, then the R3.
I also have a Foulan Tech / Faulantec 7 (VLAN ID/tag) configured for my ISP connection.

So PPPoE is handled by the R3, not the ISP modem/router.

[Sergejs Kotovs]

Also just to clarify:

In Network Speedtest / Bandwidth Settings I’ve entered my exact line rates: 250 Mbps down / 39 Mbps up.

Even with Ping Optimizer enabled (and the Congestion Control it suggests), my browser Ookla speedtest download fluctuates a lot and I still see download bufferbloat spikes.

So I’m not sure if Ping Optimizer is working correctly, or if I’m using it wrong.
Should I ignore the Ping Optimizer recommendation and manually tune Congestion Control? If yes, what would be a good starting point for 250/39 PPPoE and how should I test it properly?

[Sergejs Kotovs]

One more important detail:

I know my line capacity very well.
With other routers on the same VDSL line, Ookla Speedtest is always stable:

• Download: typically 258–261 Mbps (±2–3 Mbps)

• Upload: 39–39.5 Mbps almost every run

So the instability only appears when using the NetDuma R3.
The ISP line itself is stable and this is reproducible across multiple tests and routers.

That’s why I’m trying to understand whether this is related to Ping Optimizer / Congestion Control behavior on the R3, or if there’s a specific way it should be configured for PPPoE VDSL to avoid fluctuating download speeds and bufferbloat.

[Sergejs Kotovs]

To explain the core issue more clearly:

If my bandwidth is set to 250 Mbps, and I apply Ping Optimizer at 95%, I would expect around ~235–238 Mbps on download.

Instead, during Ookla Speedtest, download speed often drops much lower than the configured limit, sometimes down to 170–180 Mbps, fluctuating heavily within the same test — while at the same time I still see download bufferbloat / queue build-up.

So it feels like the R3 is over-throttling the download, but not preventing congestion, which seems contradictory.

Is this expected behavior of Ping Optimizer / Congestion Control on PPPoE, or does it indicate a misconfiguration or a bug?

[Netduma Fraser]

Yes ignore its recommendation and fine tune Congestion Control manually to see if you can get better results. Follow this guide https://support.netduma.com/frequently-asked-questions/legacyfaqs/test-your-ping/ while downloading & start with 95% for Congestion Control (set to Always), check results, decrease by 10%, check, decrease by 10% etc, until you get to a value that is pretty good & then try 5% either side of that value to see if it can be improved. Download & Upload on Congestion Control don't have to be the same value & you may have a better experience with differing values.

It could be the combination of PPPoE & VLAN, do the test as above see how you get on and if it continues then have your foulan handle PPPoE/VLAN instead of the R3 and see if you get better results that way.

[Sergejs Kotovs]

Let me clarify the issue clearly.

My internet connection is stable and the bandwidth is manually and correctly set to 250 Mbps down / 39 Mbps up.
This is not about auto recommendations — please ignore Ping Optimizer recommendations entirely.

The problem is that Congestion Control / Ping Optimizer does not work proportionally.

Specifically:

• Whether I set Download to 95%, 85%, or even 50%

• the actual throughput during bufferbloat / real traffic tests stays roughly the same (around 130–140 Mbps)

• while latency under load still increases significantly (+50 to +100 ms)

So lowering the percentage does not reliably reduce throughput nor prevent queue build-up.
The percentage values do not behave as expected.

Important detail:

• The built-in speedtest inside the R3 interface is always stable and consistent

• The issue appears only with real external traffic / external speedtests

My question is:
Why does Congestion Control not properly control real traffic, even though bandwidth is set correctly and the internal test is stable?

[Sergejs Kotovs]

Please read the issue carefully and respond to the actual problem, not with a rushed “try +5% / -10%” tuning suggestion.

We’ve been dealing with DumaOS QoS for a long time and we’ve already done the basic troubleshooting repeatedly. The problem is not that we don’t understand how percentages work — it’s that the percentage changes do not produce the expected effect at all.

In my case, changing Congestion Control from 95% to 85% to 50% does not scale the real throughput as it should, and it does not reliably stop latency/queue build-up under load. So “adjust the percentages” is not an answer here — it’s exactly what’s failing.

 

[Sergejs Kotovs]

I’ll be blunt.

I don’t think there’s any point in waiting anymore.

I’ve tested this extensively, and it’s very clear what’s happening: the hardware simply can’t handle it.
During real traffic, the CPU gets overloaded, and once that happens, Congestion Control completely falls apart.
Shaping becomes inconsistent, queues build up, latency explodes — it just does not work as advertised.

This is not about settings, percentages, or tuning.
I’ve already tried all of that — repeatedly. Anyone seriously using your routers has.

I’ve bought multiple Duma routers over the years. I even sold previous units privately because I kept thinking maybe the next firmware or revision would finally fix things. I bought the R3 again recently hoping something had changed. It hasn’t.

At this point it’s obvious to me that this is a hardware limitation, not a configuration problem. And if the hardware can’t reliably shape real-world traffic without maxing out the CPU, then no amount of firmware tweaking is going to fix it.

So I’m asking directly:
Is there actually a real solution coming, or should I just return the router?

If the honest answer is “this can’t be fixed on this hardware”, then please tell me how to proceed with a return, because there’s no reason to keep waiting.

[Sergejs Kotovs]

11 hours ago, Netduma Fraser said:

Да, игнорируйте рекомендации и настройте управление перегрузкой вручную, чтобы посмотреть, сможете ли вы добиться лучших результатов. Следуйте этому руководству: https://support.netduma.com/frequently-asked-questions/legacyfaqs/test-your-ping/ во время загрузки и начните с 95% для управления перегрузкой (установите значение «Всегда»), проверьте результаты, уменьшите на 10%, проверьте, уменьшите на 10% и т. д., пока не получите достаточно хорошее значение, а затем попробуйте значения на 5% в обе стороны от этого значения, чтобы посмотреть, можно ли его улучшить. Значения для загрузки и выгрузки в управлении перегрузкой не обязательно должны быть одинаковыми, и вы можете получить лучшие результаты, используя разные значения.

Возможно, проблема в сочетании PPPoE и VLAN. Проведите тест, как описано выше, посмотрите, что получится, и если проблема сохранится, то пусть ваш маршрутизатор Foulan обрабатывает PPPoE/VLAN вместо R3, и посмотрите, получите ли вы лучшие результаты таким образом.

Please read the issue carefully and respond to the actual problem, not with a rushed “try +5% / -10%” tuning suggestion.

We’ve been dealing with DumaOS QoS for a long time and we’ve already done the basic troubleshooting repeatedly. The problem is not that we don’t understand how percentages work — it’s that the percentage changes do not produce the expected effect at all.

In my case, changing Congestion Control from 95% to 85% to 50% does not scale the real throughput as it should, and it does not reliably stop latency/queue build-up under load. So “adjust the percentages” is not an answer here — it’s exactly what’s failing.

[Sergejs Kotovs]

11 hours ago, Netduma Fraser said:

Yes ignore its recommendation and fine tune Congestion Control manually to see if you can get better results. Follow this guide https://support.netduma.com/frequently-asked-questions/legacyfaqs/test-your-ping/ while downloading & start with 95% for Congestion Control (set to Always), check results, decrease by 10%, check, decrease by 10% etc, until you get to a value that is pretty good & then try 5% either side of that value to see if it can be improved. Download & Upload on Congestion Control don't have to be the same value & you may have a better experience with differing values.

It could be the combination of PPPoE & VLAN, do the test as above see how you get on and if it continues then have your foulan handle PPPoE/VLAN instead of the R3 and see if you get better results that way.

I’ll be blunt.

I don’t think there’s any point in waiting anymore.

I’ve tested this extensively, and it’s very clear what’s happening: the hardware simply can’t handle it.
During real traffic, the CPU gets overloaded, and once that happens, Congestion Control completely falls apart.
Shaping becomes inconsistent, queues build up, latency explodes — it just does not work as advertised.

This is not about settings, percentages, or tuning.
I’ve already tried all of that — repeatedly. Anyone seriously using your routers has.

I’ve bought multiple Duma routers over the years. I even sold previous units privately because I kept thinking maybe the next firmware or revision would finally fix things. I bought the R3 again recently hoping something had changed. It hasn’t.

At this point it’s obvious to me that this is a hardware limitation, not a configuration problem. And if the hardware can’t reliably shape real-world traffic without maxing out the CPU, then no amount of firmware tweaking is going to fix it.

So I’m asking directly:
Is there actually a real solution coming, or should I just return the router?

If the honest answer is “this can’t be fixed on this hardware”, then please tell me how to proceed with a return, because there’s no reason to keep waiting.

[Netduma Fraser]

It's not my conclusion that its a hardware issue currently, I mentioned what the next steps would be to see if you experience the same behaviour, sounds like you did the first part to determine that changing the Congestion Control values did not make any real differences so now: 

"It could be the combination of PPPoE & VLAN, do the test as above see how you get on and if it continues then have your foulan handle PPPoE/VLAN instead of the R3 and see if you get better results that way."

This will give us a clear indication of whether your connection method is impacting regular functioning and devs can be notified if that is the case.

[Sergejs Kotovs]

5 hours ago, Netduma Fraser said:

It's not my conclusion that its a hardware issue currently, I mentioned what the next steps would be to see if you experience the same behaviour, sounds like you did the first part to determine that changing the Congestion Control values did not make any real differences so now: 

"It could be the combination of PPPoE & VLAN, do the test as above see how you get on and if it continues then have your foulan handle PPPoE/VLAN instead of the R3 and see if you get better results that way."

This will give us a clear indication of whether your connection method is impacting regular functioning and devs can be notified if that is the case.

I understand that one possible workaround is to offload PPPoE and VLAN processing to another router in order to reduce the load on the R3.

However, in that case the R3 no longer operates as a router but effectively as an IP client behind another gateway. This introduces double NAT, and my provider router does not support DMZ or similar features to avoid this. Using a second router should not be a requirement.

From a technical perspective, this behavior is understandable. With PPPoE and VLAN, packets must be decapsulated and processed in software, and when QoS / congestion control is active, all traffic is forced through the CPU. At higher throughput and packet rates, the CPU becomes the bottleneck regardless of whether bandwidth limits are set to 90%, 95% or even 100%.

For this reason, the R3 cannot function as a primary router.
 

[Krush]

C'est quoi le but ? Désinformation...

Derrière une connexion médiéval PPPoE/VLANID à - de 300Mbps, le CPU ne peut pas être sous charge ... Sachant que DumaOS/SmartBoost n'a pas besoin de l'accélération matériel pour fonctionner !

🙃

Que répond L'IA ?

 

 

 

[Netduma Fraser]

If it has the ability to port forward then double NAT can be avoided, even if it doesn't the R3 has UPnP relay to attempt to alleviate that problem in situations like that. You've landed on the CPU being overworked/being the cause which isn't necessarily the case (more would need to be done to determine if it was), each core is dedicated to a specific purpose, them being raised just means they're working in tandem which is what you'd expect. Just like a PC, your CPU/GPU can max out but your game is still smooth. Either way you've expressed a wish to proceed with a different path so we'll continue in emails.

[Krush]

... Une double NAT sachant naviguer derrière un relais UPnP doit savoir NAT "simplement " sans se dédoubler !

[Sergejs Kotovs]

Hi,

Quick update from my side.

Instead of using the Speedport Smart 4 in pure modem mode, I replaced it with a Vigor 167.
VLAN Tag 7 is now configured directly on the Vigor, IPv6 is disabled, and the Netduma R3 is connected behind it.

After making these changes, the behaviour improved significantly:

• Speed tests are consistent

• Bufferbloat results are clean

• CPU usage on the R3 is much more stable

• No more major throughput drops during testing

With this setup, everything is now performing as expected.

For the moment, I will continue using the Netduma R3 with this configuration. I genuinely like the concept and features of the R3, which is why I have been testing different setups to make it work optimally in my environment.

I will monitor stability over the next few days. If future firmware updates further optimise PPPoE/VLAN handling or overall efficiency, that would of course be welcome.

For now, I am staying with the R3.

 

[Netduma Fraser]

Good to hear you're seeing much better results after switching the setup, thanks for providing an update with your results, I will pass your experience on to the team so they can look into this more.