From owner-freebsd-hackers  Wed Apr  5 14:58:47 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id OAA02521
          for hackers-outgoing; Wed, 5 Apr 1995 14:58:47 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id OAA02515
          for <freebsd-hackers@FreeBSD.org>; Wed, 5 Apr 1995 14:58:37 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id HAA31671; Thu, 6 Apr 1995 07:56:12 +1000
Date: Thu, 6 Apr 1995 07:56:12 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199504052156.HAA31671@godzilla.zeta.org.au>
To: bde@zeta.org.au, terry@cs.weber.edu
Subject: Re: Colorado Jumbo 250MB ft, and FreeBSD 2.0R
Cc: freebsd-hackers@FreeBSD.org, paul@isl.cf.ac.uk, rgrimes@gndrsh.aac.dev.com,
        steve2@freefall.cdrom.com
Sender: hackers-owner@FreeBSD.org
Precedence: bulk

>> >That DELAY is hardware dependent is an inevitable side effect of
>> >the fact that it is not implemented using real timer code.
>> 
>> It is implemented using real timer code.  Read the code before
>> commenting.

>Oh, well, then the symptoms being reported aren't happening.  8-).

>I didn't realize real timer code had been implemented where a
>kernel thread switch occurrs and a timer event is scheduled instead
>of blocking the kernel thread that called DELAY until the time period
>has expired.

It's implemented using a real timer (an 8254).  It just spins on the
timer.  It isn't real time code :-).  Actually it would be if interrupts
were always disabled - then a minimal machine-delay could be guaranteed.

The Linux delay routine spins on a loop that was calibrated at boot
time.  Since there are caches and interrupts around, it isn't possible
to guarantee accuracy.  It's easier to guarantee that spinning on the
timer takes >= the specified time.

Some drivers would break if DELAY() could be preempted.

Bruce