On Wed, 18 Dec 2002 00:01:43 -0500 (EST) woods@weird.com (Greg A. Woods)
wrote:

> [[ please honor my reply-to:, at least if you're going to reply to the
> list, so that I don't get duplicates -- and do feel free to set your own
> reply-to: similarly! ]]
> 

done. kinda. sylpheed/MH isn't quite as smart as I'd hoped.

> [ On Wednesday, December 18, 2002 at 14:20:59 (+1000), George Michaelson
> wrote: ]
> > Subject: Re: UVM/other problems for desktop users in current?
> >
> > I'm running what a normal desktop user self-supporting can expect to have
> > to run. If the mix is 'bad' then its worth noting the interactive response
> > on other BSD variants (FreeBSD) isn't this bad, and on Linux is
> > impercepable by comparison, *for the same job mix*
> 
> You can't expect the default out-of-the-box kernel to be tuned ideally
> for all possible job mixes.  NetBSD seems to work better, "out of the
> box", as a plain multi-user server, not as a "do it all wonder
> workstation".  Maybe those other systems have been tuned to give the GUI
> a bigger share of the resources pie.

Yes. I think thats very true. Pragmatically, they (FreeBSD/Lunix) tune for the
end-user experience and offer guidance to server-end people to re-tune.
However, I've not found their out-of-the-cd kernel to be workable for other
reasons, such as the compiled-in memory limits, or needing MP. But after a
kernel re-build I found FreeBSD very performant on servers with next to no
sysctl tuning. That bears thinking about.

> 
> > I realize this is subjective measures stuff, the thing is, its noticably
> > differently worse on this NetBSD. Which is a shame, because in so many
> > other ways its a better, more runnable release family.
> 
> Still, really, what do you expect when you go about asking your CPU do
> run a whole bunch of very large applications, all which must display
> their updates through another large application, all the while you're
> asking it to work as hard it can at running some compiles and doing some
> I/O intensive wandering about on large portions of your filesystem?
> 
> Something _must_ suffer when you punish your machine that way.  On
> NetBSD it's the Xserver, at least that's what happens "out of the box".
> 

Ok, within limits I can buy this. But, out of the box, other BSD architectures
seem to provide a sweeter sweetspot. X may be a dog, but on a Ghz CPU and big
memory its kinda strange NeBSD can't find the same spot.

> > Right. So in not running 'new' kernels, is it possible that we're on the
> > 'older is better' track here, the difference between -stable and -current
> > and
> 
> No, absolutely not.  My point was that I'm running a kernel that uses
> pretty much the default VM tuning parameters (and I haven't changed them
> in the code).  If you are running a newer kernel then you have a lot
> more knobs to twist than I do.
> 

Last time I asked about this I got the stock answer. Its 'suck it and see'
with some minimal guidance on 4 values to try increasing 'until it stops
getting better'. -Thats a little unfair on the helpful people (perry) but only
a little. [ and hey, it *is* current, you get what you pay for, if you want it
better make it better etc. ie, I know its down to me to fix my own problem,
and thats how it should be. (no sarcasm intended) -ggm]

> > So, from the general "big file I/O makes it slow" I'm  honing in on "X is
> > really not good in the jobmix here". -Is this maybe something fixable in
> > X, or in the way I run X? I self-compiled from /usr/xsrc.
> 
> There's really nothing you can do to fix X.  The Xserver is not meant to
> be run on a compute server.  The network is the computer!  ;-)
> 

Ah, plan9 here we come. Yes, but back in the office, in the real world, my
budget is one box! I'm the tech manager, the last bastion of BSD in a world of
Linux clones, running a room full of RedHat with NetBSD on me, and no other
machine. This is *it* its my mail, my X, my filestore, my server, my source
tree. I would suspect there are more than a few die-hards like me at IETF who
have to run themselves on one box, or rarely are at home where the NFS sources
are. [Its bizarre to have become the Dilbert PHB, and be running BSD, while
the real 'droids run Linux. I also have an ADM5 on the floor and a ASR-33
which they find mildly amusing]

> I don't think Xserver should ever be run on the same server system where
> anyone is trying to do CPU and I/O intensive work -- the Xserver should
> only be run on a workstation that's more tuned to fast display updates
> (and one workstation per user!), eg. even a dedicated X-terminal.
> 
> A workstation should not be expected to do big I/O and CPU intensive
> things like CVS and "make build" and whatnot -- that's a server's job.
> A workstation is not a compute server and a workstation is not a file
> server.  :-)

A budget is not a piece of elastic. Sometimes you have to do it on one.

 
> A GUI of any kind takes a lot of resources, and a different mix of
> resources, and a very different set of acceptable response times, than
> your average old-fashioned unix job mix.

Greg, I really can respect where you are coming from, but this is so ...
1970s. We've moved on from slow edge boxes, to a world where the mythical 3M's
has come true, and we all CAN have a (m)egabyte of memory, a (m)egamixel and a
(m)ip on one box. [anybody else remember that slogan?] -I am getting
castigated by the REAL phb's around here for being so anal about making
effective use of the boxen. For them, these problems were solved by money some
time ago. Yes Virginia, you can expect a current spec PC to do these things at
the same time. Hell, I've sat at Microvaxen or 3/50s which had better
interactive feel in-context, at that time, doing basic work as well as screen
work. 

Peter Seebach points out he has a 2.4Gz 640Mb system which is dog slow doing
CVS. With that much memory/CPU bandwidth, there should be no problem. No?

-George