Following my other Sun 280R questions I've had this week I reached a state
where the system is up and stable.
I installed it now with Solaris 8 (plain install, Generic_108528-29) but
comparing with our older Ultra5 I don't see the 3-4 times speed increase
that I had hoped for.
We mainly use this system for compilation of c++ code using g++ and the
specs being 2x 750 MHz with 2GB ram should outperform our Ultra 5 with 400
MHz and 512 MB easily.

While I've only done a bit of early testing I noticed that the disks are
pretty slow. The system comes with 2 Seagate 36GB FC-AL disks but currently
we only use one of them.

Maybe I'm missing some magic patches compared to a base install that would
help?

Thanks.

-- Henrik

On Apr 12, 1:18 pm, "Henrik Goldman" <h...@x-formation.com> wrote:
> Following my other Sun 280R questions I've had this week I reached a state
> where the system is up and stable.
> I installed it now with Solaris 8 (plain install, Generic_108528-29) but
> comparing with our older Ultra5 I don't see the 3-4 times speed increase
> that I had hoped for.
> We mainly use this system for compilation of c++ code using g++ and the
> specs being 2x 750 MHz with 2GB ram should outperform our Ultra 5 with 400
> MHz and 512 MB easily.
> While I've only done a bit of early testing I noticed that the disks are
> pretty slow. The system comes with 2 Seagate 36GB FC-AL disks but currently
> we only use one of them.
> Maybe I'm missing some magic patches compared to a base install that would
> help?

How about a total OS upgrade?? I mean there have been a lot of
improvments
on all kinds of levels since Solaris 8 supposedly..
Anyway - I dont know where you get your expectations from but I ball
park it
at 4-5 times more load capability at twice the speed of execution over
a 400 MHz
Ultra SPARC... 750 MHz? 2GB of RAM and GNU c++ running on a single
36 GB disk? I hope you didnt pay too much : >

I happen to have a Blade 1000 up at the moment w. a single 750 MHz CPU
running
103 processes, 689 lwps. Depending on test I see up 22 MB/sec written
with dd
on the global zone. Not blazing for sure but not bad for 10 year old
machine running
an Oracle 10g Grid Control session on a second zone either I guess.
When I first got it it seemed to be about twice as fast as the Ultra 2
single 400 MHz machine it replaced : >

Henrik Goldman wrote:
> Following my other Sun 280R questions I've had this week I reached a
> state where the system is up and stable.
> I installed it now with Solaris 8 (plain install, Generic_108528-29)
> but comparing with our older Ultra5 I don't see the 3-4 times speed
> increase that I had hoped for.
> We mainly use this system for compilation of c++ code using g++ and the
> specs being 2x 750 MHz with 2GB ram should outperform our Ultra 5 with
> 400 MHz and 512 MB easily.
>
> While I've only done a bit of early testing I noticed that the disks are
> pretty slow. The system comes with 2 Seagate 36GB FC-AL disks but
> currently we only use one of them.
>
> Maybe I'm missing some magic patches compared to a base install that
> would help?
>
> Thanks.
>
> -- Henrik

I think that your FCAL disks are probably as fast, or close to as fast
as just about anything available. You will have to look to your
applications for performance improvements.

Remember that while processor deal in nanoseconds, disk drives work in
milliseconds! The most efficient way to read a sequential file from
disk is to read a whole track or several tracks in the cylinder as a
single operation. If you do small reads and writes (one block), you are
paying an access time penalty, 6 to 12 milliseconds, each and every time
you go to the disk. Keeping the file contiguous on disk makes it
possible to read/write large chunks efficiently.

Some other Operating Systems allow you to make an allocation of
contiguous space. I don't know if Solaris does so.

Henrik Goldman wrote:
> Following my other Sun 280R questions I've had this week I reached a
> state where the system is up and stable.
> I installed it now with Solaris 8 (plain install, Generic_108528-29)
> but comparing with our older Ultra5 I don't see the 3-4 times speed
> increase that I had hoped for.
> We mainly use this system for compilation of c++ code using g++ and the
> specs being 2x 750 MHz with 2GB ram should outperform our Ultra 5 with
> 400 MHz and 512 MB easily.
>
> While I've only done a bit of early testing I noticed that the disks are
> pretty slow. The system comes with 2 Seagate 36GB FC-AL disks but
> currently we only use one of them.
>
> Maybe I'm missing some magic patches compared to a base install that
> would help?
>
> Thanks.
>
> -- Henrik
If you can and the code fits try compile in /tmp/...
see if its faster in memory.
Solaris make and gnu make has flags for parallell make.
# format -e can enable write cache for the scsi disks on the 280R.
But dont know if its recommended without UPS and no ZFS in solaris 8.
/Jorgen

On Apr 12, 10:18*pm, "Henrik Goldman" <h...@x-formation.com> wrote:
> We mainly use this system for compilation of c++ code using g++ and the
> specs being 2x 750 MHz with 2GB ram should outperform our Ultra 5 with 400
> MHz and 512 MB easily.
>
> While I've only done a bit of early testing I noticed that the disks are
> pretty slow. The system comes with 2 Seagate 36GB FC-AL disks but currently
> we only use one of them.
>
> Maybe I'm missing some magic patches compared to a base install that would
> help?

Not really disk related, but allowing make to run things in parallel
("-j 2") could have some magic effects.

Christian

--
rc at networkz dot ch

<usenetpersongerryt@gmail.com> wrote in message news:3da6995d-b36e-4a17-8064-974602c0ff55@p25g2000pri.googlegroups.com...
> On Apr 12, 1:18 pm, "Henrik Goldman" <h...@x-formation.com> wrote:
> > Following my other Sun 280R questions I've had this week I reached a state
> > where the system is up and stable.
> > I installed it now with Solaris 8 (plain install, Generic_108528-29) but
> > comparing with our older Ultra5 I don't see the 3-4 times speed increase
> > that I had hoped for.
> > We mainly use this system for compilation of c++ code using g++ and the
> > specs being 2x 750 MHz with 2GB ram should outperform our Ultra 5 with 400
> > MHz and 512 MB easily.
> > While I've only done a bit of early testing I noticed that the disks are
> > pretty slow. The system comes with 2 Seagate 36GB FC-AL disks but currently
> > we only use one of them.
> > Maybe I'm missing some magic patches compared to a base install that would
> > help?
>
> How about a total OS upgrade?? I mean there have been a lot of
> improvments
> on all kinds of levels since Solaris 8 supposedly..

Trouble with that is that for compilation, they ought to be using the oldest
OS version they support, lest they build in reliance on some function or
other that was introduced only later.

I should imagine that compilation involves creating an awful lot of
temporary files, which will be faster if these are never written to disk:
/tmp should be tmpfs in a standard-ish installation but has someone
filled it with huge "temporary" files used during installation of the OP's
software or code base? If so, empty it.

Does iostat -xnp 5 during compilation show you are i/o-bound?
Reading, writing or both? If so, consider enabling write-caching.
Incidentally, does iostat -En show errors (ignore the cd drive)?

You should perhaps consider using SVM/Disksuite to mirror your
drives, for resilience and faster reads. But a disk crash on
a compilation-only machine is not the end of the world so let's
not get hung up on it. If you do, then iirc there used to be some
wrinkle about using SDS rather than UFS logging but I cannot
remember the details. It may have concerned earlier versions.
(Are you using logging btw?)

Does mpstat 5 during compilation show you are CPU-bound and
that both CPUs are loaded? If only one then try make -j 2 (or 3).

Does vmstat 5 during compilation suggest more memory may help?

--
John.

On 2008-04-13 07:31:41 +0100, "John L"
<jl@lammtarra.notthisbit.fslife.co.uk> said:
> <usenetpersongerryt@gmail.com> wrote in message
> news:3da6995d-b36e-4a17-8064-974602c0ff55@p25g2000pri.googlegroups.com...
How
>
>> about a total OS upgrade?? I mean there have been a lot of
>> improvments
>> on all kinds of levels since Solaris 8 supposedly..
>
> Trouble with that is that for compilation, they ought to be using the oldest
> OS version they support, lest they build in reliance on some function or
> other that was introduced only later.

Is an alternative here running Solaris 8 in a branded zone on a modern
Solaris 10 box? Sun calls this the Solaris 8 Migration Assistant.

Cheers,

Chris

>> How about a total OS upgrade?? I mean there have been a lot of
>> improvments
>> on all kinds of levels since Solaris 8 supposedly..
>
> Trouble with that is that for compilation, they ought to be using the
> oldest
> OS version they support, lest they build in reliance on some function or
> other that was introduced only later.
>

Correct. Customers requires software to be Sol 8 compatible. I'd give half
of my arm to upgrade to Sol 10 which is many times better but unfortunately
it's not an option.... It's something to reconsider in 4 years...

> I should imagine that compilation involves creating an awful lot of
> temporary files, which will be faster if these are never written to disk:
> /tmp should be tmpfs in a standard-ish installation but has someone
> filled it with huge "temporary" files used during installation of the OP's
> software or code base? If so, empty it.

Yeah you maybe right on that. /tmp dir is almost empty though.

> Does iostat -xnp 5 during compilation show you are i/o-bound?
> Reading, writing or both? If so, consider enabling write-caching.
> Incidentally, does iostat -En show errors (ignore the cd drive)?

Here are the stats ... what are they telling you:

extended device statistics
r/s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device
0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 c0t6d0
0.2 81.4 1.6 572.8 30.9 3.6 379.1 43.7 22 41 c1t0d0
0.2 81.4 1.6 572.8 30.9 3.6 379.1 43.7 22 41 c1t0d0s0
0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 c1t0d0s1
0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 c1t0d0s2
0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 c1t1d0
0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0
unknown:vold(pid242)

This was performed during a recompile of gcc 3.4.5.

> You should perhaps consider using SVM/Disksuite to mirror your
> drives, for resilience and faster reads. But a disk crash on
> a compilation-only machine is not the end of the world so let's
> not get hung up on it. If you do, then iirc there used to be some
> wrinkle about using SDS rather than UFS logging but I cannot
> remember the details. It may have concerned earlier versions.
> (Are you using logging btw?)

Since the machine has enough ram and more ram is very cheap it would make
sense to try to push it to ram instead of playing with more disks.

> Does mpstat 5 during compilation show you are CPU-bound and
> that both CPUs are loaded? If only one then try make -j 2 (or 3).

During a compilation of gcc I got:

CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 297 1 361 612 511 62 3 2 1 0 293 30 2 2 66
1 123 1 34 305 287 52 1 3 1 0 167 6 1 2 91
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 0 0 301 606 505 77 0 0 0 0 0 0 0 0 100
1 1 0 1 303 299 5 0 0 0 0 3 0 1 0 99
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 0 0 301 604 503 77 0 0 0 0 0 0 0 0 100
1 0 0 1 303 300 6 0 0 0 0 3 0 0 0 100

I already enabled -j 2 for make when building our own code... not in the
particular compilation though.

> Does vmstat 5 during compilation suggest more memory may help?

procs memory page disk faults cpu
r b w swap free re mf pi po fr de sr s6 sd sd -- in sy cs us sy
id
0 0 0 3745776 1889968 80 407 42 31 31 0 0 0 8 0 0 818 446 114 18 1
81
0 0 0 3761480 1830904 0 2 0 0 0 0 0 0 0 0 0 809 4 87 0 0
100
0 0 0 3761480 1830904 0 0 0 0 0 0 0 0 0 0 0 809 73 91 0 0
100
0 0 0 3761480 1830904 0 0 0 0 0 0 0 0 0 0 0 808 4 82 0 0
100

It seems there is enough free memory.

Thanks for your suggestions so far.

-- Henrik

> How about a total OS upgrade?? I mean there have been a lot of
> improvments
> on all kinds of levels since Solaris 8 supposedly..

Yes I'm saying that to our customers as well. But as long as they are larger
then we are and we're the vendor... they win.

> Anyway - I dont know where you get your expectations from but I ball
> park it
> at 4-5 times more load capability at twice the speed of execution over
> a 400 MHz
> Ultra SPARC... 750 MHz? 2GB of RAM and GNU c++ running on a single
> 36 GB disk? I hope you didnt pay too much : >
>

It's a dual cpu machine though but in any case I had hoped for a much faster
compilation than our Ultra 5. Cutting down 1 hour compilation time to less
than 30 min would be nice.

> I happen to have a Blade 1000 up at the moment w. a single 750 MHz CPU
> running
> 103 processes, 689 lwps. Depending on test I see up 22 MB/sec written
> with dd
> on the global zone. ...

How did you do this test?

-- Henrik

> Is an alternative here running Solaris 8 in a branded zone on a modern
> Solaris 10 box? Sun calls this the Solaris 8 Migration Assistant.
>

I didn't even know about such option. Perhaps that would work if everything
else fails.
Obviously we would go through the installation hassle twice but if it would
give an improvement then it's worth considering.

-- Henrik