To prove the mettle of this prodigious workstation, OpenBench Labs ran an equally prodigious number of benchmarks on the platform. Naturally we started with our OBLcpu benchmark, which runs 34 numerically intensive kernels with a mix of integer and floating point arithmetic done in both single and double precision. While OpenBench Labs benchmark has an obvious relationship to the performance of scientific, mathematical, and engineering workstation applications, there is also a close relationship between floating point calculation performance and high-end graphics performance. 

Extensive floating point arithmetic can be found in MPEG-2 video encoding, speech recognition, financial modeling, and trading applications. These calculations are essential for geometric calculations common in CAD/CAE processing, high-precision mathematical calculations, and 3D graphics applications involving physics, geometry, and triangle setup. With the need to deliver increasing levels of realism and detail when modeling physical objects in motion, higher-quality digital video, and a richer web experience, good floating point performance has become a requirement across the workplace.

When we first ran our OBLcpu benchmark on the single 850 MHz Athlon CPU, 3 out of every 4 kernels ran distinctly faster than on a server using a single 866 MHz Pentium-III processor. In a few instances, the differential was as high as 200%-to-300%. Nonetheless, the best way to obtain a single performance number is to take the geometric mean of all of the kernels. This measure is the least susceptible to being overweighted by data points at the extremities. 

For our 866 MHz Intel Pentium III, the geometric mean of our 34 kernels clocked in at a processor index of 254. Our 850 MHz Athlon CPU clocked in at 300. Right on the numbers, the new 1194 MHz Athlon CPU in the Marquis K120 workstation was pegged at 411. OpenBench Labs currently normalizes performance to a standard 300 MHz Pentium III running Windows 2000, which we set to 100. More importantly, within a 95% statistical confidence region, performance for the 850 MHz AMD Athlon was between 275 and 353. In contrast, performance for the new 1194 MHz AMD processor was between 381 and 501. The bottom line for Linux users is the likelihood of a 20% performance edge when running on an Athlon as opposed to a Pentium III of equal speed. 

As the OBLcpu benchmark is single-threaded, the modules only run on one CPU and do not take advantage of the multiprocessor architecture or stress the scalability of the SMP implementation. To test this aspect of the ASL Marquis 120, we scripted the execution of 2, 4 and then 8 simultaneous instances of the OBLcpu program. For a single user workstation, running 8 simultaneous CPU-intensive processes is a likely limit.

Within this relatively restricted range of 8 simultaneous processes, the Marquis 120 scaled perfectly. With just two benchmarks running, each process had its own AMD-760MP CPU and measured a performance index of 400. In general, with a 2-way SMP system, doubling the number of processes should effectively cut the performance index measured by each process in half. This is exactly what we observed.  More importantly, if the kernel is optimally scheduling the distribution of time slices among competing processes, we should measure very little difference in the performance of each process. This is exactly what occurred. The performance index measured by each process ranged from a low of 206 to a high of 211. 

We then redoubled the number of processes, and once again the performance index measured by each process was halved. Moreover, we measured little variation between the processes. With 8 simultaneous CPU benchmarks running, the lowest performance index measured was 109 and the highest was 112.

To test the effectiveness of the Marquis K120’s DDRAM implementation, we ran our OBLmemband benchmark, which measures memory throughput by using the CPU to move data between memory locations and measuring the time taken. Few implementation factors are as critical to overall system performance as the usable bandwidth between the CPU and memory. Whether data is being moved to/from a device or simply manipulated by the CPU, it ultimately must be brought into memory before it can be used to achieve anything interesting.

The benchmark requires a minimum allocation of 64 MB of memory—we used 756 MB on the Marquis K120—so that a broad range of physical addresses can be used and the address translation caches can be effective without dominating the behavior of the overall system. Oblmemband varies the “stride” value as it proceeds through the test stressing the bandwidth by transferring larger chunks of data.

Since the Enlight workstation we tested in January used PC133 EEC SDRAM, our OBLmemband benchmark could directly compare memory bandwidth improvements offered by PC2100 EEC DDRAM. In theory at least, we should measure twice the throughput. In this case,  theory won out. On memory strides ranging from 4-to-64 bytes this is exactly what we measured with throughput in MB per second averaging about 80-to-100% greater For DDRAM compared to SDRAM with AMD processors. In addition, when we ran two threads in parallel, performance for strides ranging from 4-to-64bytes once again virtually doubled. 

In our final tests, we examined the performance of the disk I/O subsystem of the workstation. The use of an embedded Adaptec Ultra160 SCSI controller raised our expectations for the workstation; however, the performance of a single IBM drive absolutely surprised us. 

To defeat normal disk caching, we utilized a 2GB test file. Streaming throughput as we utilized OBLdisk to linearly access the file with varying block sizes remained fairly constant at about 24 MB per second. We then used OBLload to randomly access the disk in a database pattern making 8 KB reads. Under this scenario we were able to reach approximately 350 I/Os per second before exceeding an average access time of 100ms.

To get a sense of the workstation’s performance in a more macro scale we ran a few unscientific experiments with Gnofract4D, which is a very robust fractal generation program. With a few deceptively simple clicks of the mouse, we delved deep into our fractal. In fact, it is was so deceptively easy that it was not until we examined the fractal’s properties that we did realize we had passed through more than 16,000 iterations. 

Now that is a workaholic’s workstation.