In message <[EMAIL PROTECTED]>, "Marc G. Fournier" writes:
Hmm, I'm not saying this makes sense, but at least there is
an emergent pattern...
Col#1 is duration of the shift, sorted in increasing order.
Col#2 is the delta to the line above.
Notice stratification on 50msec boundaries:
695.426189 -
695.426190 0.000001
695.426191 0.000001
695.426191 0.000000
695.426192 0.000001
695.476192 0.050000
695.476193 0.000001
695.476194 0.000001
695.526193 0.049999
695.526194 0.000001
695.526196 0.000002
695.526196 0.000000
695.526198 0.000002
695.526201 0.000003
695.576193 0.049992
695.576195 0.000002
695.626195 0.050000
695.676192 0.049997
695.676195 0.000003
The only place I can think of 50msec in relation to the timecounter
is NTIMECOUNTER * 1/HZ.
Try to modify some of that, and see if you can affect the results.
In particular, try to yank NTIMECOUNTER _way_ up, like a thousand
and see if the problem goes away.
Another (uglier) option is that ACPI/SMI/APM or similar BIOS magic
screws up the i8254 on a regular basis, or even that the latch
functionality of the i8254 doesn't work properly. This is not
unheard off.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
