public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Nikos Chantziaras <realnc@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: [gentoo-user] Re: Overclocking CPU causes segmentation fault
Date: Wed, 23 Jan 2013 20:46:14 +0200	[thread overview]
Message-ID: <kdpb6c$8ah$1@ger.gmane.org> (raw)
In-Reply-To: <51001B00.6030102@googlemail.com>

On 23/01/13 19:16, Volker Armin Hemmann wrote:
> Am 23.01.2013 16:35, schrieb Nikos Chantziaras:
>> On 23/01/13 17:09, Nilesh Govindrajan wrote:
>>> On Wednesday 23 January 2013 07:52:03 PM IST, Nikos Chantziaras wrote:
>>>> [...]
>>>> In my experience, most of the time you can overclock.  The issue is
>>>> with the user not knowing exactly how to do it.  You need to
>>>> understand a few things and how they affect each other.  It's not just
>>>> a knob you can turn.
>>>
>>> That pretty much applies to me. I don't know much about hardware stuff.
>>> Regarding your 1 Ghz overclock, you probably have good components in
>>> terms of RAM & SMPS.
>>> When I bought this rig in 2008, I knew nothing about good components,
>>> blindly trusted local vendor... also internet shopping wasn't advanced
>>> here.
>>> So pretty much substandard components.
>>
>> The part that's really important is the mainboard.  RAM doesn't
>> matter.  In my case, I had pretty basic 800MHz DDR2 RAM.  Raising the
>> FSB would bring it above that, so I changed the DRAM ratio to 1:1, and
>> the RAM then ran at only 600Mhz.
>>
>> That was the starting point to rule out RAM problems.  After that, I
>> raised FSB but kept the VCore constant until I hit the first
>> instabilities.  When that happened, I raised VCore a bit.  Rinse and
>> repeat, until the VCore was still below the maximum recommendation by
>> Intel.  That happened at 3.4GHz (378MHz FSB * 9 CPU multiplier =
>> 3402MHz CPU clock.)  The E6600 CPU I got was an average sample.
>> Others were running it at 3.6GHz (or even higher with water cooling.)
>>
>> This was a process that took about 3 days to complete (needs a lot of
>> stability testing.)  The good thing about those older CPUs was that
>> the performance boost I got by OCing wasn't just scaling linearly with
>> the CPU frequency.  It was scaling *better* than that, because raising
>> the FSB also made the mainboard itself perform better and with lower
>> latencies.
>>
> and here we are - the point where the suspension of disbelief ends.
>
> All you may have gained you threw away with the slower ram - and you are
> trying to tell us that your rig was faster?

Yes.  It made the difference in all games.  I'm talking 40 vs 60FPS 
here.  It was huge.

The RAM wasn't much slower.  Stock was 800 and I was running it at 756.


> You do know that with today's CPUs the CPU is not the bottleneck - the
> slow as molasses, no speed bump for 10 years ram is.
>
> (just look at the internal clock rate of dram chips - and you realize
> that ddr1-3 are pretty much the same crap).

The slightly slower RAM had no effect.  As I said, the performance gain 
was huge.  If the RAM ends up heavily underclocked to the FSB change, 
you just pick another ratio for it that brings it closer to its stock 
frequency, or slightly above it.  Again, a good motherboard that has 
plenty of ratios to choose from helps immensely.

Of course today this isn't important anymore.  On my i5 CPU I can change 
the CPU multiplier.  Not that I do; performance is plenty right now 
without OCing.  I intend to overclock it in the future, just like I did 
with the C2D; if new games get more demanding, I'll do it then.



  parent reply	other threads:[~2013-01-23 18:47 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-22  7:41 [gentoo-user] Overclocking CPU causes segmentation fault Nilesh Govindrajan
2013-01-22  9:16 ` Helmut Jarausch
2013-01-22  9:43 ` [gentoo-user] " Nikos Chantziaras
2013-01-22 11:14   ` Nilesh Govindrajan
2013-01-22 11:43     ` Nikos Chantziaras
2013-01-22 11:46       ` Nilesh Govindrajan
2013-01-22 13:49         ` Nilesh Govindrajan
2013-01-22 18:35 ` [gentoo-user] " Volker Armin Hemmann
2013-01-22 18:45   ` Nilesh Govindrajan
2013-01-23  1:55     ` Dale
2013-01-23  8:21       ` [gentoo-user] " Nikos Chantziaras
2013-01-23 12:09         ` Dale
2013-01-23 14:22           ` Nikos Chantziaras
2013-01-23 15:09             ` Nilesh Govindrajan
2013-01-23 15:35               ` Nikos Chantziaras
2013-01-23 16:22                 ` Bruce Hill
2013-01-23 16:32                   ` Nikos Chantziaras
2013-01-23 17:16                 ` Volker Armin Hemmann
2013-01-23 17:21                   ` Michael Mol
2013-01-23 18:46                   ` Nikos Chantziaras [this message]
2013-01-23 17:13         ` Volker Armin Hemmann
2013-01-23 18:52           ` Nikos Chantziaras
2013-01-24  2:23       ` [gentoo-user] " Peter Humphrey
2013-01-24  4:08         ` Dale

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='kdpb6c$8ah$1@ger.gmane.org' \
    --to=realnc@gmail.com \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox