Differences between revisions 13 and 14
Revision 13 as of 2009-03-16 03:33:15
Size: 3531
Editor: anonymous
Comment: converted to 1.6 markup
Revision 14 as of 2019-11-13 19:30:53
Size: 5625
Editor: ?ChaseRayfield
Comment:
Deletions are marked like this. Additions are marked like this.
Line 7: Line 7:
There are a bunch. They can generally be divided into 32-bit (old) and 64-bit (new). 32-bit has been broken in 2.4 due to lack of hackers on old machines. There are a bunch. They can generally be divided into 32-bit (old) and 64-bit (new). 32-bit has been broken in 2.4 due to lack of hackers on old machines. In general the IO subsystem is much more robust on Sun machines that thier contemporary Intel counterparts with exception of the Ultra 5/10 system which have a broken IDE implementation, general always opt for SCSI or SATA/SAS if available instead if IDE on the machines that have it.
Line 10: Line 10:
The earliest supported 32-bit architecture, but some early exotic sun4c machiens might not work -- this is primarily a kernel issue. Includes SPARCstation 1 (aka ss1), 2, IPC, IPX, ELC. Read the Sun Hardware Faq at [[http://www.sunhelp.org]] for more information on these and older machines. Linux doesn't run as fast as NetBSD on these machines -- Linux doesn't use the hardware context storage correctly (there was a recent DaveM post to linux-kernel about this), and he doesn't feel like fixing it. Someone else may be working on it though. Support for sun4c was dropped in Linux 3.5, anyone playing with these should stick with 2.2-2.6 series kernels. Last Debian release with support is pre-Sarge, after that it is broken. A custom kernel may work with up to Etch but that is uncharted terretory.

The earliest supported 32-bit architecture, but some early exotic sun4c machines might not work -- this is primarily a kernel issue. Includes SPARCstation 1 (aka ss1), 2, IPC, IPX, ELC. Read the Sun Hardware Faq at [[http://www.sunhelp.org]] for more information on these and older machines. Linux doesn't run as fast as NetBSD on these machines -- Linux doesn't use the hardware context storage correctly (there was a recent DaveM post to linux-kernel about this), and he doesn't feel like fixing it. Someone else may be working on it though.
Line 13: Line 15:
A much more civilized class of 32-bit SPARCs. Include ss4/5, LC/Classic/LX, and ss10/20. These chips are on uniprocessor workstations, except for ss10/20 which are SMP machines with up to four processors on removable mbus cards. Speeds are up to 200 MHz in Ross Hypersparc mbus processors. Equivalent performance to a Pentium Classic, but with better FP. Tadpole SPARCbook 3 laptops are in this class. Framebuffers from bwtwo to 24-bit 1600x1200 are available. SBUS expansion cards. Very well supported. Sun4m support is retained in recent kernels but receives little testing, maintenance burden is low as the code is mature, the CPUs implement Sparc V8 and are mostly the same as modern Sparc CPUs except many modern implementations implement some of Sparc V8+ (from the 64bit spec as it adds the CASA instruction which is important for thread syncronization).

sun4m is a
much more civilized class of 32-bit SPARCs. Includes SS4/5, LC/Classic/LX/ZX, and SS10/20 and clones such as those by Tatung and Ross including the SparcPlug and Ross Hyperstation line. These chips either uniprocessor workstations, multiprocessor SS10/20 and HyperStation which are SMP machines with up to four processors on removable mbus cards. Speeds are up to 200 MHz in Ross Hypersparc mbus processors. Equivalent performance to a Pentium Classic, but with better FP. Tadpole SPARCbook 3 laptops are in this class. Framebuffers from bwtwo to 24-bit 1600x1200 are available. SBUS expansion cards. Very well supported. Some cards can be tweaked to output at 1920x1080 if they have a large enough framebuffer. TCX and CG6 are the best supported graphics on Linux but provide minimal acceleration. External SCSI expansion is typically faster than the internal SCSI port, with internal Narrow SCSI-II and Wide SCSI-II externally.
Line 16: Line 20:
The "funky" class of 32-bit SPARCs, the multiprocessor machines. ss10, 20. These can support up to 4 sun4d chips, which go up to 150MHz or faster (each). Your PROM revision limits what the machine supports. Sun4d
The "funky" class of 32-bit SPARCs that implements >= 8 procs via xdbus. Only partially supported by Linux. SS1000[e] supports up to 8 CPUs, SS2000 supports 16 CPUs, and Cray CS6400/Amdahl SuperSummit 6400E supports 64 CPUs. The SparcServers and SparcCenter models use standard MBUS CPUs while the CS6400 machines use a custom module. The multi xdbus SS2000E and CS6400 Supports up to 2MB cache per module while the single xdbus machines only support 1MB, a 2MB module will show as 1MB if installed. Only SuperSparc processors are supported no HyperSparc support for xdbus, the fastest CPU is the 90Mhz SM-91-2 which is rare, SM-81 or SM-61 is a more common cpu in these machines 85 and 65Mhz respectively. In any case for most applications an SM81 is falls somewhere between a 142-180Mhz HyperSparc due to inefficencies in the design of the HyperSparcs so this isn't too much of a loss.
Line 19: Line 24:
64-bit SPARCs. SPARCstation Ultra 1,2,5,10,30,60,80, and Enterprise 250/450/1000/etc. Up to 32 or 64-way SMP on these machines, but the processors themselves are (at the moment, anyhow) slower than the fastest P4s or Athlons (though they may be a hair faster clock-per-clock, they only go up to 800MHz). But you buy these machines for the seamless scalability to 32-way. Some models accept SBUS, others PCI expansion cards. These are very well supported, though individual framebuffers or other peripherals may not be. 64-bit SPARCs. SPARCstation Ultra 1,2,5,10,30,60,80, and Enterprise 250/450/1000/etc. Up to 32 or 64-way SMP on these machines, but the processors themselves are (at the moment, anyhow) slower than the fastest P4s or Athlons (though they may be a hair faster clock-per-clock, they only go up to 1600MHz). But you buy these machines for the seamless scalability to 32-way. Some models accept SBUS,PCI and PCIe expansion cards. These are very well supported, though individual framebuffers or other peripherals may not be.
Line 27: Line 32:
SPARC is one of the more unusual architectures. It's RISC, but instead of just having "a lot of registers" like Alpha or MIPS, it has a unique circularly-linked list of 128 registers, of which you can see a 16-register "window" at any one time. It's "circularly-linked" because you can walk the window in either direction. In general the architecture is extremely fast for floating-point operations, but suffers on any computation that relies on the stack overmuch (memory bandwidth has historically not been fantastic, which Sun has remedied by advanced cache architecture). The machines themselves are extremely well engineered and specified -- all the Sun-specific internals are IEEE standards, including the SPARC ISA, Sbus (the bus in older SPARCs; newer use PCI), etc etc. SPARC is one of the more unusual architectures. It's RISC, but instead of just having "a lot of registers" like Alpha or MIPS, it has a unique hardware linked list of 40 to 520 register windows depending on implementation, of which you can see a 16-register "window" at any one time. If the windows exceed what the hardware implements then the a trap occurs to spill to main memory. In general the architecture is extremely fast for floating-point operations, but suffers on any computation that relies on the stack overmuch (memory bandwidth has historically not been fantastic, which Sun has remedied by advanced cache architecture). The machines themselves are extremely well engineered and specified -- all the Sun-specific internals are IEEE standards, including the SPARC ISA, Sbus (the bus in older SPARCs; newer use PCI), etc etc.

SPARC is Sun Microsystems' Scalable Processing Architecture (at least that's one version, might be "Processor"). This is the most recent generation of Sun's famous line of workstations, also known as "sun4". It goes back quite a ways, already, to the early 90s.

Debian supports the more civilized models -- some of the early ones are unsupported, or poorly supported.

Sub-flavours

There are a bunch. They can generally be divided into 32-bit (old) and 64-bit (new). 32-bit has been broken in 2.4 due to lack of hackers on old machines. In general the IO subsystem is much more robust on Sun machines that thier contemporary Intel counterparts with exception of the Ultra 5/10 system which have a broken IDE implementation, general always opt for SCSI or SATA/SAS if available instead if IDE on the machines that have it.

Sun4c

Support for sun4c was dropped in Linux 3.5, anyone playing with these should stick with 2.2-2.6 series kernels. Last Debian release with support is pre-Sarge, after that it is broken. A custom kernel may work with up to Etch but that is uncharted terretory.

The earliest supported 32-bit architecture, but some early exotic sun4c machines might not work -- this is primarily a kernel issue. Includes SPARCstation 1 (aka ss1), 2, IPC, IPX, ELC. Read the Sun Hardware Faq at http://www.sunhelp.org for more information on these and older machines. Linux doesn't run as fast as NetBSD on these machines -- Linux doesn't use the hardware context storage correctly (there was a recent DaveM post to linux-kernel about this), and he doesn't feel like fixing it. Someone else may be working on it though.

Sun4m

Sun4m support is retained in recent kernels but receives little testing, maintenance burden is low as the code is mature, the CPUs implement Sparc V8 and are mostly the same as modern Sparc CPUs except many modern implementations implement some of Sparc V8+ (from the 64bit spec as it adds the CASA instruction which is important for thread syncronization).

sun4m is a much more civilized class of 32-bit SPARCs. Includes SS4/5, LC/Classic/LX/ZX, and SS10/20 and clones such as those by Tatung and Ross including the ?SparcPlug and Ross Hyperstation line. These chips either uniprocessor workstations, multiprocessor SS10/20 and ?HyperStation which are SMP machines with up to four processors on removable mbus cards. Speeds are up to 200 MHz in Ross Hypersparc mbus processors. Equivalent performance to a Pentium Classic, but with better FP. Tadpole SPARCbook 3 laptops are in this class. Framebuffers from bwtwo to 24-bit 1600x1200 are available. SBUS expansion cards. Very well supported. Some cards can be tweaked to output at 1920x1080 if they have a large enough framebuffer. TCX and CG6 are the best supported graphics on Linux but provide minimal acceleration. External SCSI expansion is typically faster than the internal SCSI port, with internal Narrow SCSI-II and Wide SCSI-II externally.

Sun4d

Sun4d The "funky" class of 32-bit SPARCs that implements >= 8 procs via xdbus. Only partially supported by Linux. SS1000[e] supports up to 8 CPUs, SS2000 supports 16 CPUs, and Cray CS6400/Amdahl ?SuperSummit 6400E supports 64 CPUs. The ?SparcServers and ?SparcCenter models use standard MBUS CPUs while the CS6400 machines use a custom module. The multi xdbus SS2000E and CS6400 Supports up to 2MB cache per module while the single xdbus machines only support 1MB, a 2MB module will show as 1MB if installed. Only ?SuperSparc processors are supported no ?HyperSparc support for xdbus, the fastest CPU is the 90Mhz SM-91-2 which is rare, SM-81 or SM-61 is a more common cpu in these machines 85 and 65Mhz respectively. In any case for most applications an SM81 is falls somewhere between a 142-180Mhz ?HyperSparc due to inefficencies in the design of the ?HyperSparcs so this isn't too much of a loss.

UltraSPARC (I, II, IIi, III)

64-bit SPARCs. SPARCstation Ultra 1,2,5,10,30,60,80, and Enterprise 250/450/1000/etc. Up to 32 or 64-way SMP on these machines, but the processors themselves are (at the moment, anyhow) slower than the fastest P4s or Athlons (though they may be a hair faster clock-per-clock, they only go up to 1600MHz). But you buy these machines for the seamless scalability to 32-way. Some models accept SBUS,PCI and PCIe expansion cards. These are very well supported, though individual framebuffers or other peripherals may not be.

Debian support

SPARC is one of the most mature Debian ports (officially supported since DebianSlink, 1999). For details, see:

Architecture Tidbits

SPARC is one of the more unusual architectures. It's RISC, but instead of just having "a lot of registers" like Alpha or MIPS, it has a unique hardware linked list of 40 to 520 register windows depending on implementation, of which you can see a 16-register "window" at any one time. If the windows exceed what the hardware implements then the a trap occurs to spill to main memory. In general the architecture is extremely fast for floating-point operations, but suffers on any computation that relies on the stack overmuch (memory bandwidth has historically not been fantastic, which Sun has remedied by advanced cache architecture). The machines themselves are extremely well engineered and specified -- all the Sun-specific internals are IEEE standards, including the SPARC ISA, Sbus (the bus in older SPARCs; newer use PCI), etc etc.

See Also