Hewlett-Packard x4000 Workstation
Hewlett-Packard's workstation line includes the x4000, which has a number of configuration options. For our testing, HP delivered a top-of-the-line machine with two 2.2GHz Xeon processors, 4GB of RDRAM memory and a FireGL4 graphics card, running Red Hat 7.1.
Our company is a visual effects production company. From our inception we had been using SGI workstations for both interactive desktop use and for batch rendering. About two years ago we began using generic Linux workstations for batch rendering, but we were still using SGI machines for artist workstations. We now feel that the maturity of both Linux and the newer hardware solutions are to a point that they can provide far better artist workstations at a reasonable cost.
We tested this x4000 as an artist workstation, as well as a batch renderer. We installed a wide range of software and performed a representative set of tasks over the course of three weeks.
As described above, the configuration is as follows:
two 2.2GHz Xeon processors, with 512KB cache each
four 1GB RDRAM
FireGL4 graphics card
Intel Camino 2 Chipset (aka 820e)
two 53c1010 Ultra3 SCSI adapters
Intel 82557 Fast Ethernet
Tehama Chipset AGP Bridge
Seagate ST318406LW disk, about 16GB
DVI-HD15 adapter cable
Software is as follows:
Red Hat version 7.1, kernel 2.4.3-12smp
Hammerhead's in-house graphics software
Shake by Nothing Real
Maya by Alias|Wavefront
RAYZ by Silicon Grail
Most of the software that we use was developed in-house and has been ported to Linux from the SGI/IRIX environment over the last couple of years. Installing this software on the x4000 was trivial; everything copied over and worked perfectly with no changes. This is a tribute to the maturity of Linux and the expertise of HP and ATI in building compatible systems.
The x4000 was shockingly faster than the machines we had been using (admittedly old SGI O2 computers). While it is unfair to compare the x4000 to SGI machines made three years ago, it is still revealing. The x4000 with the FireGL4 graphics board could display both 2-D and 3-D information on the order of 30-50 times as fast as our old O2s. Changes by a factor of two or four are amazing, but by a factor of 40 is astonishing.
In the visual effects business, it is often true that 2-D performance is as important as 3-D performance. Much of the work involves working directly with hundreds or thousands of high-resolution film frames, doing rotoscoping by tracing the outlines of regions of an image, tracking features from frame to frame and playing back high-resolution images to examine these frames in motion. The x4000 with the FireGL4 had the best performance I have ever seen, displaying more than 250 million pixels per second. At a resolution of 1,600 × 1,200, it could display 130 frames per second. There was sufficient processing power available to do fairly complex color correction on the fly and still get better than real-time performance.
While our test machine had only a 100-baseTX network card (based on the Intel i82557 chipset), it was dramatically faster at reading frames from our file server than our other Linux boxes, often approaching 10MB/sec over NFS. This allows the animators to be much more productive, as they are not waiting so long for the next image to load.
Of course, 3-D performance is also vitally important; and it is no surprise that this x4000 gave a stellar performance in this area too. In simple tests viewing independent polygons, the machine would render 2.5 million polygons per second. One can use Alias|Wavefront's Maya to edit 100,000 polygon models with true interactive performance. In general, the 3-D performance was so astonishingly better than the performance of our SGI machines that there was no comparison whatsoever; it was also dramatically faster than the RADEON and GeForce cards on our other Linux machines.
For the three and a half weeks that we had the machine, it was used almost nonstop as a rendering server. The 2.2GHz processors were, on average, about 1.4 times as fast as the 1.3GHz Athlon processors in the rest of our renderfarm. The huge 4GB of memory allowed us to render far more complex scenes at once than we could with our other smaller computers.
The SMP capabilities of the machine were a pleasant surprise, in that the performance was almost perfectly double that of a single-processor machine. Rendering two frames took almost exactly the same time as rendering one; there was little contention for shared resources. Furthermore, the SCSI disk offloaded the processor, allowing the CPUs to run at full speed even during heavy disk access—something not found in commodity ATA-based systems. An artist could use one processor for background rendering, while doing interactive work with the other processor without much contention.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Hacking a Safe with Bash
- Django Models and Migrations
- Secure Server Deployments in Hostile Territory, Part II
- The Controversy Behind Canonical's Intellectual Property Policy
- Huge Package Overhaul for Debian and Ubuntu
- Home Automation with Raspberry Pi
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development