Re: gettimeofday() goes backwards on FreeBSD 4.9
От | Tom Lane |
---|---|
Тема | Re: gettimeofday() goes backwards on FreeBSD 4.9 |
Дата | |
Msg-id | 3594.1070068950@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: gettimeofday() goes backwards on FreeBSD 4.9 ("Nigel J. Andrews" <nandrews@investsystems.co.uk>) |
Ответы |
Re: gettimeofday() goes backwards on FreeBSD 4.9
Re: gettimeofday() goes backwards on FreeBSD 4.9 |
Список | pgsql-hackers |
"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
В списке pgsql-hackers по дате отправления: