|
Description
|
A Sun customer reported that they were seeing late timer firings on a V20Z.
The Sun contact sent in a test program (see emike.c, attached). The test
program reported that once a second a 20 msec periodic timer would fire
40-70 usecs late.
Note that the test program creates a 1 cpu processor set and disables
interrupts in that cpu; the test program runs in the set so is shielded
from "distractions". It doesn't help to run the program in the RT
class; the problem is still visible.
Some interesting facts:
* the problem doesn't appear on SPARC.
* the problem doesn't always happen - sometimes the
timer is completely jitter free.
* problem is seen on both s10 and s9, which have different
cyclic implementations.
A dtrace script, attached, indicated that the timers were firing late
once a second even after the program was suspended with a ^Z, so
extraneous theories of streams output, X, etc, issues could be
easily be put to rest.
xxxxx@xxxxx.com 2005-05-07 03:34:50 GMT
|
|
Work Around
|
1) spin a bit if you wake up "early".
2) setup a higher-resolution timer to insure that the time is
more frequently recalculated. Some experimentation would be
necessary to pick a suitable value.
3) You could try setting apic_min_timer_ticks to 1 more than it's
current value. This would cause all timers to fire 10% too soon;
the cyclic subsystem would then reprogram the timer and we'd fire
more closely on time. Rather a hack, but a fun experiment on a
system you can crash w/o problems :-).
xxxxx@xxxxx.com 2005-05-07 03:34:51 GMT
In workaround 3) above, you have to change the value of
apic_nsec_per_tick, rather than apic_min_timer_ticks;
increasing apic_min_timer_ticks would potentially
increase the jitter.
|