On Thursday 30 June 2005 17:52, Bryan J. Smith <b.j.smith@xxxxxxxx> wrote:
> From: Peter Arremann <loony@xxxxxxxxxxxx>
>
> > *rofl* either you forgot how damned slow a E4500 is or you never
> > worked with them... There is _nothing_ fast about them (see, I
> > learned how to use the underscore from you, aren't you happy?)...
>
> Dude, compared to modern UltraSPARC III/IV, _yes_ they _are_ slow.
> But there are a lot of UltraSPARC II options that are still quite
> viable solutions.
Yeah - for a boat anchor or a door stop... Other than that, a US-II isn't
worth the power it would take to run it... That's why you see so many of them
on ebay now - cause no one wants it anymore :-)
>
> > Oh - misquote to omit my acknowledgment of the inadequacy of my
> > comparison. What was the reason for you leaving off where I said
> > "compilers aren't a good benchmark"? :-) Are you that desperate to
> > win an agrument that you have to misquote me to infer that I'm
> > saying something else?
>
> Dude, this is _not_ about "winning an argument."
>
> It's about reminding you that "build times" are _not_ a good
> indictator of _server_ benchmark (please note that I said _server_).
That is exactly what I said before you trimmed it off :-)
> I mean, if you want to see one benchmark that Intel has _always_
> lost to AMD -- and handily -- build times are it. ;->
But thanks for not acknowledging that you purposefully trimmed off a sentence
that was essential for the statement I made.
> > That's why I made the comment that you so nicely cut out :-)
> > Performance tuning of provisioning apps is another thing I do :-) Working
> > for a fortune 5 and dealing with the biggest systems that company has can
> > be fun...
>
> Dude, stop with the resume. The problem with pulling credentials is
> that someone else _always_ has more. Now stop while you _think_
> you are "ahead." ;->
Oh - but its ok if you do the same, right? :-)
> > 4TB databases, used by Java and C++ programs, 48way 96GB
> > ram... that a better example or still too small for you to accept that
> > I might not just do little things?
>
> Once again, I will re-iterate, there are _other_ performance considerations
> than computational. And even then, "build" times are _not_ very
> representative of performance in even some computational
I wasn't talking about builds - This is 100% transaction load. Very heavy on
the DB.. (just so you know what I mean with heavy - so heavy that Informix
had to produce a specific release just for us otherwise no commercial DB was
able to handle the load at the time)...
> > An Athlon64 3200+/4GB running on a 3ware controller with mirrored
> > disks beats an 8way E4500/4GB running a 400GB oracle database...
> > give the sun box 8GB and the performance is roughly equal...
>
> Depends on if you are computationally limited, and also what is your
> I/O -- let alone the number of sessions you are serving. In raw,
> unthreaded, linear aspects -- hell yes, the E4500 is a _dog_.
Yep - and for threaded apps its hmmm... a _dog_ :-)
14 CPU E4500 is 67103 TPC-C ... a 16CPU p5 570 is 809144...
But I guess that doesn't count either for you :-)
Point being a E4500 for todays standards is slow no matter what you use it
for.
>
> > Yes, and one of the limitations on the E4500 is throughput...
> > A 3510 on a v490 does 61MB/sec - same lun, just connected into the
> > SUNW,socal of a E4500 IO board does about 20MB/sec...
>
> It all depends on how distributed your environment works, as well
> as the application.
>
> I'm not saying an old UltraSPARC II platform is always going to be
> faster. But man, you are like a single track that thinks there are
> _no_ other considerations.
???? What does a distributed app have to do with an inheret IO limit of the
hardware????
Peter.
