From owner-freebsd-hackers  Wed Mar 20 21:15:37 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id VAA20869
          for hackers-outgoing; Wed, 20 Mar 1996 21:15:37 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id VAA20847
          for <hackers@FreeBSD.org>; Wed, 20 Mar 1996 21:15:18 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id QAA22241; Thu, 21 Mar 1996 16:13:18 +1100
Date: Thu, 21 Mar 1996 16:13:18 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199603210513.QAA22241@godzilla.zeta.org.au>
To: hackers@FreeBSD.org, pst@shockwave.com
Subject: Re: real time interrupts in FreeBSD?
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

>I've got a need for a kernel driver to go to sleep for a number of MS
>and then be awoken by an interrupt.  Timing is critical, so I can't just
>tsleep and get rescheduled later, and I don't have hardware of my own to
>generate the interrupt.

>Therfore, I need to get a free CTC register, program it up, and have it
>generate an interrupt that I can service in the device driver.

It isn't easy (on i386/isa..pci systems):
- there is no free CTC register.  You would have to multiplex an existing
  one.  This isn't easy because people would be annoyed if you messed up
  the accuracy of the existing counter by more than a few usec, and it
  takes a few usec just to program the counter.
- only one CTC generates interrupts.  I lied in the previous gotcha.  The
  speaker CTC is often free, but it isn't very useful because it doesn't
  generate interrupts.  One good use for it might be to keep track of
  jitter introduced by reprogramming the main CTC.
- FreeBSD isn't a real time system.  You have to be prepared to deal with
  a worst-case interrupt latency of 20 msec even on a P133 or do more
  work to minimise the latency.  (I'm still trying to track down what
  causes a 5 (?) msec clock interrupt latency.  I found what caused 20+
  msec clock interrupt latency.  It was a local experiment that that
  sometimes increased clock interrupt latency to softclock interrupt
  latency.)

If you only need 1 msec resolution, then speeding up the standard clock
interrupt frequency to 1000 Hz should work OK except for the interrupt
latency problem.  This is already supported for one driver at a time.
The pcaudio driver uses it to speed up the clock to 16000 Hz.  This is
too fast to run for long, but 1000 Hz is slow enough to work reasonably
even on slow 386's.

Bruce