Ultimate Linux Box
NVIDIA: Proprietary but Responsive
While putting the finishing touches on this article, I received a call from Jeff Brown, of NVIDIA, following up on getting their driver to behave with the Ultimate Linux Box. I asked him to comment on why NVIDIA had not open-sourced their driver, which might have enabled a faster resolution of my issues. His response was the driver—the core of which is a single code base that works on everything from Windows to Linux to FreeBSD to OS X—was about 50% of NVIDIA's “intellectual property” content, the rest of the IP being the GPU itself. By comparison, on network cards, Intel appears to have most of the smarts on the card itself and subsequently has GPLed the driver. In compromise to the Open Source community, NVIDIA has committed itself to keeping support and feedback channels open. Brown said that Andy Mecham, one of NVIDIA's engineers, devotes half his workday to providing help to folks on the Linux forum, nvnews.com. I saw evidence of this myself in my search for answers; Andy's name seemed to be fairly common on the boards. Brown also said the folks that really pay the freight on the Linux side, members of the Visual Effects Society (of the members he mentioned, the name Disney stuck in my head) are satisfied with NVIDIA's support. These are the people that would use a commercially supported system similar to the Ultimate Linux Box 2003 as a multimedia workstation to do bleeding-edge stuff.
The fact that Monarch was able to get me, a solo end user, direct access to an engineer who did pin down the problem correctly—without having access to my machine—speaks well of NVIDIA's commitment to support. Although I don't think we're going to see a GPL driver for any NVIDIA card anytime soon, I think perhaps we're getting the next best thing—a company that knows where the future is and is committed to helping us get there without giving away its secret recipe.
The rough edges on this machine, however, are only in the eye candy. Aside from Chromium (the video test), we were able to run the rest of the Linux Journal Benchmark Bundle on the machine (bonnie++, postgres-test, tiobench and the kernel compile), and the results were impressive. The base kernel compile averaged one minute 35 seconds using both CPUs. As a point of comparison, my personal 1.1GHz Duron took six minutes 50 seconds to do the compile. Overall, the Opteron/3ware architecture seems to offer about a 15% advantage in speed, gigahertz for gigahertz. The Opteron has an integrated memory controller that bypasses the Northbridge and gives you a 64-bit duplex channel direct to the DIMMs. This particular machine also allows use of a singleton DIMM in 32-bit mode, which is handy for debugging hardware problems, at the expense of speed.
Tiobench produced the other interesting numbers, as shown in Listing 1. I compared the performance of the 3ware/Western Digital harness on an Athlon 2800 to its performance on the ULB. The numbers are not quite apples to apples, because I took advantage of the Opteron's 64-bit addressing to handle a larger file size—but that in itself produced interesting results. The 32-bit platform appeared to do better in single-threaded sequential reads but produced comparable numbers for the rest of the run. On random reads and writes, the absolute rate of the ULB lags behind, but the latency does not. The ULB soundly trounces the Athlon despite using a file more than double the size. I suspect that the drop in numbers at the end of the sequential read and write runs is an artifact of hitting the 3ware card's buffer limit, given the nice flat curve up to that point. On a side note, these numbers compare favorably in most departments in absolute terms—and very well in terms of bang for buck—with a Dell Precision 650n SCSI system I tested previously.
Listing 1. Tiobench Output (edited for space)
Sequential Reads File Blk Num Avg Identifier Size Size Thr Rate (CPU%) Latency ------------- ------ ----- --- ----- ------ ----- Athlon 1792 4096 1 81.60 29.29% 0.048 Opteron 4096 4096 1 59.30 14.86% 0.066 Athlon 1792 4096 2 58.07 30.61% 0.132 Opteron 4096 4096 2 62.18 13.46% 0.125 Athlon 1792 4096 4 54.37 61.00% 0.285 Opteron 4096 4096 4 59.19 14.59% 0.260 Athlon 1792 4096 8 55.29 64.72% 0.542 Opteron 4096 4096 8 48.44 13.17% 0.625 Random Reads File Blk Num Avg Identifier Size Size Thr Rate (CPU%) Latency ------------- ------ ----- --- ----- ------ ----- Athlon 1792 4096 1 1.32 0.975% 2.952 Opteron 4096 4096 1 1.18 0.151% 3.296 Athlon 1792 4096 2 2.29 1.374% 3.354 Opteron 4096 4096 2 1.93 0.740% 4.017 Athlon 1792 4096 4 3.18 2.859% 4.639 Opteron 4096 4096 4 2.76 1.236% 5.431 Athlon 1792 4096 8 3.70 2.221% 7.264 Opteron 4096 4096 8 2.96 2.085% 9.860 Sequential Writes File Blk Num Avg Identifier Size Size Thr Rate (CPU%) Latency ------------- ------ ----- --- ----- ------ ----- Athlon 1792 4096 1 20.65 11.17% 0.126 Opteron 4096 4096 1 28.15 10.78% 0.101 Athlon 1792 4096 2 22.15 26.81% 0.228 Opteron 4096 4096 2 22.69 14.23% 0.292 Athlon 1792 4096 4 22.97 29.67% 0.472 Opteron 4096 4096 4 20.04 14.44% 0.714 Athlon 1792 4096 8 21.87 27.93% 0.856 Opteron 4096 4096 8 13.42 11.03% 1.978 Random Writes File Blk Num Avg Identifier Size Size Thr Rate (CPU%) Latency ------------- ------ ----- --- ----- ------ ----- Athlon 1792 4096 1 0.60 0.234% 0.014 Opteron 4096 4096 1 0.47 0.121% 0.009 Athlon 1792 4096 2 0.59 0.479% 0.028 Opteron 4096 4096 2 0.50 0.159% 0.011 Athlon 1792 4096 4 0.64 0.542% 0.029 Opteron 4096 4096 4 0.49 0.155% 0.012 Athlon 1792 4096 8 0.68 0.558% 0.036 Opteron 4096 4096 8 0.50 0.192% 0.013
After receiving some feedback on our Web article series that discussed the ULB, we decided we needed to test noise levels. The ULB scored 50.5dBa at 10" in front of the case, 50.0dBa at the operator position (24" above the top of the case) and 60.0dBa at 10" from the back of the case. Obviously, these numbers aren't as low as we'd like them to be with the aforementioned Dell coming out at 47, 45 and 55dBa respectively. I think the culprit is the Thermaltake coolers; when we had the machine in-house previously with AMD coolers, it was quieter by far. However, the AMD version did get rather warm. The ULB version seems to be quite stable with respect to temperature, at the expense of extra noise. I suspect that between now and when this issue is on newsstands, companies such as Zalman and PC Power and Cooling will have offerings available for the Opteron like the ones they now have for noisy Athlons.
The Ultimate Linux Box, like Linux itself, is a work-in-progress. By the time you read this, new toys will be on the market, not to mention new software, maybe even a major kernel revision. The Escalade 8506 also will be available, as will newer, bigger Western Digital Raptors, DVD-plus-or-minus-RW combo drives—perhaps even an Athlon 64 CPU and motherboard. Use this design as a place to start and make your own improvements.
The author would like to thank 3ware, Western Digital, NVIDIA, Arima and SuSE for their contributions and Monarch Computer Systems for tying all the hardware together in one package and making it play.
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!
- Stunnel Security for Oracle
- SourceClear Open
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Google's SwiftShader Released
- Non-Linux FOSS: Caffeine!
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
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