Adel75 up down wan lan thread

[adel75]

Yes but the antijitter specifically in dumaOS is gonna be different because it deals with downstream jitter involved with the host. Maybe even downstream line jitter. Either way that jitter involved in that process. Not LAN jitter

you always have an upstream (WAN) and a downstream (LAN) interface on a router.. you can apply fq_codel , qdisc on both so you affect all direction.

you can even use a netem delay to add artificial latency and control jitter.

 

i doubt that any router will implement an effective remote anti jitter because you can't control the remote side of thing.. (servers, other consoles..) you can only affect your own network and your upstream link saturation. someone could implement some adaptive artificial netem like delay but if someone you are playing with has a 20ms jitter you can't do anything about it unless you add latency to their connection to their worst case (+20ms) which in turn will make your latency looks bad to other players..

 

it is easy to have no jitter in a local controlled environment.. but that's not what internet is nor what a gaming router is aiming for.

what a gaming router is aiming at is to make your connection appear to be a high quality connection so your game  matchmaking "internal scoring" match you with similar good connection players (beside geofilter). but what happen in reality is if your connection is too good (superb latency, nat type 1 ) then you are matched with those nat type 3 because they can only connect to a nat type 1 player....

because : 

- Strict NAT (3) can only match to open NAT (1) people.

- Moderate NAT (2) can only match to moderate and open

- Open NAT (1) can match to everyone

 

so sometime too good is worst .. networking isn't an easy beast.

[Vader]

you always have an upstream (WAN) and a downstream (LAN) interface on a router.. you can apply fq_codel , qdisc on both so you affect all direction.

you can even use a netem delay to add artificial latency and control jitter.

 

i doubt that any router will implement an effective remote anti jitter because you can't control the remote side of thing.. (servers, other consoles..) you can only affect your own network and your upstream link saturation. someone could implement some adaptive artificial netem like delay but if someone you are playing with has a 20ms jitter you can't do anything about it unless you add latency to their connection to their worst case (+20ms) which in turn will make your latency looks bad to other players..

 

it is easy to have no jitter in a local controlled environment.. but that's not what internet is nor what a gaming router is aiming for.

what a gaming router is aiming at is to make your connection appear to be a high quality connection so your game  matchmaking "internal scoring" match you with similar good connection players (beside geofilter). but what happen in reality is if your connection is too good (superb latency, nat type 1 ) then you are matched with those nat type 3 because they can only connect to a nat type 1 player....

because : 

- Strict NAT (3) can only match to open NAT (1) people.

- Moderate NAT (2) can only match to moderate and open

- Open NAT (1) can match to everyone

 

so sometime too good is worst .. networking isn't an easy beast

 

 

Control jitter? how so? As a linux developer my self i know that jitter can be added artifically but even when extra network jitter occurs it would fall within the parameters of the jitter you set would it?

[adel75]

Control jitter? how so? As a linux developer my self i know that jitter can be added artifically but even when extra network jitter occurs it would fall within the parameters of the jitter you set would it?

 

 

 

 

i was indeed replying to someone about dumaOS anti jitter and telling him that if any it will be local jitter control , not remote one.

[Vader]

Ah right i see, the only way to process incoming jitter would be with an Adaptive jitter buffer similar to what Astriek VOIP Application uses but implementing it into the tcp/ip stack through the source code could be problematic. i would be interested in seeing what scripts you run and doing some experiments between us see if we can improve on the current solution.

 

Modifying fq_codel parameters is a thought or implementing a AdaptiveJitterBuffer could be another.

[adel75]

Ah right i see, the only way to process incoming jitter would be with an Adaptive jitter buffer similar to what Astriek VOIP Application uses but implementing it into the tcp/ip stack through the source code could be problematic. i would be interested in seeing what scripts you run and doing some experiments between us see if we can improve on the current solution.

 

Modifying fq_codel parameters is a thought or implementing a AdaptiveJitterBuffer could be another.

I think game with a good net code doesn't need an anti-jitter mechanism because this is implemented in the game server and client:

 

when a packet with a message "at tick X, my game state/ commands are Y," the server should put that message in some internal input queue for tick X, and when the simulation gets to tick X for everyone, it will execute it in time.

 

so implementing a router level anti-jitter may break what the game anti-jitter is already trying to do.

[RabX2]

I may be wrong and you obviously know more about this than I do. I understand that jitter dampening will only work locally but I thought this quest started because they wanted to smooth out what we see? With packets speeding up and slowing down, doesn't this cause the same affect on screen? If it does, is it not beneficial to smooth the jitter out a bit.