From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1MjinF-0001oA-Vv for garchives@archives.gentoo.org; Sat, 05 Sep 2009 00:06:14 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2C3E6E0760; Sat, 5 Sep 2009 00:06:12 +0000 (UTC) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by pigeon.gentoo.org (Postfix) with ESMTP id E497FE0760 for ; Sat, 5 Sep 2009 00:06:11 +0000 (UTC) Received: by ewy18 with SMTP id 18so1351853ewy.14 for ; Fri, 04 Sep 2009 17:06:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=0BEJEZGXwFOj2tyiCof/QNKDjt2JSMVsL9hXtPKnwPM=; b=qW57dANnKCndY8PM/IFAu17zSwUTHdz7vqwXjPKBIxT2nXAS1OCHxctQLMPsz+oVTC U2za8e8G6KYz+o4KrDZSx/Sup9qYCkCfC8aKw7/SIMen4IJgxkeijRR+6UvIO5E5nPmh 9uzKwbMzf6UpwaEk1hymI0J88MisPfKVYIkWU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; b=QWuO+dhkkdY/GgnrSCZ2V3iDYnhPkSCKI89aqy3U2sWauCGyjZUbGx2qoDSWbzmYzl tc8atyzo1D+1F8/c4GDRFsXuttVfKHIXO0vlgao/vVIVD5mr92dlWQk31F0CDf8vcZwg a9BDdYaOuGE83gjfUEVWbGMU95em+Kcf7c8Zs= Received: by 10.216.87.66 with SMTP id x44mr1003682wee.96.1252109170214; Fri, 04 Sep 2009 17:06:10 -0700 (PDT) Received: from energy.localnet (energy.heim10.tu-clausthal.de [139.174.197.94]) by mx.google.com with ESMTPS id f13sm207906gvd.8.2009.09.04.17.06.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 04 Sep 2009 17:06:09 -0700 (PDT) From: Volker Armin Hemmann To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Kon Colivas is working again on a new scheduler for Desktop/Multimedia/Gaming PCs Date: Sat, 5 Sep 2009 02:06:05 +0200 User-Agent: KMail/1.12.1 (Linux/2.6.30.5r4; KDE/4.3.1; x86_64; ; ) References: <200909050143.41702.volkerarmin@googlemail.com> <5bdc1c8b0909041650m4a757e92g70e02acc8b387062@mail.gmail.com> In-Reply-To: <5bdc1c8b0909041650m4a757e92g70e02acc8b387062@mail.gmail.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <200909050206.05935.volkerarmin@googlemail.com> X-Archives-Salt: d6d63a0f-2cc2-48ef-8625-87666db31e34 X-Archives-Hash: 627ba05ce02512a983bd30b4eb4b70ea On Samstag 05 September 2009, Mark Knecht wrote: > On Fri, Sep 4, 2009 at 4:43 PM, Volker Armin > > Hemmann wrote: > > On Samstag 05 September 2009, Nikos Chantziaras wrote: > >> I recently stumbled upon an LWN article that mentioned Con Kolivas is > >> working on a new kernel scheduler for Desktop/Multimedia/Gaming PCs > >> called "BFS": > >> > >> http://lwn.net/Articles/350100 > >> > >> Well, I've tried it. I wrote my experiences with it here: > >> > >> http://lwn.net/Articles/350820 > >> > >> If you're feeling adventurous, you might want to give that one a try. In > >> my case, it helped immensely, especially with sound latency and skips > >> and other artifacts during real-time playback (I was not using an RT > >> kernel before that though). Note that BFS has been updated to 0.206 > >> since I wrote that. > >> > >> The patch to kernel 2.6.30 and docs can be found at: > >> > >> http://ck.kolivas.org/patches/bfs > > > > and what is with people like me - who for some magical reasons don't have > > problems with skips or latency? Without using rt-kernels of course.- > > Fire up Ardour and record 32 channels of audio at the same time set to > <5mS latency using Jack and see if whatever version of the mainline > kernel you are running doesn't have. I've recorded as many as 48 > channels @ 48KHz across three hard drives at less than 2mS on my main > recording platform, but that requires rt-sources. I doubt I could do > better than about 25mS with vanilla-sources. > > Just my experience, > Mark > well, and your workload asks for rt. But rt also means overhead, reduction of performance. So why cater for 1 in a thousand system and punish the other 999? if you like the 'bfs' scheduler, that is great.