Archived from groups: alt.comp.hardware.overclocking.amd (
More info?)
Wes Newell wrote:
> On Tue, 19 Apr 2005 01:31:05 +1000, Michael Brown wrote:
>
>> And in his first post, Wes Newell wrote:
>> [...]
>>> On my old Jetway S755MAX board
>>> it's a snap to take my 3000+ from the default 2000MHz to 2330MHz by
>>> lowering the base ram bus to 133MHz, lowering the HT link multiplier
>>> to 3x, and raisng the FSB clock to 233MHz (unfortunately the max
>>> setting for this board).
>> [...]
>>
>> I think what he was referring to was the lowered RAM speed. I'm not
>> sure what your RAM can handle, but it's only running at 146MHz now.
>> Depending on the application and your original RAM speed, this could
>> be hurting things a bit.
>
> Before overclocking, the ram speed was set Byspd at 166Mhz. After
> lowering it to 133 manually and raising the FSB clock to 233Mhz, the
> resulting ram speed is back to 166MHz so there was no difference.
Actually, both you and I are incorrect
Previously, you had a memory
divider of ceil(10/(5/6)) = 12, so your memory was at 166MHz. Afterwards,
you had a divider of ceil(10/(2/3)) = 15 giving you 155MHz. My program gave
ceil(10/(2/3)) = 16 due to roundoff error, so it looks like I've got a bug
to fix! So there's a minor decrease; not as bad as I initially thought.
> Even if there was a difference it wouldn't have mattered much at all
> in terms of performance. 90% of data request from the cpu are handled
> by the cache, not the base ram. So with the ram even at 83Mhz, it's
> only 50% slower 10% of the time.
Regardless of where you pulled that 90% figure from, it's not that simple.
Consider a simple bit of code that (using traditional integer x86) just sums
up an array of 32-bit numbers. For a given cacheline, there will be one
cache miss and 15 cache hits. The cache hit instructions will be very cheap;
1 cycle per instruction throughput. The cache miss will be very expensive.
Say you have a 2GHz machine with 200MHz single-channel RAM. Ignoring latency
(assuming the prefetcher is doing its job correctly), it takes 4 RAM bus
cycles to fetch a cache line. This equates to 40 cycles. The cache-hitting
instructions will be inside this, so your cache miss instruction will take
25 cycles (give or take a few). Changing to a 100MHz bus speed, you require
80 cycles per cacheline, with a cacheline miss time of 65 cycles. Overall
performance will still halve (bandwidth limited), despite having a cache hit
rate of 15/16 = 94%. That's why you can't extrapolate from the cache hit
ratio to get the expected impact on performance from slower RAM.
Actual performance change will depend heavily on cache size (obvious),
processor speed (higher speed processor => more impact), application. For
example, something that is simply manipulating around 50k vertices (around
780KB), will be heavily dependent on RAM speed with 256KB cache, moderately
dependent with 512KB, but more or less independent of RAM speed with 1MB
cache (at which point it would all fit inside). The same application would
be very memory dependent in all cases at 100k vertices, and pretty much
independent in all cases at 10k vertices.
> Slow your ram speed down and note the difference.
I'd try, but none of the boards I have support running memory async. None
support multipliers well either, so dropping the FSB and pumping up the
multiplier doesn't work either. You, however, are in an ideal situation to
try it out and report back the result
[...]
> If one is still worried about the ram speed, and wanted to run it at
> 200Mhz, I could have left it at 166Mhz and then raised the FSB to
> 233Mhz and then the ram would jump to 200MHz.
In this case it'd be 194MHz ... close enough not to worry about any
performance difference
[...]
--
Michael Brown
www.emboss.co.nz : OOS/RSI software and more
Add michael@ to emboss.co.nz ---+--- My inbox is always open
/www.hardocp.com/article.html?art=Njg2
Facebook
Twitter