Thursday, February 25, 2010

Rumors and FUD

There have been a lot of rumors around OpenSolaris in the recent days, some of them claiming that Oracle will abandon OpenSolaris. I don't think this will be the case, it would damage to Oracle new enterprise operating system and generate lots of bad will. Oracle can however chose to have a different support model or not even sell support for OpenSolaris at all. This would also be bad, especially in the time before the next major release of Solaris is available. There would then be no way to use new features currently only available in OpenSolaris with support a contract.

Meanwhile, the OpenSolaris community is still very much alive with websites and a a steady stream of updates to the source, and releases that getting close to a full 2010.03 release. This is not the case for other projects like Kenai that Oracle chose to end.

I think the rational way to handle this is just to wait a few more weeks to get the official roadmap from Oracle before jumping the gun and spreading rumors about the end of OpenSolaris or anything else that Oracle is taking over with Sun.

"A posting on the company Website implied that OpenSolaris may soon be "end-of-lifed." However, there's no need for app developers and IT managers to worry: Oracle says it is not killing off the freely downloadable community version of Sun's Unix-based Solaris enterprise operating system anytime soon."

Read the full article here: Oracle Explains Unclear Message About OpenSolaris

According to Dan Roberts, director of Solaris product management, Oracle claims to continue to support and invest in OpenSolaris:
OpenSolaris Alive and Well at Oracle

Sunday, February 21, 2010

OSOL b133 and new flag day page

Development build 133 of OpenSolaris, the next to last planed build, not including possible respins. Start your update or download new ISO images here. The release notes contains a summary of the changes and other important information, especially for people updating from previous releases.

I've updated the software version table to reflect this build, you find it here.

Joerg Moellenkamp wrote about the new flag day page for OpenSolaris in his blog. This is a good page to get an overview of changes going into new OpenSolaris builds, the old page have been out of date for a few months now.

Wednesday, February 17, 2010

UltraSPARC T3 and final 2010.03 ON source

The gate have now closed for what is supposed to become the build used in OpenSolaris 2010.03 (onnv_134). Stopper bugs can of course still trigger a respin. This means that we are getting closer to the next stable release and that we will soon see more interesting stuff in the development branch.

Some interesting things have already been en put back into the the gates which are no longer being restricted to freeze for the release. The perhaps most noticeable is "6917448 processor name update for UltraSPARC T3", which indicates that the final name for the next CMT SPARC processor, UltraSPARC KT, will indeed be UltraSPARC T3.

The processor will be of the same generation as UltraSPARC T2 and T2+, Niagara 2, but with a few additional features such as hardware support for the Kasumi block cipher which is used in GSM and UTMS. This chip will as stated before have sixteen cores.

A good article about the UltraSPARC T3:

Tuesday, February 16, 2010

Thread performance on modern SPARC processors

All currently sold and supported Sun systems have some kind of multi threading on the chip, T2 or Niagara 2 uses Chip Multi Threading (CMT) which currently has 8 strands (HW threads) per core, four strands per integer execution unit and the SPARC64-VII that uses Vertical Multi Threading (VMT) with two strands per core.

A strand is in itself unable to execute any data, it's only the registers needed for a software thread to execute on a CPU. But all strands can be executed on the CPU without the cost of a context switch, every strand can have a thread bound to it and a let them execute every other instruction without overhead.

One reason I write this is that I have several time encountered a misunderstanding that processors with multiple strands per core only could run threads at a clock frequency divided by the number of strands. This would then severely impact single thread performance. E.g. a 1.6Ghz T2+ could only run a thread at 400Mhz or a thread on a 2.52GHz SPARC64-VII which has two strands per core could only run at 1.26GHz.

This not true, if there is only one thread running on a CPU the strands of a core, it will get all cycles it can consume. CMT is based on the assumption that threads is spending some of the execution time just waiting for the slower memory, during this time it's more efficient to execute another thread, given that no context switch is needed, hence several strands it's own registers.

But if we execute several threads on one CMT CPU, what will then happen? Each thread will then not be able to run at full speed, but that would more or less be the case anyway, the scheduler in Solaris would switch the thread on and off a single hardware thread. Sure the later thread will run at full speed for short fractions of time, but it will be stalled and moved off the CPU if not finished. There are of course some workloads were this is better, for example if a transaction or job can be finished in this short time. In the first case we will be able to take advantage of the CMT design, when one of the threads is waiting for memory the others could possibly execute instructions instead of wasting the cycles.

Solaris normally handles the scheduling of threads on different strands quite well, it there are more CPU resources available than the running threads can consume, they are spread out on stands on different physical cores. There is then no performance impact on threads compared to running on a system with one thread per core.

One thing that probably have had its part in creating this misconception is that the Niagara design (T2,T2+..) is built using simpler and weaker individual cores (non-superscalar) which also runs at a lower frequency. This was done to be able to have more strands per core, more cores per chip and to have lower power consumption. So while the claim of lower frequency is not really true, the Niagara class of processor do have weaker single thread performance, but not for that reason. That said, for many throughput workloads or for encryption the Niagara processors can excel and perform better than any SPARC64 processor. So as always, it depends on your workload but in general application servers and web servers works well with CMT and also many database or otherwise highly threaded workloads.

A quick test in real life on a M3000 (2 strands per core) where we see that using a single thread just has negative impact of the execution time this simple single threaded workload (md5). If they would indeed have their own cycles for each strand there would be no big impact of adding another job which runs on the second strand.
1 core, 2 strand, 1 job:  6.48s
1 core, 1 strand, 1 job: 6.52s
1 core, 1 strand, 2 jobs: 10.33s, 13.07s
1 core, 2 strands, 2 jobs: 10.85s, 10.92s
Here is a example where we can se that a single thread is consuming more than one forth of the cycles available on a T2 processor core:
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 0 0 137 241 32 18 18 3 17 1 12385 74 26 0 0
Core Utilization for Integer pipeline
Core,Int-pipe %Usr %Sys %Usr+Sys
------------- ----- ----- --------
0,0 56.07 4.37 60.44
And two threads consuming 80 percent of the cycles:
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 0 0 76 260 43 263 73 10 33 1 9345 80 20 0 0
1 0 0 17 74 0 284 74 9 30 0 8453 79 21 0 0
Core Utilization for Integer pipeline
Core,Int-pipe %Usr %Sys %Usr+Sys
------------- ----- ----- --------
0,0 76.42 5.15 81.57

Worth a read:
The UltraSPARC T2 Processor and the Solaris Operating System
SPARC Enterprise architecture
Niagara 2 opens the floodgates
Glenn Fawcett's Weblog, guidelines for Oracle on CMT.

A utility to show the core utilization on CMT/VMT processors:

Saturday, February 13, 2010

VirtualBox and OpenOffice

Just a quick news flash that new versions of OpenOffice and VirtualBox are available for download. VirtualBox is a maintenance upgrade to version 3.1.4, the OpenOffice version is 3.2.

The VirtualBox changelog and download here.
Download OpenOffice here and read the release notes.

Tuesday, February 9, 2010

Fishworks 2010.Q1 release

I was trying to get some more information on the next release of the software for the Sun Storage 7000-series appliance systems, this is what I found:

  • It will feature COMSTAR Fiber Channel targets

  • It might also include support for multiple zpools, which can be useful if data with very different performance/availability requirements are located in the same box.

The update will probably be released during or before next week since there is a event which will show of new features next Tuesday here in Sweden. Read more and register here.

Here is a short mail conversation with Bryan which mentions this and here are some (translated) references to an internal test version with FC support.

Update: The release date for this update is "in the next few weeks" according to Bryan of the fishworks team, stay tuned.

Friday, February 5, 2010

OSOL development build 132

We are getting close to OpenSolaris 2010.03, the development repository have been updated to build 132. There are also iso-images available at the usual location.

Don't forget to read the release notes, really.

There are not many new packages this late in the development cycle, but a few got in:

BRCMbnxe Broadcom NetXtreme II 10GbE NIC Driver
CPQary3 HP Smart Array HBA Driver
SUNWgnuplot gnuplot - plotting utility