mailbox performance on OpenVMS between Alpha and I64

[jackywu]

How can i get the top speed of mailbox in alpha and I64, how can I make the read performance in I64 system same as performance of read in Alpha system ?

I have a system using mailbox to communicate between processes. This feature is used commonly in the system. So the performance of the system is largely depend on the performance of mailbox.

In the system the mailboxes are implemented using sys$qio and sys$qiow.

my operating system is OpenVMS.
When I test the performance of mailbox On platform Alpha and I64, the difference between Alpha and I64 is very obvious.

The method of test program: a program write about 200M data into mailbox. After the program write data to mailbox successfully, the other program start to read the mailbox, then get the elapse time of write and read opertion. So we can get the performance of write and read per second.

test data:
mailbox write speed:
Alpha: 430M/s
I64: 470M/s

mailbox read speed:(buffered mailbox)
Alpha: 720M/s
I64: 540M/s

mailbox read speed:(nobuffer)
Alpha: 480M/s
I64: 370M/s

The question is why the performance of read mailbox is so obvious, and how can I make the read speed on I64 same as Alpha.

thanks for your help.

[Hoff]

Which Alpha? Which OpenVMS Alpha version? Which Itanium? Which OpenVMS I64 version?

That written, do check your process quotas. Memory-related username quotas on OpenVMS I64 should be set to roughly triple the values used on OpenVMS Alpha, give or take. Ensure the other process quotas are equivalent.

And check for available pool, since that's where data gets stuffed.

And run DECset Performance and Coverage Analyzer (PCA) on the package as a whole, and see where the application is really spending the time.

And also do look for alignment faults, as they'll completely clobber your performance on OpenVMS I64.

And if you'd like us to have a more detailed look, post up the mailbox test code.

Mailboxes means that the application can't easily cluster. ICC services or networking or a file-based ring buffer might be alternatives worth investigating and testing here, too.

And if there is a support contract in force here, some direct discussions with HP are probably the best course here.

[John Gillings]

I64 and Alpha are different systems that run at different speeds. There are a whole range of things that will affect the timing of mailbox operations - CPU speed, memory speed, bus speed, other processes etc...

The only way to get the same speed is to somehow slow down the faster system to the speed of the slower. That's a bit tricky to do accurately. What's your objective here?

I'm not sure I understand your test - if you write 200M into the mailbox before attempting to read, that means you have a mailbox with 200M quota? That's rather large! I also don't understand what you mean by "buffered mailbox".

[Hein van den Heuvel]

- Please explain what is implied by buffered vs unbuffered.

- 200MB of data is a lot to stick into a mailbox. I'm surprised that even works. It would means that system tuning like POOL confiuration can influence the test.

- You seem to assume that the (read) slowness is caused by the mailbox reads themself. This could be, but could it perhaps also be that the reading program has a porting issue and that it is in fact the user mode code which is slower?
Where is the data going, once read?
I can see two ways to drill down on that:
1) Replace the QIO by a 'ayup, here it is' fake routine and compare the platforms.
2) Instrument the benchmark with SYS$GETJPI to obtain the (new with 8.3) JPI$_KRNLTIM and JPI$_USERTIM as well as JPI$_CPUTIM. Compare.

Finally some folks suggest that OpenVMS on Itanium is Faster (for comparable CPUs) for USER code, but a touch slower for System task. Your benchmark may be disproportionally testing the system tasks, and presented with a full load, using real work the Itanium may end up ahead again.
Then again.. it might indeed be 10% slower (and 50% cheaper).

hth,
Hein van den Heuvel (at gmail dot com)
HvdH Performance Consulting

[Volker Halle]

Consider to also use a performance data collection tool (e.g. T4) to look at the overall system performance during the test. This tool is available for both platforms. You can adapt the data collection interval according to your test duration.

Volker.

[Tom O'Toole]

Hein,

What do you mean by "for comparable CPUs" Which are comparable? Do you mean the same clock speed? Thanks.

[Hoff]

Current-generation Itanium systems are generally faster than the end-generation Alpha boxes. Sometimes significantly faster.

There have typically been three tiers in the product lines, and I expect Hein is here referring to boxes in the same tier. The DS-class Alpha boxes to the two-socket Itanium boxes, ES-class to four-socket, and GS-class to more-socket boxes.

The other consideration here involves the general decreases in prices. With a few exceptions, Itanium hardware and software are priced cheaper than Alpha. (Salient exception when last I looked: MCOE-class and clustering. That's expensive on both.)

Benchmark your code. You're not running benchmarks, after all. Use the (free) HP Test Drive system, and see for yourself. Look for alignment faults, insufficient quotas, insufficient physical memory, small working sets, and any of the usual suspects.

Processor clock speed is not a reliable comparison across different implementations of the same architecture. From Alpha EV56 to Alpha EV6, for instance, you can't compare clock speed. Across architectures as widely different as Alpha and Itanium, there's just no way.

As for some published benchmarks, see:

http://www.spec.org/

But again, your specific application may go faster or slower. I've seen silly-fast Itanium runs, and I've seen runs where Itanium tanked. Try the Test Drive servers.

Expect to take a look at where you're spending your run-time, using tools such as DECset PCA, and at alignment fault monitoring, and at I/O throughput.

If you're doing something comparatively odd -- like looking to run a quarter- to a half-gigabyte of data per second through a mailbox -- you're working with a comparatively unusual case, and performance can take some (more) study.

There's no silver bullet here.