Netduma Fraser

You should delete the first profile and for the second then apply it to LAN1 as well and see if that fixes it. 

There isn't a new firmware currently, the firmware pinned to the top of the Early Access sub forum is the latest

You're saying the ONT requires VLAN 10, does that mean the ONT is actually set to use 10 for VLAN? If so then you do not need to input this into the R3 as well. 
How often are you disconnecting? When it happens again please grab the logs from Settings prior to rebooting and we can take a look.

Added

Disable Speed Test Bypass first of all and then re-test but it looks like you just need to re-tune the percentages to find what works best for you to keep the ping low. There are lots of variables when networking so it won't always be a case of the same settings working 100% of the time.

We'll need some more information, do you get the same high ping directly connected to your ISP modem/router for example? Are you using the Geo-Filter?

I've given you Early Access so you can try that version to see if it works better but with the Geo-Filter enabled do you notice a blocked icon on the map? (Zoom out fully) If so, add that to your allow list and try again to connect, does it work then?
https://forum.netduma.com/forum/151-netduma-r3-early-access/

I appreciate all the help an responses. I'll definitely tune in tomorrow sometime an get on an follow the steps on your video. Taken the boat out tomorrow offshore an getting some fishing in, finally got some decent weather offshore. 

Yes playing on a further away server is likely to worsen your jitter.
No, the Geo-Filter and your bufferbloat test are not connected. 
The Geo-Filter shows game servers you connect to, it is highly unlikely to show the bufferbloat server you're using. The bufferbloat server could be anywhere, that's the point, doing the test at different times of the day could have you connecting to different servers and therefore getting different results. This is why I as well as Darkness said not to put too much emphasis on its results. Yes it is testing your network utilizing a server for the test. Here is an analogy for you.
Your ping without bufferbloat is like driving your car on an empty road, you're going to a location and you know how long it will take you to get there, for example 20 minutes. This could be your baseline ping for example 20ms. 
Your ping with bufferbloat is like driving your car on a road with traffic, you're going to the same location and you know how long it should take you to get there (e.g. the 20 minutes), however due to the bad traffic it actually takes you 40 minutes to get to the same destination. Your ping here could be 40ms for example.
In regards to the server the bufferbloat test is using, without a destination to test it against you can't get a ping value or a destination to drive to. Now imagine your place of work changed depending on the time of day and the time you start work changes as well therefore it could take you anywhere from 10 minutes to 1hr to get there. Would you be so confident to say that it takes you 10 minutes to commute to work everyday? Without knowing the server the bufferbloat test is using your results cannot be 100% trusted. That's why the pingplotter suggestion is better, you know the exact server you're using, you do a test to establish your baseline ping (ping without bufferbloat) and then apply traffic and your ping raises, just like road traffic extends your journey time and then you apply Congestion Control to limit the effect that traffic has on your ping. 
There really isn't anything else we can advise honestly:
You've established it's an issue without the R3 - that automatically eliminates us personally from needing to troubleshoot with you We've advised you select the closest possible servers, this will help lower the ping and improve stability (jitter) We've advised you on how to effectively test and set your Congestion Control percentages to lower your ping and improve stability when bufferbloat would ordinarily apply

Oui, merci
Je viens de changer de firmware et tout va comme il se doit.
 

I think fine tuning Congestion Control in the way I mentioned would get you a better result, try that out and if not we can try to dive deeper into it

We don't give out ETAs as you know, once the team finalize a build they're happy with they will make the selections from the poll topic and add them to the group

Yes playing on a further away server is likely to worsen your jitter.
No, the Geo-Filter and your bufferbloat test are not connected. 
The Geo-Filter shows game servers you connect to, it is highly unlikely to show the bufferbloat server you're using. The bufferbloat server could be anywhere, that's the point, doing the test at different times of the day could have you connecting to different servers and therefore getting different results. This is why I as well as Darkness said not to put too much emphasis on its results. Yes it is testing your network utilizing a server for the test. Here is an analogy for you.
Your ping without bufferbloat is like driving your car on an empty road, you're going to a location and you know how long it will take you to get there, for example 20 minutes. This could be your baseline ping for example 20ms. 
Your ping with bufferbloat is like driving your car on a road with traffic, you're going to the same location and you know how long it should take you to get there (e.g. the 20 minutes), however due to the bad traffic it actually takes you 40 minutes to get to the same destination. Your ping here could be 40ms for example.
In regards to the server the bufferbloat test is using, without a destination to test it against you can't get a ping value or a destination to drive to. Now imagine your place of work changed depending on the time of day and the time you start work changes as well therefore it could take you anywhere from 10 minutes to 1hr to get there. Would you be so confident to say that it takes you 10 minutes to commute to work everyday? Without knowing the server the bufferbloat test is using your results cannot be 100% trusted. That's why the pingplotter suggestion is better, you know the exact server you're using, you do a test to establish your baseline ping (ping without bufferbloat) and then apply traffic and your ping raises, just like road traffic extends your journey time and then you apply Congestion Control to limit the effect that traffic has on your ping. 
There really isn't anything else we can advise honestly:
You've established it's an issue without the R3 - that automatically eliminates us personally from needing to troubleshoot with you We've advised you select the closest possible servers, this will help lower the ping and improve stability (jitter) We've advised you on how to effectively test and set your Congestion Control percentages to lower your ping and improve stability when bufferbloat would ordinarily apply

Thank you I appreciate it 

The bufferbloat test isn't the best way to determine values, 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.
Doing the screensharing is more bandwidth intensive, that's why following this guide and instructions is better as you make your network essentially as bad as it could possibly get and then apply settings incrementally to determine what best brings your network as close as possible to its baseline.

Good to hear! I've given you Early Access https://forum.netduma.com/forum/151-netduma-r3-early-access/ if you'd like to try that to see if DumaOS allows access again.

The interface is wholly loaded from your specific router, no connection to us to make that happen. Are you able to access using 192.168.77.1 through your web browser?

No we don't but good question!

There is a cloud update rolling out now that includes support for FC26 so by the end of the week you should notice it being detected

I think he is pointing to network processing unit, not AI capable hardware which in this case is irrelevant.

I wouldn't worry about that test specifically, instead 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 will be more of a real world test.

It's already available as an option to choose when using a PC. If you're using a console it will only add as a console, you don't pick the specific game.

As in typically even in GPU for Pc most people don’t upgrade every gen unless massive improvements for example 20-30 series had biggest improvement and 30-40 and 50-60 series  raw performance isn’t a lot more .
obviously time between the router models are longer as we see when the Duma R3 was released vs R2. So when we have a R4 released if the improvement is 10% vs R3 most people wouldn’t see a point to upgrade for  whereas if the improvement is a lot higher around 40% or more many people will purchase due to the price to performance also despite being more expensive than. A R3 Hope it makes sense 

Good advice above! We'll be doing more cloud updates including addressing the Oklahoma servers always appearing

You'd have to have the Unify at the top so it can control the network with it's QoS and then the R3 connected to it for the Geo-Filter aspect. I don't think it's necessary to do so and would be better to use the R3 for both functions