From owner-freebsd-arch@FreeBSD.ORG Tue Aug 19 16:38:34 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30613106566B for ; Tue, 19 Aug 2008 16:38:34 +0000 (UTC) (envelope-from freebsd@sopwith.solgatos.com) Received: from parsely.rain.com (parsely.rain.com [199.26.172.196]) by mx1.freebsd.org (Postfix) with ESMTP id E906A8FC1C for ; Tue, 19 Aug 2008 16:38:31 +0000 (UTC) (envelope-from freebsd@sopwith.solgatos.com) Received: from sopwith.solgatos.com (uucp@localhost) by parsely.rain.com (8.11.4/8.11.4) with UUCP id m7JG0lg54193; Tue, 19 Aug 2008 09:00:47 -0700 (PDT) (envelope-from freebsd@sopwith.solgatos.com) Received: from localhost by sopwith.solgatos.com (8.8.8/6.24) id PAA05091; Tue, 19 Aug 2008 15:57:50 GMT Message-Id: <200808191557.PAA05091@sopwith.solgatos.com> To: Andrew Reilly In-reply-to: Your message of "Tue, 19 Aug 2008 12:50:19 +1000." <20080819025019.GA27997@duncan.reilly.home> Date: Tue, 19 Aug 2008 08:57:50 +0100 From: Dieter Cc: freebsd-multimedia@freebsd.org, freebsd-arch@freebsd.org Subject: Re: SCHED_ULE problem: slow single processor, realtime prio vs network stack X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2008 16:38:34 -0000 > 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. This is very interesting. Rtprio does not work, but switching schedulers does. Is there something that the scheduler affects that rtprio doesn't? > 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. If you've only tried changing the priority and buffer sizes of the audio process, you could try nicing the network down, and changing the network's buffer sizes up/down. But I wouldn't count on that helping much, if any. I suspect that the answer, at least in your case, is use _4BSD. The goal of total system throughput, and the goal of real time are somewhat at odds. For example giving processes longer time slices would reduce the number of context switches and should increase total system throughput, but would hurt real time response. I've been battling similar real time problems. I'm already using _4BSD, so it doesn't solve everything. From what I can figure out, some device drivers simply hog the CPU for long periods of time. Hopefully that can be fixed. And the schedulers are concerned with allocating CPU, but ignore allocating I/O resources fairly. Nice/rtprio has very little affect on I/O if the process doesn't use much CPU. We really need a way to nice I/O up/down.