Register for free to join our community of investors and share your ideas. You will also get access to streaming quotes, interactive charts, trades, portfolio, live options flow and more tools.
Register for free to join our community of investors and share your ideas. You will also get access to streaming quotes, interactive charts, trades, portfolio, live options flow and more tools.
Opteron benchmarks?
http://www.3dcenter.de/artikel/2002/10-18.php
Estimated SPEC scores for Opteron at 1.2, 1.4, 1.8 & 2.0 GHz.
AMD Opteron
1 MB Level2 Cache 715/655 820/765 1085/1005 1202/1170
Assuming these hold, and assuming Opteron's top bin will be 1.8GHz(Best case), then my predictions of the last 2 years will be vindicated. I have been telling everyone that despite the outrageous claims by AMD, Opteron would fail to offer the "world's best" performance promised. I predicted here, on SI and Raging Bull that Intel's fastest processor would beat Opteron in SPEC and it looks like I called it right, assuming the numbers hold.
Hey - can't we all just get along?
UND
Yes, it looks like this might indeed be the case for 256KB L2 cache Athlon-64s. They are supposed to have dual 64KB L1 caches. Of course, for benchmarking purposes, the 1MB Athlon-64s will be used.
I don't expect we will ever see a 256K Athlon64. I suspect the performance is just too poor to productize it.
EP
CJ -
No, there isn't going to be anything but incremental process improvements by the time the Athlon64 comes out. There had better not be, A64 is supposed to be high volume, making big changes in the process means the yield and/or binsplits will take a hit...
The best thing AMD could do is admit SOI was a total disaster and move Hammer back to bulk silicon.
YB -
The fact that Barton is clocked only around 2.1 Ghz is most likely attributed to the estimate that AMD sacrificed some binsplits in order to get better yields.
I would guess that it's quite the opposite. If we assume that AMD's yields are somewhere north of terrible and therefore the fab is running nowhere near capacity, AMD can sacrifice yield for higher binsplit which brings higher ASPs.
Keith -
My biggest fear for Q1 CC is that the guidance for breakeven in Q2 will not be reiterated.
IIRC AMD never guided to a breakeven Q2. They just said they "hoped". I don't think many people had a real expectation of breakeven in Q2. Continued losses are priced in and AMD's "reinteration" of continued losses shouldn't in itself dramatically affect share price.
Just one man's opinion.
Good News!
Looks like Intel's Colorado Springs Flash fab is maxed out.
http://www.electricnews.net/news.html?code=9354208
Intel Ireland begins making flash chips
Wednesday, April 02 2003
by Matthew Clark
Intel Ireland announced on Wednesday that its plant in Leixlip has begun to manufacture flash memory products, using a new 0.13 micron process technology.
<more>
Dew -
Does the IBM figure include inter-company chip sales?
Your guess is as good as mine...
Dataquest issues new top 20 IC rankings for '02
http://www.siliconstrategies.com/story/OEG20030401S0051
Top 20 Chip Suppliers in 2002
2001 rank 2002 rank Company 2001 sales 2002 sales % change % of market
1 1 Intel $24.93 billion $25.26 billion 1.35% 16.1%
4 2 Samsung $6.31 billion $8.63 billion 36.7% 6.1%
2 3 Toshiba $6.63 billion $6.45 billion -2.7% 5.1%
3 4 STMicro $6.36 billion $6.35 billion -0.1% 4.4%
5 5 TI $6.05 billion $6.24 billion 3.14% 3.9%
6 6 NEC $5.39 billion $5.69 billion 5.6% 3.5%
10 7 Infineon $4.33 billion $5.25 billion 21.4% 2.9%
7 8 Motorola $4.74 billion $4.78 billion 0.8% 2.6%
9 9 Philips $4.4 billion $4.36 billion -0.9% 2.1%
8 10 Hitachi $4.72 billion $4.12 billion -12.7% 2%
11 11 Mitsubishi $3.88 billion $3.55 billion -8.6% 2%
13 12 Fujitsu $3.75 billion $3.23 billion -13.9% 2%
15 13 Matsushita $2.78 billion $3.14 billion 13.2 1.9%
14 14 IBM $3.29 billion $2.95 billion -10.2% 1.9%
19 15 Micron $2.41 billion $2.94 billion 22% 1.8%
16 16 Sony $2.57 billion $2.71 billion 5.6% 1.8%
12 17 AMD $3.79 billion $2.66 billion -29.8% 1.7%
17 18 Sharp $2.52 billion $2.66 billion 5.4% 1.7%
20 19 Sanyo $2.39 billion $2.50 billion 4.5% 1.4%
22 20 Rohm $2.25 billion $2.39 billion 6.6% 1.3%
-- -- Other suppliers $49 billion $49.1 billion 0.2% 31.7%
-- -- TOTAL $152.5 billion $155 billion 1.62% 100.0%
Source: Dataquest Corp.
Joe -
Thanks for the clarification.
Now, this brings up the question, do you think Intel is pricing to eliminate AMD or to maximize profits? I don't want to put words in your mouth but you are probably going to pick something in the middle. Do you think it's possible that Intel does not consider AMD at all when pricing, but simply what they can move and how much they can make?
Joe -
The table in my previous post illustrates it. Yes, Intel improved its bin splits, but AMD improved its bin splits faster, which allowed AMD to shrink the gap.
Like I said before, you demonstrated nothing but AMD's product offerings. That's not binsplits. You showed nothing about how many AMD sold at each bin and more importantly you showed nothing about how many they could produce at each speed. You could just say that AMD's offerings increased faster than Intel's and leave it at that.
Joe -
Please... This demonstrates nothing when you don't know anything about volumes at a given speed. Even then it would only reflect the market demand, not the production capability, which was the original claim.
If you assume that Intel is pricing to damage AMD then you can draw one conclusion. If you assume that Intel is pricing to maximize profits you could draw a different conclusion.
I can't comment on where Intel's sweetspot in manufacturing is or how it has changed over the last few months but I wouldn't assume AMD's has moved up more than Intel's if I were you.
YB -
I'm assuming Intel had 2.8 Ghz part in volume right at introduction. With their waste manufacturing space binsplits are not so important. So we'll never know what they are.
So you agree with me. You don't know what Intel's binsplits are and can't know. You made my point for me.
YB -
Elmer, agree, as jhalada said about both Q3 and Q4, this is not right. But if he had said about Q4 and Q1 he would be absolutely correct.
I don't think you can conclude that. You have no idea where Intel's binsplits are, I assure you. You may be right about sales mix but you have no idea what the binsplits are.
Buggi1000
Please read his original statement. He said "relative to Intel".
wbmw -
Of course, in the same period, Intel has gone from 2.4GHz to >2.8GHz, easily.
Which illustrates my point perfectly. He said "relative to Intel".
Joe -
The production bin splits have improved significantly relative to Q3 and Q4, relative to Intel
Where is the data to back up this claim?
wbmw -
Elmer, favorites = buddies for the next 24 hours or so.
What happens then?
What happened to Favorites????
Paul -
Known any other communication protocols or architecture to stand still for that long in today's world?
Well it's not a communications protocal but Hammer has gone absolutely nowhere in the last year and a half since it's promised introduction.
Matt -
If I had a nickel for every time some poor loser accused Intel of strongarm tactics I'd be sipping a cold one on a fishing boat off Cabo while a nubile young sweetie wiped my brow. Every time Intel is investigated they come out clean as a whistle but the losers need something to whine about.
Same old same old.
EP
CJ -
Why? HTT uses a number of individual clocking domains, one for each 4 bits. So skew is not nearly the problem it is when you are trying to drive a wider bus.
Why do they need a clock at all? Serial protocals allow for extracting the clock from the data. No clock, no skew.
Sun looking at Opteron but announces new Intel systems:
http://www.eweek.com/article2/0,3959,986414,00.asp
Sun will shortly be announcing the expansion of its entry-level x86 server product lineup beyond the current LX 50 server announced last August. "You will see in the very near future a new class of one- and two-processor [Intel] Xeon- and Pentium 4-processor … hardware in the 2.5 to 3GHz range," said Loiacono.
Keith -
so the time the board shows is EST (which I hope is the same as EDT?).
I'm in Arizona where we don't change time but I believe the rest of the country is on standard time now.
YB -
Elmer, 256K L2, 2 Mb L3, that's Xeon.
No it's not. First off, your original post said nothing about L3 cache.
IBM eServer xSeries 440 Model 8687-38X, 16-way SMP, Intel Xeon MP 2.0 GHz, 256 kB L2 cache 1090
Second, Intel doesn't offer a product with 256K L2 and 2MB L3.
The Intel Xeon processor MP was initially introduced with 256KB L2 and up to 1MB iL3 cache, and is now available with 512KB L2 and up to 2MB iL3.
http://www.intel.com/eBusiness/products/server/processor/xeon_mp/ds021101_sum.htm?iid=ipp_srvr_proc_...
UpNDown -
Lots of good discussion on ECC vrs CRC but at this point I must defer to my more knowledgable colleges.
EP
YB -
That system will beat all 4-way servers in the world, including Itanium and Power4.
Once again you are comparing tomorrows AMD vapor with what will very soon be yesterday's Intel systems. So easy to shoot off your mouth but you have no proof whatsoever.
Ten -
First of all, data corruption really shouldn't happen all that often. Maybe once per week, and that's if you add up all of the servers in a cluster. That's why bandwidth is irrelevant when it comes to retransmitting data. The only thing with retransmission vs. error correction on-the-fly is that the transmitter must keep a sizable FIFO buffer of all its transmitted data until the receiver can send back a "CRC OK" packet.
The bit error rate may be higher for highspeed differential signaling and as I pointed out, the CRC is attached to every packet, so some bandwidth is always consumed. ECC is in parallel and consumes no bandwidth.
About the receiver sending back a "CRC OK" packet, doesn't this add additional delays to snoops where a remote processor provides the data and then must wait for the CRC OK response over a couple of hops? What about snarfs by other processors? Must the processor providing the data wait for a "snarf OK"? (only half serious here).
UpNDown -
Perhaps it's time you and Elmer got a refresher course on ECC and CRC.
No need, I know what it is. The point I made was that ECC can correct an error while CRC requires a retransmit. On a shared bus ECC is in parallel with the data. Corrupted data can be corrected on the fly, no bandwidth penalty. CRCs must be attached to the data packet and therefore always consume bandwidth even when there is no data corruption. Corrupted data must be retransmitted, further consuming bandwidth. What this means is that the bandwidth claims of aHT is somewhat misleading.
YB
fastest quoted Xeon server (there are some faster Itaniums though): IBM eServer xSeries 440 Model 8687-38X, 16-way SMP, Intel Xeon MP 2.0 GHz, 256 kB L2 cache 1090
Something's wrong here. 16-way with L2 of only 256K?
I don't think so...
YB -
The crc vs. ecc in aHT is ok. Remember, ecc is used to control the memory bus, where bits are coming from memory chips, where erros are possible. I'm sure Opteron supports ecc in its memory controller.
There is still the potential for data corruption in the packet transmissions over aHT, otherwise there'd be no need for CRC, right? . Without ECC, the corrupted data cannot be corrected and must be resent.
aHT is used in the traffic between two cpu after it passed ecc control. This is more similar to the traffic between northbridge and cpu. There is no ecc there either.
I am not certain about this, but I believe there is ECC on the processor bus for Intel server processors.
wbmw -
There's no mystery. AMD underestimated the kinds of circuit design changes required to get a performance benefit out of SOI.
Yes, this is pretty much the conventional wisdom, but my point is if AMD simply fabed Hammer on bulk silicon they should have at least been able to match the frequency of their mainstream products. Barton is somewhat frequency limited by it's larger L2, but Athlon64 was intended to have only 256K L2 cache so it should have at least matched the TB speed and probably more with the 2 extra pipeline stages, plus it would have been out long ago. So maybe the question is, was SOI the biggest blunder in AMD's history?
Dew -
are you suggesting that moving to a SOI-based design could have the effect of slowing down the achievable clock speed? If so, I do not understand what you are driving at. T.i.a. Dew
I'm giving you information.
3 years ago Intel integrated a P3 core, a graphics controller and a rambus memory controller hub. They did it on their hvm fab process and they were able to maintain the full core frequency. They suffered no drop in speed.
AMD has added 2 pipeline stages to the Athlon core, moved it to a "more advanced" SOI process while adding a memory controller and aHT ports, roughly equivilent to Intel's Timna chip in added complexity. One would expect Opteron to gain speed from the additional pipeline stages and gain speed from the "more advanced" SOI process, yet all indications are that Opteron will lose substantial clock speed. It has been suggested here that 64 bitness degrades frequency but the person who made that claim did not offer a convincing case. If anything I would expect Opteron to run at higher frequencies than it's shorter pipeline, bulk silicon cousin but it looks like exactly the opposite takes place. If SOI is truly "more advanced" one might wonder why are frequencies going down?
mva5 -
Itanium's market viability is questionable:
It's pure marketing propaganda. What else do you expect SUN to say?
kpf -
After all, what I would expect is what IBM is able to produce.
Nobody knows what IBM is able to produce on SOI, in terms of yield and defect density. Maybe AMD is getting as good, or as bad as IBM?
wbmw -
The reason why Opteron is being launched at such a slow speed has to do with manufacturing difficulties, including the move to SOI. These difficulties will not last forever, but it looks as if they will impact AMD until later in the year, at the earliest.
I've been puzzled by this low clockspeed. A couple of years ago Intel designed a product called Timna. It included a P3 processor,an on die memory controller and a graphics controller, yet the processor was capable of running at the same frequency as the then current top of the line P3. With Opteron, AMD has moved to a more advanced SOI process compared to their standard Athlons. They've added 2 pipeline stages yet apparently can't come close to matching the MHz of their mainstream Athlons. Very puzzling.
Edgarcayce :
Basically what I hear on this board is AMD sucks and Intel is the God of the universe. Always amazing to me how all these people rally behind Intel whenever they come out with a new product and rant how fantastic it is. Even before it's out.
It looks exactly the opposite from my vantage point. You've sung the praises of Hammer and we don't even know if it will be available in April.
Yourbankruptcy -
You are missing an obvious disadvantage of the Opteron architecture. Snooping requires a hop for Opteron and a hop to wait for a response. On a shared bus each processor sees the bus activity in real time with no hops. Additionally aHT has no ECC. It relies on a CRC at the end of every packet. This, along with the snoop hops cuts into bandwidth. I think you have bought into the hype when there is no data whatsoever to support your unbounded optimism.
BTW, it has been suggested we use the terms aHT to refer to HyperTransport, and iHT to refer to HyperThreading. It think it's a good idea.
Yourbankruptcy
Maybe one day Intel will port Centrino to HTT.
It would seem much more likely that Intel would use PCI-Express.
XP4000
AMD will take the Barton core, stick in 1M cache,
strip the socket A interface, add a memory controller
and the Hyper transport bus. XP4000+ by xmas.
Isn't that less than an Opteron? Barton is just Athlon with 512K L2 and Opteron is Athlon with 1Meg of L2 ( plus 2 additional pipeline stages) plus aHT. So what you suggest is a step backwards.