Archived from groups: alt.comp.hardware.amd.x86-64,comp.arch,comp.sys.ibm.pc.hardware.chips (
More info?)
"del cecchi" <dcecchi.nojunk@att.net> wrote in message news:<2pblviFiiu29U1@uni-berlin.de>...
> "Yousuf Khan" <bbbl67@ezrs.com> wrote in message
> news:E1WXc.69978$UTP.42900@twister01.bloor.is.net.cable.rogers.com...
> > Looks like Newisys is using a directory-based cache coherency chip to
> take
> > Opterons beyond their 4- or 8-way internal limitations. The people who
> > designed this chipset seem to be the same people who designed IBM's
> Summit
> > chipset for Xeon.
> >
> > There's also some interesting chatter about why IBM chose not to use
> > Newisys's designs when most of the people who started Newisys were
> ex-IBM.
> > Some suggestion about protecting their Power and Xeon turf, or
> something or
> > another.
> >
> >
>
http://www.cbronline.com/article_news.asp?guid=2B3F952C-AC0D-4CCB-A285-D9E87E37A90B
> >
> > Yousuf Khan
>
> It is absolutely positively not true that the folks from Newisys were
> the ones who designed the Summit chipset. The Summit chipset was
> designed by a group in Rochester, MN. I believe the Newisys guys
> history is Austin. And Phil Hester hasn't been IBM for a long time.
>
> del cecchi
Just to set the record straight, I lead the taskforce in IBM that
established the Summit direction for the xSeries (It actually had an
internal code name different from Summit). I then went on to lead the
team that laid out the original high level design, the function
partitioning across the various chips for both Xeon and Itanium II,
the system design and simulation/performance efforts. My team was also
responsible for overseeing the design activity (which was done in
Rochester) to insure that it met both the architectural requiements
and performance objectives for Summit. I was an IBM Fellow out of
Watson Research. And all of this started before Sequent came on the
scene at IBM.
I retired from IBM in 2000 and joined Newisys.
The big difference between the IBM design and the Newisys/AMD design
is that Summit has a local L3, while Horus has a remote L3 (Remote
Data Cache - RDC) and a Remote Directory (RD). These Horus structures
were made possible by the cHT architecture and the AMD/Opteron
implementation that offered additional cache state change status to
Horus. (Such a design was not possible with the Intel FSB, either its
architecture or its implementation).
Our simulation studies show that some applications do very well with a
RDC, others, very well with a RD. So we adopted a belt and suspenders
approach in Horus. The implementation boundary between the RDC and the
RD is adjustable in our Horus design at boot time. We also expect that
the size of the system (how many nodes) will also influence the
tradeoff betwen these two structures.
The model we see is that systems built with Opteron and our Horus
hardware and system managmement software will be tuned for
performance. This tuning can be quite narrow when it is a single
application (e.g. a data base server with a particular data base) or
rather broad when a family of applications (e.g. web server doing many
different types of transactions) is run.
We await our first hardware which should occur before the end of this
year so that we can validate our design and its performance.
Rich
Facebook
Twitter
Instagram