From owner-freebsd-smp  Sun Apr  5 03:46:53 1998
Return-Path: <owner-freebsd-smp@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id DAA00827
          for freebsd-smp-outgoing; Sun, 5 Apr 1998 03:46:53 -0700 (PDT)
          (envelope-from owner-freebsd-smp@FreeBSD.ORG)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA00816;
          Sun, 5 Apr 1998 03:46:39 -0700 (PDT)
          (envelope-from bde@godzilla.zeta.org.au)
Received: (from bde@localhost)
	by godzilla.zeta.org.au (8.8.7/8.8.7) id UAA00537;
	Sun, 5 Apr 1998 20:43:14 +1000
Date: Sun, 5 Apr 1998 20:43:14 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199804051043.UAA00537@godzilla.zeta.org.au>
To: bde@zeta.org.au, peter@netplex.com.au
Subject: Re: more SMP stuff
Cc: phk@FreeBSD.ORG, smp@FreeBSD.ORG
Sender: owner-freebsd-smp@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

>I was using your diff to nanosleep, but a 1 second sleep started taking 
>724 seconds....  Perhaps it was the nanotime() twiddle I was trying..

Hmm.

I found the bug in microtime():
(1) the dummy timecounter has a frequency of only 10^5 Hz, but it runs
    much faster than that so we get too-large delta counts.
(2) scale_micro = 10^9 * 2^32 / 10^5 / 10^3 doesn't fit in 32 bits, so
    the too-large delta counts are multipled by a garbage scale factor.
    microtime loops up to about 2^31 / 10^6 = 2000 times to reduce the
    garbage.

nanotime() probably has the same bug, with a maximum loop count of
about 2^63 / 10^9 = 9 * 10^9, but I haven't seen this yet.  If the
garbage is random, then delta is < 0 half the time, and the loop
terminates early for the wrong reason.

Bruce

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message