PS: be sure to use the 'mcelog' utility and package to monitor for ECC
errors. If you have a large number of nodes this will help to identify
flaky memory and cpus with cache memory issues.
On Mon, 4 Sep 2006, stephen mulcahy wrote:
Hi Bruce,
Do you have any idea what the performance impact
I did not check, but would not expect any significant performance impact.
With the 84 msec choice of scrub times, we are only touching about a dozen
cache lines (64 bytes each) per second. I don't see how this could have a
significant impact on performance.
Cheers,
Bruce
On Mon, 4 Se
On Mon, 4 Sep 2006, Joe Landman wrote:
The most important benchmark is the one that uses the same code you use in
the way you are going to use it.
True (and I generally agree with everything else Joe said as well except
that I think he meant a one-dimensional projection, or even two, of a
mult
through 10/100/1000baseT Gigabit Ethernet. Initially we have decided
to setup cluster of 1 master and 3 compute nodes. Thus totaling 16
I think you should consider making the head node separate - in this case,
I'd go with fewer cores, more disk and perhaps less memory. you _can_
get away withou
> Hmmm we recently responded to a government RFP where they
> "require"
> runs on the hardware from the spec suite.
>
> [soap box]
>
> This is counter productive IMO as the spec suite really doesn't do
> much for you in terms of meaningful performance measurements. Does
> about the same a
Robert G. Brown wrote:
This, in turn, was supposed to stimulate a discussion on whether or not
benchmarks of this sort "need" to be licensed and controlled (I would
argue a resounding "no") and if so controlled by whom, to prevent vendor
I agree. Benchmarks, and all data around them are an
In message from "amjad ali" <[EMAIL PROTECTED]> (Wed, 30 Aug 2006
20:28:37 +0500):
Hello, Hi All.
We are developing Beowulf Cluster for the first time at our
university
department. We will perform numerical simulations in CFD on the
cluster. We have chosen that each node (master and compute) of
On Sun, 3 Sep 2006, Ed Hill wrote:
On Sun, 03 Sep 2006 16:08:05 +0200
Toon Moene <[EMAIL PROTECTED]> wrote:
This raises a really "interesting" question about the depth at
which open source GPL code is embedded in a tool when the viral
clause kicks in.
You can't be serious here, Dr. Red-Green
On Sun, 3 Sep 2006, Mark Hahn wrote:
ECC Features
ECC Enabled
ECC Scrub Redirection Enabled
Dram ECC Scrub CTL Disabled
Chip-Kill Disabled
DCACHE ECC Scrub CTLDisabled
L2
