From owner-freebsd-current Tue Sep 15 07:50:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA22326 for freebsd-current-outgoing; Tue, 15 Sep 1998 07:50:49 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from sasami.jurai.net (sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA22320 for ; Tue, 15 Sep 1998 07:50:45 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id KAA27509; Tue, 15 Sep 1998 10:49:28 -0400 (EDT) Date: Tue, 15 Sep 1998 10:49:28 -0400 (EDT) From: "Matthew N. Dodd" To: Mike Smith cc: Alfred Perlstein , freebsd-current@FreeBSD.ORG Subject: Re: Download of FreeBSD 3.0-SNAP In-Reply-To: <199809151044.DAA00966@word.smith.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 15 Sep 1998, Mike Smith wrote: > Natch; shortest seek in the last N slots in the queue is the trivial > workaround. You can go totally nuts with disk scheduling, but it all > basically boils down to not being able to tell what the disk has > remembered (think segmented cache) and which transitions will really > cost you. > > *shrug* TCQ to the rescue. Also keep in mind that most modern disks will start elevator sorting above a certain transaction rate threshold. I see any host performed sorting to be something that is tweaked during tuning as its usefulness in some situations may be very low and in the most pessimal may cause you to burn cycles that would better be spent elsewhere. -- | Matthew N. Dodd |This space | '78 Datsun 280Z | FreeBSD/NetBSD/Sprite/VMS | | winter@jurai.net |is for rent| '84 Volvo 245DL | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message