Test drive of the 6/06 Solaris 10 part 2, usage

The machine is up. If you don’t know about Blastwave, it is a helpful resource. Once you set up your machine, mozy over there, and get all the tools you would otherwise be missing.

nVidia graphics, pulled down the Solaris nVidia binary, installed it, rebooted and up it came. nVidia makes great chips and great drivers. We are lucky they are still supporting Solaris. We have an Itanium2 linux box here where the nVidia drivers are built for the old XFree86 versus xorg used in Centos 4.3, so it uses frame buffer graphics. A shame as it has a seriously nice nVidia card in it.
Comments: root in Solaris uses /sbin/sh. Ugh. Changed that to /usr/bin/bash ASAP. Also, for some reason, the root home directory is / . Reminds me of IRIX and others. I created a /root, set roots home there, and moved on.
Some things don’t work. NFS. I cannot mount my Linux servers. Don’t know why. Simply gives up, and the server doesn’t even see the mount request. My 3 other network cards are not even detected. Put them all in since I didn’t know which of them Solaris would support.
Some things barely work. scp of large files in/out. Don’t know why. Packet rate drops way down. I am lucky if I get 0.1 MB/s on a 10 MB/s link.
Some things that are supposed to install didn’t/couldn’t. I pulled down Java Enterprise bits for this system, burnt onto CD, and put it in when requested. Only to be told that they weren’t Java Enterprise bits. Huh?
Whatever, hopefully they were not important anyway.
Pulled down latest Studio 11 for Solaris. The difference between the Studio 11 for Solaris and for linux are the lack of compilers in the latter. In the former they are there. So now I have C/C++/f95 compilers. Great. Now I can test things.
First, lets use Blastwave, pull down pkg-get, and load up some needed tools. That took another few hours.
The Sun folks are always telling me how much better their tools are than Linux tools, and how much faster my codes will go when I build with their tools. Being a skeptic, I have a permanent “show me” stance.
So I pull over HMMer 2.3.2. We have a release of HMMer called Scalable HMMer, which is 1.6-2.5x faster than regular HMMer depending upon what you do with it. I pull over the baseline and our patched code base. I have previously booted this exact machine into the Redhat EL4 ES and run our binaries, so I know how long it will take.
Build with their tools. Use cc from their studio 11, and use -xO5 to optimize. Remember, this is an Athlon64 running a 64 bit version of Solaris 10 and a 64 bit version of Linux.
Run it.
Here are the results, all times in seconds

Platform Time (s)
Linux 40.9
Solaris 109

Hmmm. Something doesn’t seem quite right. If I build HMMer as a 32 bit application under Linux, it takes about 82s on this test. I wonder if the Sun compilers don’t build 64 bit binaries by default (they should).
Dig around in the docs, play with some options. Finally come up with
-fast -xarch=amd64a -xvector=simd -xdepend -xO5
after reading the release notes, the man pages, etc.
Rut it again. Here are the results.

Platform Time (s)
Linux 40.9
Solaris 57.6

The Solaris code is definitely 64 bit this time. Note that Opterons do run 64 bit code faster due to the memory address models (flat versus segmented), as well as having more registers available in 64 bit mode, as well as having more SSE registers available … Why the Solaris compilers don’t generate this by default is not obvious. I will need to ask.
Note that I wanted to try this with the 64 bit gcc for Solaris x86_64, only to discover that there was no such beast.
This is not a comprehensive test. Hard to draw general conclusions from it. It does match experience that I and others have had with other codes.
I will likely get another hard disk or two in the unit, try out Nextenta and Windows 2003 64 bit server. I have higher hopes for Nextenta. If it lives up to them, it could make a good platform to build clusters from for people who insist upon a Solaris kernel for some reason. For those who don’t know, Nextenta is the Solaris kernel with the Debian application stack. I haven’t heard of too many customers demanding Solaris based clusters. The only ones that I am aware of are the ones that bought into the SCO FUD (curiously boosted by both Microsoft and Sun).
Eventually we will try out WCC. Again, we haven’t heard of customers seeking to go this route. Likely there will be a few.

1 thought on “Test drive of the 6/06 Solaris 10 part 2, usage”

  1. Update: Replaced the 100 Mbit switch. Turned out it was in the process of dying. Once we did this, scp worked as expected. Still no joy with NFS.
    1) The desktop (Java desktop 2) is quite nice. This is one of the strong points. If we were deploying desktops, this would be in the running for such systems (JDS).
    2) Grub didn’t automatically detect the other OS on there (Linux). Had to add it in by hand. Would be nice if they fixed this or enabled it to work right.
    3) only one network card seen. Others are invisible to Solaris. This is the driver problem I talked about before. Linux has lots of mindshare, so lots of drivers get written for it. A few companies still refuse to release linux drivers, but they are in the minority, and we tend to tell our customers to avoid them anyway, as their lives will be made harder by lack of drivers. In the case of Solaris 10 x64, there are very limited number of drivers, and I do not expect this to change.
    Sun is looking at Solaris 10 as a way to sell Sun gear. Recent Sun gear, the Opteron bits are quite nice, we like them (and we sell them). The problem is the 80-20 rule of market entry. First one in the market gets most of the mind share, second one in gets much less, third one in, well, don’t build business plan on being the third one to market. Linux was first into this OSS OS market. It is now on Microsoft’s radar, and Microsoft is targeting it with tactical maneuvers such as entering into HPC to try to outflank its competitor.
    Unless there is a massively compelling reason to use Solaris over Linux, I don’t expect Linux to give way to Solaris. Driver support will be better under Linux for the forseeable future. OEM support for an OS that no OEM controls will be better. You can’t lock in customers with an OSS OS. As seen here above, you don’t get better performance under Solaris, at least on the application we used, but other data seems to suggest a mixed performance bag.
    We will look at Nextenta, as it may be the most reasonable approach to building Solaris based clusters. Then again, just like with Windows clusters, we simply haven’t seen significant interest.

Comments are closed.