Time going backwards

If you look up microuptime, backwards and FreeBSD on google you’ll find
some reference to problems like this. You can also find windows 2000
bug fix that has to do with this problem. There is buggy timer hardware
on some motherboards. Quite a few were AMD motherboards.

Corey Holcomb-Hockin

Yes. Here’s my thinking so far:

  • After all the fancy tricks to try to avoid the problem, a few cases
    will still slip through. These have to be caught in the kernel as the
    last step in gettimeofday, using the crude technique of a static variable.

  • By the time the errors get to user space, information has been lost, for
    example, user space doesn’t know which portion of the time came from the
    8253 timer and which part came from the TSC, which it can’t fix the damage
    as accurately as the kernel can.

  • Any fix to time jumping must not interfere with settimeofday :wink:

  • Time jumping errors should be logged by the kernel, just as parity errors
    on a communication channel would be, so that hardware/kernel bugs don’t go
    unnoticed forever.

  • SDL has to have code to detect and limit the damage of time jumping as
    well, because it still has to run on a wide range of buggy kernels
    (where “buggy” in this case means “does not properly compensate for
    buggy/stupid hardware”). SDL could detect the pentium-ness of its
    hardware and prefer to use the TSC. This is mainly a matter of
    turning #ifdefs into real ifs.

  • When TSC is used on a smp system, relative time values must always come
    from the same CPU. I don’t think the kernel enforces this at the moment.

DanielOn Thursday 26 December 2002 11:42, you wrote:

If you look up microuptime, backwards and FreeBSD on google you’ll find
some reference to problems like this. You can also find windows 2000
bug fix that has to do with this problem. There is buggy timer hardware
on some motherboards. Quite a few were AMD motherboards.