Archived from groups: alt.comp.hardware.overclocking (
More info?)
Michael Brown wrote:
> David Maynard wrote:
>
>>Michael Brown wrote:
>>
>>>David Maynard wrote:
>>>
>>>>BigBadger wrote:
>>>>
>>>>>No it's not 333MHz, it's actually a 166 'MHz' FSB processor....333
>>>>>is just AMD hype to sell the virtues of the DDR bus. Intel do the
>>>>>same trick but they multiply the real bus speed by 4x.
>>>>
>>>>Double and quad pumping the bus is not "hype." It's an engineering
>>>>technique for transferring data twice, or 4 times for quad, per
>>>>clock cycle.
>>>>
>>>>333 is the bus cycle rate, e.g. "Bus Speed," and is the relevant
>>>>number from a performance standpoint.
>>>
>>>Oh dear, oh dear, here we go again ...
It depends on whether you
>>>measure the control lines or the data lines for quoting the "bus
>>>speed" number.
>>
>>No it doesn't. It has to do with how many data transfer cycles there
>>are.
>
>
> This is exactly what I mean
There are some lines on the bus that
> "operate" at <x> MHz, and some that "operate" at <4*x> MHz.
It is irrelevant what "some lines" do. What's relevant is the data rate.
> What, then, is
> the bus speed?
The bus 'speed' is the data rate.
> There are valid arguments for both directions. From a
> performance standpoint, I personally think the <x> MHz number is better (and
> expand the "bus width" accordingly); you obviously think the MHz should be
> scaled.
It isn't a matter of 'scaling' anything. The data rate is the data rate.
>>>I actually think a more accurate way of representing it
>>>(performance-wise) is a 128-bit bus (DDR) or 256-bit bus (QDR), both
>>>running at 166MHz.
>>
>>Except it isn't '128 bits' or '256 bits' wide. It does, however,
>>transfer data at either 2, for dual pumped, or 4 times, for quad
>>pumped, the system clock rate.
>
>
> Hence why I explicitly said "performance-wise". The question I was answering
> was:
> Which closer represents the performance of a 64 bit <x> MHz QDR bus?
> (a) A 64-bit <4*x> MHz SDR bus
> (b) A 256-bit <x> MHz SDR bus
> The correct answer is (b).
The correct answer is (a) because that is REALITY. (b) is a figment of your
imagination.
> Of course, at the low level, it's still a 64-bit bus, except one part is
> operating at <x> MHz and another part at <4*x> MHz.
Nope. All the bits of the data arrive at precisely the same rate.
>
> [...]
>
>>>Say you have a 166MHz DDR system
>>>(aka DDR333), and a 100MHz QDR system (aka QDR400), and the CPU runs
>>>at 1GHz (6.0x for DDR, 10.0x for QDR). Excluding memory latencies,
>>>to fill a randomly-accessed 64-byte cache line would take:
>>> Waiting for bus strobe: 3.0 cycles (DDR system), 5.0 cycles (QDR
>>> system) Transferring data: 24 cycles (DDR), 20 cycles (QDR)
>>> Total: 27 cycles (DDR), 25 cycles (QDR)
>>>
>>>So DDR333 is, under random access conditions, only marginally slower
>>>than QDR400. The actual break-even point is 180MHz (actually
>>>slightly above due to memory latencies), but hopefully you get the
>>>idea. Of course, the QDR system will perform better under
>>>"streaming" type conditions, where the higher latency won't matter
>>>so much.
>>
>>No, you're analyzing the memory, not the processor bus.
>
>
> Errm, not at all. I specifically EXCLUDE any memory performance
> considerations from the analysis: see the third line of your quoted section.
You claim to be excluding it but you embed it in your analysis nonetheless.
You also create artificial conditions in direct contrast to reality by, for
example, trying to limit the analysis to 'random access' on a bus that is
specifically designed for, optimized for, and RATED AT it's synchronous
stream transfer rate whether it be SDR, DDR, or QDR.
Heck, the names you (properly) use explain it even as you're denying it:
SRD - Single DATA RATE, DDR - Double DATA RATE, QDR - Quad DATA RATE.
> I'm solely analysing how long it would take to fill (or write out) a
> processor cache line over a DDR/QDR bus, which is pretty much all the
> processor bus is used for.
> The exact same argument applies to the
> point-to-point DDR busses in a K7 SMP system, if having memory in the
> picture makes things confusing for you.
You can wag imaginative theories and pick artificial 'conditions' all you
want. I'm telling you how it works.
>
> [...]
>
>>>Incidentally, this issue is exasparated by the P4's 128-byte cache
>>>line, as opposed to the 64-byte cache line of the K7.
>>
>>Processor (L2) cache has nothing to do with bus speed.
>
>
> Hence my "incidentally" (spot the recurring theme here: I don't usually put
> in words for no reason). The processor cache line size (note: cache LINE
> size, not cache size or anything else) and bus performance characteristics
> are quite interlinked for the performance of a processor. The larger cache
> line size improves streaming performance and decreases random-access
> performance, which is exactly the same characteristics as a QDR bus. My
> point was that the P4 has been heavily tweaked towards streaming
> computations, as opposed to having fast random-access times.
We aren't talking about the "performance of a processor." We're talking
about the bus data rate.
> [...]
>
>>Btw, what don't you call a 3.4 Gig P4 a 200Mhz P4 because the 'real
>>clock' (sic) is 200 Mhz. That 3.4 Gig number is just 'hype'.
>
>
> Why don't you call it a 6.8GHz P4?
Because the reality of it is that it's operating at 3.4 GHz.
> I call it a 3.4GHz CPU because it operates on a 3.4GHz clock rate. The
> external signalling is at 200MHz or 800MHz, but this has not the operating
> frequency of the CPU itself.
Well, close. Yes, it operates at 3.4 Ghz but the "external signaling" is an
irrelevant comment. A 3.4 Gig processor is a 3.4 Gig processor regardless
of the bus speed or even what external clock it derives it's internal clock
from; as long as the internal clock ends up at 3.4 Ghz. And it doesn't
matter if it comes from single pumping, dual pumping, quad pumping, hex
pumping, or any other multiplier of the external clock.
> DDR/QDR is a much trickier problem, as part of
> it is operating at 200MHz, and another part at 800MHz.
Nope, and it's not tricky at all. A 166.6 MHz clocked DDR bus has a stream
rate of 333 million data cycles per second and a 200 MHz clocked Quad
pumped bus has a stream rate of 800 million data cycles per second. Which,
btw, is independednt of the bus width.
Hertz is the synonym of "cycles per second." I.E. In the above examples,
the DDR bus has a 333 MHz data rate and the QDR bus has an 800MHz data
rate; which happens to be the way they are typically rated.
> Sort of as if the
> ALUs all operated at 6.8GHz and the floating point units all operated at
> 3.4GHz. Oh, dearie me ...
The problem is you want everything to be a 'waveform' and that just isn't
the case. And, btw, not every signal in a 3.4 GHz processor is jumping
around at 3.4Ghz either: that's just the clock rate.
>
> [...]
>
> --
> Michael Brown
> www.emboss.co.nz : OOS/RSI software and more
> Add michael@ to emboss.co.nz - My inbox is always open
>
>