[gentoo-amd64] Re: Problem with emerge on a dual-processor machine [SOLVED]

[Duncan]

"Vesna Petrovic" <vesna.petrovic@×××××.com> posted
60bedadc0611011159s301f9b4eg76ac6e3e63e2f1b7@××××××××××.com, excerpted
below, on  Wed, 01 Nov 2006 14:59:59 -0500:

> You were right, the problem does seem to be memory. I swapped the memory
> modules, and the system was not freezing any more. I started getting
> 'Segmentation fault' errors during compile, so I limited the memory clock in
> BIOS @ 166MHZ. Now everything works fine.
> How can I find out what is the best value to set the memory clock limit to?
> I tried 200MHz, and the segmentation faults still occurred. When I set 183
> MHz, BIOS reported that the memory clock is 'unknown'. So I set it to
> 166MHz, which was the next value in the list. Is this a good method for
> determining the best value?

Well, memory sticks normally have a chip in them that tells the system
what their timings should be.  Ideally, the system can read this info and
configure the system hardware based on it, and there won't be an issue. 
Unfortunately, particularly with generic memory, which is often branded
memory that simply didn't pass some test or another so it's rejected for
branded and gets sold as generic (thus explaining why generic is much
cheaper), reality doesn't always match the claims the stick makes.  Also,
certain motherboards don't function perfectly with certain memory, due to
capacitance and other "noise in the circuit traces" issues.  These issues
of course get worse as operating frequency increases, so as memory speeds
get faster and faster, sensitivity to these sorts of issues gets more and
more common.  IOW, it's not /always/ the memory at fault.  Sometimes it's
the mobo or neither one fully, but simply a bad interaction between that
particular memory and that particular mobo.

Again ideally, when an issue such as this appears, the memory is still new
and you can send it back for an exchange or refund.  If it won't work at
rated speeds, that's the preferred solution. Of course, if you are reusing
memory previously used elsewhere, or otherwise don't have a warrantee you
can fall back on, that "preferred solution" may not be available, and you
get to try to cope with what you have the best way you can.

As far as the method you used to determine the limit speed value, yeah,
that's more or less what one does...  Again, it's not ideal, ideal is
sending the memory back for a replace or refund, but ideal isn't always an
available option.

In my case, once a BIOS upgrade with the memory declock option became
available, I was fortunate enough to only need to declock one notch, from
200 MHz (DDRed to 400 MHz, times the 8-bit bus, equals the standard
PC3200, 3200 MB/sec rating) to 183.3 MHz (DDRed to 366.6 MHz, x 8 ~=
PC3000).  At 183.3 MHz it was rock-stable -- I was even able to tweak the
individual wait-state timings up a few notches, without compromising
stability at all, thus regaining a bit of the performance I'd lost with the
declock.

In your case, it appears you are having to declock a couple notches. 
However, provided you have the BIOS settings to tweak individual memory
parameters, AND THE PATIENCE TO DO IT, you can probably tweak the
individual timings up a bit as I could, thus recovering some of the lost
performance.  You need a guide to what all those settings are, of course,
in ordered to do anything reasonable instead of just randomly poking
about in the dark, but google is your friend as it was mine. The bigger
problem is that as you get closer to the tolerances of the hardware,
you'll find you have almost but not entirely stable performance, that will
require running the system normally for some time to test stability,
between tweaks.  You'll need to run it for a day or more, doing some
emerges or other serious system stressing, between each tweak.  Since
booting actually takes time as well and I normally keep my system on 24/7,
while I did some tweaking, I never did find out how far I could actually
go or which particular setting was the most sensitive and thus likely the
one that destabilized it at the faster speeds.

So yeah, assuming you can't send the memory back, the method you used to
figure out the best clocking you could get was fine.  You may be able to
tweak things further, but at some point you are spending far more time
tweaking and testing than you would be just using the slower memory
settings as they are, and further tweaking /is/ something of a black art,
so...

Of course, the other alternative, even if you can't send the memory back,
is to accelerate your memory upgrade plans.  The memory I had the issues
with was two sticks of half-gig, giving me a gig of memory total. 
Eventually, I upgraded to 8 gig of memory.  That's overkill for the time
being for me, but four gig should be nice, and will allow you to do things
like putting $PORTAGE_TMPDIR on tmpfs so your compiles use memory instead
of disk for scratch-space.  That makes a pretty big difference in compile
speeds. =8^)  

(I went ahead and did the 8 gig here, as I'm running a dual Opteron system
currently with 242s, and am planning on upgrading to dual-core 285s either
late this year or early next (they are down to ~$1300 for the pair of 285s
on pricewatch, now). That'll be my last upgrade system upgrade for some
time, two, likely three years or longer. Since I bought the system and set
it up, originally with dual 242s and a gig of memory, in late 2003,
meaning it's three years old now, by the time I upgrade again, the mobo
will be at LEAST five years old, very likely six, and possibly seven or
more!  Of course, it was a $400 mobo, too, so it SHOULD last awhile.  I
expect that when I /do/ upgrade again, it'll be to a single CPU system
once again, but by that time the single CPU will be 8-core, thus providing
a decent upgrade from what will be a dual-dual-core system, four-cores
total.  I also expect I'll pay significantly less for it than I did for
this one as originally outfitted, back in 2003.)

(Note that with AMD's plans for multi-socket boards that can take CPUs,
GPUs and assorted other coprocessing units interchangeable in the same
sockets, I didn't say single-socket board.  I expect my next upgrade will
again be dual-socket, but that dual-socket boards will be commonplace and
much cheaper by then, as that'll be a standard solution for plugging in
GPUs and the like, and indeed, I expect I'll install that single 8-core CPU
in one, and whatever GPU in the other.  Who knows?  Maybe high-speed
memory will come in the same socket form-factor by then, and it'll be a
quad-socket board, one for the 8-core CPU, one for the GPU, and two for
memory.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@g.o mailing list