huge lag indicators with low pings

Bug #321694 reported by yarrt on 2009-01-26
Affects Status Importance Assigned to Milestone
Armagetron Advanced
Manuel Moos
Manuel Moos

Bug Description

Occurs: On chicos brake boost styball with all 0.2.8.x builds up to 20090113 Build (from (Windows client, but probably other OSs too, from player's comments). Sty+ct patches + probably custom mods by kyle are run on that server :-|.

Symptoms: This does happens usually if the server is full. After some server hickup/major packetloss, all remote player's lag indicator are huge, even though the pings are small. Not all clients are affected by the problem at the same time as far as I can tell. Some other regular player says "I have huge indicators", but I mine are small without any lag. Also during huge lag-indicator-phase the other player's lag-indicator tip seems to be their correct position. The moving "ball zone" is displayed at the correct position all the time, but it teleports at times (as far as I remember). I have ruled out bandwith or packet delays for my connection.
The problem last till the end of the round and is gone in the next round.

This looks like predicition/client side problem, but might be a server/client side bug or even a hosting problem.

I'll make a recording the next time I play there. Is a server recording required to get any leads on this ?

Related branches

Manuel Moos (z-man) wrote :

Server recording should not be required. It's probably this: Some issue causes one huge lag on the server (or the clock jumps), so the server things clients lag. The server tells the clients about it. Now, there's a new mechanism in that's supposed to deal better with with fluctuating pings, namely the client adds a little extra bit of time to its clock so game commands get sent 'earlier'. Now, the bit that goes wrong is that the 'little extra bit' turns into a huge bit. The client needs better sanity checks on the values sent by the server, and a clientside recording to get a signature of those events should be enough. Of course, more server side sanity checks may be good, too.

Manuel Moos (z-man) on 2009-01-27
Changed in armagetronad:
milestone: none →
Manuel Moos (z-man) on 2009-01-27
Changed in armagetronad:
importance: Undecided → Medium
status: New → Incomplete
Manuel Moos (z-man) on 2009-01-27
Changed in armagetronad:
assignee: nobody → z-man
Manuel Moos (z-man) wrote :

Two possible reasons:
a) a huge timer hickup on the server
b) the server has LAG_CREDIT_SINGLE set to a high value and freezes for a bit

Variant a) would not explain why some people aren't affected, unless of course timer syncing behaves differently in different versions (it does, but the last change was before Against b), a fix has been committed, the client now clamps the reports from the server as well.

yarrt (yarrt) wrote :

Recording of multiple bugs (sorry it's a long one - took alot of time for the bug to manifest).

Client: Windows

At about T500?: The ball leaves the grid (because it is pushed towards a wall, and collision detection is probably too croase).
At about T1500: Bit LAG-O-Meters AFAIK everybody else was fine.

Manuel Moos (z-man) wrote :

Ah yeah. There was real lag going on, but of an unexpected kind that causes the lag compensation to react in a non-optimal way. A small fraction of your cycle turn commands arrived very late at the server (with more than .1 seconds delay over what would be expected, up to a total delay of >.5 seconds). The lag compensation code is tuned to avoid such delays, so it adapts your timer. Clearly, in this situation, it would be better to accept the occasional delayed packet and eat a lag slide instead of completely lagging behind.

Server code modification to fix: measure the frequency of lag events and don't inform the client about even big lags if they occur rarely enough.

Manuel Moos (z-man) wrote :

Implemented the measurement system mentioned in the last comment.

Manuel Moos (z-man) on 2009-03-08
Changed in armagetronad:
status: Incomplete → Fix Committed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers