<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Bryan J. Smith wrote:
<blockquote
 cite="mid1152680403.2880.42.camel@bert64.oviedo.smithconcepts.com"
 type="cite">
  <pre wrap="">On Tue, 2006-07-11 at 23:40 -0500, William A. Mahaffey III wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Oooohhhhhhh, you're just too kind :-).
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Seriously William.  We had several threads on your issues with the i865
(as well as i845) month after month after month.  That wasn't even a
"professional/corporate desktop" chipsets, that's the i875.

I'm just trying to help you friend.

  </pre>
  <blockquote type="cite">
    <pre wrap="">When I say lightweight, I *mean* lightweight. NO public access,
    </pre>
  </blockquote>
  <pre wrap=""><!---->
What does "public" have _anything_ to do with it?
In fact, LAN I/O is typically far more intense.

  </pre>
  <blockquote type="cite">
    <pre wrap="">NO apache, NO DNS,
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Apache and DNS typically have more to do with _computational_
performance.  If you're throwing files around on a LAN, that's I/O!

We've had this discussion before, when you've had compatibility and
performance issues.  Moving from an Intel i845/i865 (again, not even a
i875 that is tested for professional, desktop use -- and totally
ignoring the E72xx/75xx) to a ViA KT series is a _lateral_ move.

Again, referring back to your experience with the 694 -- back in the
late '90s, I used to replace i440BX/GX and 693/694 chipsets with
ServerSet IIIs -- often for ~$250.  A measly $100 more in the mainboard
makes _all_ the difference when you're spending $1K!

  </pre>
  <blockquote type="cite">
    <pre wrap="">NO several dozen users at any 1 time, just CPU, RAM, & code to run ad
nauseum.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
What is its function?
  </pre>
</blockquote>
<br>
See below.<br>
<br>
<br>
<blockquote
 cite="mid1152680403.2880.42.camel@bert64.oviedo.smithconcepts.com"
 type="cite">
  <pre wrap="">
Again, why save $100 on a system that costs $500-1,000 anyway, when
another $100 will give you server performance and quality?
  </pre>
</blockquote>
<br>
Probably more like $700.00 total, apparently. $100.00+ does matter,
~15% ....<br>
<br>
<blockquote
 cite="mid1152680403.2880.42.camel@bert64.oviedo.smithconcepts.com"
 type="cite">
  <pre wrap="">
  </pre>
  <blockquote type="cite">
    <pre wrap="">It *will* live at runlevel 3,
    </pre>
  </blockquote>
  <pre wrap=""><!---->
When does "graphics" have _anything_ to do with "storage/communcation"
I/O?  William, I think this is where you keep missing the point, and why
you keep running into issue after issue on your systems.

I can't believe you've now taken all those issues and discussions we had
months ago with your issues and just thrown them out-the-window.  Spend
$175+ on an E72xx series mainboard for P4, or $235 for a HT1000 for
Opteron.

  </pre>
  <blockquote type="cite">
    <pre wrap="">but the server traits end there, for the most part. I was mostly
asking about reasonably complete/stable Linux support for that
chipset, decent %-age of full speed for RAM-intensive calculations,
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Can you elaborate on the application?
  </pre>
</blockquote>
<br>
Sure. Finite Element grid/mesh generation & subsequent analysis,
often coupled w/ CFD grid generation/analysis. Fluid-structure
interaction problems (deforming SRM propellant grains under stress from
the flow resulting from their combustion). Reasonably well resolved 2-D
(i.e., not 3-D, thus I *can* afford pretty good 2-D resolution,
borderline large-eddy type resolution on the fluid side, similar
resolution on the solid side since I spend most of my CPU time on the
fluid side & don't want/need to answer needling questions about
skimping on resolution *anywhere* in the analysis). Turbulent,
sub-sonic/transonic, complex internal geometries on the fluid side,
largish deformations on the solid side. Definitely CPU/RAM intensive,
not quite so I/O intensive. Local drives large enough to catch the
results, then processed by another box on the LAN (where the Tecplot
license lives), but still by me, i.e. only one user at any 1 time.
These boxen are like droids, w/ only 1 master, not dozens like most
public servers. I/O is less important, CPU/RAM/stability are paramount.<br>
<br>
<blockquote
 cite="mid1152680403.2880.42.camel@bert64.oviedo.smithconcepts.com"
 type="cite">
  <pre wrap="">
  </pre>
  <blockquote type="cite">
    <pre wrap="">etc. e.g. good OS/chipset interaction for my somewhat truncated
requirements.
    </pre>
  </blockquote>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="0">-- 
        William A. Mahaffey III

 ----------------------------------------------------------------------

        "The M1 Garand is without doubt the finest implement of war
         ever devised by man."
                           -- Gen. George S. Patton
</pre>
</body>
</html>