2015-03-24 23:18 GMT+01:00 Glyph Lefkowitz <glyph@twistedmatrix.com>:

It would be good to look at how many of these numbers are negative.

Not a single one, running the script for a couple of hours, under any condition

That seems right. I think there's a real problem here, since physical clocks do just fail, and sometimes NTP slew has to happen. LoopingCall.withCount has a clear opportunity to notice that time has gone backwards, and can just skip that call. This is assuming that time has gone backwards by a tiny amount for a brief period of time, though, and does not address the more complex issue of "the clock was set some significant distance into the past". LoopingCall still isn't going to be able to deal with large amounts of clock drift, we'd need a monotonic version for that :).

I must add that the anomaly doesn't appear right at the start, but after tens of seconds, mostly when the system is under medium/heavy load.

Even seriously broken clocks don't go backwards a lot. ;-)

I can reproduce the anomaly with my previous script on my linux machine with or without ntp (systemd-timesyncd) enabled and on a macbook (with kqreactor).
The only difference is that since the mac is beefier than the linux box I need to stress it more to trigger the anomaly (a couple of vms + some heavy apps)

I think the ntp cause can be excluded since the issue is reproducible without it and furthermore because once triggered the anomaly happens too frequently to think the ntpd applies so many (negative) fixes in such short time.

Here it is a log where I print a dot when the calls arg is 1, the value if not 1, each dot is separated by 0.02s

https://gist.github.com/dvinella/73e5e45a04c428f037bf

Thanks for reporting! Can you open a ticket?

Sure, I'll open it!