Re: OpenVMS.org: Marvel article and HP's press release for Marveland Alpha Retain Trust Alpha Retain Trust Alpha Retain Trust Alpha Retain Trust Alpha Retain Trust Alpha Retain Trust Alpha Retain Trust Alpha Retain Trust Alpha Retain Trust

From: Andrew Harrison SUNUK Consultancy (Andrew_No.Harrison_No@nospamn.sun.com)
Date: 04/07/03 

From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com>
Date: Mon, 07 Apr 2003 17:50:14 +0100

jlsue wrote:
> On Tue, 01 Apr 2003 12:02:39 +0100, Andrew Harrison SUNUK Consultancy
> <Andrew_No.Harrison_No@nospamn.sun.com> wrote:
>
>
>>
>>jlsue wrote:
>>
>>>On Mon, 31 Mar 2003 11:59:00 +0100, Andrew Harrison SUNUK Consultancy
>>><Andrew_No.Harrison_No@nospamn.sun.com> wrote:
>>>
>>>
>>>
>>>But the point is still that there are testimonials to counter your
>>>argument that the GS160/320 is not scalable enough for running
>>>transaction/database systems. Apparently in the real world there are
>>>ample examples of happy customers.
>>>
>>
>>Really so have you actually read the testimonials ???
>
>
> Yes, and even presented two.
>
>
>>[snip unrelated testimonials...]
>
>
>>That leaves Bank Austria which isn't a good reference unless
>>you are hell bent in illustrating how poorly GS boxes perform
>>when compared with the TurboLaser.
>
>
> Why do you keep repeating this lie. You are so blatant in ignoring
> the facts in this that it amazes me that you can have any credibility
> in anything.
>

> Show the wording in that article that states the GS160 only provides
> 28% improvement. I have read very carefully through the article and
> there's just nothing in it to support your opinion. The article is
> about upgrading to a pre-release of V7.3, which is not necessarily the
> version that came with the system (it's also supported on V7.2-1H1,
> and V7.2-2). So it's very possible it was delivered with an earlier
> release, and this win was focusing on the benefits of OpenVMS V7.3 -
> the GS160 is just an aside, but for my purposes of showing a happy GS
> customer, it's enough.
>

No you show the wording that explains what the 28% performance
improvement was based on or shut up. Repeating the claim that
the document says that the 28% is due to the 7.3 upgrade when
the article talks about two events, hw upgrade and sw upgrade
but one performance number is pointless. If you don't actually
know what the reference is about then calling me a liar only
serves to make you look more confused and less competent.

While you are at it, what was the performance improvement for
the hardware alone ??? Surely if you can apparently be so
sure what the perfromance bump for the 7.3 upgrade was you
can also publish what the 8400->160 upgrade did for them
if it isn't 28%.

> One other thing you seem to miss in the GS vs Turbolaser discussion is
> the scalability of the GS. Sure, it has a slower QBB-to-QBB memory
> transfer rate, but the scalability is much better - especially
> compared to the Turbolaser. The 8400's really didn't scale well when
> you got into the higher cpu counts. The additional cpus would give
> you some added benefit, but the benefit decreases significantly, while
> the GS decreases less significantly. So while there is additional
> latency, it can still provide greater growth potential due to better
> scalability of the CPU.
>

Ahh now you have got quite close to the real issue. Shall
I help you out.

Firstly we need to clarify a few points.

1. QBB -> QBB memory bandwidth is higher than the 8400
    interconnect bandwidth. Minimum QBB -> QBB memory
    latency is higher than the 8400 minimum memory latency.

2. QBB onboard memory bandwidth is also higher than the
    total interconnect bandwidth on 8400. However QBB
    minimum onboard memory latency is longer than the
    8400 minimum memory latency.

Now a bit of background.

Your own performance white papers indicate that for something
like a DBMS over 50% of the wall clock time is actually
spent with the CPU stalled waiting for main memory.

http://research.compaq.com/wrl/DECarchives/DTJ/DTJO01/DTJO01HM.HTM

So lets look at what happened when you "upgraded" to a GS160/320.

1. The clock speed went from 700->731 Mhz
2. The cache size halved from 8 to 4 MB.
3. The minimum latency of main memory went
        up from 257ns to 360ns.
4. NUMA intoduced a second minimum latency of 960ns
        which on a 4 QBB system with no NUMA OS tuning
        should result in 75% of all memory accesses taking
        a minimum of 960ns.

So what does this mean.

If you spent 50% of the time stalled and 50% doing useful work as
your white papers suggest then had the memory subsystem been
the same speed the wall clock time should have gone down by
2%. In fact the reduction in cache size ment that your cache
miss rate went up so your elapsed time also went up this shows
up in the CPU95 results which are you best case scenario
apart from something like dryystone.

Sadly your minimum memory latency wasn't the same it was worse
either a little bit or 4x worse. And the more QBB's you have
the higher the ratio of 4x worse accesses.

Crucially your engineers apparently seem to have spent a big part of
their time comparing a bogus set of E10K memory latency
numbers with the GS320 projected numbers rather than looking at
how the GS compared with the 8400. The real E10K numbers were
40% lower than the numbers used in the white paper and the
ratio of local->remote NUMA memory access was also very
optimistic.

So how did this pan out for customers. Well some of them reported that
with small number of CPU's the GS160/320 were quite a lot slower than
their previous systems, sometimes slower than the 8400 6/575 this is
consistent.

Some also reported that if you put enough cpus in the system you could
get more thoughput than the 8400, this is also consistent because
as you point out the bandwidth of the 8400 and increasing latency
under load ment that at some point the GS160/320 performance overtook
the 8400. It is also supported by your own TPC-C results a GS140 with
8 x 700 Mhz does 42K TPM and a GS160 with 16 x 731 Mhz CPU's does
55K TPM. Incedentally this is about 25% which is very close to the
results posted for Kingston and for Bank Austria.

Your comments about 8400 scalability will also come as a suprise
to people who were on the receiving end of the 8400 marketing
campaign.

Regards
Andrew Harrison

>
>
>>And thats your list of GS customer references, sorry this is so
>>bad that its embarassing and not one of them actually refer
>>to the "performance" advantage that the GS boxes gave them.
>>
>
>
> Many of those references, though not current, are still valid examples
> of satisfied customers. Just because you like to find fault doesn't
> invalidate them as examples where the GS systems provided good
> solutions.
>
> You have a vested interest in twisting things around and
> characterizing them in a bad light. That's your spin, but that
> doesn't reflect the reality that the solutions work well for many
> customers. No, not all customers, but that's never been my argument.
>