Subject: Re: Grrr: Small delays
To: Chris G Demetriou <>
From: Tobias Weingartner <weingart@austin.BrandonU.CA>
List: port-sun3
Date: 08/15/1995 15:59:00
In message <>, Chris G Demetriou writes:
> >    Is there a standard way of delaying for less than 1 us in the kernel?
> >    [ ... ]
> > 
> > Is not the 'hz' variable available to your routines?  At boot time you
> > could use it to calculate delay constants for the driver, perhaps
> > implement a delay200ns() macro which will use this driver constant in
> > a decrementing loop to get the accuracy you are looking for.
> you could only do so via a timing loop (while (timeout--)).  No
> machines supported by NetBSD have microsecond granularity supported
> directly by clock interrupts, and few have cycle counters.
> rather, i'd think that a routine like "delay 200ns" would be provided
> to the machine-independent part of the driver by the machine-dependent
> part, i.e. as one of the "interface" routines.  that's not an
> unreasonable demand to place on the MD code (because, at worst, if
> poor performance were OK, it could just define the function to
> DELAY(1)).

Hmm, I already sent this to the original author, but here goes nothing.
There should be a reasonable way to have a high-res timer in the OS,
with only a small bit of help from the MD code.  The MD code should
supply a "scale" factor to the MI code, which it can use to scale the
number supplied to a micro_delay() routine.  To make this scale
factor, run a loop (of some sort) against the DELAY(1) timer.  Do
we have ALARM(1)?  ;-)

I'm a scatterbrain today... hope this makes sense.

| Tobias Weingartner | Email: weingart@BrandonU.Ca | Need a Unix sys-admin?  |
| Box 27, Beulah, MB |-----------------------------| Send E-Mail for resume, |
| R0M 0B0, Canada    | Unix Guru, Admin, Sys-Prgmr | and other details...    |
|      %SYSTEM-F-ANARCHISM, The operating system has been overthrown         |