Corrected gettimeofday() test code

[Poul-Henning Kamp]

In message <20031129191941.X99096 at ganymede.hub.org>, "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
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.