Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Community » U++ community news and announcements » usecs
usecs [message #50511] Mon, 12 November 2018 11:31 Go to next message
mirek is currently offline  mirek
Messages: 11552
Registered: November 2005
Ultimate Member
In addition to "msecs", we have now microseconds precision "usecs". It is really a trivial wrapper around std::chrono.
Re: usecs [message #50687 is a reply to message #50511] Wed, 05 December 2018 12:59 Go to previous messageGo to next message
Tom1
Messages: 477
Registered: March 2007
Senior Member
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 Go to previous messageGo to next message
Zbych is currently offline  Zbych
Messages: 296
Registered: July 2009
Experienced Member
Tom1 wrote on Wed, 05 December 2018 12:59
Is 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 Sad 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 Go to previous messageGo to next message
Tom1
Messages: 477
Registered: March 2007
Senior Member
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 #50698 is a reply to message #50696] Thu, 06 December 2018 19:46 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 11552
Registered: November 2005
Ultimate Member
Tom1 wrote on Thu, 06 December 2018 18:40
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


It is not written in the stone. I can change msecs / usecs... A the moment, it seemed like a good solution to use what C++ lib provides.
Re: usecs [message #50699 is a reply to message #50698] Thu, 06 December 2018 20:19 Go to previous messageGo to next message
Zbych is currently offline  Zbych
Messages: 296
Registered: July 2009
Experienced Member
mirek wrote on Thu, 06 December 2018 19:46
A 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 #50701 is a reply to message #50699] Thu, 06 December 2018 20:56 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 11552
Registered: November 2005
Ultimate Member
Zbych wrote on Thu, 06 December 2018 20:19
mirek wrote on Thu, 06 December 2018 19:46
A the moment, it seemed like a good solution to use what C++ lib provides.


I strongly disagree.


Yet you are proposing using C++ lib as well Smile

Quote:

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;
}



Accepted. I think this is a good idea, we just need to remember that msecs is steady and usecs is not. I guess there is little harm that way - we can anticipate the use of msecs to synchronize things like sockets and usecs to benchmark things (and that is notoriously unstable for other reasons too).

Mirek
Re: usecs [message #50702 is a reply to message #50701] Thu, 06 December 2018 21:24 Go to previous messageGo to next message
Zbych is currently offline  Zbych
Messages: 296
Registered: July 2009
Experienced Member
mirek wrote on Thu, 06 December 2018 20:56
Yet you are proposing using C++ lib as well Smile


You got me Smile

BTW. I've made a mistake. Actual resolution of steady clock in Linux seems to be way below 1us.
I don't know how it looks in windows, but steady_clock seems to be good candidate for usecs as well.

int64 nsecs(int64 prev = 0)
{
	auto p2 = std::chrono::high_resolution_clock::now();
	return std::chrono::duration_cast<std::chrono::nanoseconds>(p2.time_since_epoch()).count() - prev;
}


int64 steady_time(int64 prev = 0)
{
	auto p2 = std::chrono::steady_clock::now();
	return (int64)std::chrono::duration_cast<std::chrono::nanoseconds>(p2.time_since_epoch()).count() - prev;
}


CONSOLE_APP_MAIN
{
	int64 max_delay = 0;
	int64 av_delay = 0;
	constexpr int loops = 10000000;
	
	for (int i = 0; i < loops; i++){
	
		auto start = nsecs();
		auto ms = steady_time();
		while (steady_time(ms) == 0);
		auto duration = nsecs(start);
		max_delay = std::max(duration, max_delay);
		av_delay += duration;
	}
	RLOG("Max delay: " << max_delay << "ns");
	RLOG("Av delay: " << av_delay/loops << "ns");
}



Re: usecs [message #50707 is a reply to message #50698] Fri, 07 December 2018 10:02 Go to previous message
Tom1
Messages: 477
Registered: March 2007
Senior Member
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

Previous Topic: Critical issues to resolve for U++ 2018.1 - please suggest
Next Topic: GLCtrl in GTK
Goto Forum:
  


Current Time: Thu Dec 13 04:35:55 CET 2018

Total time taken to generate the page: 0.01057 seconds