SEO

I have recently installed Solaris 10 on a Sun Enterprise 3500 server
system that was sitting unused in our hardware stores here. Primarily
I had intended to use this as a machine to serve Directory Server LDAP
information, possibly Kerberos, and Sun Calendar requests. Upon
looking into the stats for this machine, however, I see that it has
four processors installed at what appears to be 400MHz apiece,
according to system POST tests. The system utilizes 8GB of memory, as
well.

At this point what I am wondering is whether or not the requirements
for the server I have described would be better served by an x86
server, with the same amount of RAM (64-bit, obviously), that won't
have the power requirements of this piece. I know that the Sparc
processors support multiple threads per CPU; I do not know if this
will give significant improvement over the x86 architecture for the
applications I have described. The server we are currently using
supports approximately 40 Calendar and related LDAP requirement
instances; we expect this need to grow 5-10 times before we commit to
a new infrastructure.

If, indeed, the x86-64 architecture does seem to be the better
solution, what kinds of server implementations would I see better
performance from the sparc with 4 processors on?

In advance I'm sorry for my relative ignorance about this
architecture, I haven't had the chance to take any courses on Sparcs
yet; hopefully after this stabilization of the infrastructure through
our projected growth is complete I'll be able to spend a few weeks
formally learning what I need to know here.

Thanks for your help, it is much appreciated (as well as to those that
helped me get the server talking and running with Solaris 10 in the
first place)!

-Damon Getsman

In comp.sys.sun.hardware Damon Getsman <dgetsman@gmail.com> wrote:
> At this point what I am wondering is whether or not the requirements
> for the server I have described would be better served by an x86
> server, with the same amount of RAM (64-bit, obviously), that won't
> have the power requirements of this piece. I know that the Sparc
> processors support multiple threads per CPU;

Some processors do. The SPARC II modules you have do not.

> I do not know if this
> will give significant improvement over the x86 architecture for the
> applications I have described. The server we are currently using
> supports approximately 40 Calendar and related LDAP requirement
> instances; we expect this need to grow 5-10 times before we commit to
> a new infrastructure.

It almost certainly will not. The E3500 was a very nice machine, but
the 400MHz processors you have are over 10 years old. Almost any
machine today can have the I/O and RAM that the 3500 could, and can
destroy it CPU-wise.

> If, indeed, the x86-64 architecture does seem to be the better
> solution, what kinds of server implementations would I see better
> performance from the sparc with 4 processors on?

I wouldn't say the "architecture" is the better solution, but the
specific server you have is "slow" by today's technology. I would
expect better performance from any modern x86-64 system on almost any
workload, presuming it had suffcient RAM and decent I/O.

--
Darren Dunham ddunham@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >

On 2008-04-07, Damon Getsman <dgetsman@gmail.com> wrote:
> I have recently installed Solaris 10 on a Sun Enterprise 3500 server
> system that was sitting unused in our hardware stores here. Primarily

[snip]

> If, indeed, the x86-64 architecture does seem to be the better
> solution, what kinds of server implementations would I see better
> performance from the sparc with 4 processors on?

[snip]

You'd need to use an x86 of similar vintage to the E3500 to compare the
architecture, really. The E3500 is an old machine indeed, despite having more
RAM than the average PC. A new x86 based machine will have a lot more CPU
power than the E3500, especially if it has the same number of CPUs. A quad
Opteron with 8Gb of RAM would kill it completely. On the other hand, a quad
Pentium Pro wouldn't get anywhere near the throughput of the E3500.

It's not a reasonable comparison, but I will note that even the old E3500 will
still churn through a good amount of work, and the hardware is very reliable -
they tend to live on for a long time.

If you do want to benchmark it, I'd suggest using one of the Oracle benchmarks
- they're a good workout for the system. Why not post the results back here?

--
|
/\ ._ _|.__ | http://www2.purplecow.org
/--\| |(_||(/_ | email: andre at purplecow dot org

Andre van Eyssen wrote:
> On 2008-04-07, Damon Getsman <dgetsman@gmail.com> wrote:
>> I have recently installed Solaris 10 on a Sun Enterprise 3500 server
>> system that was sitting unused in our hardware stores here. Primarily
>
> [snip]
>
>> If, indeed, the x86-64 architecture does seem to be the better
>> solution, what kinds of server implementations would I see better
>> performance from the sparc with 4 processors on?
>
> [snip]
>
> You'd need to use an x86 of similar vintage to the E3500 to compare the
> architecture, really. The E3500 is an old machine indeed, despite having more
> RAM than the average PC. A new x86 based machine will have a lot more CPU
> power than the E3500, especially if it has the same number of CPUs. A quad
> Opteron with 8Gb of RAM would kill it completely. On the other hand, a quad
> Pentium Pro wouldn't get anywhere near the throughput of the E3500.
>
> It's not a reasonable comparison, but I will note that even the old E3500 will
> still churn through a good amount of work, and the hardware is very reliable -
> they tend to live on for a long time.
>
> If you do want to benchmark it, I'd suggest using one of the Oracle benchmarks
> - they're a good workout for the system. Why not post the results back here?
>

Doesn't Oracle prohibit publication of such benchmarks? The last time I
had any contact with Oracle was 2004 and, at that time, publishing
benchmark results involving Oracle was prohibited. Check your contract
with Oracle before you get into expensive legal trouble!!