low-latency benchmarks: excellent results of RTC clock + SIGIO notification, audio-latency now down

low-latency benchmarks: excellent results of RTC clock + SIGIO notification, audio-latency now down

[Benno Senoner]

Hi,
good news folks:

Paul Barton Davis added async notification via SIGIO to the RTC device,
and I enhanced "latencytest" (you can get the latest version from my page) to
measure timedifferences between two SIGIO calls, All benchmarks performed using
Mingo's low-latency patch (without his patch timing sucks)
The results are very good,
In my example I used an RTC frequency of 2048HZ, and the maximum jitter was
about 500usecs (very sporadic , shows up every 60-100secs).

look at the the results:
CPU load€%
http://www.gardena.net/benno/linux/audio/rtc2048-cpu80/2048.html

CPU load\x10%
http://www.gardena.net/benno/linux/audio/rtc2048-cpu10/2048.html

A typical use could be an app which needs 1ms timing precision
( MIDI sequencer for example).


I have more good news,  On my audio benchmarks I was able to
reduce the audio buffer size from 4.3ms to ONLY 2.1ms ( 3x0.7ms buffers) ! ,
without losing reliability ,in this case the max jitter is about  0.7ms  in the
range of the fragment-time.

look at the results:
CPU load€%
http://www.gardena.net/benno/linux/audio/audio3x128-cpu80/3x128.html

CPU load\x10%
http://www.gardena.net/benno/linux/audio/audio3x128-cpu10/3x128.html

It's interesting that If I use 4.3ms = 3x1.45ms buffers, the max jitter (again
very sporadic) is about 1.5ms , the time it takes to play one fragment.  

Seems that under high disk I/O load,
(very seldom, about every 30-100secs) the process
gets woken up one IRQ period later.
Ideas why this happens.

The trick to deliver rock-solid audio seems to use 3 buffer, so that you can
have about 33% headroom.

Seems that we are now able to outperform most of the other OSes in terms of 
timing precision/ latency ( multimedia loves this)
:-)

In future, we will probably not need RT-Linux to deliver realtime audio
on Linux. (As processors get faster , jitter will go down)

comments ?

regards,
Benno.


---
Benno Senoner
E-Mail: sbenno@gardena.net
Linux low latency audio / scheduling latency benchmarks
http://www.gardena.net/benno/linux/audio

Re: low-latency benchmarks: excellent results of RTC clock + SIGIO

[mingo]

On Sat, 11 Sep 1999, Benno Senoner wrote:

> Seems that under high disk I/O load,
> (very seldom, about every 30-100secs) the process
> gets woken up one IRQ period later.
> Ideas why this happens.

this could be a lost RTC IRQ. If you are using 2048 Hz RTC interrupts, it
just needs a single 1msec IRQ delay to lose an RTC IRQ. Especially SCSI
disk interrupts are known to sometimes cause 1-2 millisecs IRQ delays.  
But before jumping to conclusions, what exactly are the symptoms, what
does 'one IRQ period later' mean exactly?

-- mingo

Re: low-latency benchmarks: excellent results of RTC clock + SIGIO notification, audio-latency now d

[Benno Senoner]

On Sat, 11 Sep 1999, mingo@chiara.csoma.elte.hu wrote:
> On Sat, 11 Sep 1999, Benno Senoner wrote:
> 
> > Seems that under high disk I/O load,
> > (very seldom, about every 30-100secs) the process
> > gets woken up one IRQ period later.
> > Ideas why this happens.
> 
> this could be a lost RTC IRQ. If you are using 2048 Hz RTC interrupts, it
> just needs a single 1msec IRQ delay to lose an RTC IRQ. Especially SCSI
> disk interrupts are known to sometimes cause 1-2 millisecs IRQ delays.  
> But before jumping to conclusions, what exactly are the symptoms, what
> does 'one IRQ period later' mean exactly?
> 
> -- mingo

The RTC benchmark measures the time between 2 calls to the SIGIO handler.
In my example RTC freq 48HZ I used 0.48ms periods, and the max jitter
is exactly 2 * 0.48ms = 0.96ms.

The same thing happens on the audio card:

If I use 1.45ms audio fragments, then max delay between two write() calls is
2.9ms ( 2 * 1.45ms)

When I reduce the fragmentsize to 0.7ms , the max registered peak was 1.4ms 2 * 0.7ms.

Maybe in the audio case, the same phenomen  of "lost IRQ" happens,

But it's interesting that the jitter depends on the IRQ frequency.
(maybe only for very low-latencies)

look at the diagrams , you can see very clearly that the peaks are a multiple 
of the IRQ period.

Maybe on lower IRQ frequencies ( intervals > 5-10ms ), these peaks will
not show up , because that there are  no losses of IRQs ?

But if my HD is blocking the IRQs for max 0.7ms using 0.7ms IRQ period,
why should it block for max 1.45ms by using  1.45ms IRQ periods ?

regards,
Benno.