From owner-freebsd-current Fri Mar 3 22:51:59 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id WAA17851 for current-outgoing; Fri, 3 Mar 1995 22:51:59 -0800 Received: from shell1.best.com (shell1.best.com [204.156.128.10]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id WAA17845 for ; Fri, 3 Mar 1995 22:51:58 -0800 Received: from geli.clusternet (rcarter.vip.best.com [204.156.137.2]) by shell1.best.com (8.6.10/8.6.5) with ESMTP id WAA13055 for ; Fri, 3 Mar 1995 22:51:32 -0800 Received: (from rcarter@localhost) by geli.clusternet (8.6.10/8.6.9) id WAA18979 for current@freebsd.org; Fri, 3 Mar 1995 22:50:40 -0800 Date: Fri, 3 Mar 1995 22:50:40 -0800 From: "Russell L. Carter" Message-Id: <199503040650.WAA18979@geli.clusternet> To: current@FreeBSD.org Subject: Re: "feel" of recent systems Sender: current-owner@FreeBSD.org Precedence: bulk Date: Fri, 3 Mar 1995 22:03:09 -0800 From: "Russell L. Carter" To: davidg@Root.COM Subject: Re: "feel" of recent systems |From: David Greenman |Reply-To: davidg@Root.COM |Date: Fri, 03 Mar 1995 21:44:58 -0800 |Sender: root@corbin.Root.COM | |>I wonder if anybody has noticed a tad bit of hesitancy in the system |>since a few days ago. It has revived a little nostalgia in |>me, since the system I've always thought of as being the very best |>at running heavy loads: CRI Cray Y-MPs running UNICOS 6.1+, had |>the same feel; could anybody improving the system comment |>on their philosophy for doing these changes? Does the overall |>system throughput improve? | | There are multiple bugs in several parts of the system that could be |causing your specific problem. The NCR driver has been changing, for instance, #1, the hesitancy is *not* a problem. (IMHO) |and this might have something to do with it. ...and of course there are the |problems with buffer management/directory caching that we still haven't found |an optimal solution for. We always strive to strike the best balance between |overall performance and responsiveness...but -current isn't production code, #2, Who claimed it was, or ever should be? I take jkh's representations to heart. |and we make no representations that it is. If you could be more specific |about certain kinds of operations that appear slower, this would help us #3, (This will come off the wrong way, but damn the torpedos:) Use the system dammit, and you'll notice the delays... |find the problems (I saw your Bonnie results...these really aren't very |useful by themselves, however, as they are affected too much by local disk |fragmentation). #4, Wrong! Nothing personal intended!!!!!! I've used these on a couple of dozen systems, running a lot of different unices, and if they had susceptibilities I would smoke them out myself. I have absolutely nothing to gain by using inaccurate tools. If you're trying to say the scsi system isn't moderately broken, performance wise, since the 021095-SNAP, I'd really like to know why. Regards, Russell