Checking Lagstats During Replay

[Snake12534]

// Possible idea to check lagstats during replays (very significant)? // while (MatchInProgress) // Check time // Assign time to lagstats in an array // set lagstats = savedData

// During A Replay // Call savedData based on the clock (Not comfortable with the API)

[allejo]

Do replays not provide lag stats? The API does provide functions to get latency information for players.

Here are some questions you have to take into account:

• Would you be polling every player every 5, 30, 60 seconds for their lag and saving all of that in a separate file?
• This would be a lot of data, is it even worth saving? i.e. Will this help the league administration solve any problems?
• Would polling this type of information even show an accurate representation of spikes?

Keep in mind, replay servers do not have League Overseer loaded so all of the lag data would be to be written to a file and not stored in memory. Even if it was stored in memory, that would get large very quickly.

[Snake12534]

To answer the addressed questions:

Idea #1 Perhaps the five or ten most recent FMs and Officials can be saved to a file. If the game is a funmatch, the players can be polled in increments of five seconds. If the game is an official, the players can be polled every one second.

The data can be stored in a separate file and be called during a replay. After five or ten of the most recent FMs and officials, the oldest match will be deleted.

If admins see a certain red flag on a specific match, they can "mark" that match to gain access to future references of the match. The "marked" match stays in the file forever until deleted by admins.

Idea #2 We can take the account of the first five minuets of a player's lag, jitter, and pl during a match. We poll the player's latency every 10-20 (rand) seconds and take the average. During the match, we can check if the average is ever reaches 100 (lag) higher than the average, (15ms higher) than the average, and (2pl over the average) every 500-1000 milliseconds (random); if this happens, then that player will receive a 'mark' with a timestamp and latency information. These marks will be sent to a file at the end of the match where admins can check them during a replay.

For example, say Player Snake12534 is in a game and plays the first minuets. His average lag in the first minuets are 120, Jitter: 10ms, pl: 0%. However, during 19:37 of the match, his lag spiked to 400, jitter to 11, and pl to 0%. Snake12534 will receive a mark for lag spike. The mark is stored in a file where admins can reference to. Admins check the marks on players and watches Snake12534's replay. They see during 19:37 of the match, Snake12534 jumped for a capture and spiked when the bullet was about to hit him. Admins know that Snake12534 did not receive marks throughout the match and had an average of 120 lag.

Idea #3 A mixture or combination of both

[allejo]

I'm not against the idea, I'm just not convinced that this'll be accurate enough for it to actually be useful to admins. As for keeping the data or deleting it, I think that should be left up to the server owners as to when to delete it or it could actually be kept on the league website on a per match basis instead (just thought about that). If you can get other admins behind this idea or other players to put up good arguments as to how this would be beneficial or how to make it accurate, I wouldn't mind making this a feature request.

[JMakey]

When players view lagstats during a recorded match the results are already stored as private chat messages in the replay file. It should be fairly easy to modify bzfs to make just those messages visible to replay observers. That won't provide the automated anomaly detection and reporting envisioned above, but players already tend to check lagstats when they suspect a problem so it might be a good enough solution that won't be an extra burden.

[Snake12534]

I was able to gain support for the idea from admins believing it would be useful to have a system to check lagstats during a replay. Most suspicious spikes happen within milliseconds and most players will not be able to catch the lagstats in time. If this system is used, ideally, it'll more accurately assign a time stamp to a lag spike with an immensely less margin error.

[JMakey]

Lag is measured at 10 second intervals so there is no benefit to recording it more often than that.

Jitter, on the other hand, is recomputed with every update packet the server receives (up to 60 per second per player on standard GU servers). The smoothing algorithm ensures that transient changes will appear in a player's jitter value for several seconds afterward. If we can specify the characteristics of a noteworthy jitter spike (perhaps when it is greater than 5ms and changes by at least 10ms) then it ought to be enough to record only those events. This sort of change would be more efficiently implemented in bzfs than a plugin.

[allejo]

Closing. This would be better implemented and stored in actual replay files as part of BZFS instead of being saved on the league website or as a separate file alongside the replay file.