On Sun, Apr 18, 1999 at 12:59:23PM -0400, Pierre Cloutier wrote:
> RTAI was configured to use the oneshot timer. I did a new test using the
> periodic timer:
>
> oneshot periodic
> RTLinux V1 .753 .310 sec
> RTAI .303 .269 sec
>
> I did verify with printk()'s in both tasks that there were indeed
> alternating, also confirmed by counters in both schedulers.
> (Needless to say, the lines that print "NO LINUX EVER" where commented out).
We use the same code for task switch in both periodic
and non-periodic time, so what your benchmark is showing, at least for RTL
is _not_ costs of a task switch. What it is showing for RTL is that
the overhead of resetting the clock is significant for very very short
tasks -- note that your tasks are really atypical in that they do nothing
at all. So the code does
loop:
reset clock
save state
restore state
goto loop
One shot in RTL is always a loss with such loads, but it is a
serious win with 2 bigger tasks that have a small greatest common multiple
in the period. Your benchmark then does 120K task switches and shows that
one-shot causes 440 additional milliseconds to be spent -- about 4microseconds
per task switch. If your tasks were doing two operations on a parallel port
(about 3 microseconds) then the difference would be much smaller.
Things should be faster with V1.1 since we cleaned up the timer code.
To be honest, I'm there are other possible optimizations here, but I
am not convinced that they make any difference to actual applications.
> I expect to be penalised if I use the oneshot timer because my UP machine
> does not have an APIC. Still, RTAI seems to yield
> better performance in both cases, and, the oneshot mode is a nevernever for
> UP machines under RTLinux.
I'm not convinced that RTAI is actually using one shot mode. The hardware
imposes a significant delay and the difference btween the two cases in your
benchmark is not big enough. It should be easy to check.
How many times did you run each benchmark? BTW: I really appreciate it when
people run these kind of comparative benchmarks and hope to discover
some missing optimization.
> >Someone did benchmarks with Lynx that showed in one-shot mode RTL was twice
> >as slow and in periodic mode it was twice as fast as Lynxos.
> >
>
> Ditto here. But I'm still curious as to why?
When you don't need the flexibility of the oneshot mode, and your task
does little or nothing so scheduler time is significant relatively, then
avoiding the resets makes a big difference -- with an 8254 timer. I am
curious to measure the apic code when it stops crashing the machine.
--- [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/
