3 ms·

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

by Kuinox 4y ago

bob1029 4y ago
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.
- infinityio 4y ago
  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
  - Kuinox 4y ago
    Yes, but they probably run on AWS and can't use their own hardware.
bostonsre 4y ago
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
- merb 4y ago
  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.
  - bostonsre 4y ago
    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.
    - Karrot_Kream 4y ago
      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.

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

by Kuinox 4y ago

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

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.

infinityio 4y ago
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
- Kuinox 4y ago
  Yes, but they probably run on AWS and can't use their own hardware.

bostonsre 4y ago

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

merb 4y ago
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.
- bostonsre 4y ago
  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.
  - Karrot_Kream 4y ago
    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.