Official forums for BZFlag.org

Yes the lag system does not respond to instant changes in latency on every packet sent, it simply uses a special ping. It is not an accurate measurement, it is simply an indication of how "it's all generally going". Using the reported lag in any calculation will only give you an approximate result.

This is the main reason that no 2 players will ever show the same gamestate in bzflag at the same real time.

snick wrote:I know this because I have accurately simulated lag on a locally hosted server so I
know what the true lag is and what the figures show.

How did you attempt to calculate the true lag?

timestamps on the packets with synced clocks can show the actual travel time of each packet.
You can also build a simulation system that adds computed (and known) lag values to your messages. Then you can see what the lag stats system shows you and what you KNOW you lagged the system by and compare them.

snick wrote:BZFlag's lagstats are terribly flawed. They can take minutes to converge on anything
close to the actual lag values, they can behave erratically and unpredictably in the
presence of packet loss (sometimes packet loss doesn't show up as such, but shows up
as high lag instead), they can mask jitter spikes and there is no indication of lag asymmtery.

Etc.

I know this because I have accurately simulated lag on a locally hosted server so I
know what the true lag is and what the figures show. And very often the lagstat
figures are very wrong.

Well, you know what they say... 87% of lagstats are made up on the spot.

snick wrote:

Cobra_Fast wrote:BZFlag does not send packages on a regular basis (like every 100 ms), it only sends data if there is new data to be sent, so the player has to produce some traffic to have his new lag measured.

No, you do not understand how the lagstats are calculated. They are not calculated from movement and shooting data. The calculation is based on special "LagPing" messages that are sent out at regular intervals.

Both is true, but for different values of the "/lagstats" output. The lag value is calculated from special "LagPing" packets and changes slowly. The jitter value is calculated from the timestamps of "PlayerUpdate" packets and changes faster but doesn't change if you don't move or play at all. The packet loss / out of order value is calculated from both of the above but dominated by the "PlayerUpdate" packets as they are sent out much more frequently (when you play). That's at least the case for bzflag 2.0, haven't looked at the 3.0 code yet.
The last value in the "/lagstats" output also is often not a real packet loss, but the number of "out of order" packets (hence the "ooo" in the output ) caused by either high jitter or multipath routing (*) which I've seen a lot lately on some providers like rr.com.

(*) packets of the same connection get routed through different network paths which causes different travel times for different packets, so a later packet may outpace a previous packet because of a shorter network path

snick wrote:

Cobra_Fast wrote: BZFlag's lagstats are NOT terribly flawed. They work perfectly. But most players do not understand that they can only measure lag and packetloss if there is data sent. People are pausing matches and stop any actions and remain sitting there for hours to see their lag go down what won't happen because they are not producing any traffic what could be used for lag measuring. BZFlag does not send packages on a regular basis (like every 100 ms), it only sends data if there is new data to be sent, so the player has to produce some traffic to have his new lag measured.

No, you do not understand how the lagstats are calculated. They are not calculated
from movement and shooting data. The calculation is based on special "LagPing" messages
that are sent out at regular intervals. The result is used to calculate an exponential moving
average and it is that average that is shown in the lagstats. But the average moves so slowly
that changes in lag can take minutes to register fully in the stats.

The point snick is making, apart from being an educated argument based on the code he knows pretty well, should also be pretty obvious. Just think of the lag in observer mode. Observers have lag even if they do not create traffic, don't they? t is obvious ping messages must be exchanged to get lag for observers (and others too).

Lagstats are averages over given time intervals, spikes at given times that last very short may not even get reflected on the average. If I use a key to spike through a bullet and that spike is short enough that would produce only a small increase on my average lag that can perfectly pass as unnoticed.