Re^4: The most precise second (timer)

This one looks promising. :)

It is less punctual than the original code I posted, but I might do.

But I got something strange when I replaced time() in my original code with gettimeofday: exactly precise seconds (to 5 decimal places). I am not quite sure if that is actually correct–is that just calculated to be precise or it the measurement actually precise? I believe that my measurements are not as precise as yours. :)

I tried to simplify the test using my $w2 = EV::periodic( 0, 1, 0, sub { print gettimeofday, "\n";} );, but the result was quite unprecise; here’s the output:

15748078781259
15748078791348
15748078801032
15748078811008
1574807882999
1574807883541
1574807884744
15748078851030
15748078861002
15748078871099
1574807888937
15748078892034
15748078901001
15748078912030
15748078921019
1574807893339M
[download]

Do I do something wrong?

Anyway, I use chrony, too, but my original timer function (from time to time) still complains about negative time not invented yet. Although, I use default settings of CentOS 7 for chrony–do I need to adjust something to use those smooth adjustments?

Comment on Re^4: The most precise second (timer) Select or Download Code

Replies are listed 'Best First'.
Re^5: The most precise second (timer) by soonix (Chancellor) on Nov 27, 2019 at 08:11 UTC
the different length of your results, and especially the trailing "M" in the last line made me suspect `gettimeofday` doesn't return integers. A look into Time::HiRes confirms gettimeofday () In array context returns a two-element array with the seconds and microseconds since the epoch. In scalar context returns floating seconds like Time::HiRes::time() print evaluates its arguments in array context. So you could either change `$,` (`$OUTPUT_FIELD_SEPARATOR`) to somethng visible, or force scalar context by printing `scalar gettimeofday` or `gettimeofday+0`.	[reply] [d/l] [select]
Re^5: The most precise second (timer) (updated x2) by haukex (Archbishop) on Nov 27, 2019 at 11:48 UTC
But I got something strange when I replaced `time()` in my original code with `gettimeofday`: exactly precise seconds (to 5 decimal places). I am not quite sure if that is actually correct–is that just calculated to be precise or it the measurement actually precise? I'm not sure what you mean exactly, maybe you could show the code you're referring to that shows this effect? Note that Time::HiRes provides its own implementation of time, could that have something to do with it? `print gettimeofday, "\n";` soonix answered that one: in the list context of `print`, `gettimeofday` returns two values, and you're seeing the concatenation of the two. That's why I used `sprintf("%d.%06d",gettimeofday)` - using `getttimeofday` in scalar context returns a floating-point number; since I was using Math::BigFloat I didn't want any floating-point imprecisions, so I used a string instead. Although, I use default settings of CentOS 7 for `chrony`–do I need to adjust something to use those smooth adjustments? Sorry, it's been a while since I worked with it in detail, I'm certainly not an expert. But throughout its documentation you'll see references to it slewing the clock, so I believe its normal mode of operation is to change the system clock's frequency slightly to adjust the time, instead of adjusting the time itself, which would result in jumps. And just to make sure: You mean you're running `chronyd` on this machine, not just on your NTP server and using a regular NTP client on the local machine? Update: Take a look at the `makestep` and perhaps `maxslewrate` directives in your configuration - and in general I'd suggest a thorough read of those docs. Update 2: From `initstepslew`: In normal operation, chronyd slews the time when it needs to adjust the system clock. For example, to correct a system clock which is 1 second slow, chronyd slightly increases the amount by which the system clock is advanced on each clock interrupt, until the error is removed. Note that at no time does time run backwards with this method. On most Unix systems it is not desirable to step the system clock, because many programs rely on time advancing monotonically forwards.	[reply] [d/l] [select]