realtime problem

[Harti Brandt]

On Wed, 9 Apr 2003, Bernd Walter wrote:

BW>On Wed, Apr 09, 2003 at 02:45:07PM +0200, Harti Brandt wrote:
BW>> On Wed, 9 Apr 2003, Bernd Walter wrote:
BW>> BW>I need a realtime behavour in the (-current) kernel with 1ms
BW>> BW>resolution and a presision of 500us.
BW>> BW>I thought about these two ways:
BW>> BW>- use timeout(9), but it seems that on i386 we only have a
BW>> BW>  resolution of 10ms.
BW>> BW>  And I don't know of what presision quality I can expect.
BW>> BW>  Can the resolution changed to 1ms as we have on alpha?
BW>> BW>- attach to the clock service routine.
BW>> BW>  I asume the presision will be good enough.
BW>> BW>  But how can I find out the resolution on a given hardware?
BW>> BW>
BW>> BW>What is the best way to solve the problem?
BW>>
BW>> You must change HZ by putting
BW>>
BW>> options	HZ=2000
BW>>
BW>> or whatever you want in your config file.
BW>>
BW>> You should also ensure, that you have no miibus ethernet cards in your
BW>> system, or comment out the relevant sections in dev/mii that periodically
BW>> call the status update stuff.
BW>>
BW>> I fact I have used a HZ=10000 machine to simulate a 120000 packets/sec
BW>> satellite link with good success (jitters are in the order of 300usecs).
BW>
BW>That's a hopefully information.
BW>Did you use a hardclock, timeout(9) or something else?

Just timeout. If you get jitters that seem too large, edit kern_timeout.c,
locate the #ifdef DIAGNOSTIC cases where the callout times are measured
and make the constant maxdt smaller. So you find offending callouts, that
lead to large jitters. (I used an equivalent technique by using Luigi's
code that he posted a year or so ago).

BW>> If you really mean 'real-time' with bounded times for interrupts and so
BW>> on, that will be much harder :-) See Terry's mail.
BW>
BW>Well it's wishfull to have non failures on my requirements, but if it
BW>does fail once it is detectable and it only costs a small amount of
BW>money - noone will die because of it.
BW>If I would need garantied 100% acuracy, then I would spend the money
BW>into a microcontroller to do the job.
BW>In fact I need it for the programming impulse on writing EPROMs and
BW>GALs.
BW>GALs are the devices which may need a 1ms programming impulse, but I
BW>don't know if there are really devices on the maket which use 1ms.
BW>EPROMS are not very sensible on the programming length.
BW>I really hate that available burners need DOS or Windows.

So that is really not a classical real-time problem. The above should
work.

harti
-- 
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
brandt at fokus.fraunhofer.de, harti at freebsd.org