Preliminary Lag Compensation Experiment Findings

[Binary]

I was actually one of the first people to predict Netduma would soon face the backlash from lag compensation, and it seems they've finally begun to listen / learn the hard way.

 

The original Tweet: twitter.com/bina7y/status/602853737271549955

 

Netduma ignorantly discredited what I was saying, and didn't believe a word of it.

 

Since this is the main active thread upon the subject of lag compensation, I figured I would drop some information:

 

First of all, the netcode which governs lag compensation is smart enough to detect any artificially induced latency, packet loss, jitter in general, etc.

This is prevented using the Lockstep protocol - https://en.wikipedia.org/wiki/Lockstep_protocol

 

So I would be fascinated if you're able to produce any real results off host. I guarantee you will fall victim to the placebo effect.

 

As for bufferbloat nothing fixes this quite like SQM and fq_codel, but this will not solve your lag compensation problems.

 

Good luck with your findings, I will be sure to dispel any nonsense when I see it.

[Victor-Yout]

 

First of all, the netcode which governs lag compensation is smart enough to detect any artificially induced latency, packet loss, jitter in general, etc.

This is prevented using the Lockstep protocol - [url=https://en.wikipedia.org/wiki/Lockstep_protocol]https://en.wikipedia.org/wiki/Lockstep_protocol[/url

True words in my opinion lag comp includes these factors.

[Victor-Yout]

 

First of all, the netcode which governs lag compensation is smart enough to detect any artificially induced latency, packet loss, jitter in general, etc.

This is prevented using the Lockstep protocol - [url=https://en.wikipedia.org/wiki/Lockstep_protocol]https://en.wikipedia.org/wiki/Lockstep_protocol[/url

True words in my opinion lag comp includes these factors.

[A7Legit]

There must be a better explanation for advantageous lag compensation than distance lag, for example, I'm from Australia, I play BO3 between the 2 dedicated servers yet due to 3arc and Acti decisions I have players from New Zealand and as far as players from Singapore in these Aussie dedi lobbies and they get smacked around round by round. 

 

Distance lag nor lag compensation favoring them, I'm the one smacking them around with 23km's distance to the dedi here in Victoria. 

 

Here's a new quick vid (different from the other in this thread), intent is to show consistent hit detection/registration in BO3.

https://youtu.be/8t2Ysf5zV08

[Madman]

I hosted my group and I could honestly say I did not experience any advantage. People were actually laughing and telling me that they shot me around walls. But you have all my footage as well. Lol

I wonder if just hosting a lobby of friends affects anything, I've seen a lot of talk of hosting a game but nothing about hosting a lobby.  When I'm not hosting the lobby I seem to do better, I also see that we are joining the same area of dedicated servers as well.  I don't know it maybe a placebo effect.  Any thoughts?

[major masingil]

I was actually one of the first people to predict Netduma would soon face the backlash from lag compensation, and it seems they've finally begun to listen / learn the hard way.

 

The original Tweet: twitter.com/bina7y/status/602853737271549955

 

Netduma ignorantly discredited what I was saying, and didn't believe a word of it.

 

Since this is the main active thread upon the subject of lag compensation, I figured I would drop some information:

 

First of all, the netcode which governs lag compensation is smart enough to detect any artificially induced latency, packet loss, jitter in general, etc.

This is prevented using the Lockstep protocol - https://en.wikipedia.org/wiki/Lockstep_protocol

 

So I would be fascinated if you're able to produce any real results off host. I guarantee you will fall victim to the placebo effect.

 

As for bufferbloat nothing fixes this quite like SQM and fq_codel, but this will not solve your lag compensation problems.

 

Good luck with your findings, I will be sure to dispel any nonsense when I see it.

Dude, being a know it all, I told you so kinda guy is super annoying. Sitting back and waiting to dispel nonsense, is weak. If you have something real to contribute then by all means contribute, or if you're so smart, write the code to combat the issue yourself and start your own gaming router company. You'll be doing the gaming community a favor. My guess is, it's not that easy or everyone would be doing it

 

I've read and seen a bunch that indicates low ping is ultimately king no matter what the lag comp is doing. The R1 helps the user control their own network lag and also helps to find low ping lobbies. There are several threads here that indicated moving or home location is an option to experiment with combating the effects of lag comp... just like was recommended to you on Mar 25 2015. So why all the venom? Are you jealous of Netduma's innovation?

 

The purpose of this thread is to inform us all of the findings of their experiment. The one they created to help us all see the reality behind the myths of lag comp. So let's see what their finding's actually are, and then you can tell us all about how stupid we are and how smart you are. In so doing, you will provide me with a good laugh. Thanks in advance.

[killerkenmccoy]

Did i miss the video on this topic?

[PharmDawgg]

Did i miss the video on this topic?

No video was ever issued.  I believe this project has been sidelined at the moment.

[killerkenmccoy]

Cool, thx bro

[Netduma Fraser]

It will be our next network myths video. Before that though focusing on game support and revamping the wiki.

[TEH BUTCHER]

not sure though if the jitter from the hosts connection will also be realized since Fraser once mentioned potential legal issues with the nextwork agreements on the console platforms. would be nice to hear a statement from Netduma about this as having both in one feature would be awesome, it would probably be the biggest selling feature together with the geo-filter

 

Yea I think that might be an issue. I asked about a similar situation before in having the netaduma queue up information from your console so you're not sending out updates as frequently because right now it's something like console updates every 20ms and server updates every 40ms having the duma delay your console outbound packets to 40ms pushes.

[Knomax]

Another tip that maybe helps...

If your modem has the ability to prioritize packets like ACK,SYN,FIN,RST....

Prioritize ACK and SYN...it helps me to lower jitter...games sends many ACK and SYN packets.

 

From wikipedia.org...

 

<< Connection establishment:

To establish a connection, TCP uses a three-way handshake. Before a client attempts to connect with a server, the server must first bind to and listen at a port to open it up for connections: this is called a passive open. Once the passive open is established, a client may initiate an active open. To establish a connection, the three-way (or 3-step) handshake occurs:

1. SYN: The active open is performed by the client sending a SYN to the server. The client sets the segment's sequence number to a random value A.
2. SYN-ACK: In response, the server replies with a SYN-ACK. The acknowledgment number is set to one more than the received sequence number i.e. A+1, and the sequence number that the server chooses for the packet is another random number, B.
3. ACK: Finally, the client sends an ACK back to the server. The sequence number is set to the received acknowledgement value i.e. A+1, and the acknowledgement number is set to one more than the received sequence number i.e. B+1.

At this point, both the client and server have received an acknowledgment of the connection. The steps 1, 2 establish the connection parameter (sequence number) for one direction and it is acknowledged. The steps 2, 3 establish the connection parameter (sequence number) for the other direction and it is acknowledged. With these, a full-duplex communication is established.>>

 

 

.................................................................................

 

Connection termination:

 

The connection termination phase uses a four-way handshake, with each side of the connection terminating independently. When an endpoint wishes to stop its half of the connection, it transmits a FIN packet, which the other end acknowledges with an ACK. Therefore, a typical tear-down requires a pair of FIN and ACK segments from each TCP endpoint. After the side that sent the first FIN has responded with the final ACK, it waits for a timeout before finally closing the connection, during which time the local port is unavailable for new connections; this prevents confusion due to delayed packets being delivered during subsequent connections.

 

A connection can be "half-open", in which case one side has terminated its end, but the other has not. The side that has terminated can no longer send any data into the connection, but the other side can. The terminating side should continue reading the data until the other side terminates as well.

 

 

It is also possible to terminate the connection by a 3-way handshake, when host A sends a FIN and host B replies with a FIN & ACK (merely combines 2 steps into one) and host A replies with an ACK.

 

 

..........................................

 

So in both situations ACK and SYN packets must have big priority.

 

And if your modem/router has the ability to set up TCP Timeout  set it at 90 ms.....your console/server doesn't need to send FIN or RST packet to close the connection....

Your modem will "drop"  this connection....so less packets travelling....less internal jitter.

 

Think of that....

You shoot a person...you send a packet that  a "bullet" leave from you (ACK)....server confirms to you with ACK/SYN  that "really" you shoot a bullet....now your router must send a FIN packet to close this connection and after a ACK packet!!!!

If your modem can drop these connections it doesn't needs to send packets...less traffic to your network and much easy to handle that.

 

I hope i do not confuse you.

[Netduma Crossy]

That's only for TCP - pretty much all latency critical games will use UDP.

[Sal]

See below (sorry couldnt delete this comment) 

[Sal]

I may have a solution to the Algorithem question Pre-emtpive or Reactive?? Well the answer for me is reactive and i hope someone may be able to relate or shed light on the situation... When i run a buffer bloat test on preemtive my results are awful i hit 300ms - 600ms on both up and down usually upload is far far worse hitting 1000ms giving me 

This was the best run out of the lot (I've run the test using multiple CC settings and 90% up and down seems to give the best result) 

 

However when i run the same test on Reactive, the difference is night and day (Ill point out again 90% seems the best settings however generally varying CC control values give a better result than any pre emtive ones i have run also might be worth mentioning that altering the CC values below 70% on reactive harms the quality but bugger bloat remains A+ OR A) 

 

This result was run on PREEMPTIVE CC UPLOAD 90% DOWNLOAD 90% 

 

 

FURTHER UPDATE.... 

when i ran pre emptive on 100% cc for up and down the results were far better therefore i can only conclude that altering the CC % settings below 100 really hinder the results which is strange.... 

PREEMPTIVE RUN ON 100% UPLOAD AND 100% DOWNLOAD .... (ive run it 5 times to ensure result wasnt a one off and i consistently got this) 

 

Anyway guys hope this helps some of your gaming experiences!  

[NetriX]

Lag comp completely ruins this game, no other game that I play do I get such BS moments time and time again. Not even NetDuma and top of the line internet can save you for such crappy net code.

 

 

 

All game long he was whopping my a**, nothing I could do about it because you can't hit the guy. He has a 4 bar connection and skips like this, not everyone in the lobby was skipping, but yeah this guy was.

 

Like @ 0:18 my shots where on point then he skipped to the right and made my shots miss.

 

Netduma ping graph shows 2-5 ms, no high spikes whatsoever.

 

This is every single game that I join.

[NetriX]

 

[A7Legit]

You have a lot of disposable bandwidth, I wish I had your speeds but honestly speaking if I were you I'd sacrifice most of it when playing BO3 and use Preemptive algorithm with the Netduma R1.

 

This is me with 99% congestion control, I love BO3, I think if you check the 5 (quick Twitter) vids you'll see why.
http://twitter.com/A7Legit/status/750348517156147200