Fri, 12 Jan 2001 Alexander Lichius wrote:
> Hi Dingrong,
> 
> Wednesday, January 10, 2001, 7:34:39 PM, you wrote:
> 
> DY> Hello all RTLinux users and developers,
> 
> DY> I need to schdule a  procedure  by a timer at every (around) 1 ms.  I
> DY> set  the time interval of the XtAppAddTimeOut to be 1ms. But I am
> DY> uncertain is the resolution of linux timer is such fine or not? Tijs
> DY> suggested to modify parameter HZ of
> DY> /usr/src/linux/include/asm-i386/param.h to 1024 for a 2ms timing
> DY> (attached at the end). Does it  mean if modify HZ to 2048 may get a 1ms
> DY> resolution timing? If so, what  should I do after this modification so
> DY> that this modification may be  effective?
> i think you could do so, but that would let the system timer generate
> an interrupt every 1 ms. i think your machine will end up processing
> the interrupt handlers while giving less cpu time to your application
> (or worst case NO cpu time ...)

Well, Intel (pre P-II, at least) isn't exactly the most efficient architecture
around when it comes to interrupt management, but other architectures have used
HZ = 1024 for quite some time, and any recent P-II/III should be able to deal
with it without significant performance impact. Especially the Coppermine cores
(full speed cache) and the Celerons should do pretty well.

After all, the average Intel CPU these days has some 300,000+ cycles to fit
each jiffy IRQ in at 1000 Hz, so it's not exactly as if you'd have to hand code
the ISR in asm to get away with it! :-)

As to actual figures related to the hardware; quite some time ago I got my old
dual P-II 233 to run a periodic RTL thread at over 80 kHz, while leaving just
enough power for X to be (at least theoretically) usable - and that thread was
burning plenty of cycles doing port access, which probably amounted to more
cycles than the actual IRQ and RTL scheduler overhead.


> DY> I am booting with RTLinux-2.0. The reason why I do this high frequency
> DY> (1000 Hz)  task in linux instead of RTLinux is because this task need to
> DY> use lots of  graphics, big memory (60M) for object modeling, etc which are
> DY> cubersome to do in RTLinux.
> if you could do it, i will change my religion at once .... ;)

I don't knaw about religion, but I've been running SCHED_FIFO threads at 1 kHz
and beyond without problems on machines like Celeron 333 and P-II 400. (Any
decent socket 7 generation Pentium system does rather well too.)

I'm using the lowlatency patch to get very firm (*) scheduling latency
guarantees, which works great for what I do (audio processing + some prototype
development at work), without interfering with the ability to use any drivers
that make sense. (Any drivers that *should* be usable in a real time context
have behaved as expected so far - no hacking required.)

Of course, one has to be aware that some drivers do one or both of two silly
things, which hurst preformance significantly, even for RTAI and RTL:

        1. Directly using the STI/CLI instructions, thus depriving the
           kernel of any chance of giving latency guarantees.

        2. "Forgetting" about the "Is the command FIFO full?" test in
           accelerated video card drivers, thus making the card stall
           the bus and the CPU until there is room in the FIFO... (This
           is a performance hack that speeds up the command pumping in
           the normal case, while freezing for up to tens of ms if the
           card should lag too far behind the driver.)


(*) Actually it's hard real time, for all practical matters in my experience.
    Never seen a missed deadline on a system with a properly working lowlatency
    kernel - the worst case latency stays well below 1 ms regardless of system
    load.


> >> This works for x86 only:
> >> Try using #define HZ 1024 or some other high number in
> >> /usr/src/linux/include/asm-i386/param.h
> >>
> >> Usually it's 100 and that accounts for the (what I thought were 10) 20
> >> ms.
> i thought it were 10 ms too .... ?

For some reason which I cannot remember, it takes two jiffies before you get
woken up under some circumstances...


//David

..- M A I A -------------------------------------------------.
|      Multimedia Application Integration Architecture      |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------> http://www.linuxaudiodev.com/maia -'
..- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`--------------------------------------> [EMAIL PROTECTED] -'
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Reply via email to