• Welcome to PiBoSo Official Forum. Please login or sign up.
 
March 28, 2024, 10:20:18 AM

News:

GP Bikes beta21c available! :)


GPB timing problem

Started by HornetMaX, April 16, 2014, 01:15:58 PM

Previous topic - Next topic

HornetMaX

Hi all,

this is to report a weird timing issue I've found (post is mainly for Piboso and his team). I know that the issue has been raised in the past (previous forum), but I didn't recall having a clear explanation of it in order to conclude if it is a real bug or something else.

I have coded a plugin that simply logs the telemetry data passed in the plugin interface to a file. Essentially, it does what the default telemetry plugin does, but it also uses windows precision timer (QueryPerformanceFrequency, QueryPerformanceCounter) as an alternative to the timing information passed by GPB. Comparing GPB timing with my own timing I get weird results: my timing seems to be more accurate and GPB timing is sometimes way off.

1. What I do:
GPB calls the plugin function RunTelemetry() every 100ms, passing (along with other information) the current time (_fTime) and position on the track centerline (_fPos, normalized between 0.00 and 1.00).

When between two subsequent calls of RunTelemetry() you notice that _fPos was very close to 1.00 and then very close to 0.00, you know the bike has crossed the finish line. Interpolating the two times (before crossing and after crossing) you can produce an estimate of the time at which you have crossed the line. This should give you a precision better than the 100ms at which RunTelemetry() is called.

If you keep track of the timestamps of each finish line crossing you can recompute the lap times (as difference between timestamps between two consecutive finish line crossings). The lap times computed this way should be equal by the lap times recorded by GPB (which are the "official" lap times, also sent to the plugin with the function RunLap()).

All the above is done by me but is also done by the default telemetry plugin of GPB: the "beacons" line in the output shows the interpolated timing of the finish line crossings. The results of my computations do match the results of the default plugin, so there's no error hanging around there.

Beside that, my plugin also uses Windows precision timer to keep track of the time. This means that on top of logging the GPB-provided _fTime, I also log my own timing information. These two should give very similar results (some discrepancies are possible, but they should be tiny), but they don't.

2. What I see:
The image below (click to see full size) shows a screen capture from a telemetry visualization tool I'm working on. In the "Runs/Laps panel" (top left) you see a single run on Victoria (online dedicated server, professionally hosted) composed of 8 laps: Column "Time" is the lap time recalculated using GPB timing information, while column "WinTime" is the same but using Windows timer.



Lap 1 is only 8 seconds because it's the "out of pits" lap (from start to 1st crossing of finish line, which on Victoria is after the pits), Lap 8 is only 5 seconds as after crossing the finish line and completing lap 7, I ESC-aped to pits.

You can already seen that "Time" and "WinTime" start pretty close (laps 2 and 3) but then gets very different: the delta is 832ms, 796ms, 793ms and 739ms on laps 4 to 7. That's a lot of gap !

In the "Timings" panel (top right) you see the "official" GPB lap times (as recorded by the game and the server) in the column labelled "Time": lap 1 in this panel corresponds to lap 2 in the "Runs/Laps panel" (due to the "out of pits" lap not being counted by GPB), so the numbering is skewed but that's not a problem.

Now comparing the "interpolated" lap times (using both GPB and Windows timing information) with the "official" lap times you see that lap 2 and 3 (in the left panel) are OK, no problem, but from lap 4 on, windows timing leads to the correct lap times while GPB timing is way off (roughly 800ms).

I also have the very same behavior when testing (i.e. offline). In a sample I've just created (Victoria, offline), I have exactly the same pattern: GPB timing is OK on first two (full) laps, then it gets suddenly off by 375ms on the 3rd lap and then up to 600-700ms (did only 9 full laps, on last lap error is 650ms).

I would tend to say that there's something very wrong somewhere. I don't know if this could be one of the causes of our online issues, but ...

MaX.

PeterV

Nice work Max, could this be the cause of the so called session lag?
Where some riders are finished with there session (time is 0:00:00) and some have still time left on theres?

Intresting to know if this would explain it.

Ty Max.

Klax75

Interesting. I've gotten this out of sync problem before during events, but it doesn't happen all the time. Sometimes it's just a few seconds sometimes it's a few minutes. :(

HornetMaX

Up ! So that Piboso can eventually see this (I know he's busy with MXB).

MaX.

Hawk

Sorry, I didn't see this before..... Can't begin to understand all of this technical stuff above, but just wanted to say that you do some incredible investigative work for GP Bikes and us guys here Max.... Great work... Well done mate! ;D 8)