From owner-freebsd-multimedia@FreeBSD.ORG Tue Aug 19 08:54:22 2008 Return-Path: Delivered-To: freebsd-multimedia@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE6B11065687 for ; Tue, 19 Aug 2008 08:54:22 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nschwqsrv03p.mx.bigpond.com (nschwqsrv03p.mx.bigpond.com [61.9.189.237]) by mx1.freebsd.org (Postfix) with ESMTP id 7F8638FC40 for ; Tue, 19 Aug 2008 08:54:21 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nschwotgx02p.mx.bigpond.com ([124.188.162.219]) by nschwmtas01p.mx.bigpond.com with ESMTP id <20080819025023.ZBJQ19495.nschwmtas01p.mx.bigpond.com@nschwotgx02p.mx.bigpond.com> for ; Tue, 19 Aug 2008 02:50:23 +0000 Received: from areilly.bpa.nu ([124.188.162.219]) by nschwotgx02p.mx.bigpond.com with ESMTP id <20080819025022.UJCR11844.nschwotgx02p.mx.bigpond.com@areilly.bpa.nu> for ; Tue, 19 Aug 2008 02:50:22 +0000 Received: (qmail 31503 invoked by uid 501); 19 Aug 2008 02:50:19 -0000 Date: Tue, 19 Aug 2008 12:50:19 +1000 From: Andrew Reilly To: freebsd-arch@freebsd.org, freebsd-multimedia@freebsd.org Message-ID: <20080819025019.GA27997@duncan.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150204.48AA34EF.0015,ss=1,fgs=0 Cc: Subject: SCHED_ULE problem: slow single processor, realtime prio vs network stack X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2008 08:54:23 -0000 Hi all, Let me tell you a story, and perhaps someone can suggest a different course of action than the one that I've taken, which has been to switch back to SCHED_4BSD: I've got an old P3-500 machine that I use for audio processing experiments and also music playback. It's got an M-Audio Delta1010 card in it, which (in its most native mode) has ten channels in and twelve out, all 24/32-bit. I use the 4front-tech driver, because the native one doesn't do multi-channel (yet). I recently "upgraded" the OS on that box from 6-stable to 7-stable, since I've had such good experiences with 7 (and SCHED_ULE) on my desktop and server systems (and 4front now supports 7). Unfortunatly, for this application, this was a seriously retrograde step, at first: no matter how I fiddled the blocking factors and IO sizes, I couldn't stop the system from glitching (audio buffer underruns). It seemed that any (unrelated) network activity would take priority over the audio, even though I had the audio task set to rtprio=10. Loging in to the box with ssh was a guaranteed sound glitcher. It probably doesn't help that that box has a dagy old 100baseTX RealTek ethernet card, that I have to use with -r=1024 on my NFS mounts to avoid fragmentation problems. I'm pleased to report that switching back to SCHED_4BSD has retrieved the situation, and my audio task is now rock solid and stable again. I've been thinking about writing up a PR about the issue, but I haven't figured out how to generate a minimally failing example that anyone else would be able to verify. Maybe I'll just go ahead and post this message, to see if anyone has any suggestions. Given the emphasis of _ULE on multi-processor scalability and total system throughput (at which it seems to rock), I suspect that the answer may well be: "use a more suitable operating system". I hope not. I would expect that the same mechanisms that enable good multi-processor scalability would also have good real-time characteristics: the same asynchronous events and preemption are at work in both cases. So, here's the question: can I do something to my code, or the way I set its priority, to get something equivalent to the reliable real-time scheduling that I can get in _4BSD under _ULE? Cheers, Andrew