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

Benno Senoner (sbenno@gardena.net)
Sat, 11 Sep 1999 19:41:50 +0200

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=2048HZ 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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/