On Fri, 28 Nov 2003, Tom Lane wrote:
> "Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:
>
> > $ 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.
Doh! I was looking for time going backwards so that's what I saw, even though I
already new the same complaint would be made if time skipped forward a second
or so.
> 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.
Yes, all NTPed. The FreeBSD system, the one that doesn't skip back *smacks
forehead*, is the local time server but is generally lightly loaded. Not to say
that there's not going to be the odd job it has to run which could make the
system busy and time time away from this test. It's just difficult to say that
every so often there's some task that makes the system unresponsive for a
couple of seconds, which is what this is saying.
Anyway, I like your suggestion as the timeslicing being a possible
cause. Seems a little strange though, presumably all the numbers going into the
timeofday calc are gathered by the one system call at a place past where the
thread could have had it's time sliced away and before the next. However, I
have no idea how the BSD kernel operates so can't do more than assume and
guess.
--
Nigel
