In article <[log in to unmask]>, John Lee
<[log in to unmask]> writes
>I understand.  What's difficult, though, is knowing what HPUX system is a
>good match for the MPE system you're replacing.  Since noone wants to share
>info, and/or since so few have done it, it becomes a guessing game.  We
>have one statement from HP that seems to imply "start with an HPUX box that
>is upgradeable, and if it's not powerful enough in its original state, then
>start upgrading it until it is".  This approach will work I realize, but of
>course nobody wants to go through that process...nobody want to be the
>guinea pig.
>
>In my opinion, if HP truly cares about their customers, they will do some
>benchmarking, SPEC tests, etc., and publish the results so that their
>customers could begin to make concrete plans for the migration.  Or, since
>we have such a plethora of MPE and HPUX systems here, I'll do it for them
>if they'll reimburse me for the time spent.
>
>


I think one of the things that gets forgotten when people talk about
sizing a processor to replace their HP3000 and that benchmarking would
be useful to help them do it is.

1) Benchmarking is really only useful if the benchmark actually
benchmarks something that you do. So for example if the supplier of a
package that has migrated their application from the HP3000 to say an
HP9000 can say, that our application, with this amount of data, and this
number of users, running these batch processes requires an HP9000 of X
configuration to deliver similar performance to an HP3000 of Y
configuration.

This is useful to someone running the same application looking to
migrate to the same platform.

It is utterly useless to anybody else other than as a vague finger in
the air gauge. In the above example what you have is a measure of how
that particular vendor chose to migrate/re-write their application.
There are just too many variables to make it useful to anybody else.

How were their Image database structured, efficiently, inefficiently,
did it have very clever access routines that gave them stunning
performance that they just can't replicate on the database they went to.
Or vice versa was their 3000 application inefficient but when then
migrated it they have released a bunch of efficiency gains from a
relational database.

Now compare that with your applications, are your applications as well
written as someone else's, are you going to the same database they did,
are you going to migrate using the same tools, and rewrite things in the
same way? I think the answer is you just don't know.

As a very silly example its like asking somebody how much the stock in
their warehouse weighs, and then how many truck loads it took to move it
to a new warehouse. You then use the same matrix to calculate how many
trucks you need to move your warehouse. You then find out that he was
stocking steel, and your stocking polystyrene beads.

Whilst there are some measures that may give you some sort of guidance
as to the size of HP9000 you might need, in reality its only when you
have done the work that you will know how efficient what you have
migrated is, and therefore what configuration you will need. And as I
suspect for those companies migrating more than a single standalone
application what you actually end up running could be spread across
several servers, and you never have a box that was running everything
exactly as your HP3000 was.

So by all means gather together as much anecdotal benchmark information
as you can, accumulated together it will give you guide to the ball park
you will be operating in. But would I go out and order a processor based
on other peoples results, Never. Also as Birket commented as most
migrations are going to take a reasonable amount of time, why are you
worrying about the size and I assume cost of a replacement production
processor, when in 12-24 months the whole picture will undoubtedly be
different. Do worry about the size and cost of the development/testing
box and tools that you need know.

Alan
--
Alan Yeo
[log in to unmask]    Just because you're paranoid
Phone +44 1684 291710   it doesn't mean someone isn't!.
Fax   +44 1684 291712

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *