Talk:Sun Enterprise
![]() | This article is rated Start-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||
|
Cray S-MP? According to http://ftp.cwi.nl/CWIreports/1994/NM-R9415.pdf that was an Intel i860 based machine with multiple 4 CPU busses...
- NEW: 600MP (MBus, 4 CPU) - Cray S-MP (4 x some bus, possibly MBus, 8 CPU) (SPARC)
- SC2000 (2 x XDBus, 20 CPU) - CS6400 (4 x XDBus, 64 CPU) (SuperSPARC - MBus)
- E6000 (GigaPlane, 30 CPU) - E10000 (GigaPlane-XB, 65 CPU) ((UltraSPARC I/II - UPA)
- E6800 (FirePlane, 24 CPU) - SF15000 (FirePlane, 106 CPU) (UltraSPARC-III - FirePlane)
All with netcon, SSPs, remote JTAG, etc. I can't see how the i860 box fits in, unless the remote boot/JTAG technology came from there. The XDBus tech in the CX6400 was licensed from Sun, possible it couldn't have been sold to back anyone else in the terms of the license.
martin@datamodel.co.uk
- I think the document you are referring to is confusing the S-MP with the APP, another model inherited from the FPS Computing acquisition, which used i860 processors. This news article clearly describes the S-MP as a SPARC-based system. Letdorf 10:59, 25 March 2006 (UTC).
Stranger than strange, we're both right - I eventually got so intrigued I bought the PDF of the architecture (which turned out to be $35 for two paras and a diagram).
Cray S-MP connects up to 8 x 67 MHz SPARC processors via four busses into system memory (up to 4 GB). It *also* can connect up to two vector processors (via DMA), and also can connect APP systems direct to memory via HIPPI or VME.
The vector processors and the APP are then accessed from Solaris (so I guess the first article was right, they just neglected to mention it was the APP part of their S-MP they were using). This is way stranger than the CS6400/E10000/SF15000 kit, I guess the APP (up to 84 x i860) and the vector processors ( 2 x 267 peak MFLOPS) make it a proper Solaris super, rather than a big SMP. Disappointed with the PDF though - I assume the busses are XDBusses, but it doesn't say.
Also the PDF makes no mention of the management/domaining/etc. in the other kit, but yep, it's right in that evolutionary path alright.
Cheers,
Martin (at datamodel.co.uk)
Those SPARCs are a bit special too - 67 MHz ECL SPARC made by "Bipolar Integrated Technology" - B5000's. BIT being a spin-off from FPS. Each sparc CPU on a single board, up to 8 boards fit into the centreplane (centreplane stayed as a feature too). I retract the bit about XDBus - it requires SuperSPARC, and these are a bit early and different - possibly a version of MBus, which released in 1991.
Martin.
Also 15K codename was starcat, although it wasn't used in marketing AFAIK.
The E10K sure sucked
[edit]The Sun E10K was a really terrible machine for a variety of reasons. I worked with several over the course of years at different jobs. I never found anyone who was happy with their E10K.
It would be nice if this was mentioned somehow, but I can't find any source to cite, just the opinions of people I know that worked with them.
It certainly isn't appropriate to repeat Sun's marketing propaganda about the machine having high-availability features without mentioning that the whole system (every domain) could crash very easily. Sun's definition of high-availability means such things as having a board fail and the domain reboot without the board. Jqrt (talk) 19:14, 14 October 2008 (UTC)
The issue is that Sun's messaging was poor in differentiating that its systems were "highly available" versus "fault tolerant." True "high availability" systems would use clustering among multiple E10Ks or other systems to ensure the whole 5-9s uptime. — Preceding unsigned comment added by 99.38.166.127 (talk) 17:18, 10 December 2012 (UTC)