"Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:
> Ah, I have made a mistake. It's only a 2.2.18 kernal. Dual SMP P-III, perhaps
> that's the issue there.
Hm. I seem to recall there were still lots of SMP bugs in the 2.2.*
kernels.
> And on the FreeBSD system I've got this:
> $ time ./a.out 2>&1 | tee a.txt
> out of order tv_sec: 1070066197 273140, prev 1070066195 721010
> out of order tv_usec: 1070066197 273140, prev 1070066195 721010
> out of order tv_sec: 1070067322 116061, prev 1070067320 440490
> out of order tv_usec: 1070067322 116061, prev 1070067320 440490
> out of order tv_sec: 1070067833 514969, prev 1070067831 755019
> out of order tv_usec: 1070067833 514969, prev 1070067831 755019
> ^C
AFAICT the above is a legal trace, indicating only that the test program
sometimes lost control for more than a second at a time. The "revised"
version of the test will not complain about this.
Time going backwards by even one microsecond, however, is generally
considered Bad News, unless you're actively manipulating the system
clock setting.
One variable I didn't think to ask about is whether you are running
NTP. In my experience an ntp daemon that has achieved lock will never
step the clock back by even 1 usec (it's supposed to use much more
subtle methods than that to manage the clock ;-)) but maybe under
unstable conditions such things could happen. The machines I have
tested here all run NTP.
regards, tom lane
