|
|
Home » Community » U++ community news and announcements » usecs
|
Re: usecs [message #50687 is a reply to message #50511] |
Wed, 05 December 2018 12:59   |
Tom1
Messages: 1303 Registered: March 2007
|
Ultimate Contributor |
|
|
Hi,
Is usecs() a monotonically increasing timer? (I.e. no jumps backward or forward ever, even if OS time is adjusted by user or NTP.)
Best regards,
Tom
|
|
|
Re: usecs [message #50691 is a reply to message #50687] |
Wed, 05 December 2018 23:36   |
Zbych
Messages: 327 Registered: July 2009
|
Senior Member |
|
|
Tom1 wrote on Wed, 05 December 2018 12:59Is usecs() a monotonically increasing timer? (I.e. no jumps backward or forward ever, even if OS time is adjusted by user or NTP.)
According to the docs: https://en.cppreference.com/w/cpp/chrono/high_resolution_clo ck
it is implementation dependent.
It also means that new implementation of msecs() might not be monotonic as well and all timeouts in many places (sockets etc.) might randomly get shortened or extended.
If you need monotonic clock use std::chrono::steady_clock.
[Updated on: Wed, 05 December 2018 23:48] Report message to a moderator
|
|
|
Re: usecs [message #50696 is a reply to message #50691] |
Thu, 06 December 2018 18:40   |
Tom1
Messages: 1303 Registered: March 2007
|
Ultimate Contributor |
|
|
Hi Zbych,
And thanks for your input! It seems I need to stick with my previous timer solutions which are monotonic. I was just looking at an easier way out than using QueryPerformanceCounter on Windows. Linux is easy enough as it is.
Best regards,
Tom
|
|
|
|
Re: usecs [message #50699 is a reply to message #50698] |
Thu, 06 December 2018 20:19   |
Zbych
Messages: 327 Registered: July 2009
|
Senior Member |
|
|
mirek wrote on Thu, 06 December 2018 19:46A the moment, it seemed like a good solution to use what C++ lib provides.
I strongly disagree. I've made a test and std::chrono::high_resolution_clock::is_steady returned false in Linux/Gcc.
That means that new version of msecs is not reliable. Maybe for usecs it doesn't matter, but msecs is used to measure timeouts in many places in Upp.
My proposition is to use steady_clock for msecs instead:
int msecs(int prev)
{
auto p2 = std::chrono::steady_clock::now();
return (int)std::chrono::duration_cast<std::chrono::milliseconds>(p2.time_since_epoch()).count() - prev;
}
I compared returned value with old implementation (clock_gettime(CLOCK_MONOTONIC...) and they are exactly the same.
Resolution of steady_clock in Linux is about 1ms, so it doesn't make sense to use it in usecs.
[Updated on: Thu, 06 December 2018 20:35] Report message to a moderator
|
|
|
|
|
Re: usecs [message #50707 is a reply to message #50698] |
Fri, 07 December 2018 10:02  |
Tom1
Messages: 1303 Registered: March 2007
|
Ultimate Contributor |
|
|
Hi,
In my opinion, two timing methods are needed. One is the 'wall clock', i.e. something that OS supplies as UTC (or local time, but rather as UTC). This may be synchronized by e.g. NTP or adjusted by user and as such it is always just an approximation of time. There are no guarantees of its correctness or quality.
The other timing source needed is a counter for interval measurement and monotonicity (or 'steadyness' as they seem to call it in C++ lib) is a vital property of it. Monotonic counters are in the end the only solid reference for any serious timing.
(I use these monotonic counters for e.g. creating a 'UTC wall clock' that is synchronized way beyond the accuracy of any OS based clock. The timing requirements of my application are far beyond what e.g. NTP can supply over network.)
For the above reasons, I would suggest using only such APIs for msecs() and usecs() that guarantee in documentation the monotonicity of the clock. Using a source that looks fine on my system and yours does not guarantee similar behavior on the other client's system. After all these are highly hardware dependent in addition to the software platform used.
On POSIX I would stick with "clock_gettime(CLOCK_MONOTONIC,&now);". (This is what I would like to have on Windows too, but that's just a wish...)
For Windows, I would carefully read:
https://docs.microsoft.com/en-us/windows/desktop/SysInfo/acq uiring-high-resolution-time-stamps
and then go with QueryPerformanceCounter (QPC).
-
How about adding a future proof solution to U++: "int64 nsecs_monotonic()"? I guess the name says it all. The resolution will be as good as the platform can supply and monotonicity will guarantee its usefulness for any application.
Best regards,
Tom
[Updated on: Fri, 07 December 2018 13:29] Report message to a moderator
|
|
|
Goto Forum:
Current Time: Sat May 10 06:59:37 CEST 2025
Total time taken to generate the page: 0.02789 seconds
|
|
|