linux-kernel - Re: ck vs. cfs : realtime audio performance

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070801063102.GB10134@elte.hu>
Date:	Wed, 1 Aug 2007 08:31:02 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Lenar Lõhmus <lenar@...y.ee>
Cc:	Klaus Schulz <Klaus.Schulz@....de>, ck@....kolivas.org,
	linux-kernel@...r.kernel.org
Subject: Re: ck vs. cfs : realtime audio performance


> >Am Dienstag, den 31.07.2007, 10:26 +0200 schrieb Klaus Schulz:

> >>I am currently testing the 2.6.22.1 cfs-rt9 vs. ck1 on my rather pure
> >>realtime high-end-audio setup. (NO X, just a terminal, streaming .wav. 
> >>I am using my own written player and brutefir as the audio engine.)
> >>Comment: This is not a standard (amarok or xmms setup), all buffers in
> >>the chain are very small. Any problem will immidetialy end up in xruns.
> >>The sounddriver, HW (pci-bus etc.) are tweaked accordingly 
> >>
> >>Until now ck1 on 2.6.22 is giving me better results (less audible
> >>distortions) and runs extremely stable compared to cfs. 
> >>Under ck I ran my player with schedtool -R -p 98, which was better than
> >>running it e.g. with nice -20 
> >>Both setups under cfs were giving me worse results than ck.
> >>With CFS I also experienced XRUNS from time to time, what never happened
> >>with ck.
> >>
> >>However:
> >>
> >>When looking at the latest performance statistics cfs vs. ck which are
> >>spread around here, I am wondering, what might cause the differences.
> >>
> >>With ck I tweaked the rr_interval to 6 and was running at 10000Hz,
> >>which caused obvious improvements.
> >>
> >>These options I do not have with CFS.
> >>
> >>I am wondering if sched_granularity_ns should be touched when using cfs.
> >>I googled somewhere that bringing it down to e.g. 250000 instead of
> >>4000000 would smoothen the audio playback. I havn't tried it yet. I am
> >>wondering if this tweak is still applicable.

(re-sending my earlier reply to Klaus here on lkml too)

Klaus,

since you are using -rt, have you tried chrt-ing not only your audio
player but your audio IRQ as well? While playback is going on could you
create a system snapshot with the following tool:

  http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh

and send me the output file.

i'm also wondering why HZ=10000 makes a difference - audio interrupts
have no Linux-timer aspect normally (they are hardware timers in essence
themselves) - which portion of the workload is timing out so that HZ
shows up? Does the enabling of CONFIG_HIGH_RES_TIMERS help perhaps?

Also, do you have any advice for me how to reproduce your problem? I've
got a couple of PCs with various low-end/chipset-based audio hw, but the
buffers are generally large (around 500 msecs) so i rarely run into any
xrun problems. Is your player available for download so i could try it?

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