> The answer is? The answer is?

At the bottom of the post.

> FWIW, I would like to encourage you to offer an opinion on the TPC
> benchmarks idea.

TPC-C certainly seems doable, though it would require practices that most
TurboIMAGE developers seem to avoid, like locking around reads. However, one
item concerns me: the "checkpoint" rules. Specifically, 5.5.2.2.3 requires
that "The Checkpoint Interval must be less than or equal to the Measurement
Interval.  If the Checkpoint Interval is less than the Measurement Interval,
the Measurement Interval must be an integral multiple of the Checkpoint
Interval." MPE with XM qualifies as checkpointing as defined by the TPC-C
spec, but it doesn't have a fixed time interval for the checkpoint writes.
So, I'm not sure how we would meet the requirement above: it's hard to do
something for an integral multiple of an unknown period.

Nothing else in TPC-C jumps out as a serious problem, though I haven't read
every word of the spec. By far the most challenging part of producing the
benchmark would be creating the "user simulation" machine (called the "RTE",
"Response Time Emulator", in the spec). Maybe the setup HP uses for HPUX
benchmarking could be used for MPE?

OTOH, TPC-D seems to be a non-starter; it specifically requires SQL queries
(0.1: "....The TPC-D database must be implemented using a commercially
available database management system (DBMS) and the queries executed via an
interface using dynamic SQL."), so you can either
 1) run against Allbase on MPE, thus spending a lot of time, energy, and
money on benchmarking a configuration that almost no one uses, or
 2) run against TurboIMAGE with one of the ODBC drivers, thus incurring some
unspecified amount of additional overhead, not to mention using TurboIMAGE
in a sub-optimal manner.


Steve


Steve Dirickson   WestWin Consulting
[log in to unmask]   (360) 598-6111