On Wed, 18 Dec 2002, Greg A. Woods wrote:

# 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?

FWIW:

	850MHz Athlon, 640MB RAM, NetBSD 1.6K (current as of today).

No problems running cvs update -d -P from /usr/src, followed by
a compile of /usr/src, all the while running X and, in fact, xmms.
No music skips, and the build looks like a sun3 running 'make -n'.  Also
runs as a file server, though *very* lightly loaded in that department.

Any other explanations?  I would suspect that the 256MB RAM has a LOT
to do with this one.

[on the downside, I can't run xMAME during a build with any degree of
smoothitude, and <sarcasm> Gee, Doesn't THAT Just Suck? </sarcasm>.]

# 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!  ;-)

Heh.  Indeed.

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

See above.  I flout your example, sirrah!  Other people log in here,
too.

# 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.  :-)

Heh.  "It is if you have a server-class machine acting like a workstation."
Oh, wait, I'm sorry ...
<sarcasm target="purist" intensity="high">
...but all my disks are IDE, so it can't be a server-class machine.
</sarcasm>

[sorry, is that my outside keyboard...?]

# You could try tuning your system to give the Xserver process more RAM
# and more scheduler priority, and you could lock all it's pages in core
# so that it never has to wait for paging, but that'll probably hurt the
# throughput of your non-GUI jobs.
# As soon as you get accustomed to running your GUI on a workstation and
# not on your server(s) then you'll come to appreciate what I said about
# never being happy with any system where the Xserver is run on a
# multi-user multitasking server.

Well, SOMEthing is going amiss there that's not happening here
with me.  Running softdeps (but not async).

# Sure you can get away with running Xserver and one big application at a
# time like Mozilla or what have you on a workstation, but that's because
# you're essentially doing primarily GUI stuff.  However once you start
# compiling and running I/O intensive stuff like CVS then you're doing
# more what's done on a multi-user general-purpose server.  Those two
# kinds of application just do not mix well on a single CPU system -- you
# can't expect to get good compiler throughput and at the same time have
# sub-second GUI response, especially when you context switch through a
# half dozen big GUI applications all at once too!

Poppycock.  What sort of benchmarks would you like for this?

# In fact you should probably be happy that your workstation can context
# switch fast enough to handle the mouse and the Xserver and one big GUI
# application like a mozilla process all at once.  Try that on a SPARC-2
# or something older, and be prepared for it to crawl like cold molasses!  ;-)

Well, on a SPARCs* 2, sure!  X by itself will crawl like cold molasses
on a frozen water pipe.  Did that for a while.

This guy's running on a P4 2GHz with as much memory as I do.  There
is something else wrong which cannot be explained away by load
balance.

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

Now, that I cannot refute.  But I could make the same statement pertinent
to a high-availability heavily-used DB server...

				--*greywolf;
--
NetBSD: Rock solid!