Building OpenJDK Under Solaris SPARC and x64

[logo, courtesy OpenJDK]

Building OpenJDK Under Solaris SPARC and x64

[Duke Thinking]

Abstract:

There has been must discussion regarding Java and Solaris, both SPARC, Intel x86, and AMD x64. Oracle had released Java into the wild, under a fast continuous release plan, and paid support plans for long term releases. OpenJDK is the reference release of JavaSE since Java 7. Once concern in the industry has been, how to we compile the latest versions of Java, and this has been discussed in detail by various authors to be cited.

[Duke Plugging]

Building OpenJDK 12 under Solaris:

Guest Author Petr Sumbera had published an article on Oracle's Solaris Blog on how to compile your own version  of OpenJDK 12. What is interesting is that it uses an existing JDK to perform that process!

To compile OpenJDK 12, SPARC Solaris requires JDK 8 under Intel Solaris and JDK 11 under SPARC Solaris. In addition, you will need Oracle Solaris Studio 12.4.

[Duke Drawing]

OpenJDK on SPARC Solaris:

In  March 2019, Oracle Author Martin Mueller also published an article on Building OpenJDK Java Releases on Oracle Solaris/SPARC. In addition, you will need Oracle Solaris Studio 12.4. This article may help in the build of of OpenJDK for SPARC.

[Duke Plumbing]

OpenJDK on Intel or AMD Solaris:

In February 2019, Birkbeck College, Computer Science Department, Author Andrew Watkins also published an article on Building OpenJDK 12 on Solaris 11 x86_64. This followed on his October 2018 article on  Building OpenJDK 11 on Solaris 11 x86_64. This followed on his September 2018 article on Building OpenJDK 10 on Solaris 11 x86_64. These articles may help in the building of OpenJDK for Intel or AMD systems.

Conclusions:

The availability of the latest Java, license & support free, is available if one wants to roll their own. If commercial support is desired, Java can can still be acquired from Oracle with a Long Term Support (LTS) contract.

Oracle: Solaris 10 Update 11 Released!

Oracle: Solaris 10 Update 11 Released!

Abstract:
Solaris 10 was launched in 2005, with ground-breaking features like: DTrace, SMF (Services), Zones, LDom's, and later ZFS. The latest, and perhaps last, update of Solaris 10 was expected in 2012, to co-inside with an early release of the SPARC T5. In 2013, Oracle released yet another update, suggesting the T5 is close to release. The latest installment of Solaris 10 is referred to as 01/13 release, for January 2013, appears to be the final SVR4 Solaris release, with expected normal Oracle support extending to 2018. Many serious administrators will refer to this release as Solaris 10 Update 11.

(Oracle SPARC & Solaris Road Map, 2013-02-11)

What's New?
Oracle released the "Oracle Solaris 10 1/13 What's New" document, outlining some of the included features. The arrangement of the categories seems odd, in some cases, so a few were merged/re-orded below. Some of the interesting features include:



(Solaris 10 Update 11 Network File System Install Media Option)



• Installation Enhancements
  iSCSI LUN boot support
  NFS (Network File System) media support
  SVR4 Package Dependencies with Installer Preserve Option
  LU (Live Update) preserves Dump slice
  LU Pre-Flight Checker

(Solaris 10 Update 11 SVR4 Package Dependency Install Support)

• Administration Enhancements
  OCM (Oracle Configuration Manager) Client Service
  Oracle Zones Pre-Flight Checker
  SVR4 pkgdep (Package Depends) Command
  Intel x86 FMA (Fault Management Architecture) Sandy Bridge EP Enhancements
  AMD MCA (Machine Check Architecture) Support for Family 15h, 0Fh, 10h

# zfs help                                                              
The following commands are supported:                                   
allow       clone       create      destroy     diff        get         
groupspace  help        hold        holds       inherit     list        
mount       promote     receive     release     rename      rollback    
send        set         share       snapshot    unallow     unmount     
unshare     upgrade     userspace                                  

(Solaris 10 Update 10 zfs help system enhancements)

• Security Enhancements
  64 bit OpenSSL Support
  RESTRICTIVE_LOCKING now optional
  Speed Tuning/Improvements for: SSH, SCP, SFTP

# zpool help                                                            
The following commands are supported:                                   
add      attach   clear    create   destroy  detach   export   get      
help     history  import   iostat   list     offline  online   remove   
replace  scrub    set      split    status   upgrade                    
# zfs help create                                                       
usage:                                                                  
             create [-p] [-o property=value] ...                        
             create [-ps] [-b blocksize] [-o property=value] ... -V     

(Solaris 10 Update 10 zpool help system enhancements)

• ZFS File System and Storage Enhancements
  Help tiered into sub-commands for: zfs, zpool
  ZFS aclmode enhancements
  ZFS diff enhancements
  ZFS snap alias for snapshot
  Intel x86 SATA (Serial ATA) support for ATA Pass-Through Commands
  AMD x86 XOP and FMA Support
  SPARC T4 CRC32c Acceleration for iSCSI
  Xen XDF (Virtual Block Device Driver) for x86 Oracle VM

# zfs help create                                                       
usage:                                                                  
             create [-p] [-o property=value] ...                        
             create [-ps] [-b blocksize] [-o property=value] ... -V     

(Solaris 10 Update 10 zpool help create system enhancements)

• Freeware Enhancements
  Evince,  GNU Make, GNU gettext, GNU IDN (International Domain Naming), Ghostscript, gzip, Jakarta Tomcat, Lightning, rsync, Samba, Sendmail, Thunderbird, Firefox, wxWidgets
• New and Updated Device Drivers
  Broadcom BNXE (BCM57712 NetXtreme II 10 Gigabit Ethernet) Driver new support
  Intel SR-IOV (Single Root I/O Virtualization) support for i350 Gigabit and x540 10 Gigabit
  Sun Blade 6000 Virtualized 40 GbE NEM (Network Express Module)
  USB 3.0 Support (Block File Throughput: 150MBps Intel/AMD; 50MBps SPARC)
• Virtualization Enhancements
  LDom / Oracle VM SPARC Memory Dynamic Reconfiguration (DR) on Migration

Competitive Pressures:
Competition makes the Operating System market healthy! Let's look at the competitive landscape.

(Illumos Logo)

Solaris USB 3.0 is in a better support position than Illumos still missing USB 3.0 today since Solaris 10, Solaris 11, and Illumos all have top-of-the-line read and write flash accelerators for hard disk storage... a USB 3.0 flash cache will provide a nice inexpensive performance boost! Slower Solaris USB 3.0 support from 2013q1 on SPARC will be shunned with Solaris ZFS SMB's considering Apple MacOSX. Apple released USB 3.0 support in 2012q4 with Fusion Drive, making OSX a strong contender. Apple may have been late to Flash when proper licensing could not be agreed between Sun/Oracle and Apple, Apple is still late with deduplication, but now Oracle and Illumos are late with USB 3.0 to combine with ZFS.

(Lustre logo, courtesy hpcwire)

Sun purchased Lustre, for ZFS integration back in 2007. NetMgmt salivated as Lustre for ZFS was on-tap back in 2009, ZFS needed cluster/replication for a long time. Redhat purchased GlusterFS in 2011 and went beta in 2012, for production quality filesystem clustering. IBM released ZFS and Luster on their own hardware & Linux OS. NetMgt noted Lustre on EMC was hitting in 2012, questioned Oracle's sluggishness, and begged for an Illumos rescue. Even Microsoft "got it" when Windows 2012 bundled: dedupe, clustering, iSCSI, SMB, and NFS. It seems Apple, Oracle, and Illumos are the last major vendors - late with native file system clustering... although Apple is not pretending to play on the Server field.

(Superspeed USB 3.0 logo, courtesy usb3-thunderbolt.com)

The lack of File System Clustering in the final update of Solaris 10 is miserable, especially after various Lustre patches made it into ZFS years ago. Perhaps Oracle is waiting for a Solaris 11 update for clustering??? The lack of focus by Illumos on clustering and USB 3.0 makes me wonder whether or not their core supporters (embedded storage and cloud provider) really understand how big of a hole they have. An embedded storage provider, should would want USB 3.0 for external disks and clustering for geographically dispersed storage  their check-list. A cloud provider should would want geographically dispersed clustering, at the least.

(KVM is bundled into Joyent SmartOS, as well as Linux)

Missing native ZFS clustering and hypervisor at Oracle is making Solaris look "long in the tooth". Xen on Oracle Linux with Xen being removed from Solaris is a poor excuse by Oracle. Joyent's SmartOS KVM integrated into Illumos helps the Solaris community move forward, but what is the use of a hypervisor without shared-nothing clustered storage, to migrate those VM's at will? Missing USB 3.0 and native ZFS clustering is putting pressure on Illumos to differentiate itself in the storage market.

Conclusions:
Oracle Solaris 10 is alive and well - GO GET Update 11!!! Some of the most important features include the enhancements to CPU architecture (is SPARC T5 silently supported, since T5 has been in-test since end of 2013?), USB 3.0, iSCSI support for root disk installations, install SVR4 package dependency support, and NFS media support. Many of these features will be welcomed by SMB's (small to medium sized businesses.)

(Bullet Train, courtesy gojapango)

The Solaris Train continues to move at Oracle, producing high quality product, SPARC support, and new drivers (i.e. USB 3.0) - if Solaris 11, Illumos, or SmartOS releases ZFS clustering, the resulting OS will be market leading.

Itanium: The Death of Microsoft Windows Support

Itanium: The Death of Microsoft Windows Support

Announcement:

In December of 2009, it was reported that Red Hat Linux started the process of ceasing support for Intel Itanium processors. Now, it appears that Microsoft is starting it's process of discontinuing support for Intel Itanium.

History:

See former blog entry when Red Hat Linux discontinued their Itanium support.

Network Management Implications:

None. There were no serious Network Management products using Microsoft Windows on Itanium. There are really only HP operating systems left on this CPU platform, a single isolated software vendor on a single isolated chip supplier.

Why Few Implications:

Single vendor processors (IBM POWER and Intel Itanium) are somewhat more risky, when there is a gap in the development cycle due to human error. Specialized software vendors looking for longevity often look for multiple suppliers when producing a product, to ensure that a single vendor glitch does not damage their product marketing.

In the areas of server processors, there really only seems to be two multi-vendor CPU vendors left: SPARC (Oracle/Sun and Fujitsu) and x64 (Intel and AMD.)

Who Will Be Affected?

Probably, the people who will be most affected by this move will be businesses who depended on Microsoft SQL Server on Itanium.

Had those vendors chosen another database vendor, who supports multiple architectures (i.e. Oracle RDBMS) - a migration to another Operating System (i.e. an HP Operating System) on the same hardware could have been done, to extend the life of the asset, and any desired hardware architecture could have been chosen to migrate to later (i.e. SPARC, POWER, Intel x64, AMD x64.)

Itanium: The Death of Red Hat Linux Support

Itanium: The Death of Red Hat Linux Support

Announcement

As reported on The Register, Red Hat quietly announced RHEL 5 as the "end of the line" for Intel Itanium.

The History
The processor market as basically split between two comodity CISC (Completed Instruction Set Computing) chip makers, Intel (x86) and Motorola (68K) where high-end workstation & server vendors consolidated in Motorola (68K) with PC makers leveraging Intel (x86).

Motorola indicated an end to their 68K line was coming, x86 appeared to be running out of steam. A new concept called RISC (Reduced Instruction Set Computing) was appearing on the scenes. Wholesale migration from Motorola was on, many vendors creating their own very high performance chips based upon this architecture. Various RISC chips were born, created by vendors, adopted by manufacturers, each with their own operating system based upon various open standards.

• SUN/Fujitsu/Ross/(various others) SPARC
• IBM POWER
• HP PA-RISC
• DEC Alpha
• MIPS MIPS (adopted by SGI, Tandem, and various others)
• Motorola 88K (adopted by Data General, Northern Telecom, and various others)
• Motorola/IBM PowerPC (adopted by Apple, IBM, Motorola, and various others)

There was reletively small volume shipments to most vendors of full fledge processors, although the computing prices allowed for continued investment to create increasingly smaller chips to enhance performance. Many of these architectures were cooperative efforts, with cross licensing, to increase volume, and create a viable vendor base. The move to 64 occurred in most of these high-end vendors. As the costs for investment continued to rise, in order to shrink the silicon chip dies, a massive consolidation started to occur, in order to save costs and continue to be profitable.

The desktop market continued to tick away with 32 bit computing at a lower cost, with 2 primary vendors: Intel and AMD.

A massive move to consolidate 64 bit RISC processors from the minority market shareholders from their smaller shares to a common, larger, Intel based 64 bit Itanium VLIW (Very Long Intruction Word) processors. This was a very risky move, since VLIW was a new architecture, and performance was unproven. The consideration by the vendors was Intel had deep enough pockets to fund a new processor. Some of the vendors, who consolidated their architectures into Itanium included:

• HP - PA-RISC
• DEC, purchased by Compaq, Purchased by HP - Alpha
• DEC, purchased by Compaq, Purchased by HP - VAX
• Tandem, purchased by Compaq, Purchased by HP - MIPS
• SGI -> MIPS

Many of the RISC processors did not go away, they just moved to embedded environments, where many of the more complex features of the chips could continue to be dropped, so development would be less costly.
 

[Sun Microsystems UltraSPARC 2]

[Fujitsu SPARC64 VII]

[IBM Power]

Majority RISC architecture market share holds in the desktop & server arena seemed to consolidate during the fist decade of 2000 around RISC architectures of an open consortium driven by specifications called SPARC (predominately SUN and Fujitsu) and proprietary final proprietary single vendor drive POWER (predominately IBM)
 

[AMD Athlon FX 64 Bit]

AMD later released 64 bit extensions to the aging Intel x86 instructions (which all vendors, including Intel, had basically written off as a dead-end architecture) - creating what the market referred to as "x64". Intel was later forced into releasing a similar processor, competing internally with their Itanium. Much market focus started, consolidating servers onto this proprietary x64 based systems, sapping vitality and market share from RISC and VLIW vendors.

Network Management Implications

HP really drove the market to Itanium, after acquiring many companies. There was a large number of operating systems, which needed to be supported internally, so the move to consolidate those operating systems and reduce costs became important.

HP OpenView is one of those key suites of Network Management tools, which people don't get fired for purchasing. HP made announcements of their proprietary operating system HP-UX, Microsoft proprietary Windows, and open source Linux support for Intel Itanium. HP was never able to get OpenView traction with it under Linux under Itanium or Windows under Itanium, although they were able to provide support for their own proprietary HP-UX platform, as well as Linux under x86 architecture.

With Open Source Red Hat Linux going away on Itanium. Itanium as a 64 bit architecture is clearly taking a severe downturn in the viable 3rd party architectures, and Network Management from OpenView will obviously never become a player in a market that will no longer exist.
The IBM POWER architecture, even though it is one of the last two substantial RISC vendors left, has never really been a substantial vendor in Network Managment arena, even with IBM selling Tivoli Network Management suite. Network Management will most likely never be a substantial power under POWER.

"Mom & Pop" shops run various Network Management systems under Windows, but the number of managed nodes is typically vastly inferior to the larger Enterprise and Managed Services markets. The software just does not scale as well.

Sun SPARC Solaris (with massive vertical and horizontal scalibility) and Red Hat Linux x68 (typically limited to horizontal scalibility) are really the only two substantial multi-vendor Network Management platform players for large Managed Services installations left. Red Hat abandoning HP's Itanium Linux only continues to solidify this position.

OpenSolaris 2009.06 - Network Virtualization

OpenSolaris 2009.06 - Network Virtualization

Network Virtualization Technology: Project Crossbow

Sun has been working at re-architecting the TCP/IP stack in Solaris for Virtualization for close to 3 years, making progress each year with new features. OpenSolaris 2009.06 exhibits some of the most recent enhancements
http://link.brightcove.com/services/player/bcpid1640183659?bctid=24579687001

Network infrastructure in Solaris has been re-written at the NIC, Driver, and Socket levels - all the way up the stack.

Network Virtualization has to do with dedicated resources and isolation of network resources. They are talking about multiple: Hardware Ring Buffers in a NIC, TCP/IP Stacks in a Kernel, Kernel Ring Buffers in a Stack.

http://www.opensolaris.com/use/ProjectCrossbow.pdf
"Crossbow is designed as a fully parallelized network stack structure. If you think of a physical network link as a road, then Crossbow allows dividing that road into multiple lanes. Each lane represents a flow of packets, and the flows are architected to be independent of each other — no common queues, no common threads, no common locks, no common counters."

Some of the more interesting results of this integration: create networks with no physical NIC cards; create switches in software; assign bandwidth to a virtual NIC card (vNIC); assign CPU resources to a vNIC; assign quality of service (QoS) attributes to a vNIC; throttling protocols on a vNIC; virtualize dumb NIC's via the kernel to look like smart NIC's; switch automatically between interrupt and polled modes.

The implications are staggering:

• Heavy consumption of network resources by an application does not necessarily have to step-on other mission critical applications running in another virtual server
• Priorities for latency sensitive protocols (ex. VoIP) can be specified for traffic based upon various packet policies, like Source IP, Destination IP, MAC address, Port, or Protocol
• Security is enhanced since Solaris 10 containers no longer have to share IP stacks for the same physical NIC, but physical NIC's can now have multiple IP stacks for each container
• Multiple physical ports can be aggregated into a single virtual port and then re-subdivided into multiple virtual NIC's so many applications or many virtual servers can experience load sharing and redundancy in a simplified way (once at the lowest layer instead of multiple times, for each virtual machine)
  
• Older systems can be retained for D-R or H-A since their dumb NIC's would be virtualized in the kernel and the newer NIC's with newer equipment can be added into the application cluster for enhanced performance
• Heavily used protocols will switch a stack into "polled mode" to remove the overhead of interrupts to the overall operating system, providing better overall system performance, as well as providing faster network throughput to competing operating systems
• Enhanced performance at a lower system resource expense is achieved by tuning the vNIC's to more closely match the clients mean flow control can happen at the hardware or NIC card level (instead of forcing the flow control higher in the TCP stack)
• Modeling of applications and their performance can be done completely on a laptop, all application tiers, including H-A, without ever leaving the laptop - allowing architects to test the system performance implications by making live configuration settings
• Repelling DoS attacks at the NIC card - if there is a DoS attack against a virtual server's vNIC card, the other virtual servers do not necessarily have to be impacted on the main system due to isolation and resource management, and packets are dropped at the hardware layer instead of at the kernel or application, where high levels of interrupts are soaking up all available CPU capacity.

Usually, adding & leveraging features like QoS and Virtualization will decrease performance to an operating system, but with OpenSolaris, adding these feature with a substantial re-write of code, enabled a substantial increase in read & write throughput over Solaris as well as substantial increase in read throughput (with close to on-par write throughput) in comparison to Linux on the same hardware.
http://www.opensolaris.com/learn/features/networking/networkperformance/

This OpenSolaris technology is truly ground-breaking for the industry.

Usage of Network Virtualization in Network Managment

In the realm of Network Management, there is usually a mix of unreliable protocols (ICMP and UDP) with reliable protocols (TCP sockets.) The unreliable protocols are used to gather (ICMP, SNMP) or collect (Syslog) data from the edge devices while reliable protocols are used to aggregate that data within the management platform cluster.

While the UDP packets are sent/received, they can be dropped under times of high utilization (event storms, denial of service attacks, managed network outages, etc.) - so applying higher quality of service to these protocols becomes desirable to ensure the network management tools have the most accurate view of the state of the network.

Communication to internal system, which are aggregating that data, require this data for longer term usage (i.e. monthly reporting) and must be maintained (i.e. backups) - but these subsystems are no where near as important to maintaining an accurate state of the managed network when debugging an outage, which affects the bottom line of the company. These packets can be delayed a few microseconds to ensure the critical packets are being processed.

Enhanced performance in the overall TCP/IP stack also means more devices can be managed by the network management platform while maintaining the same hardware.

Implementation of Network Virtualization in Network Management

The H-A platform can be loaded up with OpenSolaris 2009.06 and the LDOM holding the Network Management application can be live-migrated seamlessly in minutes.
http://blogs.sun.com/weber/entry/logical_domain_mobility_between_solaris

After running on the production H-A platform for a time, the production platform can be upgraded, and the LDOM migrated back in minutes.

Conclusion

Operating systems like OpenSolaris 2009.06 offer to the Network Management Architect new options in lengthening asset lifespan, increasing return-on-investment for hardware assets, ensuring better system performance of network management assets, ensuring the best possible network management team performance possible.

SUN, Solaris, Linux, and Growth

The Past 10 Years for SUN

SUN's investment into Linux, historically, to blunt Microsoft, has cut it's own throat since 2000. Without SUN's investment into Linux, UNIX like environments could have become irrelevant, however, with Microsoft's NT operating system release and IIS - so I think no matter what SUN did, it was a lose-lose situation... but SUN's backing of x86 Linux was a more strategic move than just ceding the position to Microsoft & x86, giving them a better position to compete later.

Linux and The Future

SUN's more recent targeted investment into Debian Linux to endorse Ubuntu and now adopt a variant of Debian packaging, may be an attempt to stop the bleeding of Solaris into RedHat and create more "choice" - which helps keep Solaris relevant under x64.

I think the adoption of Debian Linux packaging was a mistake by SUN, I believe they could have adopted new standards using a limited SVR4 format to achieve the same goals and back-port the new standard packaging to Linux for all of their OpenSource products (i.e. OpenOffice, NFS, ZFS, MySQL, GlassFish, Java, etc.)

Competition with Linux & Solaris under x64 and T Processors

Is Linux needed needed on the T processors to compete with x64?

Considering that SUN's hardware T market running Solaris has double the volume of the x64 market running combined Linux, Solaris, and Windows, Linux does not seem that important, to drive SUN sales (more on this later, with a quarterly report graph.)

Since the same software is available under Linux as it is under Solaris, perhaps not. I think the competition between the T and x64 processors is a more significant issue, with Linux impact. A single Solaris socket T processor no longer outruns Linux quad socket x64 processors on web serving workloads.

If Web Serving is the typical Linux workload, then the SPECWeb indicates that the T processors have been outperforming x64 for years on a price/performance ratio, until benchmarks published just a few months ago (with a single socket T2 outrunning quad sockets x64... but now quad socket hex core Intel chips are pushing 25% higher performance over a single socket T2) making x64 Linux price competitive with Solaris & SPARC T.
http://spec.org/cgi-bin/osgresults?conf=web2005&op=fetch&proj-COMPANY=256&proj-SYSTEM=256&proj-PEAK=256&proj-HTTPSW=256&proj-CORES=256&proj-CHIPS=256&proj-CORESCHP=256&proj-CPU=0&proj-CACHE1=0&proj-CACHE2=0&proj-CACHE3=0&proj-MEMORY=0&proj-NETNCTRL=0&proj-NETCTRL=0&proj-NNETS=0&proj-NETTYPE=0&proj-NETSPEED=0&proj-TIMEWAIT=0&proj-DSKCTRL=0&proj-DISK=0&proj-SCRIPTS=0&proj-WEBCACHE=0&proj-OS=0&proj-HWAVAIL=0&crit2-HWAVAIL=Jan&proj-OSAVAIL=0&crit2-OSAVAIL=Jan&proj-SWAVAIL=0&crit2-SWAVAIL=Jan&proj-LICENSE=0&proj-TESTER=0&proj-TESTDAT=0&crit2-TESTDAT=Jan&proj-PUBLISH=256&crit2-PUBLISH=Jan&proj-UPDATE=0&crit2-UPDATE=Jan&dups=0&duplist=COMPANY&duplist=SYSTEM&duplist=CORES&duplist=CHIPS&duplist=CORESCHP&duplist=CPU&duplist=CACHE1&duplist=CACHE2&duplist=CACHE3&duplist=NETTYPE&dupkey=PUBLISH&latest=Dec-9999&sort1=PEAK&sdir1=-1&sort2=SYSTEM&sdir2=1&sort3=CORESCHP&sdir3=-1&format=tab

This being said, in the carrier markets, with the 1U high dual T2+ platforms, there are no 8 socket 1U high hex-core Intel platforms to compete with it. Also, a 4U high quad socket T platform from sun scaling up to the equivalent of 4 T sockets, three quad socket X64 units would be required to compete (with dozens of NIC cards.) The modern x64 competition is starting to press the 1 & 2 year old T chips now. SUN really needs a T refresh (T3 should get them to be about 2-3x as fast as the T2 per-socket an restore the performance lead to 1x T socket being faster than 4x x64 sockets, to compete in this workload arena effectively.)

If SUN can release a T processor for embedded consumer or network devices, I think Linux may be a requirement, or a significantly slimmed down Solaris, in order to compete. I think that SUN avoiding this space has been disastrous decision, seeing the Apple had become largely relevant again, through this angle.

Profitability of the SUN SPARC T Processors

Some believe it is a "wild guess" to suppose the T family is profitable, but I think we can analyze the quarterly results to come up with a conclusion based closer to reality. SUN's product gross margins seem to float between 35% and 50%.
http://www.sun.com/aboutsun/investor/images/earnings_slides/img10_lg.jpg


It seems the T processors make up about 375 Million (in Q2-2009) vs non-T SPARC at about 700 Million.
http://www.sun.com/aboutsun/investor/images/earnings_slides/img07_lg.jpg


Everything else looks about equal. Take these two product sets (T SPARC, non-T SPARC), with increasing revenue on T and decreasing revenue on non-T, plot both against the Products gross margin... it looks like the T processors are not as profitable as the Non-T processors, but still reasonable. Clearly, SUN needs a refresh in the non-T processors (SPARC64 VII+ or RocK), to stabilize the downward trend, since this is the lion-share of the product revenue.

The "Other Systems" trend, seems to be inversely proportional to the T SPARC revenues... this bothers me historically, since any growth in the T SPARC seems to be getting canceled out by this other legacy category over the past 2 years, but this legacy category does not really exist any longer, as a proportion of significant revenue, so I don't believe it is worth tracking, moving forward.

If the T revenue can become in-parity with the non-T sales or supercede the non-T sales, then the unpredictability of SUN's quarterly profits & losses will be suppressed, improving the suitability for longer term investors.

Choosing a Platform for a Workload (part1)

Choosing a Platform for a Workload
Part 1

When working with a platform for managing networks, integrating systems through middleware, or presenting data to customers - web servers and encryption become extremely important. These two factors should be considered when choosing a platform.

Network Management increasingly requires encryption and compression functions for transport protocols. Encryption is part of established protocols such as SNMPv3. Compression is common in proprietary protocols, where data is built on a foreign platform, shipped to the management platform (increasingly over encrypted HTTPS), and unbundled.

Seasoned architects agree that the combination of encryption and web server performance becomes a key factor with scaling any application in large applications.

Web Serving Platform Metrics

Traditional benchmarks had surrounded CPU single thread performance in integer and floating point. Business applications were single threaded on desktops in the past, but modern applications are centrally deployed, driving the need for new benchmarks.

Newer benchmarks had surrounded multi-threaded CPU integer and floating point performance. Newer high-throughput CPU's, such as the Hex Core 7000 Series Intel provide outstanding throughput in comparison to older Octal Core T2 SPARC Series.

Sockets MHz Result Vendor Model
4 1414 301.0 SUN T2+ (8 cores/socket)
4 2667 294.0 Intel Xeon X7460 (6 cores/socket)
2 1415 160.0 SUN T2+ (8 cores/socket)
2 2667 158.0 Intel Xeon X7460 (6 cores/socket)
1 1417 085.5 SUN T2 (8 cores/socket)
CINT2006 Rates, 1 Sockets, (Cores/Socket > 5)
CINT2006 Rates, 2 Sockets, (Cores/Socket > 5)
CINT2006 Rates, 4 Sockets, (Cores/Socket > 5)

This is a better metric for measuring scalability of centrally deployed application, but this is beginning to be insufficient when modern CPU architectures include other embedded functionality to accelerate modern management applications with encryption and web serving requirements.

Web Serving Platform Metrics

Understanding the implications in platform choice in modern management application deployment has been lacking, until newer benchmarks have been made available.
The SPECweb2005 benchmark is a good start.
http://www.spec.org/cgi-bin/osgresults?conf=web2005&op=fetch&proj-COMPANY=256&proj-SYSTEM=256&proj-PEAK=256&proj-HTTPSW=256&proj-CORES=256&proj-CHIPS=256&proj-CORESCHP=256&proj-CPU=256&proj-CACHE1=0&proj-CACHE2=0&proj-CACHE3=0&proj-MEMORY=0&proj-NETNCTRL=0&proj-NETCTRL=0&proj-NNETS=0&proj-NETTYPE=0&proj-NETSPEED=0&proj-TIMEWAIT=0&proj-DSKCTRL=0&proj-DISK=0&proj-SCRIPTS=0&proj-WEBCACHE=0&proj-OS=0&proj-HWAVAIL=256&crit2-HWAVAIL=Jan&proj-OSAVAIL=0&crit2-OSAVAIL=Jan&proj-SWAVAIL=0&crit2-SWAVAIL=Jan&proj-LICENSE=0&proj-TESTER=0&proj-TESTDAT=0&crit2-TESTDAT=Jan&proj-PUBLISH=256&crit2-PUBLISH=Jan&proj-UPDATE=0&crit2-UPDATE=Jan&dups=0&duplist=COMPANY&duplist=SYSTEM&duplist=CORES&duplist=CHIPS&duplist=CORESCHP&duplist=CPU&duplist=CACHE1&duplist=CACHE2&duplist=CACHE3&duplist=NETTYPE&dupkey=PUBLISH&latest=Dec-9999&sort1=PEAK&sdir1=1&sort2=SYSTEM&sdir2=1&sort3=CORESCHP&sdir3=-1&format=tab

Platform Performance Metric Implications

Viewing the high-end of the report, performance implications are astounding.

CPU_Architecture	Sockets	Cores/ Socket	Total Cores	Performance	HW_Avail
Sun UltraSPARC T2	1	8	8	41847	Jan-2008
AMD Opteron 8384	4	4	16	48007	Jan-2009
Intel Xeon X7460	4	6	24	51395	Jun-2008 *

* The Intel hex-core processor was not available for production release until Sept 2008

Is the best platform to deploy applications on a hex-core Intel or an octal-core SPARC?

The 4 processor Intel Xeon X7460 from vendors like HP will run you a similar cost to a 1 processor Sun SPARC T2 (i.e. low-mid $20K US$) - so it seems like a good possibility from price perspective.
http://www.pcworld.com/shopping/reviews/prtprdid,91898999-sortby,retailer/reviews.html
http://shop.sun.com/is-bin/INTERSHOP.enfinity/WFS/Sun_NorthAmerica-Sun_Store_US-Site/en_US/-/USD/ViewStandardCatalog-Browse?CategoryName=SPARC_T5120&CategoryDomainName=Sun_NorthAmerica-Sun_Store_US-SunCatalog

Probably not, if heat, cost, scalability, future growth, and rack space are considerations.

• The Quad-Socket Hex-Core Intel platforms are typically 4U-5U in height, while the Single-Socket Octal-Core SPARC platforms are typically 1U in height.
• The Quad-Socket Hex-Core Intel platforms are typically at their maximum number of CPU's, meaning a total of 8 sockets will mean 8U-10U in height, while the Dual-Socket Octal-Core SPARC platforms are typically 1U in height... but the Intel platform will require clustering hardware & software to take advantage of the additional capacity at lack of linear scalibility, while the SPARC platform will just scale linearly.
  
• The Quad-Socket Hex-Core Intel platforms are typically at their maximum number of CPU's, meaning a total of 12 sockets will mean 12U-15U in height, while the Quad-Socket Octal-Core SPARC platforms are typically 4U in height... but the Intel platform will require clustering hardware & software to take advantage of the additional capacity at lack of linear scalibility, while the SPARC platform will just scale linearly.
• The Quad-Socket Hex-Core Intel platforms are typically at their maximum number of CPU's, meaning a total of 16 sockets will mean 16U-20U in height, while the Quad-Socket Octal-Core SPARC platforms are typically 4U in height... but the Intel platform will require clustering hardware & software to take advantage of the additional capacity at lack of linear scalibility, while the SPARC platform will just scale linearly.

To chart the space, price, and performance implications... I am using a discounted price for HP and straight retail prices for SUN, meaning the SUN will probably be much lower.

CPU_Architecture	Sockets	Cores/ Socket	Total Cores	Height	US$	Model
Sun UltraSPARC T2	1	8	8	1U	$25K	SUN T5120
Sun UltraSPARC T2+	2	8	16	1U	$35K	SUN T5140
Sun UltraSPARC T2+	3	8	24	4U	$70K	SUN T5440
Sun UltraSPARC T2+	4	8	32	4U	$90K	SUN T5440
Intel Xeon X7460	4	6	24	4U	$25K	HP DL580
Intel Xeon X7460	8	6	48	8U	$50K *	HP DL580
Intel Xeon X7460	12	6	72	12U	$75K *	HP DL580
Intel Xeon X7460	16	6	96	16U	$100K *	HP DL580

* Clustering hardware and software are not included, driving up cost; clustering decreases linear performance increase

It should be noted, the T2 and T2+ processors run 8 threads per core, meaning that single thread performance is slower than the single thread performance on the Xeon, while Opteron seems to have best single thread performance.

If single threaded performance is a requirement, then this should be kept in mind.

Future Architecture Planning

It is clear that the T2 & T2+ architecture is competitive today, while leading the market from the date of their initial release.

The T2 and T2+ processors have been out for years, indicating that a refresh on this CPU line will probably be released soon, to compete with the brand new Intel hex-core processors released just months back.

Considering how old the T2 processor line is and seeing how well it competes with modern processors on a price/performance basis, there is a good indication that the refreshed line will give a tremendous application performance boost, if you can delay hardware purchases until Q3 or Q4 of 2009 over the competition.