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

Replies are listed 'Best First'.
Re^3: Time::HiRes gettimeofday producing timestamps out of order by BrowserUk (Patriarch) on May 06, 2016 at 14:07 UTC
See above; I added to my post. Perhaps something similar can happen on *nix? Eg. Perhaps the systems clock runs fast, and if NTP updates the time, making the clock step back between timestamps, you get the result you are seeing. If that is the cause, you'd expect it to happen at most once per NTP update frequency. (Which should be checkable.) With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :) In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]
Re^4: Time::HiRes gettimeofday producing timestamps out of order by 1nickt (Canon) on May 06, 2016 at 14:11 UTC
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.	[reply] [d/l]
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]