The Quintessential Linux Benchmark
Some device drivers in the Linux kernel need timing delays. Either they need a very short delay, or the delay must be very accurately determined. A simple non-busy loop cannot do this. Therefore, Linus Torvalds added a calibration in the boot procedure to predetermine how often a specific busy-loop algorithm can be calculated in one second. This predetermined value, called loops_per_second, is used in the device drivers to delay for precisely measured times.
For fun, Linus also added a print statement presenting this predetermined value (divided by 500,000) as BogoMips. Linus apparently loves it when millions of Linux users are gazing at their computer, baffled by these bogus MIPS. Note that BogoMips have nothing to do with the million instructions per second that the name suggests; that is why they are bogus.
The only serious reason for paying attention to the BogoMips presented on booting Linux is to see whether it is in the proper range for the particular processor, its clock frequency, and the potentially present cache. 486 systems are especially prone to faulty setups of RAM caching, turbo-buttons, and such things.
People continuously ask on Usenet: “I have an XYZ CPU running at clock MHz. How many BogoMips should it do?” The answer can be calculated from the following table:
Intel/AMD 386SX clock * 0.14 (± 0.01) Intel/AMD 386DX clock * 0.18 (± 0.01) Cyrix/IBM 486 clock * 0.33 (± 0.04) Intel/AMD 486 clock * 0.50 (± 0.01) Pentium clock * 0.40 (± 0.01) 680x0 (insufficient data) PowerPC clock * 0.77 (± 0.02) Mips (insufficient data) Alpha clock * 0.99 (± 0.01)
From the above calculation we see several important points. First of all, the Intel and AMD 486 CPUs are not showing the same BogoMips as Cyrix and IBM 486 CPUs. This does not mean that they have a different perceived performance; it just means that they process the busy-loop algorithm differently.
The table also shows that the Pentium processor doesn't have the expected extrapolated multiplication factor. This is due to the fact that the specific busy-loop algorithm is not optimized for the parallelism of the Pentium processor.
The BogoMips calculations for the Motorola, PowerPC, Mips, and Alpha processors are similar to the Intel type processors calculations. Because the non-busy loop algorithm is coded in Assembler, however, they cannot be identical. It clearly shows that comparison of BogoMips between CPUs is really bogus, even between two different Intel type CPUs.
Last but not least, you see an allowed variation in the multiplication factor of about 0.01. The BogoMips calculation loop is “quantizised” (Linus's term), so it is likely that you will get exactly the same number all the time. Yet, if the speed is just on the edge, small variations, such as different lengths for interrupts, will cause your machine's BogoMips to vary.
“When I boot Linux I get the message:
Calibrating delay loop.. ok - 23.96 BogoMips failed
Where or why has the calibration delay loop failed?”
The obvious answer is that it didn't fail. If it had failed the text would have been:
Calibrating delay loop.. failed
What likely did fail was a driver for some gadget which may not be in the machine. The point is that just after calculating the BogoMips, all device drivers are initialized: first the SCSI devices, then Net devices, etc. Any failure in these initializations is duly reported. The AHA152x drive is noted for such failures. Other effects of failing drivers (and not of failing BogoMips calculations) are systems crashes, long waits, and complete system lock-ups.
Since Linux 1.2, many error messages have improved, so upgrade to at least that version to find out which particular driver is failing.
For people without Linux systems, or for those people who do not want to reboot their system time and again, a stand-alone program for calculating BogoMips is available in the standard archives (e.g., on sunsite.unc.edu in /pub/Linux/system/Status/bogo-1.2.tar.gz). On Linux, by default, it runs the same code that is used in the Linux kernel while booting, but runs as a user program. Note that due to system load, values calculated with the stand-alone program may be lower than expected for the CPU you are running, and lower than reported during boot. For the non-Linux systems, a portable C version is available that may run on any system that supports an ANSI C compiler and library.
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!
- Google's SwiftShader Released
- SUSE LLC's SUSE Manager
- Interview with Patrick Volkerding
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Tech Tip: Really Simple HTTP Server with Python
- 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