From owner-freebsd-hackers  Fri Mar 22 06:11:38 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id GAA07528
          for hackers-outgoing; Fri, 22 Mar 1996 06:11:38 -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 GAA07522
          for <hackers@FreeBSD.org>; Fri, 22 Mar 1996 06:11:35 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id AAA08451; Sat, 23 Mar 1996 00:56:57 +1100
Date: Sat, 23 Mar 1996 00:56:57 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199603221356.AAA08451@godzilla.zeta.org.au>
To: bde@zeta.org.au, hdalog@zipnet.net
Subject: Re: real time interrupts in FreeBSD?
Cc: hackers@FreeBSD.org, pst@shockwave.com
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

>>   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.)

>To address this make sure you have a way to measure your latency.

The i586 cycle counter can probably be used reliably (only on 586's of
course).  I'm currently using the i8254 counter to adjust the (value
read from the) i586 counter because I trust the i8254 counter more.
The maximum adjustment over the last hour was 0x7ec9 ticks = 246 usec
(for latency from the clock interrupt to cpu_thisticklen()).

>When I last played with this I used a conversion overrun on a
>clocked A-D board as a "missed deadline" flag, restarting the
>conversion in the real time tick.  This was real easy - I'm sure
>you can also do this using clock with more work.

It's not easy if the latency is > 10 msec.  Then clock interrupts are
lost.  The best approaches that I can think of are:
- reserve the speaker timer for improving the main timer.  Set it to
  a maximum count of 65536.  Then 55 msec worth of lost clock interrupts
  can be noticed.
- recalibrate against the rtc every second.  You could tell if you lost
  clock interrupts, but not exactly when.

>BTW: With 20 msec latency how can we can keep up with 115200 input data?
>We're receiving about 240 characters in 20 msec at that rate.

Serial interrupts have higher priority.

With a latency of 20 msec you can only handle the following speeds:

8250:	            50 cps  (300 bps works,  600 bps fails)
16550:	16 * 50 = 8000 cps (4800 bps works, 9600 bps fails)

Bruce