Hi David,

Thanks for the great article. This definitely draws a picture that coming 3 years (2007,2008,2009) intel will get annihilated in multiple sockets highend unit sales because of the achillesheel that CSI is not yet there until end 2009 for Xeon MP processors, which means 2010 we can see that in businesses.

Of course by then core architecture will be totally outdated and it will again be an open market to whoever can produce the best total system by then.

What i don't quite understand is how the 'internal bandwidth' that such a technology like CSI can provide can be compared to the memory bandwidth that a system can generate.

Is that the same?

I ask this because i read that todays videocards with DDR3 already can generate far over 100GB/s memory bandwidth, both ATI and AMD.

How can CSI handle such future bandwidths, knowing it will exist for another 10 years or so, by then the memory can hopefully deliver up to a terabyte/s, if not more, bandwidth and CSI cannot handle that.

Can you enlighten that?

Thanks,
Vincent

David Kanter (dkanter@realworldtech.com) on 8/28/07 wrote:
---------------------------
>Dear RWT Readers,
>
>I have waited a rather long time to put this article online (since February when
>I first started researching). As many of you know, Intel is in the midst of redesigning
>their entire system architecture. The last time something of this magnitude happened
>was when the split transaction P6 bus debuted in 1995 - a bus that lasted for roughly a decade.
>
>Next year, the Common System Interface will ship in two products (Nehalem and Tukwila),
>ushering in a new system architecture from Intel.
>
>I have put up an extremely in-depth report that is the work of roughly 5 months
>of research, studying Intel's patent disclosures. In this article, I describe CSI
>is exquisite detail, including the physical layer, link layer, coherency protocol
>and I provide some speculation as to how CSI will be used in future products.
>
>http://www.realworldtech.com/page.cfm?ArticleID=RWT082807020032&p=1
>
>I hope you all enjoy the read. I'd also like to thank everyone who helped with
>this article. I relied on the technical expertise of quite a few friends, and
>without their help this article wouldn't be nearly as compete or understandable.
>
>
>Regards,
>
>
>David Kanter