Slashdot Mirror

One of my favorites can be read here:
http://www6.tomshardware.com/cpu/98q3 /980725/

Summed up, it says:

• IA-64 is on the way and everyone is on the bandwagon
• PPC is dead in the water
• The next Alpha chip looks really impressive
• The Alpha looks much better than Merced
• Intel will conquer everyone all the same

That's about when I lost faith in Tom and stopped reading his drivel. Lets all stop playing the fool for Tom's "news" site.

That's funny, because all the benchmarks I've ever seen show exactly the opposite - PIII squeaks ahead of Thunderbird (granted, you'd never notice the difference between equally clocked & configured Coppermine and Thunderbird systems... a few percentage points aren't much to get excited about). Perhaps you'd be kind enough to enlighten the rest of us with the particular data you're referring to.

Here's a couple of reviews I've seen that come to mind:

Tom's Hardware
PC World (pre-Coppermine/Thunderbird)

I used to run the BP6 Dual Celey combo (366 -> 523mhz x2 for over 1250Mflops according to WinTune) And bang for the buck, that was the winner.

But the new FPU king is the Athlon T-Bird, check out the specs here at Tom's Hardware (note: the Duron KILLS the Celeron 2, much less the original Celey)

Down the road, look for Linux for PPC on these boards .

The P3 is already faster than the Athlon at the same clockspeed in many areas. Try checking out a review at Anandtech, or Toms Hardware. The athlon does take advantage of some technologies that the P3 has yet to use, but once it does, I predict it will be faster than the Athlon in *most* areas of performance.

The biggest problem will be the price. That is why I think the Athlon has done so well all this time. For 50% less money, you get a chip that performs only 5% worse than the intel equivelant. I think that is why most people, myself included, like Athlons.

C'mon, this is OLD NEWS . I have posted this link numerous times in the past. Get a clue, Slashdot.

If I were in nVidia's PR department, I'd have my resume out now before the axe falls. The absolute first thing you learn in PR school is don't piss off the press.

A few years ago, Tom's Hardware was nearly shutdown by Intel because he gave them a poor review on a single product. Intel got such enormous bad press, they had to stop.

Nowadays, Tom Pabst still gives them good reviews when their products warrant it, but never gives them the benifit of the doubt (which is, IMHO, is prefectly understandable).

The CEO of nVidia will sooner or later figure out how crappy his PR department is and fire them. If these strong arm tactics get the attention they deserve, I'd guess sooner.

Everything from ATI blows? Not performance-wise...

See the review of the Radeon on Tom's Hardware.

But caveat: While the specs of the final models seem to have been decided on, the Radeon isn't exactly a shipping product yet.

T he Benchmark Results of the Radeon compare well with a Geforce2.
The Rage Pro Fury just sucks; not even beating a TNT2. Aple is Dum.

T he Benchmark Results of the Radeon compare well with a Geforce2.
The Rage Pro Fury just sucks; not even beating a TNT2. Aple is Dum.

This is just marketing hype from Intel. Their 1GHz Pentium III is being outshipped by the 1GHz Athlon by a factor of 12 to 1. You can't even find a 1GHz Pentium listing on the Pricewatch CPU page, let alone compare prices.

Given how much Intel has been suffering from their decision to go with Rambus (see this article from Tom's Hardware), you can see why they feel the need to brag about something.

I'm surprised there was just Sharky's review. All of the sites normally come up with reviews when the NDA's expire:

AnandTech
Fast Graphics
FiringSquad
GamersDepot
GameSpot
GA-Hardware
HotHardware
PlanetHardware
Tom's Hardware

For my money, Anand's is the best place to go for these things, although Tom usually has better discussions of the details behind the hardware and features itself.

Also, 20 questions with ATI, mostly about Radeon.

Here's what Tom had to say...

J:)

Go Here.

Fixed.

Mong.

* ...Student, Artist, Techie - Geek *

The tecnique is detailed in this article over at Tom's Hardware.

This development will tend to weed out all but the most hardcore overclockers, though, as far as modifying the clock multiplier goes.

AMD has a horrible problem with people remarking their Slot1 chips. The problem is most distinct in Australia. Read the Monday Blurn on Tom's Hardware for the scoop (including the contents of correspondence from AMD. However, this morning Tom turned around and disclosed how to get around the "lock" and overclock the chip anyway. The overclock involves burining away and recreating the contacts on the chip. The advantage to that is that chip alterations will be very, very, very obvious (or at least I believe that to be the case - we'll see soon).

AMD was attempting to, but has failed, to prevent a remarker from having the technology to cost-effectively remark their chips. The chips are overclockable, as you can see here.

-Phredrick Dobbs
Emperor of the Universe
Grand and High Protector of Everything

Tom's Hardware Guide alludes to an E-mail he received from Rambus stating that the performance problems he observed in his benchmarks were the result of Intel bungling the technology. I doubt Intel would be too happy if such comments are flying around. That would be enough reason for Intel to start being truthful ...

I'm speaking out of my nethers when I say that it's my belief that when they changed to the socket cpu design they introduced the abiltiy to control this from the mb and bios... no gold fingers.. just extra pins that do the same functions. This is just the first mb that has taken advantage of those options.

They probably did this to enable jumperless configuration, but the ease with which overclocking can be done is a nice bonus for people who are so inclined. On Socket A processors, there are four pins that tell the motherboard what settings (multiplier, FSB, and voltage, IIRC) to use. The motherboard then generates signals that go to the processor on another pin to set it to a particular multiplier. Theoretically, the BIOS will only echo back whatever the processor told it to use. In practice, the BIOS can ignore what the processor says and set up the processor to run at whatever multiplier it wants. This is just the first motherboard to take advantage of that capability.

(More details here, at Tom's Hardware.)

I love AMD... I've used them since their K-6 series first came out and have used them ever since.

Likewise...I'm running a K6-III-450, a K6-2-300, and a K6-200 here, and have never run into problems with any of them while running Win9x, NT4, Linux, or whatever (only thing I haven't tried on them yet is NetWare, and I have no reason to believe it wouldn't work). I see a K7 of some kind in my future...(most likely a Spitf^H^H^H^H^HDuron due to the lower price...)

_/_
/ v \
(IIGS( Scott Alfter (remove Voyager's hull # to send mail)
\_^_/

Here is his take on this...

Here is his take on this...

Even the classic Athlons could be set to the "proper" multiplier. The only catch was that you had to open the CPU casing and attach a goofy widget. You can see a review of Athlon GoldFinger devices (GFD) here, or if you're a DIY kind of person, the specs are here.

as far as i read, it actually does have somthing to do with AMD. AMD made these chips so that the multiplier could be controled, some of the pins are just for exactly that.

it's mentioned in the toms hardware article... here.

-------

Way to go ASUS and ABit!

Now we can tuck in our cheap Durons or expensive T-birds and overclock to our hearts content! According to Toms Hardware the three Duron 700 and one Duron 650 they tested were all overclockable up to 950 MHz, and the T-bird 1000 to 1100, all at 1.85 V.

Now all we need is motherboards with chipsets supporting DDR memory...

/Dervak

Even the benchmark systems had to use a different setup.

Sorry to rain on your parade. Having said this though, Tom's managed to get a T-Bird 750 to go on a K7V with the latest BIOS, however they couldn't overclock it.

It's probably not what you wanted to hear, but t's all I've been able to dig up. (Having said that it made me feel a little less cheated having bought my 'Classic' Athlon 6 weeks before the T-Bird came out).

Swinging back on-topic, it definitely sounds like the fault isn't with the processor. Most likely either Gateway aren't regulating the voltage too well, or their design's a bit squiffy. I remember that my friend's MSI Athlon system seemed to have a voltage issue, which was sorted by switching to the K7V.

Even the benchmark systems had to use a different setup.

Sorry to rain on your parade. Having said this though, Tom's managed to get a T-Bird 750 to go on a K7V with the latest BIOS, however they couldn't overclock it.

It's probably not what you wanted to hear, but t's all I've been able to dig up. (Having said that it made me feel a little less cheated having bought my 'Classic' Athlon 6 weeks before the T-Bird came out).

Swinging back on-topic, it definitely sounds like the fault isn't with the processor. Most likely either Gateway aren't regulating the voltage too well, or their design's a bit squiffy. I remember that my friend's MSI Athlon system seemed to have a voltage issue, which was sorted by switching to the K7V.

I want to see more charts like this. Nice.

Yours Truly,

Dan Kaminsky
DoxPara Research
http://www.doxpara.com

Those are the most disgusting charts I've ever seen:

Tom can say what he will about RDRAM, and nVidia, and 3Dfx, and whatnot. I'll be amused, but I'm not going to get pissed.

These charts piss me off.

Half a frame per second lost from AGP Fast Writes in one game does not a half-chart spanning differential make.

Graphing two values against eachother is meaningless if the scale is not consistent from graph to graph, you just end up with "more" vs. "less" being visually amplified, without "perceptably equal" even being an option.

Fifty Pixels Of Hype over .5 FPS? Are you kidding? (No, I didn't count exactly fifty pixels. So sue me.)

Yours Truly,

Dan Kaminsky
DoxPara Research
http://www.doxpara.com

I don't see what the big deal is, Intel released a new chip. ::sarcasm mode:: Whoopi! ::sarcasm mode:: Tell me where to get cold hard specs, and not off of the intel site. Lets find them from someone like Tom. Then, if it pans out, we can wet our pants because of this thing.

The really disappointing thing is that it looks like RAMBUS is quite inferior to the current crop of SDRAM offerings. Check out this recent article at Tom's hardware for details.

For more info on Rambus' past business practices, check Tom Pabst's article on "Why We Don't Trust Rambus"

However, I am puzzled by this strategy. For one thing, despite TI's success at defending their patents on fundamental aspects of DRAM (one of many legitimate IC patents they obtained in the early days of IC manufacturing), RAMBUS must know that there is prior art that weakens their claim. While exisiting licensees would arguably tend to support (or stand idly by) as they pressed others to license their technology, cockily taking on an entire industry in this manner is just begging for a barrage of assualts on the patent itself.

I can't believe they would be so blind, even in the heady glee of being gran such ridiculously broad patents like #6,067,592 System having a synchronous memory device [May 23, 3000] and #6,049,846 Integrated circuit having memory which synchronously samples information with respect to external clock signals

In fact, I think we have a duty to use the accumulated experience of our older (and much underappreciated) readers to start picking off the more outrageous patent claims one by one.

The easier we make it for the remaining memory companies to see their options, the better for *us*

To save you some work, here's a partial list of active Rambus patents (and linked to each of the patents themselves). It's not a complete list (IANAPA), but it should save everyone some work getting started. See anything that looks familiar from "way back when"?


1. 6,075,743. Method and apparatus for sharing sense amplifiers between memory banks

2. 6,075,730. High performance cost optimized memory with delayed memory writes

3. 6,070,222. Synchronous memory device having identification register

4. 6,067,592. System having a synchronous memory device

5. 6,049,846. Integrated circuit having memory which synchronously samples information with respect to external clock signals

6. 6,044,426. Memory system having memory devices each including a programmable internal register

7. 6,038,195. Synchronous memory device having a delay time register and method of operating same

8. 6,035,369. Method and apparatus for providing a memory with write enable information

9. 6,035,365. Dual clocked synchronous memory device having a delay time register and method of operating same

10. 6,034,918. Method of operating a memory having a variable data output length and a programmable register

11. 6,032,215. Synchronous memory device utilizing two external clocks

12. 6,032,214. Method of operating a synchronous memory device having a variable data output length

13. 6,021,076. Apparatus and method for thermal regulation in memory subsystems

14. 5,995,443. Synchronous memory device

15. 5,966,731. Protocol for communication with dynamic memory

16. 5,956,284. Method and apparatus for writing to memory components

17. 5,954,804. Synchronous memory device having an internal register

18. 5,953,263. Synchronous memory device having a programmable register and method of controlling same

19. 5,940,340. Method and apparatus for writing to memory components

20. 5,928,343. Memory module having memory devices containing internal device ID registers and method of initializing same

21. 5,913,046. Protocol for communication with dynamic memory

22. 5,896,545. Transmitting memory requests for multiple block format memory operations the requests comprising count information, a mask, and a second mask

23. 5,872,996. Method and apparatus for transmitting memory requests by transmitting portions of count data in adjacent words of a packet

24. 5,844,855. Method and apparatus for writing to memory components

25. 5,748,914. Protocol for communication with dynamic memory

26. 5,748,554. Memory and method for sensing sub-groups of memory elements

27. 5,680,361. Method and apparatus for writing to memory components

28. 5,657,481. Memory device with a phase locked loop circuitry

29. 5,606,717. Memory circuitry having bus interface for receiving information in packets and access time registers

30. 5,511,024. Dynamic random access memory system

31. 5,499,385. Method for accessing and transmitting data to/from a memory in packets

32. 5,499,355. Prefetching into a cache to minimize main memory access time and cache size in a computer system

33. 5,434,817. Dynamic random access memory system

34. 5,430,676. Dynamic random access memory system

35. 5,390,308. Method and apparatus for address mapping of dynamic random access memory

I agree, the little blurb tells us sweet FA, but there was another Rambus link on Tom's index, more informative of what Rambus is up to.

http://www6.tomshardware. com/blurb/00q2/000525/index.html


Paul Bryson
"The shortest distance between two spoons is irrelevant.

Maybe so, but that's not the problem. The issue is, Rambus is trying to take an equal-performance (and cheaper) alternative to it's product and raise the price through royalties so it's not as competitive on the market.

Rambus claimed that the poor performance on P2's was due to slow CPU speeds and that faster CPU's would show how RDRAM shines. Well, between Tom's Hardware and the last review posted on here (don't have the link-sorry), on identical high-end P3's it's just barely the equal of SDRAM (at over twice the price). It shines in data streaming - one high-latency memory query, then lots of data flows. What SDRAM is good at is little file queries - I want to open a Word doc that's 4k. By the time RDRAM finishes it's slow query my SDRAM has already delivered the page...

If the world was fair, what people would do is boycott buying RDRAM modules, systems, etc. and buy more SDRAM. Enough to offset the higher royalties with economy in volume. Who cares if they're paying royalties - the chip makers are selling lots of SDRAM, there's no demand for RDRAM so they don't produce it, Rambus stock hits the toilet, then the royalties stop when Rambus goes bankrupt.

The world being what it is, the Rambus royalties will price SDRAM almost as high as RDRAM, people will put off buying it "until the price comes back down", by which time RDRAM boards and RIMMS will be more common. Big royalties to Rambus, lots of happy Rambus stockholders, lots of locked-in consumers. Gotta love the 'free-market' economy...

Duron vs PIII FPU

Rambus is faster, albeit more expensive, I think we all know that.

The specs I've seen...

Now I myself would love to get my hands on some RDRAM, but I simply don't have the money.

If they don't sit still and stagnate technology...

Memory Wars

Dissecting Rambus and

Rambus Requiem for good technical discussions and benchmarking.

And there are several other good ones if you look up "Rambus" or the mainboard guides on the site.

And if anyone can get a copy of the serious and excellent Forbes ASAP, apparently the May 29, 2000 issue has a good summary of Rambus's tactics.

K

Memory Wars

Dissecting Rambus and

Rambus Requiem for good technical discussions and benchmarking.

And there are several other good ones if you look up "Rambus" or the mainboard guides on the site.

And if anyone can get a copy of the serious and excellent Forbes ASAP, apparently the May 29, 2000 issue has a good summary of Rambus's tactics.

K

Memory Wars

Dissecting Rambus and

Rambus Requiem for good technical discussions and benchmarking.

And there are several other good ones if you look up "Rambus" or the mainboard guides on the site.

And if anyone can get a copy of the serious and excellent Forbes ASAP, apparently the May 29, 2000 issue has a good summary of Rambus's tactics.

K

Memory Wars

Dissecting Rambus and

Rambus Requiem for good technical discussions and benchmarking.

And there are several other good ones if you look up "Rambus" or the mainboard guides on the site.

And if anyone can get a copy of the serious and excellent Forbes ASAP, apparently the May 29, 2000 issue has a good summary of Rambus's tactics.

K

I pray that this is a troll. If not, Rambus(t), Inc. is planting employees on /. to spread anti-SDRAM FUD.

Virtually all "real world" benchmarks contradict this AC's comment, and even Memory specific benchmarks disagree with the parent post.

--

I've been hoping that someone would bring this up so that I could rehash the discussion we had on RDRAM back when this whole latency story broke. Below you will find a number of links to other places. Suspiciously, out of the holy trinity of hardware review sites (Tom's Hardware, Anandtech, and Sharky Extreme), the ONLY one that speaks up in favor of RDRAM and doesn't talk about its latency problems is Anandtech. Hmm...

From Sharky Extreme on this page:

The memory bus we are all used to operates at 100MHz and is 64-bits wide. Rambus' offering runs at 400MHz (transferring on the rising and falling edges of the clock) and is 16-bits wide. What this essentially translates into is a faster Rambus interface (in terms of frequency) with added latency because of the smaller "width" of the bus.

From Tom's Hardware: This page tells what the theoretical bus bandwidth is for SDRAM, DDR SDRAM, and RDRAM. I quote from the following page:

Continuously managing multiple latencies would be a nightmare for the memory controller. In order to work around this, when a system is booted the RDRAM subsystem performs an involved initialization process to determine what the greatest latency is for the entire RDRAM system and adjusts all RDRAM devices to have the same latency as the slowest RDRAM device on the system. And remember that in a real world system each RIMM will have many RDRAM devices so this latency balancing is quite complex.

(Emphasis is mine.) The next paragraph reads:

An RDRAM chip typically has a normal 20 ns page read access latency. To balance latencies, these chips have a TPARM control register that can be programmed with a 2.5, 5.0, 7.5 or 10.0 ns of artificial compensating latency. This means that the normal chip latency can be as much as 50% higher than the minimal 20 ns often quoted as RDRAM's page read latency. Compare this with the fastest PC100 SDRAM with a latency of only 20 ns, but again remember that RDRAM has even other issues that bring its total latency much higher still.

Finally, An article from Real World Tech explains just what the timings are like, why they occur, and why they mean that DDR SDRAM is going to be faster for the forseeable future. A very instructive paragraph on the general problems with RDRAM follows:

RIMMs also generally require a metallic heat spreader enclosure to avoid an excessive localized heating of any single memory device. Finally, the computer system motherboard into which RIMMs plug must have tightly controlled electrical characteristics that match RIMM circuit cards to avoid unwanted impedance mismatches and signal reflections. This can require extra signal layers and power planes, which along with the tighter manufacturing tolerances, results in a more expensive computer motherboard.

So let's see, RAMBUS memory has higher latency, less bandwidth, consumes more power and therefore dissipates more heat, and it's more expensive. It basically sucks compared to DDR SDRAM in every way... Where's the plus side?

I've been hoping that someone would bring this up so that I could rehash the discussion we had on RDRAM back when this whole latency story broke. Below you will find a number of links to other places. Suspiciously, out of the holy trinity of hardware review sites (Tom's Hardware, Anandtech, and Sharky Extreme), the ONLY one that speaks up in favor of RDRAM and doesn't talk about its latency problems is Anandtech. Hmm...

From Sharky Extreme on this page:

The memory bus we are all used to operates at 100MHz and is 64-bits wide. Rambus' offering runs at 400MHz (transferring on the rising and falling edges of the clock) and is 16-bits wide. What this essentially translates into is a faster Rambus interface (in terms of frequency) with added latency because of the smaller "width" of the bus.

From Tom's Hardware: This page tells what the theoretical bus bandwidth is for SDRAM, DDR SDRAM, and RDRAM. I quote from the following page:

Continuously managing multiple latencies would be a nightmare for the memory controller. In order to work around this, when a system is booted the RDRAM subsystem performs an involved initialization process to determine what the greatest latency is for the entire RDRAM system and adjusts all RDRAM devices to have the same latency as the slowest RDRAM device on the system. And remember that in a real world system each RIMM will have many RDRAM devices so this latency balancing is quite complex.

(Emphasis is mine.) The next paragraph reads:

An RDRAM chip typically has a normal 20 ns page read access latency. To balance latencies, these chips have a TPARM control register that can be programmed with a 2.5, 5.0, 7.5 or 10.0 ns of artificial compensating latency. This means that the normal chip latency can be as much as 50% higher than the minimal 20 ns often quoted as RDRAM's page read latency. Compare this with the fastest PC100 SDRAM with a latency of only 20 ns, but again remember that RDRAM has even other issues that bring its total latency much higher still.

Finally, An article from Real World Tech explains just what the timings are like, why they occur, and why they mean that DDR SDRAM is going to be faster for the forseeable future. A very instructive paragraph on the general problems with RDRAM follows:

RIMMs also generally require a metallic heat spreader enclosure to avoid an excessive localized heating of any single memory device. Finally, the computer system motherboard into which RIMMs plug must have tightly controlled electrical characteristics that match RIMM circuit cards to avoid unwanted impedance mismatches and signal reflections. This can require extra signal layers and power planes, which along with the tighter manufacturing tolerances, results in a more expensive computer motherboard.

So let's see, RAMBUS memory has higher latency, less bandwidth, consumes more power and therefore dissipates more heat, and it's more expensive. It basically sucks compared to DDR SDRAM in every way... Where's the plus side?

I've been hoping that someone would bring this up so that I could rehash the discussion we had on RDRAM back when this whole latency story broke. Below you will find a number of links to other places. Suspiciously, out of the holy trinity of hardware review sites (Tom's Hardware, Anandtech, and Sharky Extreme), the ONLY one that speaks up in favor of RDRAM and doesn't talk about its latency problems is Anandtech. Hmm...

From Sharky Extreme on this page:

The memory bus we are all used to operates at 100MHz and is 64-bits wide. Rambus' offering runs at 400MHz (transferring on the rising and falling edges of the clock) and is 16-bits wide. What this essentially translates into is a faster Rambus interface (in terms of frequency) with added latency because of the smaller "width" of the bus.

From Tom's Hardware: This page tells what the theoretical bus bandwidth is for SDRAM, DDR SDRAM, and RDRAM. I quote from the following page:

Continuously managing multiple latencies would be a nightmare for the memory controller. In order to work around this, when a system is booted the RDRAM subsystem performs an involved initialization process to determine what the greatest latency is for the entire RDRAM system and adjusts all RDRAM devices to have the same latency as the slowest RDRAM device on the system. And remember that in a real world system each RIMM will have many RDRAM devices so this latency balancing is quite complex.

(Emphasis is mine.) The next paragraph reads:

An RDRAM chip typically has a normal 20 ns page read access latency. To balance latencies, these chips have a TPARM control register that can be programmed with a 2.5, 5.0, 7.5 or 10.0 ns of artificial compensating latency. This means that the normal chip latency can be as much as 50% higher than the minimal 20 ns often quoted as RDRAM's page read latency. Compare this with the fastest PC100 SDRAM with a latency of only 20 ns, but again remember that RDRAM has even other issues that bring its total latency much higher still.

Finally, An article from Real World Tech explains just what the timings are like, why they occur, and why they mean that DDR SDRAM is going to be faster for the forseeable future. A very instructive paragraph on the general problems with RDRAM follows:

RIMMs also generally require a metallic heat spreader enclosure to avoid an excessive localized heating of any single memory device. Finally, the computer system motherboard into which RIMMs plug must have tightly controlled electrical characteristics that match RIMM circuit cards to avoid unwanted impedance mismatches and signal reflections. This can require extra signal layers and power planes, which along with the tighter manufacturing tolerances, results in a more expensive computer motherboard.

So let's see, RAMBUS memory has higher latency, less bandwidth, consumes more power and therefore dissipates more heat, and it's more expensive. It basically sucks compared to DDR SDRAM in every way... Where's the plus side?

I've been hoping that someone would bring this up so that I could rehash the discussion we had on RDRAM back when this whole latency story broke. Below you will find a number of links to other places. Suspiciously, out of the holy trinity of hardware review sites (Tom's Hardware, Anandtech, and Sharky Extreme), the ONLY one that speaks up in favor of RDRAM and doesn't talk about its latency problems is Anandtech. Hmm...

From Sharky Extreme on this page:

The memory bus we are all used to operates at 100MHz and is 64-bits wide. Rambus' offering runs at 400MHz (transferring on the rising and falling edges of the clock) and is 16-bits wide. What this essentially translates into is a faster Rambus interface (in terms of frequency) with added latency because of the smaller "width" of the bus.

From Tom's Hardware: This page tells what the theoretical bus bandwidth is for SDRAM, DDR SDRAM, and RDRAM. I quote from the following page:

Continuously managing multiple latencies would be a nightmare for the memory controller. In order to work around this, when a system is booted the RDRAM subsystem performs an involved initialization process to determine what the greatest latency is for the entire RDRAM system and adjusts all RDRAM devices to have the same latency as the slowest RDRAM device on the system. And remember that in a real world system each RIMM will have many RDRAM devices so this latency balancing is quite complex.

(Emphasis is mine.) The next paragraph reads:

An RDRAM chip typically has a normal 20 ns page read access latency. To balance latencies, these chips have a TPARM control register that can be programmed with a 2.5, 5.0, 7.5 or 10.0 ns of artificial compensating latency. This means that the normal chip latency can be as much as 50% higher than the minimal 20 ns often quoted as RDRAM's page read latency. Compare this with the fastest PC100 SDRAM with a latency of only 20 ns, but again remember that RDRAM has even other issues that bring its total latency much higher still.

Finally, An article from Real World Tech explains just what the timings are like, why they occur, and why they mean that DDR SDRAM is going to be faster for the forseeable future. A very instructive paragraph on the general problems with RDRAM follows:

RIMMs also generally require a metallic heat spreader enclosure to avoid an excessive localized heating of any single memory device. Finally, the computer system motherboard into which RIMMs plug must have tightly controlled electrical characteristics that match RIMM circuit cards to avoid unwanted impedance mismatches and signal reflections. This can require extra signal layers and power planes, which along with the tighter manufacturing tolerances, results in a more expensive computer motherboard.

So let's see, RAMBUS memory has higher latency, less bandwidth, consumes more power and therefore dissipates more heat, and it's more expensive. It basically sucks compared to DDR SDRAM in every way... Where's the plus side?

As far as this patent goes, I think it stinks. I definitely don't want to put Rambus in my computers. It is overpriced, and underpowered. The Tom's Hardware Benchmarks said it all.

Here's a far better English version of the Tom's Hardware article

I know it's late in the day for this, but here's another - new - Tom Article. Guess what, he still doesn't like RAMBUS and gives more benchmarks to back his arguments up. In typical Tom Tirade fashion.:)

IMHO, as per

J:)

I'm no fan of Intel, but Tom's accusations seem like a stretch to me.

In 1999, Intel made $29-Billion in revenue. It doesn't seem reasonable that Intel would gamble such a large part of it's reputation on a shoddy product get a piddly $158 Million dollars (Well, I guess that's piddly). They probably spend more then that on advertising and marketing in 1999.

Then Intel went to coppermine: 256K of L2 cache running full speed. This yielded about a 10% speedup: for instance see Tom's comparison here.

Meanwhile, though faster Athlons were released (at 700, 750 MHz), they had no faster L2 cache: they had to run at 40% or 33% of the core speed. The result? Coppermine beats Athlon, narrowly. You can see it happening in this graph, if you imagine the blue line extending about straight (which is more-or-less what happened.) The two chips are quite comparable at the lower end, or maybe Athlon wins. But in the 1G processors, PIII is the winner (see this, for instance).

Now with Thunderbird, Athlon will again be more or less the same in L2 cache as PIII: 256K full speed on-die cache. So, we should expect the Thunderbird to kick PIII's butt, by about 10% or so plus the fact that it will actually be available.

Duron should also beat celeron, though perhaps by a smaller margin.

Then Intel went to coppermine: 256K of L2 cache running full speed. This yielded about a 10% speedup: for instance see Tom's comparison here.

Meanwhile, though faster Athlons were released (at 700, 750 MHz), they had no faster L2 cache: they had to run at 40% or 33% of the core speed. The result? Coppermine beats Athlon, narrowly. You can see it happening in this graph, if you imagine the blue line extending about straight (which is more-or-less what happened.) The two chips are quite comparable at the lower end, or maybe Athlon wins. But in the 1G processors, PIII is the winner (see this, for instance).

Now with Thunderbird, Athlon will again be more or less the same in L2 cache as PIII: 256K full speed on-die cache. So, we should expect the Thunderbird to kick PIII's butt, by about 10% or so plus the fact that it will actually be available.

Duron should also beat celeron, though perhaps by a smaller margin.