Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 04 Mar 1995 00:06:29 -0800
From:      "Justin T. Gibbs" <gibbs@estienne.CS.Berkeley.EDU>
To:        "Russell L. Carter" <rcarter@geli.com>
Cc:        current@FreeBSD.org
Subject:   Re: "feel" of recent systems 
Message-ID:  <199503040806.AAA03149@estienne.cs.berkeley.edu>
In-Reply-To: Your message of "Fri, 03 Mar 1995 22:50:40 PST." <199503040650.WAA18979@geli.clusternet> 

next in thread | previous in thread | raw e-mail | index | archive | help
>Date: Fri, 3 Mar 1995 22:03:09 -0800
>From: "Russell L. Carter" <rcarter>
>To: davidg@Root.COM
>Subject: Re: "feel" of recent systems
>
>|From: David Greenman <davidg@Root.COM>
>|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...

I think you missed David's point.  You may be using the system in different
ways or with different devices than David or any other developer.  What
are you doing when you notice the delays?  Thats all that he is asking.

>|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.

You missed the point again.  Bonnie is not perfect.  It is affected by
local disk fragmentation as David says above.  You're Bonnie output is
not enough for anyone to pick out exactly what is causing your problem
because it can be biased.  A more reproduceable benchmark that does not
depend on disk, controller, fragmentation, etc is what is needed.

>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.

I don't see why you think this is his attitude.  He clearly says that there
are many bugs on the stack that are being worked on.  My oppinion is that
you are seeing what John Dyson calls the "chatter" bug.  It has to do with
poorly caching filesystem meta-data.  This is not a SCSI system specific
problem and if you actively read -current, you should have heard all about
it.

>
>Regards,
>Russell
>

--
Justin T. Gibbs
==============================================
TCS Instructional Group - Programmer/Analyst 1
  Cory | Po | Danube | Volga | Parker | Torus
==============================================



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503040806.AAA03149>