Subject: Re: QUESTION: real-time, interrupt latency & atom process
To: Peter C. Wallace <firstname.lastname@example.org>
From: Alfred Perlstein <email@example.com>
Date: 11/14/2001 20:29:04
* Peter C. Wallace <firstname.lastname@example.org> [011114 20:11] wrote:
> I've been curious about this myself. We have a little PC/104 card
> that is a 8 axis host based servo motor controller. For most motors you
> need a 3-4 KHz interrupt rate to get good performance (though larger
> slower motors can use a slower update rate) This works fine on DOS where
> nothing else is really happening, but would this high an interrupt rate be
> possible with NetBSD?
> The calculations for 8 axis of simple PID + feed forward +
> profile generation take very little time on a 486, but the interrupt
> latency is liable to be the problem.
> I guess the rate of lost characters on an unbuffered serial port might
> give a clue...
> Anyone run an 8250 at 38400 baud?
> If anyone is interested in playing with the hardware, I am willing
> to donate motor controller cards (and ISA adapters if needed)
Three to four thousand interrupts a second sound like quite the load
for a 486, I don't think the real problem is actually going to
be servicing the interrupts, it's really just serving _all_ of them,
basically without RTOS you may have hiccups, they will be subsecond
hiccups, but hiccups nontheless. Depending on how idle the machine
is otherwise this may also help, you can tune down certain operations
such as how often priorities are recalculated and how often the
syncer runs and other such things to reduce the times when high
priority stuff is run. You can also do certain tricks like what
has to be done for the serial devices, you run them in such a way
that they are never masked but occasionally check the mask and
proceed to batch move data, or something like that. :)
I'd be interested in the hardware, but I don't have a 486 handy
nor much time nowadays.
-Alfred Perlstein [email@example.com]
'Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.'