PluginHost.CreateTimer accuracy/regularity

So in this post. I was running into some issues with PluginHost.CreateTimer(). Ilya mentioned that CreateTimer actually relies on System.Timer, not to mention that the plugin could be running on a heavily loaded host etc. I've found that you cannot rely on the timer firing accurately, and in fact relying on it to figure at accurate and precise intervals is a bad idea. I've seen it vary by as much as 20-50ms from the desired frame time (measured using StopWatch).

All this to ask, is this the expected behavior? It seems then that while writing an authoritative server you cannot rely on this being a regular interval, and should not attempt to set accurate server time messages to the client based on it.

Does that sound about right? Or am I misunderstanding something?

Thanks for any help?

Comments

  • hi, @bererton

    as i already said this is by design. it is not a bug. if your plugin method call take 1 minute to exuecte, then timer callback, which stayes in execution queue, will be executed around 1 minute later. and in your case if you scheduled some callback on interval less then 1 minute all fired callback calls will be executed later. Neither you nor we can change this.

    to work around this you may either use timers directly, or create extra fiber and use it. but you should remember, that in this chase you will have concurrent access to your plugins data. this does not happen when you use PluginHost.CreateTimer

    best,
    ilya
  • Hi Ilya,

    I'll dig into profiling my code some more to see if indeed I am running some long executing code sometimes. However as far as I can tell initially at least, the only thing that seems to be taking a long time to run is outputting to the default log file...

    C
  • hi, @bererton

    please, do not get me wrong (my english is far from perfect yet). i do not want to say that problem is in your code only. if one will have quite big activity in his game, rooms may have a lot packets to handle. this will also prevent timer from being accurate.

    i do not see right now good solution.

    best,
    ilya
  • Ultimately, the solution I have currently settled on was to create a 99% authoritative server instead of a 100% authoritative server. Basically the server receives commands from the packets and executes the exact same simulation logic as the client does (barring the fact that the server might hold a different world state from the client w/r to the position of other players/objects in the world). This also means that it sees time a being the same as the client sees it. i.e. if the player says that it is moving to the right with a velocity of 1m/s and the client says it executed 3 commands with a duration of 10milliseconds each, the server will then place the client 0.03 meters to the right of where it was before. Now it will still do sanity checking on the amount of time that is passing on the client and velocities, but ultimately if the client says that it move 0.03 meters to the right over the last 3 commands and that its local client time is 30 milliseconds later than at the server, the server will do it's best to put it at that position and local client time barring velocity/time sanity checks and physics etc. So at least in the absence of other players and obstacles the server will put the client *exactly* where and when it thinks it should be in the next update.

    This leads to smooth interpolation on the client at least in the case where other players/obstacles are not present... the key here was to allow clients to have their own "local client time" that gets advanced on both the server and the client. I haven't read about other people doing this, but this seems to be a way to move forward that doesn't have jitter artifacts given that the server may be under heavy load or run at an uneven frame rate given that I don't control the server very well.

    That's what I'm trying anyways... We'll see how it works.

    C
  • as far as i know this is the right way to go

    best,
    ilya