[Highquality]

For the past few months the Ive been having a problem on a bhop server I manage with a timer plugin called bTimes, by blacky. It's been only recording times in increments of 0.125 for the most part.
Picture for example: http://i.imgur.com/mj0WrPT.jpg
This is just a small example but as you can see most of the times are rounded to an increment of 0.125 and this happens a lot.
I thought maybe something was wrong with the plugin so I asked the plugin dev about it and he said the time is fetched with GetEngineTime() and that it's just getting the servers time. So I messaged the server operator and they said that the engine time is per machine so if it was malfunctioning on my server it should be malfunctioning across all servers which is not the case.
The problem also temporarily fixes itself when the bhop server is reset. Maybe this is an issue with sourcemod or maybe its just a confliction with another plugin im not sure but this issue has had me stumped for awhile.
Any help would be greatly appreciated

[Fragkiller]

Either change your tickrate to 66 tick or life with that. You are probably running 100tick which is causing that.

[Miu]

GetEngineTime() is the second worst timekeeping function in the game, it has the same occasional tick-skipping behavior of GetGameTickCount() but gets even worse as the server uptime increases: it starts incrementing wrong (100 tickrate should be .01 increment per tick but it'll add something else) and it starts duplicating ticks CONSTANTLY (two subsequent ticks might both be e.g. 1234.125, and then the third will be 1234.150 or something weird). GetGameTime(), while imperfect, is the best timekeeping function, and you need to either use that instead or start periodically restarting the server (like, every few hours).

[Highquality]

@Fragkiller, Yeah 66tick is something that would ruin the gametype as bunnyhopping changes quite a bit depending on tickrate

@Miu, Yeah restarting daily was something I was considering but wanted to avoid. I might consider getting it changed to GetGameTime() as long as it is as precise but more accurate as GetEngineTime() was as record times on certain maps do come down to the milliseconds. Thanks for the help!

[Miu]

In a physics engine that operates in discrete 0.01 second timesteps, any precision beyond that is illusory and caused by timing errors. Since GetGameTime() has less error, I don't think you'll see any precision beyond that on small maps.

I guess you could theoretically calculate how far you were from the finish zone in the last instant of time to infer higher precision, e.g. if you moved 10 units in the last tick but only needed 7 units to get to the zone, it would be reasonable to subtract 0.003 from your time since 3/10 of your movement in the tick were unneeded. I don't think his timer does that, though.

[Highquality]

It does not. I always knew the third decimal spot seemed too precise to be accurate for source engine. Honestly it rarely goes into the thousandths on time so 0.01 would work 99% of the time. Ill talk to the plugin dev about all of this though