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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Tech Tip: Really Simple HTTP Server with Python
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Returning Values from Bash Functions
- Rogue Wave Software's Zend Server
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide