The OCUS R20 Benchmark Results

- Last modified: Jul 28 2000 -

Here are the results of my OCUS R20 Benchmark.

In february 1999 I have sent out a message to the Pro/USER mailing list with a request to everyone to run my benchmark trail file on their computer.

The trail file was created with my OCUS pro_bench script (version 5.0; R20) and performs several tasks. This mainly checks the speed of the CPU and the Graphics card.

If you want to run it it yourself you can download it here. Calculate your results with my count utility.

Below are the results I received so far. I am now also accepting R2000i results, but be aware when you compare R2000i with R20.
Scores are in seconds, lower is better:

• Total score

• CPU tests only score, Graphics test only score, GUI test only score, DISK test only score

You can also:

• view the Total score including sub-scores
• view the Full results
• Search the results pages
  

• view the top 10 per task scores
• view the scores sorted by vendor
• view the results of the top 25 as a graph (50Kb).

This kind of benchmarking can also be done to compare Pro/E builds on one and the same machine:
Click here for a comparison of R20 with R19 and R2000i

In 1998 a R18/19 benchmark was performed. You can view those old results on this page.

Future changes

Remarks, conclusions and tips...

• Do not take these result for granted. You can make a lot of adjustments on every machine to make Pro/E run faster or slower. Furthermore, note that these benchmarks were performed at all kinds of sites and with a lot of different builds. This surely influences the results.
• This benchmark is in fact a benchmark with relatively small models. When you're mainly concerned in large assemblies you should be carefull interpreting these results. Swapping memory is one thing, but some graphics cards can also only be much better when certain display intensive tasks are performed.
  Take a look for instance at my own results on the Compaq AP550 comparing the GVX1 with the much cheaper SynergyII. (Use the search utility with these words: gvx1 synergy +ap550 +r2000i +olafc). It clearly shows that the SynergyII appears to be faster, and then especially in the dynamic rotation and dynamic zoom test. Tests you would assume would be better with better graphics cards.
  But when I ran the same OCUS tests using a large assembly instead of the OCUS Benchmark part, then suddenly the GVX1 is two times faster than the SynergyII.
• The benchmark could also be influenced be adjusting monitor configurations and display resolutions. Especially when fast display rates are concerned, adjusting the frequency and synchronization, toggling double buffering and lowering the resolution could make a big difference. Although you then might have a really ugly display which you normally wouldn't use.
• Some of you are concerned with the fact that vendors are entering results as well. Are they really reliable? My opinion in this is, that if a vendor performs special tricks to get abnormal fast results he will soon be uncovered by users who have such a machine as well. If you consider buying a machine based on these results why not perform this benchmark on a demonstration model by that vendor and see if the fast results can be reproduced under normal working conditions.
  I'll try to make future releases less dependable on monitor configurations by preventing to much flashing of menus and views.
• This benchmark needs at least 150Mb of RAM to run without swapping. So results from machines with less are not accurate at the end of the test.
• If your machine performs bad only on specific tasks verify if you've really removed all configuration files in the $PROELOADPOINT/text and $HOME directory.
• Floating licenses could make a difference, since Pro/E has to check the network for free licenses.
• I did not add any prices. Too much uncertainty ... You'll have to calculate your own price/performance values.
• Whatever the results are. If a machine runs the test really fast it will probably be a really fast machine (check for no abnormal sub-scores). If it is really slow on the other hand you will first have to check if this is not some kind of configuration issue before judging the computer.
• In the config.pro there is an option called OVERLAYS_ENABLED which is set to YES. This is a SGI IRIX specific option and should not work on other machines. But I received reports about this option slowing down HP UNIX machines resulting in X-protocol errors. If you get these errors on a non-SGI UNIX machine, try setting this option to NO in the config.pro file AND in the trail file.

Future recommendations