[sf-lug] Rick's explanation of his internet setup.

[Rick Moen]

Quoting jim stockford (jim at well.com):

>    rick, you mention i/o considerations when you
> discuss balance.
>    could you elucidate some? 

Hi, sorry to say that I'm going to have to rush this reply -- a lot.  
(Am doing work stuff.)  'Hope it comes out coherent and relevant.

I sort of threw into "I/O" just about everything else other than the
aspects I mentioned:  disk access, various actual I/O ports, memory
access.  But I meant primarily disk (mass storage subsystem) performance
-- given that gamers _are_ smart enough to ensure adequate amounts of
fast RAM on a fast memory bus.

>    my interest is first the bus: PCI is best?
>    then NIC? then what?

Apologies, but I don't understand the question.

In _any_ given situation, the component you want to take out and shoot
is whatever is the one that's holding you back, that is the most
significant bottleneck for whatever operations are going on at that
moment.

As a (hypothetical) system designer, your task is to allocate your
spending dollars in the various categories so that they do the most 
good, in the sense that (theoretically) shifting a dollar from that 
aspect of the machine to any other would result in slower and less
satisfactory performance.  That's what a bottleneck _is_.

Basically, bottlenecks exist only relative to usage models and situations. 
It makes no sense to say "You must always get a good X".


Imagine that I had an Internet server running my domain on a 1.54Mbps
T-1 line, again.  (That would elminate, for purposes of our
hypothetical, the current aDSL bottleneck, in the presence of which
basically _all_ of uncle-enzo's pieces are so far in excess of need that
it's a "who cares" situation.)

In that case, _if_ I attempted to do that server-role duty (Apache
httpd, MySQL, rsync daemon, vsftpd, OpenSSHd, ntpd, etc.) using Linux on
a typical gamer box, it would be the (usually) anemic hard drive
subsystem that held the system back, mostly.  By contrast, the extremely
expensive CPU(s) would go almost entirely to waste, and ditto (of
course) the Nvidia GeForce4 video thingie, even if the machine didn't
run headless as normal.

The machine that actually _did_ fill that role (on the T-1) back around
1997 also simultaneously served as my main desktop box -- multiple
xterms, AbiWord, Netscape Communicator, Gnumeric, Window Maker for the 
window manager.  It was my now-antique K2/233 with 128MB of PC-100 CAS2
SDRAM and two very fast SCSI drives.  And _that_ machine could saturate
the T-1 while simultaneously being my desktop box in foreground.

Sorry that I can't give you easy, bankable guidelines:  In truth, all 
aspects of the hardware are important, but just not _equally_ important 
unless you either cut too deeply or splurge too much in that area.  What
is too much or too little is a matter of judgement and knowing what
_types_ of stress (in what hardware areas) the intended machine usage
will put on the box.  

Adrien's point is a really good one, that a machine that is intended to
run Half-Life -- either in a pure MS-Windows environment or in an
emulated Windows environment under Linux/X11 -- pretty much ought to 
have its strengths and weaknesses arranged the way a typical gamer box
is:  stupendous (and expensive) CPU and 3D-oriented video, and
relatively sucky in I/O areas particularly mass storage performance.

My point was intended to parallel that:  that, even aside from
open-source vs. proprietary driver issues, a box intended for 
_more typical_ tasks in a native-Linux environment (whether server or
desktop) would do better at any given price point if it had less
emphasis in typical-gamer areas, and more on good HD performance.
(Snappy video is often a really good idea, but that does _not_ require
fancy 3D stuff used basically only in 3D games and some sorts of exotic
scientific "visualisation" software.  E.g., an aging Matrox card with
exceptional 2D aka regular video imaging might be just the thing.)