All Activity

Buongiorno, volevo delle informazioni precise riguardo il settaggio del qos, cercando su internet ho visto che è consigliato per le ftth stare tra l 80% e il 90% e non necessariamente stare in bufferbloat a+ questo perché se per raggiungere a+ dovessimo scendere sotto la soglia del 80% in giochi come warzone verrebbe aggiunto un jitter artificiale, che ne compromettere la fluidita e l hit reg del gioco. È reale tutto ciò sapete dirmi qualcosa di concreto

Привет, Краткое обновление с моей стороны. Вместо того чтобы использовать Speedport Smart 4 в чистом режиме модема, я заменил его на Vigor 167. Теперь на Vigor настроен VLAN Tag 7, IPv6 отключен, а за ним подключен Netduma R3. После внесения этих изменений поведение значительно улучшилось: Результаты тестов скорости согласуются между собой. Результаты проверки на заполнение буфера чистые. Использование ЦП на R3 гораздо стабильнее. В ходе тестирования больше не наблюдалось существенных падений производительности. При такой настройке всё работает как положено. На данный момент я продолжу использовать Netduma R3 в этой конфигурации. Мне действительно нравится концепция и возможности R3, поэтому я тестировал различные варианты настройки, чтобы добиться оптимальной работы в моей среде. В ближайшие несколько дней я буду следить за стабильностью работы. Если будущие обновления прошивки дополнительно оптимизируют обработку PPPoE/VLAN или повысят общую эффективность, это, безусловно, будет приветствоваться. Пока что я остаюсь с R3. Скриншоты прилагаются.

New clip just dropped 🎯🔥 Grinding the 50 small map / 25 big map win streak camo. Best so far: 37 straight on small map. 7 on big map. Streak ended by some “final circle hide-a-hackers that turn into full rage hackers” 🤔 We’re looking for: 2 DEMONS for win streak grind 1 for Ranked DM if you’re built for it 💀 — Outsmarted. Outgunned. Out-routed. This is exactly why I run the NETDUMA R3. Low ping. Clean routing. No desync. Instant hit reg. Smooth flow. When your connection is locked in, gunfights feel different ⚡ 🎥 Watch here 👉 https://youtube.com/shorts/jBFP1bu-UT4?si=Fzp1oXRXFdlZ26i0 — 🔗 All Platforms & Links: https://linktr.ee/TODDzillaInLA 🛒 My Setup & Gear: https://amzn.to/4khVx9G 💬 Join the Discord: https://discord.gg/TODDzillaInLA Or Watch Here: 👇 Thanks for watching! 🙏🎥❤️✨

Worth flagging something I’ve just noticed — Sammy-PC has been experiencing repeated BSODs when it is powered on, specifically KERNEL_AUTO_BOOST_INVALID_LOCK_RELEASE and WATCHDOG_VIOLATION, which point to low-level driver issues (likely NIC or power management related). Something I need to look into and fix but that pc is getting old and could be facing electrical degradation. Given that, I’ll disconnect it entirely for a couple of days and leave it powered off to see if the Wi-Fi instability persists. That should help rule out whether it’s acting as a trigger on the LAN side. The only caveat I’ll note is that this PC is powered off ~90% of the time, and I’ve still experienced Wi-Fi instability during periods when it hasn’t been in use. That said, for the sake of proper process of elimination, I’m happy to test with it fully removed for a while. I’ll report back once I’ve had some clean runtime without it connected.

Added, you can find it here: https://forum.netduma.com/topic/58424-new-r3-firmware-dumaos-40645/

MERHABA NETDUMA R3 SON GÜNCELLEMESİ 645 DENEMEK İSTİYORUM

You don't need a VPN for that: Quit the application/game/client completely - including the game client from the System Tray - important! Remove device from the Geo-Filter Give your PC the PlayStation Device Type in the Device Manager Resync from the Geo-Filter Map menu Re-add the device to the Geo-Filter Set up the Geo-Filter how you like Wait 2 minutes Boot up application/game/client To force servers you need to do the following: It's essential the Geo-Filter is enabled before the game client (e.g. Steam etc) if on PC or platform (e.g. Xbox, PlayStation) or the game have been launched. If you change Geo-Filter settings when you're on the game then you will need to restart the game for those changes to take effect, otherwise it will use the previous Geo-Filter settings and appear not to be working. For settings ensure Ping Assist and Geo-Latency are disabled in the Geo-Filter menu that can be found by clicking ⋮ in the top right hand corner of the page and go to Settings. Strict Mode should also be enabled, it is enabled by default so if you haven't disabled it you can ignore it. If you have disabled it or want to check it can be found in the same Settings menu as above or in Settings > Troubleshooting > Advanced > Developer Options depending on your firmware version. Fast Search should also be disabled which it is by default so can be ignored if you haven't changed it, otherwise this can be found in the same place.

How do I do this VPN method? I am UK based and Geofilter worked fine black ops 6, but for black ops 7 on PC I cannot get it to work I keep connecting to French servers and not U.K. Any help would be appreciated as I mainly bought the R3 for the geofilter.

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

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.

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 ?

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.

Do this: Quit the application/game/client completely - including the game client from the System Tray - important! Remove device from the Geo-Filter Give the PC the PlayStation Device Type in the Device Manager Resync from the Geo-Filter Map menu Re-add the device to the Geo-Filter Set up the Geo-Filter how you like Wait 2 minutes Boot up application/game/client To force servers you need to do the following: It's essential the Geo-Filter is enabled before the game client (e.g. Steam etc) if on PC or platform (e.g. Xbox, PlayStation) or the game have been launched. If you change Geo-Filter settings when you're on the game then you will need to restart the game for those changes to take effect, otherwise it will use the previous Geo-Filter settings and appear not to be working. For settings ensure Ping Assist and Geo-Latency are disabled in the Geo-Filter menu that can be found by clicking ⋮ in the top right hand corner of the page and go to Settings. Strict Mode should also be enabled, it is enabled by default so if you haven't disabled it you can ignore it. If you have disabled it or want to check it can be found in the same Settings menu as above or in Settings > Troubleshooting > Advanced > Developer Options depending on your firmware version. Fast Search should also be disabled which it is by default so can be ignored if you haven't changed it, otherwise this can be found in the same place.

@Netduma Fraser still ongoing as well for me. whats more Geo-Filter shows everytime that I'm connecting to Kansas server (LOL) when I'm in the UK and chosen servers in game are EU.

Is it Sammy-PC the device connected to LAN port 3? Are you able to disconnect this for a day or two to see if the WiFi issue persists? It could be relevant, you can connect it to the ISP modem/router instead during this process, obviously not ideal but I think it's important to eliminate it as a potential cause.

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.

No need to create a new topic, I'll close this one and respond to your first topic.

Pas besoin de multiplier les sujets STP ! C’est un comportement normal lorsque tu effectues ce type de test avec la page home ouverte de la GUI. Elle consomme plus de charge CPU. C’est comme effectuer un benchmark de GPU avec un jeu en cours sur un PC … Tu peux effectuer le même test sur un autre onglet de la GUI et nous dire comment se comporte la charge CPU stp 😉

I’m creating a new thread to clearly summarize the real issue, based on extensive real-world testing. My internet connection itself is stable. This is not an ISP or line problem. Bandwidth is set manually and correctly. The core problem is how Congestion Control and Bufferbloat behave under real load. When I reduce bandwidth slightly (for example a small reduction of ~5%), the router behaves as if the bandwidth was reduced massively, sometimes closer to cutting it in half. The reduction is not proportional to the value set. At the same time, bufferbloat testing becomes unreliable: throughput shown in bufferbloat tests is far lower than expected latency spikes heavily under load results fluctuate and look unstable / glitchy real traffic causes spikes, stutter, and lag In other words: small bandwidth changes cause disproportionately large throughput drops, while queue control still fails. Important observations: The built-in speedtest inside the R3 interface is always stable and consistent When QoS / speedtest bypass is enabled, external speedtests immediately become stable and show correct speeds With other routers on the same connection, external speedtests and bufferbloat behave normally and consistently This strongly suggests that under real traffic: the R3 CPU becomes overloaded once the CPU is saturated, Congestion Control no longer works correctly shaping stops scaling properly bufferbloat testing no longer reflects reality This does not look like a tuning issue. All common adjustments have already been tested extensively. The behavior points to a hardware / CPU performance limitation, where the router cannot reliably handle real-world traffic shaping and bufferbloat control at this connection speed. My questions are: Is this non-linear bandwidth behavior and bufferbloat instability under load expected when the R3 CPU is saturated? Is there any real fix or workaround, or is disabling shaping the only realistic option? If this is a hardware limitation, can this be confirmed clearly? The screenshots I attached were taken during active bufferbloat testing.

It looks like Internet Optimiser support for Ultrafast plans is tied to a specific firmware version. For anyone waiting on the activation, I’d suggest keeping a close eye on your Gen 4 modem and checking for firmware updates regularly.

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.

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.

Hey Fraser, I grabbed another set of logs after seeing repeated Wi-Fi issues on my phone (getting messages like “can’t reach 5GHz network”). This seems to line up with moments where Wi-Fi briefly drops or becomes unreachable. Looking through the logs, I noticed several instances where eth3 appears to go down and then back up again in quick succession. From my side, these timestamps seem to correlate pretty closely with when clients lose access to the 5GHz band. There are also some repeated Overwatch warnings around this time, for example: “Unknown netmask; IPv4 broadcast filters will fail to compile” and some cleanup calls failing in com.netdumasoftware.overwatch Not sure if those are expected log noise or if they could be contributing to the instability, but I wanted to call them out in case they’re relevant. For context, this is happening without me running speed tests or the ping optimiser manually — it’s just during normal usage. I’ve already increased DHCP lease time and have been testing QoS both on Auto and Always On to rule out bufferbloat-related behaviour. Let me know if there’s anything specific you’d like me to change, lock down (channels, widths, features), or capture next. Happy to test an EA build as well if that helps narrow it down. Thanks again for the help — really appreciate it. Oh and I changed the DHCP lease like you mentioned. I think my unit at least clearly has some issues going on. It's driving my wife absolutely mad as it's happening to her devices and my tv as well interrupting streams. She is pretty much at the point where she wants me to buy new equipment but I'm still hoping it can be fixed one way or another. R3_2026-02-10T09_24_23.895Z_logs.txt Cheers, Zac

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.

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.