Date: Sat, 2 Mar 1996 01:12:14 +1100 From: Bruce Evans <bde@zeta.org.au> To: current@freebsd.org Subject: clock going backwards on Pentiums Message-ID: <199603011412.BAA17568@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
Clock interrupts are sometimes blocked for a very long time. On Pentiums all clock interrupt latency causes anomalous results from microtime(), e.g., times going backwards. Blocking clock interrupts for longer than one clock tick causes the clock to run slow on all machines. I just got the following log messages when I started up `cvs co src' on a P133: mi_switch: negative time: -88501 usec current = 825686718.054236, microtime = 825686718.054234, runtime = 825686718.142735, rtime = 0.326348 mi_switch: negative time: -55619 usec current = 825686809.271253, microtime = 825686809.271250, runtime = 825686809.326869, rtime = 0.0 calcru: negative time: -42726 usec current = 825686809.409137, microtime = 825686809.409134, runtime = 825686809.408070, rtime = -1.956210 `runtime' somehow got 88501 usec ahead of the current time. This can happen if 8 or 9 clock interrupts are missed, e.g. for the following sequence of events: 1) all initially clocks correct. 2) s = splhigh(). 3) don't lower ipl for 9 clock ticks. 4) microtime(&runtime) stores the correct time into `runtime'. 5) splx(s). 6) clock interrupt occurs. Synchronizing between the Pentium clock and the scheduling clock in effect forgets between 8 and 9 clock ticks. On non- Pentiums they've already been forgotten and the time in 4) was wrong. 7) microtime(&tv) gives a time between 8 and 9 clock ticks before `runtime'. I don't know of any other ways that it can happen. I'm also measuring the clock interrupt latency directly but wasn't logging it when the above occurred. The maximum measured latency is currently 9624 usec. However, the measuring method only works for latencies of less than 10000 usec. I sometimes run an lkm to measure timeout latency. Timeout latencies in the 2000-5000 usec range are quite common. This isn't surprising but isnt very good. How did 1980's machines that were 50-500 times slower finish anything? :-) Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603011412.BAA17568>