Yes, I was thinking it could be related to the timers, even when I wrote that post.
This is one of these things that is a little more complicated than it seems at first. What we want is simple : for the "time since race started" to proceed at exactly the same speed and have exactly the same value on guests as on the host, at any moment, no matter where you are in the world.
A first idea might be for the host to say "go" and everyone starts their clock at that time. But then of course, everyone who is far from the host would be starting later than those who are near to the host. So the solution for this problem is the host and guests mark their packets with the time they were sent and also send some info of when the last received packet arrived. So guests can estimate how far ahead or behind the host they are, assuming the packets take the same time in each direction. Also there is instant nudging when "impossible" packets arrive. A guest knows for a fact it should make an instant timer adjustment of X if a packet arrives from the host at a time X ms before it was sent.
You might think then, that by ignoring particularly late packets and looking at at the time stamps on the ones that seem reasonable, we could get in time and stay in time. But the extra complication is that the clocks run at different speeds on different computers. From memory, I think we discovered that it was normal for time to differ by about 1ms per second and 4ms per second was not uncommon. It sounds like a lot, 4ms per second is a drift of about 6 minutes per day. That is a bad clock, but some of them are that bad. And you can see this becomes very serious in a multiplayer game. With one way pings of about 20 ms for computers in the same country, you can see that after only 5 seconds, with one having a bad time clock with error 4ms / sec, one computer might be so far ahead of another that packets seem to be arriving before they were sent. Even with normal 1ms / sec error (1.5 mins per day) after 20 seconds they could get into a bad state.
So LFS tries to deal with this by adjusting a time multiplier. It does this slowly and gradually because it must not get tricked by occasional late packets and so on. It tries to get the guest's time clock running at the same speed as the host's and also to the same time value.
It does rely on some smoothness for this to work. If the latency keeps changing, for example things downloading in the background or other things happening on the internet, then the continually changing results are hard to make sense of. Also I think there might be a limit of 5ms per seconds on the adjustment. So for example if you have a host that runs 3ms per second slow and a guest that runs 3ms per second fast, then they will never get nicely into time synchronisation. The guest would always look "early". His car lag would look impossibly low and he would see other car lags as being high.
)
