I suspect I've beaten the i386 (8253/4) microtime code to death.

The most likely bug in the current implementation is that 3 ticks
can happen between the latch being activated and the ICU read.
This would cause the code to assume that the interrupt happened
before the counter was latched - not afterwards.

Serious amounts of bus-master activity by other masters (eg
disk controllers or high speed network cards) could load the
PCI bus enough to make this happen.

Increasing the 'magic' 3 to a larger value won't have a detremental
effect unless hardware interrupts are disabled for a significant
fraction of the tick time.  If they are disabled for that long
they are likely to be disabled for longer than a tick.
It is possible that 3 is only just large enough - I haven't
tried 2 to see.

It should also be noted that is the counter has a broken latch
(see comments in arch/i386/isa/clock.c) then it is probable
that absolutely nothing can be done to make microtime work.
My system has an AMD756 south bridge and reading the unlatched
counter returns bytes that are not monatonic (I expect the
read isn't synchronised to the increment), this is impossible
to correct in software....

Anyway I've put 2 copies of microtime.s onto my web space (www.l6s.co.uk):
netbsd/microtime/microtime.s is an optimised version
netbsd/microtime/microtime.s.diag contains diagnostics for time travel

Both are about 20% faster than the 'standard' version.
(If the unlatched counter gave valid bytes then it could be
improved much more.)

	David

-- 
David Laight: david@l8s.co.uk