From owner-freebsd-hackers  Mon Nov 20 17:40:48 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id RAA05992
          for hackers-outgoing; Mon, 20 Nov 1995 17:40:48 -0800
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA05974
          for <hackers@FreeBSD.ORG>; Mon, 20 Nov 1995 17:40:23 -0800
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id MAA19964; Tue, 21 Nov 1995 12:37:26 +1100
Date: Tue, 21 Nov 1995 12:37:26 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199511210137.MAA19964@godzilla.zeta.org.au>
To: Andres.Vega_Garcia@sophia.inria.fr, julian@ref.tfs.com
Subject: Re: Notion of time in kernel + malloc
Cc: hackers@FreeBSD.ORG
Sender: owner-hackers@FreeBSD.ORG
Precedence: bulk

>the  variable structure (struct timeval) time;
>can be examined directly to give time to the nearest 'tick' (100hz usually)

It shouldn't be examined directly since direct access is not atomic.  You
must use

	int s = splclock();
	struct timeval temp_tv = time;
	splx(s);

>however, calling the "microtime()" function
>(in /sys/i386/i386/microtime.s) will give you the value in 'time'
>updated to the nearest microsecond (within a certain error or course)
>where just reading 'time' will give you the last time that
>variable was updated..

microtime() is more accurate and slower.  `time' is updated every 10 ms.
Thus `time' will be 0-10 ms behind the time given by microtime().

>using "microtime()" has of course the problem that it uses more cpu time..
>On a pentium, microtime uses the pentium's Usec timer and is a lot quicker..

On a pentium, microtime uses the pentium's cycle counter and is a lot
quicker than microtime on a non-pentium and a bit slower than directly
accessing `time'.

Bruce