AMD has the answer for Intel

In article ,
says...
has been ok for
the PC world since we've had 64-bit buses on every system for nearly 10
years now.

64-bit wide buses != 64-bit wide registers. Before MMX the 64-bit wide bus
was mainly useful for double floating-point data type.

The 64bit data path had little or nothing to do with FP
instructions. The data bus width was increased to increase memory
bandwidth. The caches were designed to be 256b wide. Thus it
took four beats of 64b or eight at 32b.

10 years? It only started with the Athlon and P4. Prior to that all x86
cpu's had only one data bit per clock cycle.

Why 32-bit memory was required in pairs on Pentium? One data bit? Explain.

I think he meant "per pin" (no DDR). Though even here it's not
correct unless he is only counting the burst, ignoring the
address cycle and latencies.

Also, "required" (pairs of sticks) is a bit strong. Several
chipsets would support single DRAM sticks. Though by the time
these came about, memory was cheap enough to ignore the feature.
It wasn't pretty, so it was more or less forgotten.

--
Keith

andrew wrote:
Put a digital signal into a receiver and take the video/baseband output
to a spectrum analyser. Tell me what the big spike is that coincides
with the baud rate of the digital signal? Spectrum analysers measure
frequency! Frequency is measured in Hertz.

I just knew my ham radio hobby would come in useful sometime


I don't even know where to begin with this one.

Ben
--
I'm not just a number. To many, I'm known as a String...

In article ,
says...
So I take it that it doesn't work becuase it is in fact, NOT an 800MHz
bus.
Thanks. You've established my point.

Equivalent to, which might be inprecise but it's not really a big secret
what the figure is based on. I'm not a big-fat-ass hardware expert (I am
software expert ;-), neither it is confusing at all that the actual clock
the data is synchronized to, is quarter of the presented figure, however,
data is moved through at frequency equivalent to 800Mhz since each clock
pulse is equivalent to four times the number of signals.

Even though there is *no* signal operating at 800MHz, it's just
peachy to call it 800MHz? I don't believe I've seen any
"equivalent to" disclaimer (it's "equivalent to" an 800MHz single
clocked bus) on the bus MHz rating. As a hardware type, I
understand what they're doing, though it is misleading.

In otherwords the hardware clock is 200Mhz, but the data is moving at
frequency of 800Mhz, effective.

Nope. The fastest signal you're going to find is the equivalent
of 400MHz (800 *transitions* per second).

I don't find that too massively misleading
advertising, especially when the facts aren't hidden and IMHO, publicly well
known. Most teen kids know what it means, those who don't know Mouse from
Monitor aren't ofcourse expected to know their ass from the hairs that are
on it.

I think it's misleading, though not grossly so. I'd prefer a
"data rate" number. A real and sustainable number would be nice,
though not likely to become reality. The marketeers wouldn't go
for it. Too much work doing the bench-marketeering... ;-)

--
Keith

In article ,
lid says...
On Thu, 2 Oct 2003 21:54:07 +0100, "Ben Pope"
wrote:

chrisv wrote:
If you want to argue that a "2400 baud" modem should always be
desribed "properly" as a "600 baud modem with quadrature
amplitude modulation", then I'd say you're a freakin' nutcase.

2400bps would fine though, wouldn't it?

Tell us, how exactly would you say that to a lay person? Would you
say "2400 bee pee ess", or "2400 bits per second"?

Absolutely!

You see, there's a
reason "2400 baud" become nomenclature - it's quick, easy, and it
works,

....and wrong.

despite not being "technically correct".

Words mean things. The use of a technical term in an improper
way does nothing but confuse the issue. Baud should *never* be
confused with bps.

If people use the correct units, there would be no confusion. It's the
poeple that use incorrect units, incorrect terminology and incorrect
reasoning that cause confusion.

I'm also curious as to what, exactly, you would say to a lay person
regarding the "800MHz FSB"?

Me? (I'll butt in here ;-)

"Don't worry 'bout it. It doesn't matter. Marketeering."

....or maybe I'll explain why it's marketeering, if I think they
can handle it. ;-) I'll also explain why MHz is just as
meaningless. However, I will refuse to get into a discussion
where the misuse of terms is prevalent. The field is confusing
enough without market-speak and gross misuse of terms.

Because if you have a way to describe it,
that effectively communicates what's going, without being too
technical for anyone but a computer hardware geek, I may use your
suggestion.

Then why use a technical term like "baud" or "MHz" at all?
You're simply propagating ignorance that will have to be cleaned
up later. Words have meanings.

--
Keith

In article ,
says...
What's the problem? The new data is transfered every 1/800000000 th of a
second, that's the frequency.

No, that would be the period. Now you're trying to measure frequency in
seconds AND data rate in Hz.

Yes, ofcourse that is the period.

No, that's only *HALF* a period. There is *nothing* on that bus
switching at 800MHz. The fastest you could possibly see would be
400MHz. Hz is an absolutely incorrect unit to use.

It's inverse of the frequency, gee, forgot
to mention that. Now that this omission was cleared up, is new data "pulse"
is going through every 1/800000000 th of a second, giving the data
throughput frequency 800 Mhz, or not?

As Ben said, it's a good think you've only a self-proclaimed
"software expert" because you have this all wrong.

There is no pulse "going through every 1/800000000 th of a
second". There is, however, a data transition (possibility)
every 1/800000000 th of a second. This is not 800MHz in any way
shape or form! It's (a possibility of) 800M transitions per
second or a maximum of 400MHz.

This multiplied by width of the data
lanes gives the bits per second, which is more common measure of bus
bandwidth,

You got that part right.

but the figure here is frequency, not bandwidth.

Oops! You fell back in your old trap. ...in the same sentence,
no less!


Bandwidth is not measured in hz, right?

Nope. Bits/bytes/whatever per second. Or it could be
bits/(pin*sec), or whatever.

It's a bit misleading to print data throughput
frequency

Data throughput is *not* a frequency! It's data per unit time.
Not cycles per unit time!

into brochures but it's far from outright lying, like you imply.

It's a gross misuse of long accepted terminology (I.e. a lie).

Let's try again. If new data pulse comes through every 1/800000000 seconds,
what's the frequency?

Since you start with an invalid assumption, it's not surprising
that your conclusion is just as whacked.

Since you seem to be "expert" on reciprocals you can
tell us what it is, since my 800 Mhz wasn't correct in your opinion. Oh, it
is 200 Mhz? Okay, and how you did this maths again, show us.

The correct, though perhaps meaningless, answer is "less than
400MHz". The math is simple (see above).

MHz is simply the wrong unit to use. It's only being used by the
marketeers because they've spent the last 20 years whacking
people over the head with it. At one time it wasn't such a bad
number. However it's lost all meaning (in this context) over the
last ten years.

Just as well you don't class yourself as a hardware expert since you would
have failed the simplest test - getting your units correct.

Well aren't we just thrilled. I don't class myself as a hardware expert,

Then stop playing one on the Usenet. ;-)

since I am not one. But believe me, I sometimes even get multiplication and
even addition wrong, but no one makes such a fuss about like you do.

Nope, your arithmetic is OK. As Dan said; you got your units
wrong. Faulty assumption = faulty conclusion.

--
Keith

In article ,
says...
In article , Ben Pope
writes
wogston wrote:
I'm not a big-fat-ass hardware expert...
...but the data is moving at frequency of 800Mhz, effective

Data speed has never been measured in MHz. Herts defines cycles per second.
Which means you inherently need something cyclic. Data is not cyclic,
otherwise it contains no information (since it's pretty predictable if it's
cyclic)

So data is not, and cannot be measured in Hertz. It is measured in bits per
second or some variant thereof.

Not strictly true!

Put a digital signal into a receiver and take the video/baseband output
to a spectrum analyser.

Why would you go through such contortions? Wouldn't a spectrum
analyzer be the right tool right out of the box?

Tell me what the big spike is that coincides
with the baud rate of the digital signal? Spectrum analysers measure
frequency! Frequency is measured in Hertz.

Better try again. First of all, have you actually *done* this??

If you connect a proper antenna to a spectrum analyzer and point
it towards the motherboard, the first thing you'll see is the
clock. That will be 200MHz, in this case. You'll then see
spikes repeating at 200MHz intervals up the spectrum, to perhaps
5x the processor's frequency. I haven't done this in a while, so
it may not be so pronounced up that high. You'll also see
harmonics of the memory clocks, if they're different. In short,
you'll see all multiples of the base clock (200MHz), so I don't
know how you're going to show me the big emission at 800MHz is
the "data frequency" (which would be at 400MHz anyway).

I just knew my ham radio hobby would come in useful sometime

Try again.

--
Keith

There is no pulse "going through every 1/800000000 th of a
second". There is, however, a data transition (possibility)
every 1/800000000 th of a second. This is not 800MHz in any way
shape or form! It's (a possibility of) 800M transitions per
second or a maximum of 400MHz.

Precisely, 800 M transition per second and what is the period with 800 M
transition per second if they are evenly spaced out in time?


Bandwidth is not measured in hz, right?

Nope. Bits/bytes/whatever per second. Or it could be
bits/(pin*sec), or whatever.

For example, but Intel doesn't claim this so I fail to see where the
outright lie -part is supposed to be.


It's a bit misleading to print data throughput
frequency

Data throughput is *not* a frequency! It's data per unit time.
Not cycles per unit time!

Ofcourse not, but Intel isn't claiming it is data throughput, so I fail to
see where the outright lie -part is supposed to be.


into brochures but it's far from outright lying, like you imply.

It's a gross misuse of long accepted terminology (I.e. a lie).

But he just argued, that most 'folks' who get distracted by the misuse of
terminology don't know it to begin with, so how it could mislead them, or
mislead those who know what it stands for, I ask?


Let's try again. If new data pulse comes through every 1/800000000
seconds,
what's the frequency?

Since you start with an invalid assumption, it's not surprising
that your conclusion is just as whacked.

Since you start with this foot, I state that I don't mean clock pulse, but
one bit of data, four times per each clock 'pulse', 'signal', or whatever
you hardware Gurus call it. I got the impression, that RIMMs are using QDR,
which stands for Quad Data Rate or something similiar. I know how DDR works,
clock signal is a SQUARE waveform.

The squares have raising edge and falling edge. Correct me at any time I am
incorrect. In charts I see the edges being sharp rises, practically
vertical.. but in practise my layman's sense says that analogic signal
cannot make *instant* 90 degree turn, or switch from on to off state,
electronics as far as I understand has a small delay and is continuous,
there must exist current between "on" and "off" states aswell. But let's
assume for practical reasons that the edge is rising and falling for the
signal.

DDR as far as I understand, again, correct when I am wrong, does synchronize
to both rising AND falling edges, so it requires only half the frequency for
the clock signal for it's operation, and therefore the clock don't have to
be as precise and therefore it is feasible to manufacture cheaply or
something along these lines anyway (tell me more if you like, I am all ears
and willing to learn).

QDR as far as I understand, again, I am a layman and haven't studied or
practised electronics, but I do have a little common sense and I hope it is
applicable here, works so that there are actually four "events" per clock
signal, I could read on the details but I take it for face value that QDR
means four data "events" per clock signal. Between every rising edge, four
bits of data can be transfered per wire.

Therefore, if I see 800 Mhz FSB which is QDR I understand it to mean 200 Mhz
clock, four "bits" of data between every rising edge of clock signal.
Correct me where I am wrong. I don't need to be called moron, called names,
etc. etc. etc. Thank you very much.

In this light for me, as consumer, I don't feel cheated by Intel one little
tiny bit. I am precisely the group this self-proclaimed Hardware-Pope Ben
Pope claims should feel cheated and lied to. Surprise Ben, I don't-- feel
free to explain for the millionth time why I *should* feel cheated by Intel,
and don't forget to mention that I am self-proclaimed so-called software
"expert", you're very good at that but not very good making a point.


Well aren't we just thrilled. I don't class myself as a hardware expert,

Then stop playing one on the Usenet. ;-)

I'm not pretending to be one, but I'm not completely out of the loop how
computers work.. and if I am incorrect, being corrected is the least I
expect from group with talent such as this. But this Ben Pope person's
attitude has been anything but friendly.


since I am not one. But believe me, I sometimes even get multiplication
and
even addition wrong, but no one makes such a fuss about like you do.

Nope, your arithmetic is OK. As Dan said; you got your units
wrong. Faulty assumption = faulty conclusion.

No, I'm sorry the assumption was correct, the wording of it wasn't: I know
what frequency and period are, hell, I known for a long time. I just worded
it incorrectly, which is the kind of mistake I do often, even if I mean
other way around. I'm a human, I do err, and I admit when I have said
incorrectly. But the crux of the matter is that I meant, OFCOURSE FOR ****'S
SAKE, that for time *PERIOD* of 1/800000000 th of second, naturally the
frequency is 800000000 hz, or otherwords: 1/period = freq, and freq =
1/period.

But Ben Pope had to tear it up, avoid the actual issue, and concentrate on
the inprecise output/wording, which I can't help since I'm NOT talking about
these things day-in-day-out, even if I have a fairly good idea what's what.
Therefore I feel very, very bad that I am such an idiot. Least I would have
expected Ben The HW-GURU to do, is to see the context and being the expert
he is, to grasp the meaning even if I laid it out inperfectly. No, but he
chose to spank me for it which tells me what kind of a guy he is. On the
other hand, what he did was to correct a incorrect statement, but he could
have chosen a bit more civil way to do it, hence, I don't think he's a very
nice guy but then again I don't know him and he is just one click of a
button away from being muted (ignorance is bliss, even if he is correct, I
don't have to listen to his tone of voice).

Beep.

-W

snip
Data throughput is *not* a frequency! It's data per unit time.
Not cycles per unit time!

Ofcourse not, but Intel isn't claiming it is data throughput, so I fail to
see where the outright lie -part is supposed to be.
snip

http://www.intel.com/design/motherbd...deskmb+p4pmb_d
875pbz&

You don't think that a P4 mainboard actually has an 800MHz FSB do you (as
stated on the page above)? The FSB does theoretically attain 800bps, but
there is not a single run on that board that is operating above 200MHz.

Both AMD an Intel are full of crap right now when it comes to stating the
specifications of their FSB.

bye, Rick

wogston wrote:
Data throughput is *not* a frequency! It's data per unit time.
Not cycles per unit time!

Ofcourse not, but Intel isn't claiming it is data throughput, so I fail to
see where the outright lie -part is supposed to be.

They're claiming it's clock rate, thats the whole point. If you use Hertz,
you are talking about cycles. The only cycle is the clock, which is NOT
800MHz! If they WERE calling it Bandwidth (per pin), they'd be correct.

It's a gross misuse of long accepted terminology (I.e. a lie).

But he just argued, that most 'folks' who get distracted by the misuse of
terminology don't know it to begin with, so how it could mislead them, or
mislead those who know what it stands for, I ask?

Just because somebody doesn't care, or doesn't undestand doesn't make it
acceptable to use the incorrect units or terminology.

Since you start with an invalid assumption, it's not surprising
that your conclusion is just as whacked.

Since you start with this foot, I state that I don't mean clock pulse, but
one bit of data, four times per each clock 'pulse', 'signal', or whatever

Then you CANNOT use Hertz to measure or describe it.

The squares have raising edge and falling edge. Correct me at any time I
am incorrect. In charts I see the edges being sharp rises, practically
vertical.. but in practise my layman's sense says that analogic signal
cannot make *instant* 90 degree turn, or switch from on to off state,
electronics as far as I understand has a small delay and is continuous,
there must exist current between "on" and "off" states aswell. But let's
assume for practical reasons that the edge is rising and falling for the
signal.

OK. So since you actually have an understanding of the situation in hand,
why can you not accept that incorrect units is wrong. Your laymans sense is
correct, you cannot instantaneously change the potential, as the bus has
capacitance (meaning that it needs charging - introducing the delay and the
smooth transition from one potential to another). The transitionary state
between on and off is precisely why you decide to synchronise transfers (so
that you can assume the bus has settled at the correct value, before
measuring it) and precisely why there is a limit to maximum clock rate.

DDR as far as I understand, again, correct when I am wrong, does
synchronize to both rising AND falling edges,

Yes.

so it requires only half
the frequency for the clock signal for it's operation,

No. You can't go from 0 to 1 and then 0 to 1 unless you've already gone
from 1 to 0 in between. So it still requires a full cycle. But within a
full cycle you can squeeze out two transfers.

and therefore the
clock don't have to be as precise

They need to be more precise, since the synchronisation is happening twice
as often. Additionally the on period and off period are now BOTH important
in determining the delay. Whereas before you could get away with a clock
that does not necessarily have equal on and off periods, you now need them
to be equal (assuming that sourcing and sinking current is symmetrical too,
which is rarely the case without extra giggery-pockery but only serves to
complicate the issue and require even tighter restrictions)

and therefore it is feasible to
manufacture cheaply or something along these lines anyway (tell me more
if you like, I am all ears and willing to learn).

No. The manufacturing process is, as I understand it, the same. But there
is a difference in the final stage that makes SDR become DDR.

QDR as far as I understand, again, I am a layman and haven't studied or
practised electronics, but I do have a little common sense and I hope it
is applicable here, works so that there are actually four "events" per
clock signal, I could read on the details but I take it for face value
that QDR means four data "events" per clock signal. Between every rising
edge, four bits of data can be transfered per wire.

QDR is 2 DDR systems interleaved by 90°. So you get two rising edges,
followed by two falling edges. So yes your abstract view is correct.

Therefore, if I see 800 Mhz FSB which is QDR I understand it to mean 200
Mhz clock, four "bits" of data between every rising edge of clock signal.

Yep.

But you can't call that Hz, since it is data.

In this light for me, as consumer, I don't feel cheated by Intel one
little tiny bit. I am precisely the group this self-proclaimed
Hardware-Pope Ben Pope claims should feel cheated and lied to.

I'm not saying that in some sense you should feel cheated, merely that the
incorrect terminolgy and units leads to confusion (and rediculous futile
arguments, it seems). I also did not proclaim myself a hardware expert -
you'll have a significantly harder time proving that, than I did proving
that you proclaimed yourself a software expert.

Surprise
Ben, I don't-- feel free to explain for the millionth time why I *should*
feel cheated by Intel, and don't forget to mention that I am
self-proclaimed so-called software "expert", you're very good at that but
not very good making a point.

I'm not saying that you should feel cheated! there are 800 Million
transfers per second. But thats what they are transfers per second, not
cycles per second and therefore can't be measured or descibed in Hertz.

I'm not pretending to be one, but I'm not completely out of the loop how
computers work.. and if I am incorrect, being corrected is the least I
expect from group with talent such as this.

I've been trying to correct you and others since the beginning of the
thread.

But this Ben Pope person's attitude has been anything but friendly.

And thats because you WILL NOT BE corrected. You insist, along with many
others, that you can measure data rate in Hertz. You cannot. Your
explanation of the clock above was pretty damn good, and shows that you do
have an understanding of hardware beyond many others in here.

No, I'm sorry the assumption was correct, the wording of it wasn't: I know
what frequency and period are, hell, I known for a long time. I just
worded it incorrectly, which is the kind of mistake I do often, even if I
mean other way around. I'm a human, I do err, and I admit when I have said
incorrectly. But the crux of the matter is that I meant, OFCOURSE FOR
****'S SAKE, that for time *PERIOD* of 1/800000000 th of second,
naturally the frequency is 800000000 hz, or otherwords: 1/period = freq,
and freq = 1/period.

But in converting "period" to frequency you must make sure that your
"period" is the complete time for a complete cycle. Not half of a cycle,
not a quarter of a cycle. And most certainly not something that isn't
cyclic. One whole cycle, from start to start (of the next one).

This is a major assumption. The reciprocal of frequency is always period,
denoted T. The time between two events is merely t. If the two events are
the equivelent point on two adjacent cycles then you may take the reciprocal
and call it frequency.

E.g. (and now for an analogy that will probably get torn to shreads, which
is why I do not like them)

If the time between me starting to blink and the time between me finishing a
blink is 0.1 seconds, then t (note the lower case) is 0.1s, that does not
necessarily make me blink at 10Hz.

Just because A data transfer happens every 1/800 000 000 s, doesn't mean the
frequency is 800MHz unless each consecutive transfer is an equivelent point
in consecutive cycles. Although they are called the same thing (unlike my
blinking example), they are not the same point in a cycle when using DDR and
"QDR".

But Ben Pope had to tear it up, avoid the actual issue, and concentrate on
the inprecise output/wording, which I can't help since I'm NOT talking
about these things day-in-day-out, even if I have a fairly good idea
what's what. Therefore I feel very, very bad that I am such an idiot.
Least I would have expected Ben The HW-GURU to do, is to see the context
and being the expert he is, to grasp the meaning even if I laid it out
inperfectly. No, but he chose to spank me for it which tells me what kind
of a guy he is. On the other hand, what he did was to correct a incorrect
statement, but he could have chosen a bit more civil way to do it, hence,
I don't think he's a very nice guy but then again I don't know him and he
is just one click of a button away from being muted (ignorance is bliss,
even if he is correct, I don't have to listen to his tone of voice).

Well you caught me mid-argument with chrisv, insisting that I was wrong
after I'd already argued the toss countless times. You even had the
audacity to say that you are no hardware expect. In saying that, you are
admitting that you do not know (or at least that you are not entirely sure),
merely that thats what you think the case is, yet you continue to argue that
I'm wrong.

Ben
--
I'm not just a number. To many, I'm known as a String...

On Sun, 05 Oct 2003 16:56:59 +0100, andrew wrote:

In article , Ben Pope
writes
wogston wrote:
I'm not a big-fat-ass hardware expert... ...but the data is moving at
frequency of 800Mhz, effective

Data speed has never been measured in MHz. Herts defines cycles per
second. Which means you inherently need something cyclic. Data is not
cyclic, otherwise it contains no information (since it's pretty
predictable if it's cyclic)

So data is not, and cannot be measured in Hertz. It is measured in bits
per second or some variant thereof.

Not strictly true!

Put a digital signal into a receiver and take the video/baseband output
to a spectrum analyser. Tell me what the big spike is that coincides
with the baud rate of the digital signal? Spectrum analysers measure
frequency! Frequency is measured in Hertz.

I just knew my ham radio hobby would come in useful sometime

Do a search for Heinrich Hertz and read up on him. You will find that his
name was used for 2 fields to honor his work, radio and electrical
frequences. Data rates are not a part of this. Data rates are measured in
data bits/bytes per second. Using Hz to measure data rates is totally
wrong. Period.

http://www.ideafinder.com/history/inventors/hertz.htm

--
Abit KT7-Raid (KT133) Tbred B core CPU @2400MHz (24x100FSB)
http://mysite.verizon.net/res0exft/cpu.html