Hacker News Reader

Comment by Kuinox | Hacker News Reader

Seems something very hard to do in software but very easy to do in hardware.

Think other people have already done the hard part. Wouldn't be too hard to write something that wraps tc and ping.

  # hping -S -p 1234 somehost.com
  HPING somehost.com (ens3 1.2.3.4): S set, 40 headers + 0 data bytes
  len=46 ip=1.2.3.4 ttl=64 DF id=0 sport=1234 flags=SA seq=0 win=26883 rtt=0.9 ms
  len=46 ip=1.2.3.4 ttl=64 DF id=0 sport=1234 flags=SA seq=1 win=26883 rtt=0.8 ms
  len=46 ip=1.2.3.4 ttl=64 DF id=0 sport=1234 flags=SA seq=2 win=26883 rtt=0.7 ms

  # tc qdisc add dev ens3 root netem delay 25ms

  # hping -S -p 1234 somehost.com
  HPING somehost.com (ens3 1.2.3.4): S set, 40 headers + 0 data bytes
  len=46 ip=1.2.3.4 ttl=64 DF id=0 sport=1234 flags=SA seq=0 win=26883 rtt=25.9 ms
  len=46 ip=1.2.3.4 ttl=64 DF id=0 sport=1234 flags=SA seq=1 win=26883 rtt=25.8 ms
  len=46 ip=1.2.3.4 ttl=64 DF id=0 sport=1234 flags=SA seq=2 win=26883 rtt=25.7 ms

well adjusting the latency is the easy part. doing it in real time while observing the connection and making adjustments, that is when it becomes hard.

and they did it basically after the network stack, so if a paket took 40ms they added no latency if it took 20ms they added 15ms and so on.

so EACH paket was evaluated and of course this is not an easy feat, because lol is serverside authoritive so the latency must be correct inside the server and the client for each packet.

Yea, I guess the question is whether or not to try to do it at the packet level or just keep a running average of ping latency and adjust it over time. They said `adjust the latency (ping) to 35 ms` so I am assuming they are just trying to do something like attempting to maintain an average ping latency of 35 ms.

This is a pretty classic PID here. You're attempting to keep latency at 35ms and based on the latency on each packet as observed by the server, and previously recorded latencies, you can add corrections. With some simulations and tuning I'll bet you can get a pretty good algorithm going.

Simulating this stuff is pretty simple. Model each incoming stream as an MM1 queue and play around with your PID algorithm until it gives you the results you need.

I'd argue the complexity of trying to achieve this at all is too much to bear in practice, especially considering the type of customers this would be inflicted upon. Competitive gamers will now also be wondering if the "fake lag" system is bugged, in addition to all of the other problems that could still exist.

Some problems cannot be solved with clever tricks.

if they pulled an IEX and just ran the Busan clients through a few km of fibre to induce delay they could use native pings and verify easily

Yes, but they probably run on AWS and can't use their own hardware.

Reply on news.ycombinator.com