On Tue, 13 Apr 2004 09:19:18 GMT, Wes Newell
wrote:

On Tue, 13 Apr 2004 00:35:58 +0200, somebody wrote:

On Sat, 10 Apr 2004 13:01:39 -0700, "Jim" wrote:

Ok, one problem here is that the marketing hype leads the advertising people
to not quite state things correctly. Let's forget the details of that ad,
and talk as accurately as possible.

The CPU FSB is more correctly stated as 200MHz (actual), but since it
employs DDR technology, it's *effective* rate is 400MHz. The "400MHz"
number you see in the ad is actually misleading, the CPU FSB does NOT
physically *run* at 400MHz, it runs at 200MHz (that's what would show up on
a scope!), *but*, because the DDR technology it employs allows data to
travel BOTH on the up and down side of each cycle (per MHz), it's *behaving*
as if it data was traveling on ONE side of the cycle, but at 400MHz! Get
it? It's a marketing gimic, the CPU isn't actually *faster*, it's more
*efficient* (2x in fact) at the same speed of a 200MHz processor (1x) that
does NOT employ DDR technology.

The clock is just that. It's just a clock. It might run at 'just' 200
MHz, but it's _NOT_ the speed of the bus! The speed of the bus is
400MHz, and there's no marketing gimmick about that. That is indeed
the _speed_!

Bus speed is measured by the clock cycles.

What is that "Bus speed"? And why is it "measured by the clock
cycles"?
Who does this? - Certainly not AMD or Intel.
That's just the thing here. If that "bus speed" is measured in clock
cycles, then it's because that "bus speed" is the bus clock speed.
We're running in circles.

The speed is 200MHz, not double
that or 4 times that. That is the data rate. Data rates are measured in
Bps or bps, not MHz.

Frequency of data transfers should be measured in MHz (Hz), just like
any frequency of any event. Clocks do not own the unit MHz.
But sure, data rate is fine to measure in Bps.

And anyone that thinks any different is just a stupid
stubborn idiot.

- Tsk, tsk. - I'll reserve my judgement on the making of such a
'statement'. :-D

Granted, that the bandwidth no longer depends on bus
speed, but data rate. The cpu clock speed does however depend on the bus
speed. Every cpu has a multiplier that sets the cpu clock speed in
accordance with the FSB speed. And now just a few problems that can arise
from calling the data rate the the FSB speed.

You can forget about stupid, and idiot too, - well, at least in the IQ
sense.
But: - Stubborn? - Oh most certainly. I'm not married!
So here goes:

The bandwidth does depend on a 'speed'. How could it possibly not?
And the 'effective FSB speed' is not the same thing as data rate.
Data rate is width of bus times 'effective bus speed'.

(And I could disagree, if I wanted to, what we see are some few
problems arising from calling 'FSB clock speed' 'FSB speed' ;-).)

'Bus speed' is an unfortunate term, since AMD and Intel use it as
short for 'effective bus speed', in the case of FSB, while it's also
established in use as short for 'bus clock speed'. I only used that
term (bus speed) once in my post, and I propose that we henceforth are
explicit about this and use 'effective FSB speed' respectively 'FSB
clock speed', or our argument will indeed be stupid.
So ok, I agree, maybe marketing haven't made us any immediate favor
here.

I think I primarily used the term 'speed'. Also as in 'speed of the
bus', which you interpret as 'clockspeed' at every turn. Please don't
do that. I meant speed as speed. As does AMD and Intel.
"Speed" is speed. 'Clock speed' is just a term for the frequency of
the clock pulses. It doesn't own 'speed'.

Tell an engineer to build you a MB with a 400MHz bus do you think they'll
know that you really only mean 100, or 200 in AMD's case.

- But isn't that pretty much exactly what DEC did? "Give us a 200MHz
bus" and they came up with the Alpha bus at a 100MHz clock?
I would think anyone actually asking for a 'speed'(sic) is concerned
with speed in terms of performance.
(And I think any engineers building a mobo would have to work from
very detailed specs, not just a loose MHz figure.)

Use that 400MHz to calculate your cpu speed and see how far off you'll be.

Why should I? If I know enough to calculate cpu 'clock speed', I'd
know I need a multiplier and an external _CLOCK_. Why should I grasp
blindly for any and all MHz figure floating around?

The DDR rates and "effective bus speed" again in MHz, are terms and
concepts established in language and specs. It might not be to your
liking, but they are technically motivated, and insisting on your ways
is not very constructive. The concepts needs explaining, not
dismissing. To more often strictly employ 'data rate' and 'Bps' is
excellent. I think you're right about that (still there's a
possibility for another mixup with 'data transfer rate' here). But
language develops as language will. There's not terribly much we can
do about it, but explain and try to avoid misunderstandings. Not using
'speed' when you really mean 'clock speed' is also helpful.

Language also evolves when there's specific communication needs,
within specific groups. In this particular case the need is to
communicate the relevant properties to users. The simplistic concept
of always understanding 'speed' exclusively as clockrate might work
for a digital engineer with his arms full of detailed manuals. But he
doesn't need that. He can make do with the more explicit 'clock
speed'. It's also not proper for the market. The market assumes
'speed' denotes an aspect of performance, since that is usually
fundamental to the concept of speed. So there is a need for concepts
like "effective FSB speed" and DDR rates.

Since that "400MHz" FSB is an established concept, there is the need
to explain it's not the clock. Likewise, there is the need to explain
why we could possibly have use for PC2700 on a 166MHz FSB clock (for
all those assuming 'clock speed' is the speed(sic) of the bus).

SNIP

But you are forgeting the major point. Bus speeds are mearsured by clock
speeds. Data speeds are measured by throughput in bps/Bps. Saying the bus
speed is 400MHz simply because the data rate is DDR is like saying my car
is going 120MPH when I have 2 people in it actually doing 60MPH.

Bus speed is the movement rate over ground, of a large vehicle,
transporting people, traveling on the road, and is measured in mph or
km/h... ;-)
'Bus clock speed' or 'effective bus speed' on the other hand...

- And I don't agree, - it's more like saying your car is doing 60mph
at 6000rpm, in 2'nd gear, when it is in fact indeed traveling at
60mph, even though it would only do 30mph at the same 6000rpm in 1'st
gear.
(And if those figures are totally wild off, I'm sorry, I don't know
much about cars, you know what I mean any way.)

Suppose we had only one gear, and an established tradition of
expressing speed of a vehicle, in terms of engine rpm. And also
suppose we had a tradition of interpreting 'speed' as short for
'engine speed', how appropriate will all that be when someone invents
the gearbox?
And how silly is it to be frantically wailing that it's more "correct"
to say that the 'speed' of the car is 6000rpm?
(I'm not saying you're actually doing that, but you could be ;-))

(The number of persons traveling in the car looks more like width of
the bus, or dual channels, to me.)

Frequency of pulses on a clock is measured in MHz.
Frequency of data transfers occurring on a bus is also measured in
MHz.
I'm perfectly aware of which one of these is the 'clock speed' or 'bus
clock speed'.
The transport capacity of the bus is of course the throughput, in Bps,
but wouldn't that also be the width of the bus times it's *speed* or,
more exactly, it's 'effective speed'?
- So, what is the speed(sic) of the bus?

Is the transport capacity, of a vehicle, the number of seats times
engine rpm?

And without a clock, absolutely nothing in the system would work. I blame
both Intel and AMD for trying to change standard engineering practices by
multiplying apples (clock in MHz) times oranges (data in bps) and then
calling the final number apples. Pure BS.

Yes, I can possibly understand some of those sentiments. But
technology and the world changes. And so there are some people that
feel the need for new terms, since perceptions of properties, commonly
associated with the old terms, are no longer valid. No one is in a
better position than AMD and Intel for that. That's how it goes. Chew
well.

However, In this case I'd also argue it's not a case of "apples times
oranges". MHz is not an exclusive unit for measuring clockrates,
neither is 'speed' the exclusive property of clock frequencies. MHz is
a unit for measuring frequency of an event. In the case of 'effective
bus speed', I've always assumed it's the frequency of data transfers.
It makes sense to me.

My point, which I possibly was somewhat overanxious to get across, (by
responding to the previous posters perfectly correct post) was that
there is nothing 'write up' or 'fake' about 'effective fsb speed', in
terms of relevant properties. On the contrary, it's the 'bus clock
speed' that carries the wrong implications. Particularly if you're in
a habit of calling it 'bus speed'.

SNIP

DDR ram is designated by bandwidth. PC2100 ram has a clock rate of 133MHz.
PC3200 has a clock rate of 200MHz, not 400 as you'll see all over the
f*cking place now.

Yes, DDR ram modules are designated by maximum bandwidth, it's max
transfer speed (sic) is designated by its DDR400 rating, and the
clockspeed for that is half (as implied by "double..."). I certainly
know all that! That is not what I was considering when I said "I don't
know how it works". But never mind.
It should also be obvious that the '400', that you're so annoyed with,
is technically motivated, since it denotes the transfer rate,
irrespectively of the width of the module..

And as my last comment on this. When I pinned AMD to the wall, they
admitted that their bogus FSB speeds were just that, by saying that it's
the effective clock rate when compared to a non DDR bus.

I'm pretty sure though, that they didn't admit to any "bogus"? But
rather tried to explain what it meant, in terms of relevant
properties?

ancra