with the optiminzed version below, I still see a few timewarps
but not nearly as many as before.  my test program (which just
calls gettimeofday() as fast as possible and looks for negative
deltas) used to spew about 10 events per second, and it was
usually going backwards by about 1 clock tick each time.
with the new version I see about 1 event per minute, and the
magnitude of the delta is much less.  here's what I got in
15 minutes or so:

1 spathi:~> ./timetest 
1029080127 160303 < 1029080127 160318
1029080372 93649 < 1029080372 93654
1029080477 434398 < 1029080477 434445
1029080489 451238 < 1029080489 451253
1029080576 555363 < 1029080576 555370
1029080603 182467 < 1029080603 182514
1029080623 901721 < 1029080623 901736
1029080635 206652 < 1029080635 206657
1029080747 418211 < 1029080747 418213
1029080762 993850 < 1029080762 993892
1029080771 713540 < 1029080771 713622
1029080852 642103 < 1029080852 642105
1029080869 218755 < 1029080869 218762
1029080912 296588 < 1029080912 296610
1029081007 679829 < 1029081007 680035


unless someone speaks up to say there's a problem with this
in the next few days, I'll go ahead and commit it.

-Chuck


On Mon, Aug 05, 2002 at 11:27:36PM +0100, David Laight wrote:
> 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