Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Riot Games: Artificial Latency for Remote Competitors

lolesports.com

Post reply on HN
Print view View original

81–90 of 160 posts

Re: Riot Games: Artificial Latency for Remote Competitors

#81

Post by [deleted] »

vikingerik wrote: post #44
dematz wrote: post #8

As context this was a big international fiasco. Nobody was acting maliciously but fans of RNG and other teams felt wronged. RNG didn't want to attend due to covid restrictions on travel but Riot really wants Chinese viewers in international tournaments, hence all this online latency work. Pros on other teams were lied to by the false latency information which must be almost paranoia inducing to be told it's only 35ms…

You can in fact have that magical time-travel approach to get apparent latency lower than the real number. Keep a history of the game state at every tick, so you can roll back to any previous instant. If real latency from one client is 50 ms, and you're targeting 35 ms, you roll back the game state by 15 ms each time input comes in from that client, and re-run the game logic from that point forwards and send the resu…

[deleted]

Re: Riot Games: Artificial Latency for Remote Competitors

#82

Post by jedberg »

JamesSwift wrote: post #57
gmueckl wrote: post #54

Earlier quoted context omitted.

Isn't that where the randomness of the trading interval comes in? How do you optimally fill out a time interval with a length that is unknown to you?

Ah, I didnt interpret the comment as being a variable delay. I think the point still holds though that you would still optimize for the lower bound.

You could, but then if say the delay is 439ms, then you'll sit idle for 239ms. It would make more sense from a game theory perspective to simply process for as long as necessary and then place the order.

Re: Riot Games: Artificial Latency for Remote Competitors

#83

Post by gverrilla »

bigcat12345678 wrote: post #47
sdwr wrote: post #17

I love the intent and actions behind this post. Finding an unfair bug mid-tournament is serious, and it takes courage and integrity on the part of the technical team to -listen to the players -investigate past what your own analytics are saying -find and fix the bug under time pressure -and disclose the (potentially embarrassing!) initial mistake I think the article itself could have been worded better though. It did…

Yep, look at what Valve is doing to dota 2...

would you care to elaborate? I didn't play dota in a few years

Re: Riot Games: Artificial Latency for Remote Competitors

#84

Post by jedberg »

teddyh wrote: post #28
jedberg wrote: post #21

Earlier quoted context omitted.

You would use an external source of randomness, which you can definitely prove is sufficiently random.

You could do something like this: • Pre-publish, for each time batch, a public key. You could publish lists of these well in advance. • Let everyone submit, alongside each order, a number arbitrarily selected by them. It does not matter how they select the number, but it would be simpler if everyone chose distinct numbers. • When order processing is done, do it by the order of closeness of the submitted number to the…

That seems unnecessary. Today the traders have to trust the exchange to process fairly and in order -- there is no verifiability. The verifiability would be nice, but unnecessary.

Re: Riot Games: Artificial Latency for Remote Competitors

#85

Post by chabons »

someweirdperson wrote: post #51

Artificial or natural delays, I am somewhat confused that one end measuring/calculating ping can end up with a wrong value. Transmit at local time x, receive at local time y, subtract. It only needs a working local clock. Second surprising thing is artifical latency added on the client. Anything on the client I would avoid, if possible. Third, this all looks like magically connecting two ends. But it is packets flowi…

I think the symmetric delay here makes sense, since you're trying to simulate the latency of a (likely) symmetric connection between another client and the server.

If you only add latency on the transmission, then 2 actions taken at the same time by players with different amounts of physical latency will be processed at different times. If we assume the game clocks on each client and the server are in sync, then this creates a competitive advantage for the player with lower physical latency. For instance, if we have a timing battle (ie: Zhonya's hourglass), where both players know that at time 'T' they must each take an action, and the first to do so comes out on top, then the player with higher physical latency is at a disadvantage.

Re: Riot Games: Artificial Latency for Remote Competitors

#86

Post by jedberg »

teen wrote: post #34
jedberg wrote: post #11

Earlier quoted context omitted.

I never understood why they didn't use randomized length micro batches to solve this. Instead of processing orders instantly, wait between 200ms and 500ms and then process all orders that came in that window in random order. Then being 5ms closer to the server wouldn't matter.

That's the same problem, you're just trying to get into the earliest window

Ok but you don't know the window size for any given batch, so game theory-wise your best bet is to just process as fast as you can and then place your order.

Re: Riot Games: Artificial Latency for Remote Competitors

#87

Post by jedberg »

pdpi wrote: post #79
jedberg wrote: post #11

Earlier quoted context omitted.

I never understood why they didn't use randomized length micro batches to solve this. Instead of processing orders instantly, wait between 200ms and 500ms and then process all orders that came in that window in random order. Then being 5ms closer to the server wouldn't matter.

2-500 ms latency for games is atrocious. That's an order of magnitude higher than what this tournament was targeting.

This thread is about HFT.

Re: Riot Games: Artificial Latency for Remote Competitors

#88

Post by jedberg »

w-m wrote: post #27
jedberg wrote: post #11

Earlier quoted context omitted.

I never understood why they didn't use randomized length micro batches to solve this. Instead of processing orders instantly, wait between 200ms and 500ms and then process all orders that came in that window in random order. Then being 5ms closer to the server wouldn't matter.

I don't think I get how that solves the issue: you would have set a fixed cutoff time, where you switch from one window/batch to the next. It doesn't matter when you arrive within the window. But statistically, even for random window lengths, if you have a smaller latency, you will make the cutoff for the earlier window more often.

But because of the random ordering within the windows, it won't matter. In most cases you wouldn't hit the cutoff.

Re: Riot Games: Artificial Latency for Remote Competitors

#89

Post by [deleted] »

vikingerik wrote: post #44
dematz wrote: post #8

As context this was a big international fiasco. Nobody was acting maliciously but fans of RNG and other teams felt wronged. RNG didn't want to attend due to covid restrictions on travel but Riot really wants Chinese viewers in international tournaments, hence all this online latency work. Pros on other teams were lied to by the false latency information which must be almost paranoia inducing to be told it's only 35ms…

You can in fact have that magical time-travel approach to get apparent latency lower than the real number. Keep a history of the game state at every tick, so you can roll back to any previous instant. If real latency from one client is 50 ms, and you're targeting 35 ms, you roll back the game state by 15 ms each time input comes in from that client, and re-run the game logic from that point forwards and send the resu…

[deleted]

Re: Riot Games: Artificial Latency for Remote Competitors

#90

Post by pdpi »

jedberg wrote: post #87
pdpi wrote: post #79

Earlier quoted context omitted.

2-500 ms latency for games is atrocious. That's an order of magnitude higher than what this tournament was targeting.

This thread is about HFT.

So it is. I somehow managed to miss that at the top of the thread. My bad!
Post reply on HN