SUMMARY: V440

• Previous message: Marco Greene (Home): "A Raid manager 6.22.1 issue with Solaris 2.6 on E3000"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Fri, 5 Mar 2004 18:56:05 -0600
To: sunmanagers@sunmanagers.org

Thanks for all the responses, I got very good feedback regarding the V440
server, and it looks like the problem of the evil US-IIi L2 cache has gone
away with the redesign of the US-IIIi CPU. Where the 256kb cache on the
US-IIi CPU did make a large impact, the 1mb cache on the US-IIIi cpu vs the
8mb cache on the US-III does not seem to play a role unless you have an
application that is very dependent on CPU cache. One response also mentioned
issues with the RAID controller, and get the latest patches to resolve.

The orignal question:
Hello,
We are looking at getting several V440 servers, and I am looking for some
feedback on them. The main concern I have is the US-IIIi CPU with 1mb cache.

I remember with the US-IIi, the limited cache made a large performance hit,
and I am wondering if the same is true for the US-IIIi line of CPUs.

The responses:

<hike1272-sunhelp@yahoo.com> mentioned that the cache will depend on
application.

Richard Skelton had some very good information to share:
Hi,
It will depend on you application.
I have just compared A V480 4x1052 MHz 48GB memory with a V440
4*1.28MHz 16GB memory.
My test was the Solaris v9 version of setiathome with the same work units.
The V440 took 5:43:01.46 and the V480 took 6:10:23.51

Eric Paul also had a very good response:
We recently purchased a bunch of V440s, mostly as replacements for E450s and
E4500s. Here's a quick bench for you. One of the database servers we
replaced was a E4500 8X450 MHz, 8 gig ram running a large (500 GB) Oracle
database. We replaced it with a 4 X 1.06GHz machine with 8 gig of ram. Our
performance has increased by at least a factor of 2. I ran a similar query
on a similarly configured V480 (slightly slower CPUs, 1.02s I think, but the
8MB of L2 cache instead of 1MB) and didn't see any significant performance
changes either way.

I think unless you KNOW that your application is cache-bound, you'll be fine
saving the big bucks on a V440 over a V480. Just make SURE you download all
the latest patches. The internal raid controller has a LOT of issues with
the rev 1.0 firmware. Check SunSolve, there's a hefty list. (Or worst
case, open a ticket with Sun and make them give you a tarball of all the
V440 patches, which is what I did.)

Stephen Ficklin responded that (s)he would like a to see a summary, here
you go :-)

Joe Fletcher mentioned that it is going to be based on workload, and he would
expect a 5-10% performance hit when compared to a V480 or a v880 (4 way)

Useful information from Kris Hogg with UNIX4Less:
We have sold a lot of these machines, and have had no reports of any
loss of performance due to the limited cache. It was a known problem on
the earlier Sparc proc's and I believe it was specifically addressed
whit the intro of the Sparc III

Some info from Octave Orgeron:
I've worked on V480's and above with the USIII CPU's and used the V210
and V240. There is definitely a performance hit with applications and
services that make use of the CPU cache. So applications like Oracle,
BEA Weblogic, etc definitely need the cache to perform well. The same
is also true for services, like E-mail, NFS, LDAP, Firewalls, etc.
You'll find that things like Apache 1.3.x and other non-multi-threaded
apps will run well with the IIIi's. But as soon as you use an
application that's multi-threaded and manages large pages of memory or
manipulates a lot of storage.. you'll need the regular III's cache.
Think of it like this.. the IIIi is cutdown like a celeron and the III
is like a Xeon.

And best for last, some very good info from Daryl McKinnon:
I thought I would send a quick response about your V440 question.

We have purchased a number of V440s (a few already in production) and we are
seeing that they are performing very well. Since the V440 is so much cheaper
than a 4 CPU V880, we thought we would buy one and give it a trial before
getting more.

I did a fair bit of research about the L2 cache, because I also was concerned
about the cache size. However, if you look through the white papers, you'll
see that the L2 cache is twice as fast as for the UltraSPARC IIICu for the same
chip frequency (about 19.2 GB/s vs 9.6 GB/s). Also, the memory access is
almost twice as high (4.25 GB/s vs 2.4 GB/s, though I admit I've seen some
descrepancies in some of the numbers).

I tested some applications using the cputrack(1) and cpustat(1M) routines to see
the cache hit ratios, and I saw very similar ratios on the 1 MB vs larger L2
caches (I was also comparing to the UltraSPARC II as we had old E4000 servers
we're replacing with the V440s). Somewhere I heard someone say "1 MB on chip
cache is worth 8 MB off chip cache" -- don't hold me to that quote, but I must
say that my fears about the small cache size don't seem to have amounted to
much.

Considering the cost of the V440s, we figured it was the best solution for our
needs. I don't know what you want to use one for, but for a midsized system, I
think it's a great performer.

Then another response with:
PS: When comparing the UltraSPARC IIIi chip, note that its L1 cache is larger
than the US-II (32/64 KB instruction/data vs 16/16) and the L1 caches are 4-way
set associative. So, there is a much better L1 cache on the IIICu/IIIi than on
the II/IIi, so some of the issues you may have experienced with the IIi
shouldn't make one quite as nervous about the IIIi (but, hey, what do I
know??).

 -Mike Ekholm

-- 
Mike Ekholm, UNIX Sys Admin  -  ekholm@ekholm.org
web: http://www.ekholm.org ham: kc0mpu irc: Nalez
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
UNIX - The Swiss army knife of software.
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers

• Previous message: Marco Greene (Home): "A Raid manager 6.22.1 issue with Solaris 2.6 on E3000"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]