Kirk Smith wrote:
(...)
> Two questions:
> 
> 1 - Could rtlinux be modified to run soley on the second cpu?  This would let
> the primary cpu run normal linux, and the second run all time critial apps?

*Anything* is possible! This is Open Source... :-)

Ove Ewerlid has been doing this without RTL, with good results. He has a
kernel patch that simply blocks anything but SCHED_FIFO tasks from the
second CPU. When a SCHED_FIFO task is started, it'll run on the second
CPU, and can safely run continously, polling AD/DA cards or whatever,
while Linux runs on the first CPU.

(Sorry, no email here... He's on linux-kernel, so you could ask
[EMAIL PROTECTED] about subscribers to linux-kernel and search
for his name.)

> 2 - If you had all real-time code running on one cpu alone, what is the
> achievable max periodic rate?

If you stay in the L1 cache, you should be able to approach the MHz
range, as long as you don't get bus problems when doing I/O... DON'T use
the periodic scheduler in one-shot mode for that, though!

> I am suggesting here you would not context
> switch in / out of real-time but instead read the real-time clock in pentium
> processors to determine when to switch from task to task (have a stall proceess
> that waits for next schedule point).  The purpose of the stall loop remove the
> need to "interrupt" the processor with a hardware timer, and thus loose time
> servicing the interrupt.

Note that this solution would disable preemptive RT task scheduling...
You're restricted to round-robin cooperative multitasking.

> My final goal is to have a realtime application (single task most likely) that
> performs an action every 0.01ms (100khz).

I've managed to run a task at around 83 kHz with the periodic scheduler,
accessing I/O ports in the task code. This was on a dual P-II 233...
With decent hardware (no port access in RT code) and a timer interrupt
directly triggering an RTL IRQ handler, you should be able to achieve
this rate. The jitter starts to show, though...

> With a pentium 90 running in dos I
> was only able to achieve 5kh due to interrupt handling overhead.

That low!? I hacked a simple semi-preemptive RTK in pure C++ for DOS (3
days of work) as a demo when I applied for my current job. I used a
linked list for tasks, and both the high prio (IRQ) and the low prio
(main program loop) schedulers simply scanned the list for every
reschedule. Very simple code, not optimized...

With 8 tasks registered and the most active one scheduled to run on
every timer interrupt, I got 27 kHz on a 40 MHz 486... And that's while
driving a stepper motor with the 27 kHz task, and reading switches,
keeping track of speed etc in the other tasks. I think you must have
missed something.

> I have heard
> talk about the pentium real-time counter being used to measure time to
> micro-seconds.  Thus I assume if the task were short enough, one could perform
> that task then wait for the next schedule point to perform that task again.
> 
> Does this make sense?

Yep, with a second CPU locked to that task.

BTW, that trick can also be used as a way of cutting the scheduling
jitter away. Start the high precision task early, and busy-wait until
the exact start time... I would prefer buffered hardware for that kind
of jitter requirements, though.


//David
--- [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