Slashdot Mirror
Documents Reveal Rambus' Patent-Enforcement Plans
spiro_killglance writes: "Electronic News Online asked the U.S. District Court of San Jose to release the Rambus Internal Memos on JEDEC. The court did so
yesterday. Get the scoop here. But in brief, it looks like
they were planning to stick it to memory manufactures all along,
and did add patent claims from information gained at JEDEC in 1992." Hmmm. Rambus, slimy business practices? Say it ain't so.
In a suprise announcment today Rambus announced that they were retroactively announcing their patant for magenetic-core memory. Analysts speculate that this is a defensive move by Rambus in the event of a failure in their current bussiness model to patent other peoples' ideas that are currently applicable. This new initiative would patent other peoples' ideas that are already patented.
When questioned weather he expected to be granted a patent, the CEO of Rambus pointed out Amazon's One-Click patent, and said, "What do you think?"
When further questioned if he thought there was a market for slow memory in 128 byte chunks, he pointed out that people were buying RDRAM.
--
Remove the rocks to send email
On the whole, I find that I prefer Slashdot posts to twitter ones because I don't get limited to 140 chars before
--
--
We have fought the AC's, and they have won.
No, you're wrong.
r ev iews/1787/9/
Please go read Tomshardware stuff on RDRAM or
Hardwarecentrals article.
"However, when the memory system is under higher load the answer can be quite different. When one or more additional transactions are being serviced, factors such as bank conflicts and address bandwidth become important issues. The higher bank count of RIMMs versus DIMMs means that the probability of bank conflicts occurring is much lower. Therefore, the high latency and bandwidth penalties associated with bank conflicts occur far less often in RDRAM-based systems than in SDRAM-based systems. Furthermore, as illustrated in the previous timing diagrams, the need for 2-cycle addressing on an address bus used to specify both Row and Column addresses means that the address bus may not be available to start a subsequent transaction in SDRAM-based memory. During periods of higher memory utilization, when more than one request is sent to the memory controller, some memory requests may be delayed waiting for the address bus. For these reasons, under higher loads RDRAM-based memory can be much more efficient, achieving lower latency and higher bandwidth than SDRAM. "
http://www.hardwarecentral.com/hardwarecentral/
If you disagree, please provide some resources as foundation.
--sn0w
The primary issue here is not whether Rambus' patents are valid by themselves. The issue is that Rambus may have violated contractual obligations to JEDEC and its members. The JEDEC member rules specifically prohibit what Rambus allegedly did (sitting on patents while allowing them to become standards), and presumably if it's determined that Rambus violated those rules... then lots of penalties could be applied. I don't know what they might be (I don't know if they could actually invalidate the patent, or just force Rambus to pay huge settlements.)
There's no point in JEDEC having a set of rules for just this purpose if they can't be enforced. It seems that if Rambus really did violate them, they should be punished. Otherwise, standards organizations simply can't function, as long as for-profit members can get away with breaking the rules and producing tainted standards.
The other allegation, which is harder to prove, is that Rambus may actually have "stolen" ideas brought up duruing the JEDEC meetings. If that's the case, their claims on the patents may be illegitimate.
It is shocking that a corporation would invent something and then turn right around and patent it!
It's only shocking because Rambus agreed not to file patents on any of the SDRAM technology, but while the standard was being made, Rambus amended an existing patent application to include new claims that covered SDRAM.
All your hallucinogen are belong to us.
Will I retire or break 10K?
How d'ya s'pose TI managed to survive the latter half of the 1980's? Check out this guy's resume: http://www.jaeckle.com/attys/fitzgeraldthomas.asp -- "As part of the Texas Instruments licensing program that generated over one billion dollars in patent royalties, he was responsible for identifying and enforcing TI patents against unlicensed U.S. companies. This activity included identifying infringers, reverse engineering and analysis of infringing devices, and presentations of that analysis to potential licensees to encourage them to take a license."
I've been saying for the past three or four years that if we don't learn from the semiconductor industry, whose path we, the builders and users of the internet are following, we will end up with the same environment here, as well. Or, more succinctly, "Work toward your vision of tomorrow, or surely you will live in someone else's".
--
Warning: This signature may offend some viewers.
What I see with the first release of the P4 is an incomplete processor pushed out the door by marketing 'droids. If the missing pieces of the P4 are ultimately implemented, it may actually turn out to be a decent processor with decent performance and expandability.
My jury is out on that one for the next year. When/if the "real" P4 comes out, we'll see if it can actually keep up with the Athlon. If I need a kick-ass box before then, I expect that I'd buy an Athlon.
As for RDRAM and a P4 with optimized code beating SDRAM (on what processor?), I think that you should be comparing a P4 with optimized code on RDRAM vs SDRAM (both using properly optimized chipsets), to know that it's not dependant on something other than the RAM protocol. Until then, though it seems that for the current state of the art, RDRAM doesn't seem like a very good bet.
That having been said, the fact that they had to pretty much blackmail various manufacturers into use RDRAM doesn't bode well for the technical superiority of the technology either.
--
Free Software: Like love, it grows best when given away.
You have no chance to survive. Make your time.
Well, I haven't really thought about the best way of interleaving data across banks with parallelization in mind. I think it's one of those things I'd have to see simulated before I could really picture it. You'd definately want more per bank in a higher-latency design, but the exact ratio isn't clear.
:)
I can definately agree with the idea of needing out of order transactions, that's one of the wins with SCSI. With many small requests you end up getting fairly large gains from serving some out of order where with large transfers the access cost is outweighed by raw transfer speed.
As for the job stuff... I have to agree with the idea of people being cross trained. I myself rant about high-level programmers not having any low-level experience, they think that all instructions take as long to process, despite one translating easily into a single opcode and the other being a o(n^2) list operation on complex data. Argh.
Anyways, I have to agree. People should know all parts of the system, even if they tend to specialize, because it enables them to better use the tools.
And yeah, the short build cycle of software is a huge plus compared to an actual physical process. I remember making circuit boards (simple stuff in high school) and how screwing something up meant spending about an hour, with correcting the mistake, reprinting the board, etching it (and dying your hands green in the process) and then redrilling and soldering the components on.
I'm so spoiled these days because I'm doing a lot of prototyping in stuff like perl. When I have to go to C I find myself saving the code and immediately trying to run the executable, forgetting completely about having to build it... heh. In some ways I can't imagine going back to a long build cycle.
Regardless, hardware seems more tangible, mainly because it's hard to just hack together, so it's a larger achievement. I've only done little projects, but they still feel more impressive than the much more complex stuff I've written in code, most of the time.
I guess a good mix of the two would be best. Some hardware design, but mainly writing the code to make the hardware do funky stuff. But then, being able to fix a hardware bug instead of having to just work around it.
To answer you and the AC who responded:
Many architectures support interleaving. If the CPU wants 32b at a time and the RAM is 16b wide, you simply use two banks. It's a bit more complex, but not by much.
What modern chipsets do is decouple the CPU and the RAM. In old computers traces ran straight from one to the other. Today they use the chipset as a gateway. For the most part these chipsets are fairly stupid, the IDE drives of the RAM world. They simply take one request and pass it along, interleaving directly across banks.
A server-level chipset is more like SCSI, it takes a list of requests and fills them in the quickest order. It also doesn't interleave just to get the number of bits / transfer that the CPU wants, it interleaves data across multiple banks which are each as wide as the regular data path.
With a translator (the chipset) between the RAM and CPU, you're free to fetch the data in any way you want and then just assemble it for transfer to the CPU in the most convenient way. Complex chipsets are able to do this with more banks at once.
That's a fairly gross oversimplification, but it's the jist of it.
As to why it's not done... chip size and number of traces. DIMMs are 168 pins, you basically need that many traces between the chipset and the RAM, and for two banks, you need twice that many. In addition to the traces from the chipset to the CPU, and everything else it handles.
Being that traces can only be so thin, you need more layers on the motherboard to cram them all in, which increases complexity and thus cost. Not to mention the chips being so big simply from the number of pins sticking out the bottom.
This is where RDRAM comes in, it's got a narrow bus so it takes less pins per bank. But, RDRAM is much more complex than SDRAM, making it take longer to do something, like ask for the data at a certain address. That latency makes it slower start sending data even though with more channels it's faster once it starts.
Compare this to SDRAM which is very fast to make requests of, meaning that it may be slower in the long haul but it's faster off the line.
So it comes down to a price/performance tradeoff. Multiple channels of SDRAM is always better, but more expensive and harder to do. So for some things where a little latency is less important, RDRAM might make sense. Unfortunately this isn't (IMHO) in regular computers, but instead in texture cache on a PS2 or something.
Well, the Tomshardware link isnt very positive towards RDRAM really, and Sander Sassens articles on hardwarecentral have been rather controversial.
Theory is very nice, but unless there are some hard facts or at least consistent benchmarks made by several independent testers (rather than
the dubious ones that exist now), that show anything more than an infinitesimal performance difference either way for general applications (and which currently appear to show a generally worse performance for RDRAM), the price isnt even close to worth it. Even for servers.
http://www.inqst.com/ddrvrmbs.htm, tomshardware articles on ddr sdram, etc.
RDRAM is not the way to go, and not just because of price. DDR SDRAM is faster (benchmarks vary, but usually favor DDRSDRAM), cheaper (pricewatch $65 vs $129), more reliable (not because of RDRAM itself, but because of controller difficulties on motherboard), less power consuming, and cooler (RDRAM needs a fan). DDR SDRAM is also, by open source philosophy, ethically superior, because it is an open standard while RDRAM is closed. DDR SDRAM is superior to RDRAM in nearly every way.
Presently, no video card exists which uses RDRAM, and given the thermal and latency issues with RDRAM, it's probably going to remain that way indefinitely. The high-end GeForce cards use high-grade DDR SDRAM at very high clock frequencies, which is much faster but generally even more expensive than RDRAM.
------------------
A picture is worth 500 DWORDS.
The fact that these technologies could give them the patent to SDRAM isn't, in and of itself, at least relatively, worrisome. I think the idea that Microsoft owns the rights to Winblows has far more wide-ranging effects and is far more troubling than the possibility of a company owning rights to SDRAM.
If you think that IT patents are crazy, look at some of the non-IT patents that have had half the world paying royalties, over the years. For years anyone using plexiglass (thousands of engineers and architects around the world) had to pay the fellow who patented it. The paper clip was patented in 1899. Everyone knows the telephone was patented. Motorola patented the cell phone, for that matter. If the idea of SDRAM's rights being owned is scary, it's because we should be scared of the idea of patenting, itself, not because of any misuse of patent law by RAMBUS. Trademark Infringement: Just do it.
To ensure open standards remain open, I think all profit-driven members of standards committies should be banned. It's the only way.
I disagree with that viewpoint. Not all profit driven companies are scumbags. There is more than one ligitimate way to derive profit from a situation like this - pulling stunts like RAMBUS'es isn't nessisary. In fact, it's the really fscking lazy way to do it, or a last resort option.
And even funnier - how do you propose to determine which companies involved are simply profit driven, and which ones have a very ligitimate desire to be involved in the creation of an open standard? Or do ypu contend that all for-profit organizations (individuals, companies, etc.) should simply be banned - and anyone with any real stake in the subject be left out of it?
I could ramble on and on about this one - but I won't Yes, companies like RAMBUS piss me off, but, what are the realistic alternatives?
Davis Ray Sickmon, Jr - looking for something to read? Check out my three free novels at MidnightRyder.org
The technology must be pretty pathetic for it to be bitchslapped so badly by equipment that costs maybe a third as much.
(Either that, or you're John Corse, the RMBS Stock Shill, under a pseudonym. Then again, you're not coming across as shrill and strident as he does.)
20 January 2017: the End of an Error.
To ensure open standards remain open, I think all profit-driven members of standards committies should be banned. It's the only way.
Then, no "profit-driven" member will adopt the technology. The whole point of standards is to avoid having the industry big-wigs develop redundant, incompatible technologies that lock in customers. With things like DRAM, no one who isn't "profit-driven" can really benefit from the work of a standards committee. Just try and manufacture a new RAM standard in your garage.
Standards bodies are good, and it's essential to get the big companies on board to adopt the technologies created and to bring the experience in manufacturing and design that other entities just simply don't have.
While I have a very low opinion of corporations in general, especially profit-driven public corporations, the majority of companies realize that acting against a standards organization is counter-productive. The only people who can afford to are all near-monopolies, such as Microsoft, or little underhanded IP clearinghouses with no actual product like Rambus.
I'm just worried that companies like Rambus have spoiled the process for everyone else. Just like the article said, it's like a sporting event where you expect everyone to be playing fair. When someone doesn't, it casts doubt on all the other athletes and the event itself. The last thing we need is for Rambus's actions to destroy confidence in open standards organizations.
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
That's because Microsoft applications don't use standard ASCII for quotes in order to do their "smart quotes" feature. There's a program called the "Demoronizer" that fixes that and other damage if you want your web pages viewable outside Windoze.
When Rambus dies, they'll get handy severence cheques. After that, they'll sadly pack their porches and drive off into the sunset, looking for another sweet deal.
--
Free Software: Like love, it grows best when given away.
In that case, IMO, if/when RAMBUS loses, the other members of JEDEC should sue RAMBUS's principals.
These memos seem to provide evidence RAMBUS execs were deliberately promoting fraud..
=== The price of freedom is eternal vigilance
I agree with you on that "use it where it makes sense". I just don't think that RDRAM makes sense as the main memory of a general purpose computer.
For video, which is dealing with large concurrent data, it's fairly good. For databases which are small non-linear pieces of data, it's not.
Your point about the concurrent memory busses is interesting, but I still think a general CPU would be best served by lower latency. And it'd be a different architecture, because you'd need to interleave the data across physical RAM a MB or so at a time instead of at the bit/byte level, or you'd need to hit all the busses anyways.
I personally think you'd be better served by a decent L3 cache which could actually deal with this sort of issue better than a general-purpose memory architecture. Sort of the way an L1 cache can be so low-latency because of the tradeoffs being made in design.
I can't say that I've tested this theory, but I think with the complexity of the controller you'd basically lose any speed benefits of the architecture.
Sounds like you've got a great job. I often think I was born many years too late considering I love playing with the bare metal so much.
A real server, not something on a Abit-VP6, but something on a Tyan dual or quad CPU board, would be best served by dual or quad SDR-SDRAM channels.
It's called the ServerWorks series of chipsets, read up here (on AnandTech): ServerWorks HEsl: DDR bandwidth without DDR SDRAM
It'd add a few hundred dollars to the price, but it'd easily outpace anything RDRAM could throw at it, with all the bandwidth needed AND the low latency of a good technology.
And they are expensive too...
Macs did this a long time ago (memory interleaving) and it's nice to finally see this feature implemented in motherboards again. It'd be nicer if they'd be implemented in lower-end motherboards as well (if Apple did it years and years ago, it can't be some sort of trade secret...).
Abit's "-RAID" boards should have it... they have RAID, why not use a "RAM RAID" as well?
The Register is running a short
clip about the story. Also the PR department of Rambus has been active, the result can be seen
here (althoug nothing very original, just typical quoted out of context defence)..
It's anyway funny to see that Micro$oft isn't the only company which is conserned about the protection of "innovation"...
My DeCSS archive:
Documents Reveal Rambus? Patent-Enforcement Plans
Close guys. It is good you knew the "question mark" belonged somewhere in that phrase. And you were pretty close in putting it in the right position. Try one word over...closer....now try right after "Plans". There you go! I knew you could do it...
We all know Rambus has been using sneaky tatics to gain market share, i hope something really comes out of this. They've been holding back innovation in the memory field. How many millions of dollars have been spent in court rather than researching new memory technologies? Rambus doesn't care they have nothing new coming and depend that nothing new and improved comes out.
Anyone seen the recent figures on their expenditures? 1/3rd of expenses is for lawyers!, i don't mind computer companies being run by marketers(MS) but its the ones run by lawyers that bother me. Think if there was a program like napster for computer memory, the creator would be on death row. Time for an anti-trust suit against rambus
This was all part of their plan! They applied for patents on RAM technology, and when they were approved, they lied in wait like a tiger ready to ambush its prey. And then, they saw their chance in 1992. To prevent suspicion of foul play, they waited 8 years to sue the RAM makers. And when they did, they claimed that they had patents established well in advance.
IMHO, this was the perfect patent scam. They remained aloof while SDRAM proliferated in the consumer market, and then when computers all over the world were infringing on "their patents", they struck.
I hope they all fry in a vat of their own excrement (or they can just have numerous stories on FC). Such a despicable death is only fitting for this company of weasels.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
Pud's gonna love this one!
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
I know you're trolling, but other people have bitten, so I'll correct your lies.
.5MB-4MB textures and sends them to a video card. This is only one primary read request and then a nice long stream. Both DDR-SDRAM and RDRAM shine in this area. Unfortunately, this benefit is negated by video cards with texture compression and 64MB (like all of the upcoming generation). The consumer-level chipsets used also negate many of the benefits of any technology.
RDRAM tends to be the worst for servers. The large cache on servers negates much of the benefit of high bandwidth RAM. Instead it calls for very low latency. SDR-SDRAM is lower bandwidth, but also lower latency. RDRAM and DDR-SDRAM are higher bandwidth but also higher latency.
Few real server applications involve sending fifty megabytes of static data per second, servers are called on to do dynamic data, sites like Slashdot, or CNN, or Google, where data is processed in complex ways and then presented. There's little locality of access (it's unlikely two things near each other in memory will both be wanted) so what really matters is how little time it takes for the server to fetch these isolated bits of information that it needs.
A gaming station, on the other hand, frequently loads
Low-end PC chipsets (the stuff most of us use) handle RAM a little inefficiently and most RDRAM/SDRAM comparisons are based on a consumer-level SDRAM chipset and a server-level RDRAM chipset, so they claim that the low-end chipsets deficiencies are problems with SDRAM where they're really just a problem with a consumer-level product. People are spending $400 for a GeForce 2 Pro, yet the chipsets for their motherboards cost $15 in bulk... It's like actually putting a porsche engine in a volkswagen, you might be able to make it fit but you'll realize that a porsche is much more than a fast engine.
A real server, not something on a Abit-VP6, but something on a Tyan dual or quad CPU board, would be best served by dual or quad SDR-SDRAM channels. It'd add a few hundred dollars to the price, but it'd easily outpace anything RDRAM could throw at it, with all the bandwidth needed AND the low latency of a good technology.
RDRAM only looks good on paper and a few carefully constructed (ie, outright lies) benchmarks. All the claims of Rambus are outright lies. And you can quote me on this. They're thieves, cheats, and liars. They produce no product and exist merely to patent technology invented by other people. If there's a list of people most deserving of prison, these guys and all their shareholders belong on it.
I think that these memos clearly show that RAMBUS all along intended to violate the legal agreements they had with the JEDEC members. And that they deliberately used JEDEC to get patents, and also to get their patented IP into the SDRAM standard...
Now all it will take is an honest court and judge to hear this case. Which seems to be hard to get these days...
However, time and money is against RAMBUS. RAMBUS is now left completely without friends in an industry that wants to see them gone. Micron, et all have time and revenue on their side... Even Intel is no longet their friend. Intel is speeding up the release of their own DDR chipset for the P4. RAMBUS memory has already failed in the marketplace, and royalties on that is about the only income RAMBUS has to feed their legal machine.
So, one way or another, I think that this is the beginning of the endgame for RAMBUS. They are not developing any new technology (that we know of) to counter DDR. They put all their eggs in the basket of dubious IP and lawyers.
And it will be good for the whole tech industry for RAMBUS to fall in a spectacular and final fashion. The RAMBUS business model (dishonestly patent shady IP then sue everyone) needs to be demonstrated to be a failure.
=== The price of freedom is eternal vigilance
The interesting thing to look at is the point where usefull concurrency maxes out - which is roughly the point where the data transfer time of cache line size matches the access time on a bank (this is different if you do speculative accesses) - if you assume that the memory accesses coming out the back end of the L2/L3 cache are random (not always true - but, apart from startup and context switch, simulation seems to bear this out) it's best to interleave across dram banks at a cache line granularity - this means that if you have enough concurrent banks (say 8) you can have concurrency 7/8 of the time (the difference between 16 banks 15/16 and 7/8 isn't much). However as I mentioned in my previous post if you have to send the data across a bus (slot 1 for example) that's much slower then either the memory (RDRAM clocks I mean) or CPU then you get little concurrency at the memory controller (which starts to win when it can choose between multiple concurrent transactions for the 'best one' - and it really needs 3 active transactions before this kicks in) - to make matters (here it hits latency) is when you have a bus (like slot 1, not slot A) where the memory controller must retire data back in-order - for a gross example an early transaction waiting for refresh (or any other bank conflist) will stall following transactions even though the memory subsystem might be able to retire them earlier.
Sounds like you've got a great job. I often think I was born many years too late considering I love playing with the bare metal so much.
Actually I started out as a programmer doing OS stuff (I ported Unix V6 for example :-) but I had always done some hardware stuff - I fell into chip design architecting Mac graphics accelerators - eventually it got easier to code Verilog myself than tell other people what to do .... these days chip design is very similar to normal programming - Verilog is just a wierd C - I actually think that chip design needs more designers with a software background - that hard wall between hardware groups and software groups has always seemed to me to be a real problem - there are lots of hardware software tradeoffs that don;t get done because neither group understands each other well enough.
Having said this I've actually been trying to get out of doing full-time chip-design and in to doing a lot more software design - mosstly because I find coding is much more satisfying on a day-to-day level - doing chip design you're spending maybe 10% of your time doing the cool creative stuff that's really satisfying, and 90% of your time making sure that chip is absolutely perfect when you tape out - with programming you tend to get something working every day
Yup. RDRAM is best utilized in something like streaming video, or textures. Anything where you store a lot of large 512kB or larger chunks of data and want them to come in quickly.
It does very poorly where you have data that's between 16 and 128B and you want many different little chunks from different places.
RDRAM would shine in something like video encoding, or pumping textures to a video chip, or sending large static webpages. Stuff that benchmarks easily.
RDRAM falls over doing things like Slashdot, where each page view might be constructed from five to five hundred database accesses and many little perl scripts.
RDRAM is a quest for more bandwidth at any cost, whereas SDRAM is the quest for lower latency. DDR-SDRAM is a good middle-ground.
RDRAM is fundamentally high-latency with its complex architecture. You can add more RDRAM channels and you can't combat that basic flaw. But if you take nice low-latency SDR-SDRAM and add more channels you get more bandwidth, thus counteracting any benefit RDRAM has.
Now, slow RDRAM would actually be useful in low-end PCs, the sub-$500 market. You could make a very cheap motherboard because it requires less traces. You also wouldn't care about it being really slow because, hell, it's a $500 PC running a Winchip or something. But, Rambus killed that idea with their license fees, they'll end up making it so expensive that nobody could use it except in a server, where it really really sucks.
"RDRAM is certainly the way to go"
Maybe for playstation and N64, but RDRAM based PC's are routinely slower than their DDR counterparts.
I wonder if PS2 were being designed today if they would still use RDRAM? Probably not. It was fashionable when it was designed, but now its an evolutionary dead-end.
When you add in their higher price and lower performance, RDRAM's time has come and gone.
You were mistaken. Which is odd, since memory shouldn't be a problem for you
It is not under question here whether Rambus really could file for those patents. What is under question is whether these undisclosed patents violated existing contracts. If it can be proved that Rambus acted in bad faith on the contracts, all kinds of contract fun comes into place. IANAL, but this looks as those who are will make lots of money off of this. The lawyers may be the only ones who make good on this in the end...
More and more patents seem to seem like the intelectuall version of "First Post"s...
Rambus joins a group develuping new technology "First Patent"...
Amazon and one click shopping "If we didn't they would have"...
The whole busness of "We patented it before you could do it" is getting silly...
It's just a good thing for Microsoft somebody didn't patent FUD or they'd be sued up to there eyeballs...
I don't actually exist.
Im not sure exactly which kind of server RDRAM would be good for tho. Most servers Ive ever seen would be even more sensitive to latency issues compared to a desktop, due to the multiuser nature of servers in general.
Maybe it would be useable for some very specialized multimedia work or computation machines, where the benefits of high bandwidth would outweigh the latency problems.
But if you have to go that far out from any ordinary usage to find a use for the product, just forget it. Its probably not ever worth it. RDRAM might find a niche if it was cheaper than ordinary SDRAM but as it is now, its dead.
Remember, that paragraph is a theoretical evaluation, based on the benchmarks and on the author's personal opinions. Looking at the benchmarks, I noticed that the SDRAM used was CAS3 (low-grade), which will perform more poorly that CAS2. It compared this against PC800 ECC RDRAM, which is top-grade and extremely rare. A search on Pricewatch came up with $41 for 128MB CAS2 PC133 SDRAM, $154 for the same amount of PC800 RDRAM.
This significantly hurts the credibility of the benchmarks. In the one benchmark where RDRAM took a significant advantage, the author says that "the benchmark isn't designed to make efficient use of memory architecture, and the scores don't fairly represent it, this is still a good measure of raw memory throughput", seemingly contradicting is own results while affirming them. On the Q3A benchmarks PC133 SDRAM out-performed the PC800 RDRAM, and on SYSmark RDRAM won only by 6%.
------------------
A picture is worth 500 DWORDS.
all your base are belong to us.
Not my base, FreeBase. It belong not to your. All my base are belong to Open Source Base.
... if Intel can't pull some legal tricks on Rambus for deliberately sabotaging RDRAM by annoying virtually every RAM Manufacturer out there with their royalty practices and hence hurt sales of Intel chipsets tied to RDRAM.
"By the way if anyone here is in advertising or marketing... kill yourself." -- Bill Hicks