At 07:48 AM 18-04-99 -0600, you wrote:
>On Sat, Apr 17, 1999 at 11:15:18PM -0400, Pierre Cloutier wrote:
>> At 06:08 PM 17-04-99 -0600, you wrote:
>> >
>> >I looked at your benchmark a third time and really don't understand
>> >it at all now. If A's priority is > than B's shouldn't A simply
>> >run 60000 resumes and exit? How do you measure termination of the
>> >benchmark?
>> >
>>
>> In fact, priorites can be the same with RTLinux using rt_task_wakeup() and
>> rt_task_suspend(). The "conceptual example" given was taken from RTAI.
>> The RTLinux and RTAI schedulers, albeit similar, are different animals. For
>> the RTAI test, TaskB's priority = 1, TaskA's priority =2.
>> Now, 1 is smaller than 2 which means that B has more priority than A. I
>> measured elapsed time with rt_get_time(). In one case it returns clock
>> ticks (0-1,192,180) in the other it return CPU cycles (0-233,000,000).
>
>Can you add counters to make sure that both tasks execute as many times
>as you think they do?
>Also you should use rdtsc for more accurate timing. If you want, I can
>send you example code.
>
>I'm still unsure of what really happens during the test
>Does running resume force a task switch?
>In the RTL case it will, have you checked to make sure that this happens in
>rtai?
>
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).
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.
>
>> So, I stand by my numbers. The SMP overhead is expected to be marginal but
>> is real. The scheduler has to worry about which CPU, there are spin
locks etc.
>
>I don't know enough about RTAI to understand this. Is there a SMP overhead
>in a non-smp machine?
The smpscheduler in RTAI also works for a UP machine. Although the
scheduler knows there is only one CPU, it still goes through code
that's there to support the second CPU. Maybe Paolo could elaborate on this
one as he is the "creator".
>
>> The real issue, IMHO, is that 2.2.5 may bring major improvements to bear
>> over 2.0.36, but I'm not familiar enough with kernel guts to evaluate.
>>
>
>V1.1 has better timing code than 1.0 but I'd like to see the measurements
>with set_periodic since, if I understand Paolo's arguments, he only has
>periodic mode in RTAI.
>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?
>
>> On the other hand, if 2.2.5 does not bring major improvements over 2.0.36,
>> then there is something magic in RTAI, or something bad in RTLinux.
>
>
>>
>> Regards
>>
>>
>>
>>
>> _______________________________________________________
>>
>> Pierre Cloutier
>> Tel: (450)-659-9186
>> Fax: (450)-659-0014
>> POSEIDON CONTROLS INC
>> _______________________________________________________
>
_______________________________________________________
Pierre Cloutier
Tel: (450)-659-9186
Fax: (450)-659-0014
POSEIDON CONTROLS INC
_______________________________________________________
--- [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/
