434
edits
Clock story in TimeManager: Difference between revisions
Jump to navigation
Jump to search
→2021 (hopefully): main text
(→before 2021: main text) |
(→2021 (hopefully): main text) |
||
| Line 35: | Line 35: | ||
=2021 (hopefully)= | =2021 (hopefully)= | ||
To summarize, we have a time step multiple of 1/modelHz, a steady clock based on the wall clock, and a good concept for the multiplayer lag compensation based on time concordance. So what could be wrong? | |||
We won't deal this time with the multiplayers, but with something a bit more delicate, ie the net external protocol, and that lead to investigate precisely what was possible from a [[flightgear]] perspective. | |||
The question was: can we make each [[flightgear]] loop stick to a time grid with a fixed step ? | |||
This would allow multiple FG sessions to be delayed inside the frame, and in synch with some 3rd party software ([[simulink]], [[JSBSim]] standalone etc...) | |||
Assuming the wall clocks are in synch (ntp over internet or ptp in local networks or on the same pc) there were 2 problem in Flightgear: | |||
* the prop "/sim/frame-rate-throttle-hz" allow FG to run at a specified frame rate, but the tests showed inegal spacing between frame because: | |||
** we have minimal step equal to 1/modelHz and if modelHz is not a multiple of Throttle-frame-rate, we'll have different length of frame time reported, even if the throttle is equally spaced. | |||
**the waiting implementation was based on the last timestamp from the system, if we are a bit late, this accumulate and make us loose frame in the long time. | |||
* the steady clock was initialised with the wall clock time at startup, that make it random. | |||
there are 2 parts for the "hopefully" 2021 winter change: | |||
* we don't start the steady clock with the value from the wall clock directly, but we are finding the timestamp just before on a time grid of 1/modelHz, and the difference goes in dtRemainder (the one we introduced in the first topic :) ) this make the steady clock pass by the full second. To allow a volontary shift of the steady clock there's an offset (sim/time/frame-time-offset-ms) used to delay in time two FG sessions. | |||
* Throttle-frame rate has 2 change: | |||
** we wait not a fixed time, but until the next step on the time grid (1/modelHz). If the load allow this work very well (you can log "sim/time/dt-remainder" to have an idea of far you are from the time grid. | |||
** We don't try to follow the value of throttle-frame-rate precisely, but find the closest value giving equally spaced frame on a 1/modelHz step, ie for modelHz=120, we can have 120,60,40,30,24,20,15,10,8,6,5,3,1 | |||
Other values are possible but need a change of modelHz. | |||
For now this work well only if we set the different prop at start, changing modelHz in sim will lead to randon steady clock offset, and the frame-time-offset-ms is only applied on the initial run and stay the same. To ensure a steady frame rate stick to precise grid, you should give the same value at modelHz and throttle-frame-rate. | |||
Possible improvements: | |||
* allow only a limited time windows for the timestamp we start the loop, if we're too late, just skip a frame and start on time on the next grid step. | |||
* make the frame time offset tunable, eg to find the best value when dealing with a source with unknown offset in frame (case with simulink packet replay with tcpreplay, wich allow strict time grid, but unknown start time) | |||
I'll let you see this in action in this [[a_simulink_exploration | simulink exploration]], when it'll be done :) | |||
[[Category:Core_developer_documentation]] | [[Category:Core_developer_documentation]] | ||