Sign in to follow this  
homojedi

time sync for dead reckoning

Recommended Posts

homojedi    121
hi all, i stumbled across this article while researching dead reckoning http://www.mine-control.com/zack/timesync/timesync.html and im having trouble discerning why you actually need to synchronize clocks. to my knowledge, if the server tests the latency every few seconds and finds out how long it approximately takes for a packet to get from server to client then why should it matter if their clocks are synchronized? it's as that famous guy said "time is relative." edit:upon further thought I suppose they would need to synchronize clocks if they wanted to reduce the latency tests which I just described and thus just synchronize clocks and the server sends the time it sent the packet and the client then compares that too the time it received it and performs dead reckoning, rather than having to send and receive to find out the latency you just receive. Am i Close?

Share this post


Link to post
Share on other sites
oliii    2196
Why does the A-Team always sync their watches before starting a dangerous but non-lethal mission? [grin]

If you can get the sync to a reasonable amount, it is useful. Especially for dead-reckoning.

Someone might say, "I launched a missile at global time 'T'". Regardless of the current latency, or how much that message has been delayed, someone can predict the position and path of the missile at any time reasonable accurately.

Share this post


Link to post
Share on other sites
CadetUmfer    234
You have no way of knowing how much latency a client is experiencing. That is, without trusting the client.

If you use that information in your physics simulation, you're opening yourself up to speed hacks.

Share this post


Link to post
Share on other sites
ddn3    1610
You could poll an aggregate of the users peers (people in close proximity) and use that instead if u had enough sample points (assuming they are all not hacked :).

But more to the question, you sync clocks because using individual pings is subject to individual latency and other variance, collecting a bunch of pings and doing some statical analysis upon it u can reduce the error and then use periodic maintainace pings to correct for drift, is alot easier people have found in the long run to sync time.

Once you have that you can correct for latency for moving objects on either side within a bounds of error (assuming the client is truthful).

Good Luck!

-ddn

Share this post


Link to post
Share on other sites
hplus0603    11356
You can sync the clock without getting speed hacks pretty easily, as long as you run the simulation on the server, too. As long as the server keeps a running average (leaky integrator, one-pole IIR, whatever you want to call it) and doesn't accept any sudden jump in indicated latency, it's not really ameanable to cheating. Playing catch-up after a big lag spike is what opens you up to speed hacks (turn off/on the network hub), as is accepting arbitrary packets at arbitrary rates from a client instead of just the expected rate (CPU clock hacks).

Time management from the server's point of view can really be quite simple. Things happen in some order. The client knows that, when it sends commands, other things may already have happened on the server, so it might be told that what it thought the world was, wasn't true. The server just executes commands when they get to it, checking things like overall speeds, turn rates, ammo expenditure or whatever.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this