Re: [Fwd: Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4]

[Ingo Molnar <mingo@elte.hu>]

* Florian Schmidt <mista.tapas@gmx.net> wrote:

> also, i have uploaded an overhauled version of the wakeup timer
> program. It now deferres all output to another SCHED_FIFO thread [with
> prio 1 lower than the main process]. The data is passed via a lockless
> fifo [ripped from jack sourcecode]. Also it handles commandline
> options better and has sensible [?] defaults:
> 
> ~/source/my_projects/wakeup$ ./rtc_wakeup -h
> usage: wakeup [options]
> options:
> -f freqency(hz) (default 1024) 
> -p realtime prio (default 90(91))
> -n max number of interrupts (default 0: run until stopped)
> -t jitter threshold (%) (default 5) 
> -o history_file (default /dev/null)
> -h show help

cool! May i have a feature request :-) It would be quite useful to have
an option to see the jitter output in percentage and in microseconds as
well. I.e. an option to have such a format:

 late wakeup: +151.3 usecs (14.6%) jitter.

cycles are too large to be human readable, and absolute values are
harder to read when HZ is not 1024. So to get a 'quick feel' of the
delays in a system the above line would be the most informative (for me
that is). Also, the percentage can go back to %.1f i think, instead of
%.5f or so - it's good to have a decimal point in the percentage but one
number after it is more than enough.) The more compact the output, the
fewer useless info, the quicker the human brain can read it. (Obviously
to generate a nice graph out of it needs a different format.)

> Here's a typical run (still on V0.5.16, will try V0.6 now):

please try -V0.6.1, -V0.6 had a pretty stupid bug that could trigger
frequently.

> threshold violations: 20
> max jitter:           58.1228%

here it would also be useful to have the 'max jitter' in usecs. I.e. in
the above case it was somewhere around ~570 usecs.

	Ingo