=>From: Brendan Miller <[EMAIL PROTECTED]>
=>...
=> Tue Oct 19 22:38:51 FWD:308942/ 1:BACK ( -15us > delta > 3162us)
=> Tue Oct 19 22:39:03 FWD:294034/ 1:BACK ( -38us > delta > 29909us)
=> Tue Oct 19 22:39:03 FWD:299624/ 1:BACK ( -25us > delta > 11848us)
=>
=>This basically says that one process saw "negative minimum delta" at
=>23:58:51 and both proceses saw "negative minimum delta" at 23:39:03,
=>but _what does this mean_?
Good question. It means kernel timekeeping is screwed up, for one.
Time should NEVER run backwards unless it's user-instigated, in one
large chunk, for the purpose of adjusting the clock. Xntpd is
supposed to try to adjust a fast clock by reducing the size of the
forward step at each timer interrupt (i.e. the timer hits every 10ms,
but we only add 1ms to the time-of-day variable, causing it to run
slower and allowing wall-clock time to catch up). The NTP
compile/runtime doesn't appear to understand that, though, so running
ntp will cause backward steps (which are usually both small and
infrequent, like your results above).
The thing that I've found screws up my mouse is timer decrements of
more than about 5ms. It's much worse with the XiG accelerated server,
which seems to be more sensitive to this. (XiG support confirmed that
negative delta-Ts will screw stuff up.) It's also possible that the
way the XiG server operates exacerbates whatever problem is causing
the negative steps in the first place.
I started having this problem back at 2.3.3, and then I'd get
forward/backward jumps of ~4239 seconds (the clock would jump forward
about 4239 seconds -- which would set off the screen saver -- and then
back after a few milliseconds), or the clock would start racing
forward (hours every few seconds). Andrea Archangeli tried to help
out, but we could never get it clean (although I had a hack that would
just force the gettimeofday system call to always return a time later
than [or the same as] the previous call).
2.3.18 is much better: I only see small decrements (without xntpd),
but they're still large & freqent enough to screw up the accelerated
server. (Or perhaps whatever the accelerated server is doing is still
enough to cause time warps.) In any case, I've found that after a
reboot, my clock has no negative steps, and either Xaccel or XF86 work
fine. For a while. Then, if I run my time checker right after I
notice the first odd mouse movement or click, I'll see fairly frequent
negative deltas. The mouse will continue to behave oddly until the
next reboot.
So, to answer your question, negative time steps are correlated with,
and may cause, mouse wierdness. I don't know what causes the negative
time steps (except for xntpd, but this happens even if you're not
running xntpd).
regards,
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]
