sound driver for RTAI

Jan Kiszka kiszka at rts.uni-hannover.de
Fri Jul 29 15:11:33 CEST 2005


Paolo Mantegazza wrote:
>>> - Load: X opened, "ping -f -s1500 somewhere", "dd if=/dev/hdb2 
>>> of=/dev/null bs=1M count=1000".
>>>
>>> + Native fusion latency.c run at 50 Khz:
>>>
>>> == Sampling period: 20 us
>>> RTT|  00:00:01
>>> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat 
>>> best|---lat worst
>>> RTD|        4200|        5728|       24315|      20|        4200| 24315
>>> RTD|        4340|        5830|       47553|      54|        4200| 47553
>>> RTD|        4036|        5737|       43138|      81|        4036| 47553
>>> RTD|        2130|        7257|       42522|     364|        2130| 47553
>>> RTD|        2333|        5838|      236254|     410|        2130| 236254
>>> RTD|        4402|        5778|       42390|     423|        2130| 236254
>>> ---|------------|------------|------------|--------|------------------------- 
>>>
>>> RTS|        2130|        6028|      236254|     423| 
>>> 00:00:07/00:00:07 (i.e. a 7 second run)
>>
>>
>>
>> This is likely a bug, not a design problem. The latencies we measured 
>> even on smaller systems (Pentium I 133 MHz) over longer periods are 
>> not that extrem, a bit higher than classic (due to the strictly 
>> layered design of fusion), but acceptable for common applications. The 
>> latency numbers I recall for a Pentium M, 1,3 GHz: < 20 us. Not tested 
>> with latest fusion and kernel release, but rather constant over the 
>> last versions.
> 
> 
> You are likely thinking UP, where even magma is far better. Moreover you 
> forgot we are talking of "acustic band" real time, not the usual at most 
> 1 ms PID stuff.
> 

Yep, I disregarded the 20 us. My fault.

Anyway, the numbers remain strange to me. When overloading a UP box, I 
do not get such a worst-case latency jump. Actually, the numbers are 
similar to test with ms periods (only a bit smaller) - exept for the 
overrun counter of course. Is this the difference between fusion in UP 
vs. SMP mode? SMP is not yet a target for us, so I never tested on such 
a system.


Anyway, running rt-tasks in regions above 20 KHz or so on a normal PC 
architecture is pure lottery to me. Typical worst-case hardware delays 
of PCI subsystems etc. already reach dimensions of some 10 us (I once 
heard about 30 us or so). So, if you do not want to let your rt-task run 
simple nop loops, specifying its worst-case execution time becomes very 
hard - as long as it does not have exclusive hardware access, which 
would forbid a shared use with a GPOS underneath.

Jan




More information about the Rtai mailing list