---------------------------------------------------------------------------- The Florida SunFlash When to Buy a Faster Computer SunFLASH Vol 27 #6 March 1991 ---------------------------------------------------------------------------- This is a short technical article written by Mike Loukides. It was provided by: Cindy Adelman O'Reilly & Associates, Inc. 90 Sherman Street Cambridge, MA 02140 617-354-5800 Thanks, Cindy! -johnj ________________________________________________________________ In these times, when clock rates seem to be increasing by 20 percent or more each year, it is always tempting to buy a faster computer. Out with the old and in with the new! Get rid of that 10 MHz 68000 and buy a 50 MHz machine with a fancy high-performance RISC architecture! Of course, if this were the only argument you listened to, you'd be buying more hardware every month. Most of us can't afford to buy new hardware every year, or even every other year. And furthermore, a higher clock rate and a more efficient architecture doesn't necessarily translate into better performance. Most computers don't spend most of their time computing: many spend the lion's share of their time doing I/O, coping with memory shortages, and so on. Buying a faster CPU won't help these problems, at least not substantially. Before you invest a lot of money in new equipment, you should find out whether or not your new equipment will do the job. It is altogether too common for someone to buy a faster computer only to discover that CPU speed wasn't the limiting factor at all. Disk, memory, or something else was preventing the old system from delivering its potential performance, and upgrading didn't help the situation at all. To find out whether you really need a new processor, you should first find out how much time your CPU is spending idle. Either wait until your system is under a heavy load, or run a benchmark that represents a typical workload. Then, if you are using a BSD UNIX system, give the command iostat 5 10. For System V, give the command sar -u 5 10. Both of these commands produce a series of 10 reports at 5-second intervals showing, among other things, the percentage of the last interval that the CPU was ideal. Here's a report from a Sun: los% iostat 5 tty sd0 cpu tin tout bps tps msps us ni sy id 3 7 0 0 0.0 1 0 0 99 3 7 43 6 0.0 5 0 5 90 0 18 35 4 0.0 94 0 3 3 0 52 17 2 0.0 94 0 6 0 0 31 17 2 0.0 98 0 2 0 0 37 57 7 0.0 96 0 4 0 0 41 14 2 0.0 98 0 2 0 0 23 10 1 0.0 71 0 3 26 0 7 3 0 0.0 1 0 7 92 3 7 0 0 0.0 1 0 0 99 Initially, the system was almost completely idle (reported in the id column: I was just editing a file. I then started a large nroff job, which took all (or most) of the CPU's attention. The idle time went to zero until nroff was finished. Virtually of the system's time was spend in the ``user state'' (us), although a little time was spent servicing system calls (sy). We can tell a number of things from this report: * If the idle time is zero, your computer system is basically healthy: it has enough memory and I/O capacity to handle this workload without delay. If your system was short of memory or I/O capacity, the idle time would be non-zero while the program was running. The system would be spending time waiting for disk operations to complete, either on behalf of the program itself, or because it is paging furiously trying to get enough memory to run your program. * If your idle time is non-zero when the system is under load, you have memory or I/O problems. Buying a faster CPU probably won't help you very much. Unless you also upgrade your memory and I/O subsystems, you'll see even more idle time, without any more throughput. * If your idle time is zero, the system is "CPU-bound": there is enough computation to occupy all of the CPU's time. Consequently, buying a faster CPU will help you to run your jobs faster. Whether or not this is important to you is something we will discuss below. In short, when I look at idle time, I ask the question "Is there anything (memory, I/O) that is getting in the way of complete CPU utilization?" I have seen several administrators, articles on administration, and even manuals that suggest that 100% CPU utilization means that your system is compute-bound and that you should buy something faster. Rubbish. All it means is that your system is working efficiently and that nothing is getting in the way of complete CPU utilization. Any job that requires a lot of processing (almost any kind of compilation or modelling) with relatively little I/O will be CPU-bound. And buying a faster CPU will make these jobs go faster. And when you run iostat, you'll still see 100% CPU utilization--you just won't see it for as long. To discover whether your system is really CPU-bound, you should be looking at the idle time over a much longer interval. You can make a good argument for a faster CPU if your system is chronically CPU-bound, even if you can live with the performance of any particular program. Try iostat 600 (for System V, sar -u 600 10), getting a report every 10 minutes. Or better yet, pick an interval that's several times the running time of your longest program. You already know that the CPU will be 0% idle while a compute-bound job is running. What you really want to know is: just how much of the time is a compute-bound job running? If the system is always running flat-out, if the idle time is 0% from 10 AM to 8 PM, you're a prime candidate for a faster CPU. When you try this experiment, be careful to interpret the results correctly. If idle time if 0% from 10 AM to 1 PM, and then suddenly rises to 30 or 40%, you're probably not seeing a mid-day dip in system usage. You're probably seeing an increase in usage that forced the system into paging. Check your memory statistics--that's another topic. Once you've gone through these gyrations, ask yourself the big question: "do you really care"? It is very important to be pragmatic about system usage. If a faster CPU means that it will take you 10 seconds to nroff a man page instead of 20, is it worth spending the money? Probably not, particularly since you can always run nroff in the background and do other useful work. If a faster CPU means that it will take you 10 hours to run a large financial model rather than 20, it probably is worth spending the money, though you may be happier if you wait another year and buy a system that will run the model in 6 hours. If a faster CPU means that your WYSIWYG editor will write a postscript file in 1 minute instead of 2 minutes, hold your system hostage in the meantime, a faster CPU may be worth the additional aggravation--but it may not. Here's another approach to the same issue. Pick your favorite compute-bound program. Run it under zero load and measure the elapsed time (``wall-clock time'') it requires. Then run it under a heavy load (say, at 2 PM): again, measure the elapsed time. What is the ratio of the two times? What kind of a ratio is acceptible to you, as the user? I've seen one manual that claims that the ``no-load'' and the ``heavy-load'' times should be within 10%. This strikes me as a good way to sell a lot of computers. But the principle is certainly valid. Looking at response times is often more effective than looking at abstract statistics, like the load average and the percentage of idle time. Decide what kind of performance degradation under load is tolerable. When your system no longer meets your requirement, think seriously about an upgrade. Nothing I've said is anything more than common-sense. But sexy new hardware and fast-talking sales reps can do a lot to subvert common sense. Sure, it's nice to have state-of-the-art hardware. And if you're going to upgrade, you should do it right. But don't upgrade until you really need to. If you can live with your system for another year or two, the state-of-the-art will be even better. Mike Loukides, is a member of the O'Reilly editorial staff. He previously worked at Multiflow Computer, where he created all of Multiflow's documentation on programming languages. He has a BS in Electrical Engineering and a PhD in English Literature. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ For information send mail to info-sunflash@sunvice.East.Sun.COM. Subscription requests should be sent to sunflash-request@sunvice.East.Sun.COM. Archives are on solar.nova.edu and paris.cs.miami.edu. All prices, availability, and other statements relating to Sun or third party products are valid in the U.S. only. Please contact your local Sales Representative for details of pricing and product availability in your region. Descriptions of, or references to products or publications within SunFlash does not imply an endorsement of that product or publication by Sun Microsystems. John McLaughlin, SunFlash editor, flash@sunvice.East.Sun.COM. (305) 776-7770.