koobas.hobune.stream
How to realize accurate time counter (millisecond precision)
Sorry for my English.
I develop a client-server game and I need equal time counters on the client and server for synchronization. On the server side (Java) all work fine.
On the client I tried set Fixed Timestep to 0.001 and count time on FixedUpdate. It works, but in one thread with other scripts and sometimes lagged. I became convinced of this in this article
Also I try to count time in other thread, but this code get wrong time (I try TICK_TIME 1 and 5)
while (started)
{
time += TICK_TIME;
Thread.Sleep(TICK_TIME);
}
How to realize stable counter? And is it possible in Unity?
If this is also your question please don't cross post: http://stackoverflow.com/questions/27879724/how-to-realize-accurate-time-counter-millisecond-precision
it's perfectly O$$anonymous$$ to cross post, and you should do so
"Standard netiquette from the last thirty or so years suggests that cross-posting is discouraged" http://meta.stackoverflow.com/questions/266053/is-it-ok-to-cross-post-a-question-between-non-stack-exchange-and-stack-exchange http://meta.stackexchange.com/questions/141823/why-is-cross-posting-wrong-on-an-external-site http://meta.stackexchange.com/questions/95615/cross-posting-etiquette http://meta.stackexchange.com/questions/64068/is-cross-posting-a-question-on-multiple-stack-exchange-sites-permitted-if-the-qu
that's just the lame owners of SO trying to promote their site to make more money, don't worry about it.
Now, it might be that ON SO, "they" discourage people posting -- on SO -- something that has been posted somewhere else. If so, that is exactly their commercial decision and that's fine. Whatever.
But I can absolutely assure you that there is no problem posting something here, which happens to have been posted somewhere else (whether on a commercial enterprise like SO, some little web site, a forum, wikipedia, AOL, or whatever).
I'm the like #20 drunk moderator (click on the link) so that's "official". If you don't believe me don't hesitate to ask the dude from unity who shows up on here.
(If you're saying you do not agree with that official policy here on unity-answers, well tough. get a job with unity and have the policy changed :) )
It's pretty difficult. All you need is something hogging the CPU for a bit (e.g. the garbage collector or some third party process) and you're timer goes out, as you discovered. Unity multiplies movement by deltaTime to deal with fluctuating times between calls for just this reason.
There are millisecond based clocks available for Unity so you don't need to implement one of those yourself.
Maybe you should rethink your approach? Some alternate approaches are:
1) Choose a communication protocol that is more robust with respect to fluctuations in time, or (possibly)
2) Distributed clock synchronization is a pretty difficult thing to do (see Clock synchronization ) But you could try an approach similar to the way NTP does it (the server sends out times and the client syncs it's local time to the server). E.g. here's some C# code to make an NTP client.. C# NTP client you could alter it I suppose to piggy back that info in your network protocol and hook up the java server to an ntp server or subsume the ntp server functionality.. Some code here: Java NTP Server
It's a lot of work though and you may well run into complications. It's a risky and time consuming thing to do if you ask me. (In fact I'd say that if you need to ask this question then this is probably too hard a solution for you).
you cannot achieve "millisecond precision" in a video game. game engines are frame based.
Just because you get code called every frame does not mean that it is impossible to achieve distributed clock synchronization which seems to be what kimreik is asking.
right on. you can certainly (a) achieve strategies that see$$anonymous$$gly synchronise even fast-moving cars, etc in multiplayer video games {although this is very, very, very, very, very, very hard to do} and (b) you can indeed simply (if for some reason you wanted to) reasonably as you say synchronise abstract clocks within client servers (although not even in the vicinity of a millisecond)
as you very accurately point out it's likely the OP is actually just trying to "synchronise cars in a race game" (which as you know is incredibly diffifulct, but not impossible) and the OP thinks that "syncing the clocks" has something to do with that (in fact it has nothing to do with it, as you know)
finally (to just repeat what you explain in your excellent answer) if for some reason the OP is just trying to sync as in exactly what your $$anonymous$$ac does when it syncs to the remote atomic clock; that is a very specialised filed (which has been utterly worked out): one can read the various research papers on it or (it seems difficult to believe there would be any reason to do other than this) use the calls in unix which do exactly that for you
"I got an email from this site saying "Fattie has accepted an answer by Fattie for How to realize accurate time counter (millisecond precision)" Is that the accurate?" -- yes, because (a) the OP is brand-new and (b) the question is silly and trivial, moderators often just drop in a three-word answer and tick it, to try to clear up the board a bit (as if there is any hope of that on here). i ticked your answer ins$$anonymous$$d since it's a good one and you deserve the points since you're new :)
I didn't try it in Unity, but in desktop C# applications for accurate purposes, I would use System.Diagnostics.Stopwatch, but I guess System.DateTime is millisecond accurate. But overall, it is virtually impossible to keep the server and client perfectly sync, there's always stuff like network latency. My advice: Change your design! Otherwise, if you are sure that both client and server start a method at the same time (or you don't care about this offset), you could start an Stopwatch or set DateTime variable as the start and use the delta with current time.
