Maximum System Bus Speed

kinda.... i was really after whether or not the 200(MHz? : )) bus was safe
for the processor
"David Maynard" wrote in message
...
Ziferten wrote:
Alright, so I didn't get an answer, but I learned way more about Hertz!

Hehe. Well, actually you did. What it "supports" is what it's rated at.

I rather suspect you want to know what you can 'get out of it' and that
was
answered too.


"Ziferten" wrote in message
...

What is the maximum that the Athlon XP 2800+ supports? I use a Gigabyte
GA-7N400 Pro2 by the way

You seem to have a misconception about how DDR/QDR busses operate, or
possibly busses in general. A "bus" in the computer world (ie: the world in
which DDR and QDR have a meaning) includes both the data lines, and the
control/address lines (different than a bus in the electrical world, which
is usually just a collection of similarly functioning lines). For example,
the EV6 bus scheme of the 21264/K7 has 72 bidirectional data lines (64 bits
data bits + 8 ECC bits), and 26 unidirectional control/address lines, plus
several other miscellaneous lines. The data lines "operate" at 2x or 4x
MHz, but the control and address lines only "operate" at x MHz. The "bus"
includes both data AND control/address lines. EVERY request across the bus
requires the use of the control lines, so they are no less important than
the data lines.

A request across the bus can only be started through the use of the control
lines. You can't start sending the data, then send the address later. So if
a request comes in at time 0.25 on a QDR bus, you have to wait until time
1.0 before you can start the transmission, even if nothing was sent at time
0.

For example, sending 32 bytes across a x MHz 64-bit QDR bus goes as
follows (simplified):
time 0.00: Bus sits idle
time 0.25: Bus sits idle, request is sendable but cannot be sent
time 0.50: Bus sits idle, request is sendable but cannot be sent
time 0.75: Bus sits idle, request is sendable but cannot be sent
time 1.00: Request sent
time 1.25: Request data continues
time 1.50: Request data continues
time 1.75: Request data continues
time 2.00: Bus sits idle, ready for next request
etc etc

In a x*4MHz 64-bit SDR bus, it would look like:
time 0.00: Bus sits idle
time 0.25: Request sent
time 0.50: Request data continues
time 0.75: Request data continues
time 1.00: Request data continues
time 1.25: Bus sits idle, ready for next request
etc etc

On a x MHz 256-bit SDR bus:
time 0.00: Bus sits idle
time 1.00: Request sent (all 32 bytes in a single cycle)
time 2.00: Bus sits idle, ready for next request

Which brings me back to the original point that an x MHz y bit QDR bus
is equavalent in performance to a x MHz 4*y bit SDR bus, and slower than
an 4*x MHz y bit SDR bus.

I know you dislike bringing memory into it, but the exact same thing applies
to DDR memory. Requests can only be sent on integer cycles, but data can be
sent on both integer and half-integer cycles. This is why DDR400 chips have
a 5ns access time, not 2.5ns.

David Maynard wrote:
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.

Why are the data lines more important than the signal lines when determining
how many MHz the bus operates at? Without both, you don't have a bus, and
there are arguments for adopting either of the two speeds.

What, then, is the bus speed?

The bus 'speed' is the data rate.

nitpick
Data rate is measured in bps, not MHz. Which is why I'm semi-comfortable
with the DDR333/DDR400 terminology, but dislike people saying it's a 333MHz
bus.
/nitpick

What I *think* you mean is that the data signal characteristics are more
important than the control signal characteristics. Again, there are
arguments for both sides: the data signal characteristics are more important
under streaming conditions (the norm for GPUs), control signal
characteristics are more important under random access conditions (the norm
for CPUs).

[...]
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.

Again, you miss the "performance-wise" part. See the bit at the top of the
post for the reasoning behind this.

[...]
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.

Please, tell me where in my analysis I bring memory performance into it
(excluding the "slightly above" remark, of course). All of the numbers above
are only influenced by the speed and signalling scheme of the bus in
question. A few quotes below, I say that you can think of it as two
processors exchanging a cache line. Another option is a write to an I/O
port. This is even more dramatic, as these writes are not cached, and DDR333
bus will annihilate a QDR400 bus: the DDR333 bus will do 166 million I/O's
per second, whereas the QDR400 bus will only manage 100 million per second.

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.

Could you please provide a reference that states that the EV6 bus was
"specifically designed for" streaming data transfers. I'm not holding my
breath.

And limiting the analysis to non-streaming applications is creating
artifical conditions? Excluding applications such as media encoding/decoding
and large matix computations, much of the traffic that flows across the bus
is random-access for the purpose of analysis. To get into the streaming
case, you need to be running a bus-bandwidth limited task. Believe it or
not, just about everything except media encoding/decoding or large matrix
operations are CPU limited, not bus limited (which is why you don't get a
50% increase in performance moving from 133x15 to 200x10).

Certainly, the P4 is designed and tweaked for streaming, but that doesn't
mean that ALL DDR/QDR busses are designed/tweaked for that purpose. The main
reason why DDR/QDR was implemented is that it's easier to use a x bit bus
at 2*y MHz, as opposed to running a 2*x bit bus at y MHz due to signal
skew problems. Sorta similar reasons as to why it's cheaper to use a USB2
interface than a EPP interface.

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.

Please provide a quote where I say that the data lines are running at the
same speeds as the control lines. They are most certainly typo's and I'd
like to correct them. What I HAVE said is that the performance of a DDR bus
running at 166MHz (control signal clock) is identical in performance to a
SDR bus that is twice as wide running at 166MHz. It is NOT equavalent in
performance to a SDR bus (running at the same bus width as the DDR bus)
running at 333MHz.

I use the names DDR333, QDR400, etc (note the lack of MHz) simply because
these have become the "standard" names for the particular busses. I would
NOT call a DDR333 a 333MHz DDR bus though. To me, this says that the bus
runs at 333MHz, with the data lines running at double this (ie: 667MHz).
Also, I wouldn't I call it a 333MHz bus or a 166MHz bus, as this fails to
specify the scheme used. I *would* call it a 166MHz DDR bus.

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.

So, analysing the typical use for a bus is an artificial condition?
Riiiiggghhhttt ...

I'm telling you how it works.

I know EXACTLY how the EV6 bus works, and know fairly well how the DDR
memory bus and the AGTL+ busses work. I wrote, pretty much from scratch, a
VHDL program to log transfers across a EV6 bus (and also played with, but
never got very far with, a DDR memory bus logger). Granted, it probably
wouldn't actually work correctly because of signal purity issues if it was
actually hooked into a bus, and that it was designed from the 21264 specs,
but I do know the theory behind it quite well. The EV6 isn't a great example
of a DDR bus for several reasons, but it still operates in much the same
manner as I described above.

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 he 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.

sigh

Will you PLEASE go and read back over what you quoted. It was simply a
comment about how the cache line size and bus type are interlinked with
respect to the performance of a processor. If you think it's off topic for
the thread, then just snip it instead of trying to make a great big issue
over it.

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? :P

Because the reality of it is that it's operating at 3.4 GHz.

Not all of it ... the ALUs and some parts of the scheduler are operating at
6.8GHz, and numerous other bits are operating at all sorts of different
speeds..

[snip further P4 stuff, as this is really getting off-topic for a discussion
on busses]

--
Michael Brown
www.emboss.co.nz : OOS/RSI software and more
Add michael@ to emboss.co.nz - My inbox is always open

Michael Brown wrote:

You seem to have a misconception about how DDR/QDR busses operate, or
possibly busses in general.

I understand how the busses operate just fine, but thanks anyway.

A "bus" in the computer world (ie: the world in
which DDR and QDR have a meaning) includes both the data lines, and the=

control/address lines (different than a bus in the electrical world, wh=
ich
is usually just a collection of similarly functioning lines). For examp=
le,
the EV6 bus scheme of the 21264/K7 has 72 bidirectional data lines (64 =
bits
data bits + 8 ECC bits), and 26 unidirectional control/address lines, p=
lus
several other miscellaneous lines. The data lines "operate" at 2x or=
4x
MHz, but the control and address lines only "operate" at x MHz. The "=
bus"
includes both data AND control/address lines. EVERY request across the =
bus
requires the use of the control lines, so they are no less important th=
an
the data lines.
=20
A request across the bus can only be started through the use of the con=
trol
lines. You can't start sending the data, then send the address later. S=
o if
a request comes in at time 0.25 on a QDR bus, you have to wait until ti=
me
1.0 before you can start the transmission, even if nothing was sent at =
time
0.
=20
For example, sending 32 bytes across a x MHz 64-bit QDR bus goes as
follows (simplified):
time 0.00: Bus sits idle
time 0.25: Bus sits idle, request is sendable but cannot be sent
time 0.50: Bus sits idle, request is sendable but cannot be sent
time 0.75: Bus sits idle, request is sendable but cannot be sent
time 1.00: Request sent
time 1.25: Request data continues
time 1.50: Request data continues
time 1.75: Request data continues
time 2.00: Bus sits idle, ready for next request
etc etc
=20
In a x*4MHz 64-bit SDR bus, it would look like:
time 0.00: Bus sits idle
time 0.25: Request sent
time 0.50: Request data continues
time 0.75: Request data continues
time 1.00: Request data continues
time 1.25: Bus sits idle, ready for next request
etc etc
=20
On a x MHz 256-bit SDR bus:
time 0.00: Bus sits idle
time 1.00: Request sent (all 32 bytes in a single cycle)
time 2.00: Bus sits idle, ready for next request
=20
Which brings me back to the original point that an x MHz y bit QDR =
bus
is equavalent in performance to a x MHz 4*y bit SDR bus, and slower=
than
an 4*x MHz y bit SDR bus.

The issue is not in comparing various bus speeds to each other, nor is it=

bus latency, nor is it inventing analogous models. The issue is the data
rate and it's current designation in how many data transfers per second i=
t
is capable of.


I know you dislike bringing memory into it, but the exact same thing ap=
plies
to DDR memory. Requests can only be sent on integer cycles, but data ca=
n be
sent on both integer and half-integer cycles. This is why DDR400 chips =
have
a 5ns access time, not 2.5ns.

Which is again irrelevant to the bus stream rate.

You are so intent on playing with bit timings that you have completely lo=
st
track of what the issue was: Whether the 333MHz rating of a 166.6Mhz
clocked DDR bus was "hype" (subtitled: it's 'really' [sic] a 166.6Mhz bus=
)
and then, secondly, whether Mhz even applied to the number. And I've
answered both: No, it is not just 'hype' and yes, MHz is perfectly approp=
riate.

We can wax eloquent all day long about when request signals can, or canno=
t,
be sent with a particular bus implementation, which would be fine if the
topic were bus latency, but the fact of the matter is that the data is NO=
T
streaming at 166.6 MHz; it is streaming at 333 Mhz, even if it has to wai=
t
till the cows come home to start doing it.

Now, if you want to introduce "The Brown Formula" for how bus speeds shou=
ld
be designated, and get that accepted as a new standard, then have at it a=
nd
best wishes. But, until then, it's useful for people to know what the
333MHz means in this context since that's the one in common usage. And, t=
o
that end, it is referring to the bus data stream rate.


David Maynard wrote:
=20
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.
=20
=20
Why are the data lines more important than the signal lines when determ=
ining
how many MHz the bus operates at? Without both, you don't have a bus, a=
nd
there are arguments for adopting either of the two speeds.

Because the 'speed' designation we are discussing is the data rate and no=
t
how fast any of the bus lines go up and down.


What, then, is the bus speed?

The bus 'speed' is the data rate.
=20
=20
nitpick
Data rate is measured in bps, not MHz. Which is why I'm semi-comfortabl=
e
with the DDR333/DDR400 terminology, but dislike people saying it's a 33=
3MHz
bus.
/nitpick

bps is fine for a bit wide serial stream but it don't work worth spit for=
a
bus.


What I *think* you mean is that the data signal characteristics are mor=
e
important than the control signal characteristics. Again, there are
arguments for both sides: the data signal characteristics are more impo=
rtant
under streaming conditions (the norm for GPUs), control signal
characteristics are more important under random access conditions (the =
norm
for CPUs).

No, we are not talking about (electrical) 'signal characteristics'. The
number is the data rate.

And, btw, "random access" is not "the norm for CPUs" (and especially not =
on
the cpu/memory bus that is typically stream filling cache.)


[...]
=20
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.
=20
=20
Again, you miss the "performance-wise" part. See the bit at the top of =
the
post for the reasoning behind this.

I didn't miss it at all. It's simply not relevant to the matter because t=
he
issue is not what the 'best' kind of bus would be or which is 'more
efficient' or which would have lower latency. The issue is what the heck
333MHz means in this context.

With all due respect, it is you who have read more into my comment about =
it
being a 'performance' number than was there. I simply meant that it has
nothing to do with 'clocks' or any other type of 'circuit' description;
That the number refers to the data rate in a (simple) 'performance'
context, not that it encompasses every aspect of performance.


[...]
=20
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.
=20
=20
Please, tell me where in my analysis I bring memory performance into it=

(excluding the "slightly above" remark, of course). All of the numbers =
above
are only influenced by the speed and signalling scheme of the bus in
question. A few quotes below, I say that you can think of it as two
processors exchanging a cache line. Another option is a write to an I/O=

port. This is even more dramatic, as these writes are not cached, and D=
DR333
bus will annihilate a QDR400 bus: the DDR333 bus will do 166 million I/=
O's
per second, whereas the QDR400 bus will only manage 100 million per sec=
ond.

Whatever you want to claim here is fine with me and I should have ignored=

it the first time because it's irrelevant.


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.
=20
=20
Could you please provide a reference that states that the EV6 bus was
"specifically designed for" streaming data transfers. I'm not holding m=
y
breath.

Fine. It's a synchronous bus where data streaming is an accident.

http://www.ul.ie/~flanagan/ce4518/re...AMD-Athlon.pdf

"The Industry=92s First 200-MHz System Bus for x86 Platforms

The 200MHz AMD Athlon processor system bus=97the fastest front-side bus
implementation for x86 platforms=97leverages the high-performance Alpha E=
V6
system interface technology to significantly boost system performance and=

provide ample headroom for today=92s and tomorrow=92s applications...

The flexible AMD Athlon processor system bus provides advanced features,
such as... packet-based transfers for maximum transaction pipelining, lar=
ge
64-byte burst data transfers,...

The 200MHz system bus implemented in the AMD Athlon processor is capable =
of
delivering a peak data transfer rate of 1.6 Gbytes/sec=97... AMD=92s 200M=
Hz
system bus also provides 64-byte burst transfers,..."


snip

Not that the rest isn't interesting but it's irrelevant to the issue and
now you're just arguing to be arguing.

The basic issue is given a bus that has two different parts operating at two
different frequencies, what is the "correct" number to use when referring to
the bus as an "xMHz bus"? Like I've said numerous times, there's arguments
for using either of the numbers; the number is undefined if you want to look
at it mathematically. My personal view is that it should be called, for the
DDR333 example, a "166MHz bus with a double data rate" or in a shorter form,
"166MHz DDR bus", but not just a "166MHz bus" or a "333MHz bus" (which IMO
implies SDR), nor a "333MHz DDR bus" (which IMO implies that the data lines
operate at double the 333MHz speed). You obviously have a different view,
and I don't think any amount of discussion is going to change that.

That said, I don't think it's worth commenting on anything else apart from
clarifying one point:
David Maynard wrote:
[...]
And, btw, "random access" is not "the norm for CPUs" (and especially
not on the cpu/memory bus that is typically stream filling cache.)

In hindsight, the term "random access" was probably not well chosen. What I
was referring to was the time between requests (each request being a 64-byte
or 128-byte request to read/write a cache line) sent over the bus. In most
applications (excluding the afore-mentioned streaming applications), the
time between requests is largely random, and the bus is not used to
capacity. If the bus is fully used, then the controller doesn't have to wait
to send information over the address/control lines. However, if the bus is
not fully utilised (as in the case in most current CPU/system designs), then
the times of the requests can be treated as random, and this was the basis
for the previous analysis.

[...]
and now you're just arguing to be arguing.

Funnily enough, I was coming to the same conclusion about you with your
repeated ignoring of the "performance-wise" part ...

--
Michael Brown
www.emboss.co.nz : OOS/RSI software and more
Add michael@ to emboss.co.nz - My inbox is always open

Michael Brown wrote:
The basic issue is given a bus that has two different parts operating
at two different frequencies, what is the "correct" number to use
when referring to the bus as an "xMHz bus"? Like I've said numerous
times, there's arguments for using either of the numbers; the number
is undefined if you want to look at it mathematically. My personal
view is that it should be called, for the DDR333 example, a "166MHz
bus with a double data rate" or in a shorter form, "166MHz DDR bus",
but not just a "166MHz bus" or a "333MHz bus" (which IMO implies
SDR), nor a "333MHz DDR bus" (which IMO implies that the data lines
operate at double the 333MHz speed). You obviously have a different
view, and I don't think any amount of discussion is going to change
that.

FWIW I agree with you Michael. Not wanting to be argumentative at all about
it though, just a POV.
--
~misfit~

Michael Brown wrote:

The basic issue is given a bus that has two different parts operating at two
different frequencies, what is the "correct" number to use when referring to
the bus as an "xMHz bus"? Like I've said numerous times, there's arguments
for using either of the numbers; the number is undefined if you want to look
at it mathematically.

And as I have told you numerous times the number does not refer to any
particular electrical 'part' of the bus so, no, the 'issue' is not what
speeds various 'parts' of the bus operate at. It refers to the stream data
rate, not 'this clock' or 'that clock' or whatever strobe signal someone
may think is of particular interest (and very well might be in another
context).


My personal view is that it should be called, for the
DDR333 example, a "166MHz bus with a double data rate" or in a shorter form,
"166MHz DDR bus", but not just a "166MHz bus" or a "333MHz bus" (which IMO
implies SDR), nor a "333MHz DDR bus" (which IMO implies that the data lines
operate at double the 333MHz speed). You obviously have a different view,
and I don't think any amount of discussion is going to change that.

What things in the world would be called if you or I were linguistic
dictators doesn't really matter much since we aren't.

Where my 'different view' comes from is in simply acknowledging what the
numbers in use already mean.

But I could make the same 'complaints' in reverse as you make. That "166MHz
DDR bus" is 'confusing' since it's data rate is 333. Explaining it's data
rate comes from being DDR is nice information, assuming one is technically
inclined, but it doesn't alter the fact that it streams at 333 so why not
call a spade a spade? I.E. it's a 333MHz DDR bus: a bus which uses the
technology of DDR, for the techies, to operate with a data stream rate of
333Mhz. It's simply a matter of 'emphasis'. You think 'the clock' is 'god'
(well, multiple gods with DDR and QDR, which causes some of the 'debate' of
which 'god' to worship in the title) and my version of the 'complaint'
focuses on the data stream rate as the item of interest.

In my opinion, both complaints are 'picky', from a technical standpoint,
and simply a personal 'feeling'. Both can be 'understood' if you simply
accept the terminology and while one might 'prefer' their version that
doesn't make the other 'wrong'. (E.g. "Hey Bill, when they say 333DDR have
they already multiplied it out or does the reader have to do that themselves?")

I think it should be rather clear, however, that when presenting the
information to the typical buyer that the matter of which 'clock' is used,
and even DDR, QDR and other such 'consumer obtuse' terms, is much less
obvious than 333 being 'faster' than 200.


That said, I don't think it's worth commenting on anything else apart from
clarifying one point:
David Maynard wrote:
[...]

And, btw, "random access" is not "the norm for CPUs" (and especially
not on the cpu/memory bus that is typically stream filling cache.)


In hindsight, the term "random access" was probably not well chosen. What I
was referring to was the time between requests (each request being a 64-byte
or 128-byte request to read/write a cache line) sent over the bus. In most
applications (excluding the afore-mentioned streaming applications), the
time between requests is largely random, and the bus is not used to
capacity. If the bus is fully used, then the controller doesn't have to wait
to send information over the address/control lines. However, if the bus is
not fully utilised (as in the case in most current CPU/system designs), then
the times of the requests can be treated as random, and this was the basis
for the previous analysis.

OK.


[...]

and now you're just arguing to be arguing.


Funnily enough, I was coming to the same conclusion about you with your
repeated ignoring of the "performance-wise" part ...

You took that from me and I explained what it meant. In particular, it was
simply to distinguish from the 'technical' aspect. The data streaming
number is an overall performance 'type' of number, not that it is expected
to answer every aspect of the system's performance you might decide to take
issue with. That's what spec sheets are for, not 'ratings'.

E.g. Does PC100 memory send all of it's data within 10ns of the request?
No, that's the maximum burst rate. Does a 166.6MHz SDR bus send all data
without interruption or delay at 166.6MHz? No, that's the maximum burst
rate. Is it even true that all 1 Gig processors are 'equally fast'? No. And
so on.


--
Michael Brown
www.emboss.co.nz : OOS/RSI software and more
Add michael@ to emboss.co.nz - My inbox is always open

CPU bus != system bus

"David Maynard" wrote in message
...
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.


The maximum that the processor will run at depends on many things. If
it's
un-locked you would be able to lower the multiplier and run it on a
200MHz
FSB, however if its one of the more recent locked models the maximum FSB
would be in the region of 175-190MHz, depending on how overclockable the
cpu
is, how good your cooling is etc.


He didn't ask what speed he might be able to push it to. He asked "What is
the maximum that the Athlon XP 2800+ supports?" and the "Maximum System
Bus
Speed" that the processor "supports" is the bus speed it's rated for.

NuT CrAcKeR wrote:
CPU bus != system bus

I take it you think there's a salient point in there somewhere.

"David Maynard" wrote in message
...

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.



The maximum that the processor will run at depends on many things. If

it's

un-locked you would be able to lower the multiplier and run it on a

200MHz

FSB, however if its one of the more recent locked models the maximum FSB
would be in the region of 175-190MHz, depending on how overclockable the

cpu

is, how good your cooling is etc.


He didn't ask what speed he might be able to push it to. He asked "What is
the maximum that the Athlon XP 2800+ supports?" and the "Maximum System

Bus

Speed" that the processor "supports" is the bus speed it's rated for.

I said the same thing as the post that I responded to, just in not so many
words.

NuTs

"David Maynard" wrote in message
...
NuT CrAcKeR wrote:
CPU bus != system bus

I take it you think there's a salient point in there somewhere.

"David Maynard" wrote in message
...

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.



The maximum that the processor will run at depends on many things. If

it's

un-locked you would be able to lower the multiplier and run it on a

200MHz

FSB, however if its one of the more recent locked models the maximum
FSB
would be in the region of 175-190MHz, depending on how overclockable
the

cpu

is, how good your cooling is etc.


He didn't ask what speed he might be able to push it to. He asked "What
is
the maximum that the Athlon XP 2800+ supports?" and the "Maximum System

Bus

Speed" that the processor "supports" is the bus speed it's rated for.

cpu bus = 333

fsb = 166

333 != 166

!= means "not equal to"

NuTs

"David Maynard" wrote in message
...
NuT CrAcKeR wrote:

I said the same thing as the post that I responded to, just in not so
many
words.

I wrote the post you responded to and your reply doesn't even address the
point, much less say the same thing.

NuTs

"David Maynard" wrote in message
...

NuT CrAcKeR wrote:

CPU bus != system bus

I take it you think there's a salient point in there somewhere.


"David Maynard" wrote in message
...


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.



The maximum that the processor will run at depends on many things. If

it's


un-locked you would be able to lower the multiplier and run it on a

200MHz


FSB, however if its one of the more recent locked models the maximum

FSB

would be in the region of 175-190MHz, depending on how overclockable

the

cpu


is, how good your cooling is etc.


He didn't ask what speed he might be able to push it to. He asked
"What

is

the maximum that the Athlon XP 2800+ supports?" and the "Maximum
System

Bus


Speed" that the processor "supports" is the bus speed it's rated for.