Re^4: Time::HiRes gettimeofday producing timestamps out of order

Thanks again. Will look into it. I *thought* ntpd was careful to avoid large changes in updating the clock, but maybe not careful enough.

Update: Ubuntu docs:

The ntp daemon ntpd calculates the drift of your system clock and cont
+inuously adjusts it, so there are no large corrections that could lea
+d to inconsistent logs for instance.
[download]

Hm. Define "large" ...

The way forward always starts with a minimal test.

Comment on Re^4: Time::HiRes gettimeofday producing timestamps out of order Download Code

Replies are listed 'Best First'.
Re^5: Time::HiRes gettimeofday producing timestamps out of order ("large") by tye (Sage) on May 06, 2016 at 19:55 UTC
so there are no large* corrections* Less than 1 second is likely not considered "large" in a lot of contexts. But that paragraph is more about an ideal than some absolute guarantee. If ntpd is well configured and the hardware clock is relatively reliable / consistent and the network connection is pretty reliable and the reference servers are relatively reliable, then that paragraph will likely apply. If time drift is a serious problem for your systems, then you should switch to recording a timestamp for the first event and then recording durations for the gaps between events and measure those durations using the monotonic high-resolution clock. Or, you can get the timestamp for the first event and use the monotonic clock to measure the gap duration and then compute a timestamp for the event by adding the duration to the original timestamp. Of course, that may be impossible if all events don't get delivered to the same system. On our huge selection of Unix servers, time slips of a few seconds are fairly frequent and time slips of many seconds are not unheard of. We have actually resorted to replacing hardware because we found some hardware clocks were much worse than others. - tye	[reply]
Re^5: Time::HiRes gettimeofday producing timestamps out of order by Anonymous Monk on May 06, 2016 at 15:32 UTC
Timekeeping is messy; PC hardware sucks with errors >100 ppm not uncommon. You can configure ntpd to not discipline the kernel clock. Use adjtimex to manually check and compensate for drift, ntpdate to set the time. Or just enjoy the bumpy ride, network hiccups etc....	[reply]