Jump to content
Reminder, starting today you will no longer be able to login to the forum using your display name, to login you must now use your email address. ×

SmartQoS Version 2 is unfair!!!


Recommended Posts

Just wanted to share my own experiences with the beta firmware.  I'm using 3.3.347.

This is what I found works well for me and is mostly duplicated from other posts.  My use might be a little different than others, my Netduma R2 is only for one PC and only for gaming.  I use another router for everything else.

I set the max speeds in Netduma to 200 down / 8 up. I've got a 400mbit download / 12mbit upload from Xfinity (Cable). So roughly half to two-thirds of the actual speed.

In Smart QOS -
- permanently added COD
- permanently added Gaming Console
- I've set the download to 50% and upload to 80% in the QOS sliders. This is in addition to the lower max speeds from the Netduma.

In Network Settings:
- Disabled UPNP
- Added all PC ports to port forwarding (and a few more - 3075-3080 tcp/udp) from https://support.activision.com/articles/ports-used-for-call-of-duty-games

Couple things I test for:
- Ping tests in Netduma result in a A+ in all the categories.
- The NAT Type is Open in Call of Duty Settings -> Network -> show Network (something like this)

When I was testing and playing I didn't see a big difference in the hit registration or overall game latency with just the QOS settings.  What really changed it for me was the move from NAT type Moderate to NAT type Open.  After that it was totally different, sub's killed fast, all bullets seemed to hit.  I presume that it is a combination of all these things that made it work.

Link to comment
Share on other sites

24 minutes ago, Snicklfritz said:

In Network Settings:
- Disabled UPNP
- Added all PC ports to port forwarding (and a few more - 3075-3080 tcp/udp) from https://support.activision.com/articles/ports-used-for-call-of-duty-games

Couple things I test for:
- Ping tests in Netduma result in a A+ in all the categories.
- The NAT Type is Open in Call of Duty Settings -> Network -> show Network (something like this)

When I was testing and playing I didn't see a big difference in the hit registration or overall game latency with just the QOS settings.  What really changed it for me was the move from NAT type Moderate to NAT type Open.  After that it was totally different, sub's killed fast, all bullets seemed to hit.  I presume that it is a combination of all these things that made it work.

For my part I do not use netduma r2 and do not open any ports, upnp is disabled and everything is ok. Never done port forwarding... if it's good for you so much the better

Link to comment
Share on other sites

The reason:

There are three main NAT types depending on your platform: Open, Moderate, and Strict on Microsoft or PC, and Type 1, Type 2, and Type 3 on Sony. Moderate/Type 2 and Strict/Type 3 NAT types limit the connections your gaming console or PC can make to other gaming consoles or PCs. For example, Moderate/Type 2 NATs can only connect with gaming consoles or PCs using Moderate/Type 2 or Open/Type 1 NAT, and Strict/Type 3 NATs can only connect with gaming consoles or PCs using Open/Type 1 NAT. Ultimately, an Open/Type 1 NAT will provide the best connection quality.

Link to comment
Share on other sites

sounds like some of you need to stay off reedit lol, proof is in the pudding boys. test and find out

i will have another video up later today or tomorrow

screen shots from some gameplay from yesterday

117 in plunder

fc346cf4-386c-4785-bc20-628a41eab9a1.jpg

shipment

7bca5bdf-ece7-4046-880a-8dc6eb68620d.jpg

Link to comment
Share on other sites

22 minutes ago, TODDzillaInLA said:

sounds like some of you need to stay off reedit lol, proof is in the pudding boys. test and find out

i will have another video up later today or tomorrow

screen shots from some gameplay from yesterday

117 in plunder

fc346cf4-386c-4785-bc20-628a41eab9a1.jpg

shipment

7bca5bdf-ece7-4046-880a-8dc6eb68620d.jpg

you don't understand it's not your mtu that is at the origin

Link to comment
Share on other sites

On 4/24/2023 at 11:30 PM, TODDzillaInLA said:

smaller mtu manipulates the packet size and makes cod think you have a much slower connection to the server then what you actually do

???? 

360_F_130802984_cVtUhqNTweokXbsyUo4OlravNeGUg9n9.jpg

Link to comment
Share on other sites

18 hours ago, TODDzillaInLA said:

Fuzy how am i wrong when it works for me?

Because you don’t understand what’s going on no matter what’s said. Fragmenting packets for reconstruction within a router is a known no no in the industry and the R2 will badly suffer because it’s a milestone behind 99% of most routers with it’s hardware. 

You can’t blame the hardware though, it’s the end user to blame and quite frankly a simple search would put your mind at rest why fragmenting taxis memory and CPU and slows down the network. 

When every router company explains why fragmentation is bad and remember it’s both ways so in your eyes you are behind because the router is reconstructing before it then continues through the network which puts you at a disadvantage after all latency increases because it takes time for the R2 or any of our routers to put it together. 
 

if you can show me a source link where MTU is one way or where fragmentation is a great idea from any manufacturer I’ll look at it.

 

Link to comment
Share on other sites

What works for one person, may or may not work for others. I do agree, it doesn't make networking sense as to why fragmented or lowered MTU works in this sense. But, the thing is, we are talking about Lag Compensation here. I didn't know what LCE was. But, I did research and there are some papers that actually states how it functions. These papers are not published in a MAINLY computer software engineering, but they do give a a sense of how it functions and the MTU is mentioned. Not only that, we are also including the use of SBMM along with it. So it's pretty interesting nonetheless. The paper I'm referring to is by Yifan Zhu published '22

https://ieeexplore.ieee.org/document/9921990

But here's actual Lag Compensation for 'Multiplayer' gaming by Gabriel Gambetta

https://www.gabrielgambetta.com/lag-compensation.html

We are all just trying to find ways to make our online gaming experience enjoyable.

Less Stress, More Fun.

Link to comment
Share on other sites

7 hours ago, TODDzillaInLA said:

smaller mtu manipulates!!! crazy how you guys get stuck on one thing and ignore the whole picture lol

Only in your mind. All those packets arrive at about the same time and the servers are far more equipped to build those fragmented packets where as your router can’t. 

Some gamers have a particular outlook for trying to achieve better results. So my question is for you.

How much latency from incoming fragmented packets add to your side as MTU is both ways so in your eyes it makes it slower for you to receive packets too. 
 

I think looking at your posts you think MTU is a one way trip to the servers. So again can you show any source that shows that. 
 

 

Link to comment
Share on other sites

16 hours ago, TrayDay said:

What works for one person, may or may not work for others. I do agree, it doesn't make networking sense as to why fragmented or lowered MTU works in this sense. But, the thing is, we are talking about Lag Compensation here. I didn't know what LCE was. But, I did research and there are some papers that actually states how it functions. These papers are not published in a MAINLY computer software engineering, but they do give a a sense of how it functions and the MTU is mentioned. Not only that, we are also including the use of SBMM along with it. So it's pretty interesting nonetheless. The paper I'm referring to is by Yifan Zhu published '22

https://ieeexplore.ieee.org/document/9921990

But here's actual Lag Compensation for 'Multiplayer' gaming by Gabriel Gambetta

https://www.gabrielgambetta.com/lag-compensation.html

We are all just trying to find ways to make our online gaming experience enjoyable.

Less Stress, More Fun.

It’s because MTU works both ways. So for example the server can reconstruct those packets far quicker than what our routers can and packets can and will end up being dropped through errors. 
I can see why he thinks it’s arriving slower but it does not work that way as it’s a 2 way trip which he forgets about so incoming traffic needs to be sorted. Not only that but if it’s the main network all traffic incoming and out going is effected by the MTU value which on his side has further impact as everything is being handled by a limited CPU and memory capacity. Remember the router has to assign resources and that’s not great.

here’s a post that tells a bit more about UDP.

https://community.cisco.com/t5/routing/udp-fragmentation/td-p/4412567

 

 

 

Link to comment
Share on other sites

To be honest, I was just waiting for someone to notice... But anyway the MTU value change on the latest R2 FW.347 is just not taken into account. (Does not work anymore)

image.thumb.png.808d0cb77f0fbbb85b0285e34bc12edc.png

You can put zero if you like......

Link to comment
Share on other sites

30 minutes ago, Fuzy said:

To be honest, I was just waiting for someone to notice... But anyway the MTU value change on the latest R2 FW.347 is just not taken into account. (Does not work anymore)

image.thumb.png.808d0cb77f0fbbb85b0285e34bc12edc.png

You can put zero if you like......

What do you think the default value is? That’s a bug that needs fixing.

Link to comment
Share on other sites

1 minute ago, Newfie said:

What do you think the default value is? That’s a bug that needs fixing.

I was too lazy to look behind the R2's WAN, but I think it still defaults to 1500 (ethernet). If it can prevent the gullible user from breaking their network by doing anything, just leave it like that!

Link to comment
Share on other sites

1 hour ago, Newfie said:

What do you think the default value is? That’s a bug that needs fixing.

For the sake of conscience I checked, and the MTU remains by default regardless of the modification on the R2 side ... As I thought!

Link to comment
Share on other sites

1 hour ago, Fuzy said:

I was too lazy to look behind the R2's WAN, but I think it still defaults to 1500 (ethernet). If it can prevent the gullible user from breaking their network by doing anything, just leave it like that!

Thanks for the info. Might be worth noting it to Fraser as some isps tend to have different values. 

Link to comment
Share on other sites

12 minutes ago, Newfie said:

Thanks for the info. Might be worth noting it to Fraser as some isps tend to have different values. 

Could you also look on your side, I would like to have a second opinion? If you still have the R2 on hand!

Link to comment
Share on other sites

  • 2 weeks later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...