[rescue] Solaris vs sparclinux

[Justin Haynes]

I don't know which T2000 this would be, but you may wish to spin up an
OpenBSD instance to compare.  Their support for the models supported have
been very good for those I have tried.  4 models with "T2000" in the name
are supported according to http://www.openbsd.org/sparc64.html.  I'm
guessing it is the SPARC Enterprise.


   - Sun Fire T1000/T2000
   - Sun SPARC Enterprise T1000/T2000
   - Netra T2000
   - Fujitsu SPARC Enterprise T1000/T2000

Binaries and INSTALL.sparc64:
http://ftp.openbsd.org/pub/OpenBSD/5.7/sparc64/

OpenBSD 5.7 notes:
http://www.openbsd.org/57.html




On Fri, Jun 12, 2015 at 3:27 PM, Meelis Roos <mroos at linux.ee> wrote:

> > Hmm, it would be interesting to install Solaris on a spare disk in T2000
> > and run some bencharks.
>
> Well, I did that - grabbed Solaris 11.2 and installed it on identical
> disk.
>
> Debian unstable with 4.0.0 kernel and my custom configurationf for that
> machine (left out most drivers I will never need, left out some features
> I would not use).
>
> Server is T2000, 1 GHz, 32 threads, 16G RAM, 10kRPM SAS disks. Bare
> hardware, no virtualization if any kind (no ldoms, zones, containers).
>
> > And, should I run single-disk Solaris on ZFS or journaled UFS for this?
>
> ZFS was the only option.
>
> > Also, what is the latest freely available Solaris and does it let me
> > publish the benchmarks?
>
> Nope, the license does not allow publishing of benchmarks without
> Oracles permission. So no numbers, just subjective impressions.
>
> The results are mixed again.
>
> First, one of the tools that I often wait after is git (for big repos
> like Linux kernel), so I first tested different git scenarios (with git
> 2.3 on both systems)- initial remote clone, local clone, git fsck (rare
> but slow if it happens), checkout. This led to more filesystem tests -
> copy and rm of the tree.
>
> In these tests, Linux was clearly superior - on the average about twice
> as fast as Solaris. The only big exception was git fsck that was
> CPU-bound and here Solaris was about twice as fast as Linux. Also, rm -r
> of a big tree was slighlty faster on Solaris. Maybe ext4 is just so much
> faster on single disk...
>
> So I tried lmbench3 to test more than filesystes. Notable difference was
> Bcopy where niagara-optimized Solaris implementation was about 3 times
> as fast as Linux. It appears that Linux glibc has implementations for
> ultrapsarc-T* variants too but Debian has disabled them because they saw
> some bug some time ago, and it hasn't been reported or investigated
> until now, and Debian-packaged glibc uses ultrasparc-III level of
> optimizations only.
>
> There were 2 other trends: first, context switch was slightly but
> consistently faster on Solaris (more on no dirty data(?), less so on
> more dirty data) and local communication latencies were faster on Solaris
> on
> the average. There were exceptions but this was the general trend. Also,
> pipe and AF_UNIX bandwidth was higher in Solaris.
>
> Another trend was that anything related to filesystems was about twice
> as fast on Linux, same as in macrobenchmarks.
>
> So I fired up hackbench (CPU scheduler benchmark that uses socket pairs
> for ping-pong of data between tasks). I expected Solaris to win here but
> was suriprised to see Linux clearly winning.
>
> Another real-life-like test for shell scripts was simplistic spawning of
> shells, like
>
> time for i in `seq 10000`; do sh -c true; done
>
> Here again Linux was many fimes faster.
>
> So the results are mixed but for most of my real-life-like test on
> command line, sparclinux still seems to be faster.
>
> Now if the glibc ultrasparc-T* optimizations could get fixed... it has
> just risen into the radar of the main sparclinux developer, DaveM.
>
> --
> Meelis Roos (mroos at linux.ee)
> _______________________________________________
> rescue list - http://www.sunhelp.org/mailman/listinfo/rescue