Doh. The small (~5us) clock decrements were the work of xntpd. I thought it worked by reducing the size of the forward tick, but apparently not. Oh well. Still, with xntpd off, stock 2.2.9 gives me large (~10-100ms) time decrements quite frequently when running the XiG 5.0 server and scrolling in Netscape. I tried forcing the use of do_slow_gettimeoffset() in arch/i386/kernel/time.c, but that only reduced my gettimeofday() count from about 900k/sec to 120k/sec, without fixing the time warps. Next, I changed do_fast_gettimeoffset() so that it'd only do the TSC calculation if the same CPU that had done the timer_interrupt was doing the do_gettimeofday (if a "wrong" CPU was doing it, it would just use the last offset that the "right" CPU returned). Still, no dice. Then I had do_fast_gettimeoffset() just return delay_at_last_interrupt in all cases, but that was worse: I got warps of +/-4295 seconds (!) (so I guess delay_at_last_interrupt was frequently negative). Finally, I put a "return 0;" at the beginning of do_fast_gettimeoffset(), and everything works great. So far. I'm copying linux-smp on this in hopes that somebody who knows about the "delay_at_last_interrupt" calculation can shed some light here. Thanks again for your help with this! d. - Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/ To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
