From owner-freebsd-current@FreeBSD.ORG Fri May 7 08:03:57 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E6A5316A4CE for ; Fri, 7 May 2004 08:03:57 -0700 (PDT) Received: from out002.verizon.net (out002pub.verizon.net [206.46.170.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79AAD43D45 for ; Fri, 7 May 2004 08:03:57 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com ([68.161.84.3]) by out002.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040507150356.ZLSI9273.out002.verizon.net@mac.com> for ; Fri, 7 May 2004 10:03:56 -0500 Message-ID: <409BA553.2030907@mac.com> Date: Fri, 07 May 2004 11:03:47 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: freebsd-current@freebsd.org References: <20040507005518.75B6A79004C@ws1-14.us4.outblaze.com> <20040507040852.GA78023@VARK.homeunix.com> <20040507165839.Q24428@gamplex.bde.org> In-Reply-To: <20040507165839.Q24428@gamplex.bde.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out002.verizon.net from [68.161.84.3] at Fri, 7 May 2004 10:03:56 -0500 Subject: Re: low HZ value causes "Time Warp Bug" (re: this Puny Pentium2suddenly became 45% slower!) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 15:03:58 -0000 Bruce Evans wrote: [ ... ] > The importance of scheduling is shown by the number of users who notice > when it is broken: it is very small. Aren't blocking system calls wonderful? I suspect that problems with the scheduler don't matter nearly as much when you've often only got a handful of tasks which are runnable to choose from. If one considers problem domains requiring multitasking between non-blocking tasks (realtime games seem to be a good example), you'd probably find scheduling much more important there... -- -Chuck