From owner-freebsd-hackers  Tue Apr  1 14:01:16 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id OAA05200
          for hackers-outgoing; Tue, 1 Apr 1997 14:01:16 -0800 (PST)
Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA05188
          for <hackers@freebsd.org>; Tue, 1 Apr 1997 14:01:12 -0800 (PST)
Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.8.5/8.7.3) with SMTP id RAA03711; Tue, 1 Apr 1997 17:00:19 -0500 (EST)
Message-Id: <199704012200.RAA03711@whizzo.transsys.com>
X-Mailer: exmh version 2.0gamma 1/27/96
To: gbeach@cybernet.com
cc: hackers@freebsd.org
From: "Louis A. Mamakos" <louie@TransSys.COM>
Subject: Re: Internal clock 
References: <3340C326.6150@cybernet.com> 
In-reply-to: Your message of "Tue, 01 Apr 1997 09:11:18 +0100."
             <3340C326.6150@cybernet.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 01 Apr 1997 17:00:19 -0500
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> How can I make time measurements in increments smaller than the clock
> tick?  Specifically, I am running BSD on a Pentium PC which has 128
> clock ticks per second.  Is there any way to improve the resolution?

The gettimeofday() system call has resolution finer than the 128hz tick
rate.  If you look at the microtime subroutine in /sys/i386/i386/microtime.s,
you'll see some pretty scary code which does this.  On non-586/686 cpus,
it looks at the counter which fires the 128hz interrupt to see how far along
it is since the last interrupt, and uses that to compute the "current"
time.  The 586/686 case is somewhat more interesting..

The xntpd daemon uses this feature to synchronize the system clock to within
a very few milliseconds by timestamping the arrival of packets delivered.

As others have mentioned, arranging to wakeup at some arbitrary time in
the future is a different thing all together.  I think that the scheduling
events are either based on the 128hz clock tick, or some other process
blocking.

louie