[linux-audio-dev] Some explanations what latencytest's green and white line means ... Was: 2.4.0test5-pre4-lowlat latencies benchmarked ...

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: [linux-audio-dev] Some explanations what latencytest's green and white line means ... Was: 2.4.0test5-pre4-lowlat latencies benchmarked ...
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Wed Jul 26 2000 - 11:39:22 EEST


[ for those which still have doubts about the meaning of the green and white
lines in latencytest ... ]

On Wed, 26 Jul 2000, Iain Sandoe wrote:
>> My point was (re. Linuxppc) that, in the case of the 'green lines', we seem
> to have some action (kernel or otherwise) that is precipitated by
> pre-emption of the SCHED_FIFO task. This (AFAIK) can only happen as a
> result of an IRQ - given that we have not voluntarily given up the CPU (by
> doing a sys call etc. ) - which is my interpretation of what the green line
> is supposed to represent.

You are right: the latencytest main loop is very simple

while(1) {

  start_time=gettime();
  waste_cpu_in_a_calibrated_empty_loop() (*)
  green_time=gettime():
  write() to audio card
  white_time=getttime();

  green_delta=green_time - start_time;
  white_delta=white_time - start_time;
}

(*) eg if the fragmentlen is 1msec and we want to waste 80% of the CPU , then we
    run X loops so that we exactly waste 0.8msec which is 80% of 1msec.
    At startup time we calibrate the loops_per_sec variable and then simply
compute X = loops_per_sec * fragment_time (eg. 1.5msec) * cpu_load ( eg 80%)

latencytest simply plots the two timedeltas: green_delta and white_delta

if there is a big spike in the green line, it means that we were still sitting
in the CPU wasting loop and did not want to give up the CPU yet
(opposed to the blocking write() to the audiodev)
This spike can only caused by either an IRQ which then executes a kernel routing
which uses several msecs worth of CPU or another higher-pri SCHED_FIFO task.
The latter is not the case since in all tests latencytest was the only
SCHED_FIFO task running , plus it ran at max priority.

BTW: I am just about to retest the 2.2.16 kernel and perhaps it could be an APM
issue (even if I booted with apm=off). I'll tell you later about my findings.

Benno.


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Jul 26 2000 - 11:24:17 EEST