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.