My Move to Solid State
For the next test, I decided to time how long it took to extract the 2.6.22 kernel bzipped tarball. Now, because this tarball is bzipped, a good deal of the stress on the system will be on the CPU, not the disk. However, because most tarballs are compressed, and it is a pretty common desktop activity, I thought it was still worth comparing. The results weren't nearly as dramatic as the first two tests (due to the activity being mostly CPU-bound), but the SSD still beats the 4200rpm drive by 13 seconds:
4200rpm: 66 seconds
SSD: 53 seconds
Many laptop users (myself included) rarely boot and shut down their systems between uses. Instead, they rely on the hibernation and suspend features to save their current state and resume to it quickly. With hibernation, the laptop writes its current state to disk and powers off. With suspend, the laptop keeps its current state in RAM and stays on in a low-power state. Because the hibernation process is so disk-heavy, I decided it would be a good way to test whether an SSD gave any speed benefit. So, for the first test, I measured the time from enabling hibernation until the system powered off:
4200rpm: 75 seconds
SSD: 50 seconds
Again, before I saw the numbers, I didn't realize it had taken more than one minute 15 seconds to shut down and preserve my 1GB of RAM. Although the SSD still took some time, it beat the old drive by 25 seconds.
The follow-up to my hibernate test was to resume from the hibernation state. I started the clock once I pressed Enter at the GRUB prompt and stopped it once I got to the login window for my locked screen:
4200rpm: 83 seconds
SSD: 38 seconds
This result really surprised me. The SSD fared better than the 4200rpm drive when suspending to disk, but it was more than twice as fast when resuming! When you compare the combined tests, the 4200rpm drive takes 158 seconds to suspend and resume, and the SSD shortens the process down to 88 seconds.
Even though the everyday benchmarks were enough to convince me of the speed benefit of an SSD, I knew a lot of you also would want some raw data to compare. So, I also ran hdparm and bonnie++ on both drives with some interesting results. First, I ran hdparm three times in a row:
/dev/sda3: Timing cached reads: 1842 MB in 2.00 seconds = 921.90 MB/sec Timing buffered disk reads: 64 MB in 3.08 seconds = 20.79 MB/sec /dev/sda3: Timing cached reads: 1814 MB in 2.00 seconds = 907.56 MB/sec Timing buffered disk reads: 64 MB in 3.08 seconds = 20.78 MB/sec /dev/sda3: Timing cached reads: 1794 MB in 2.00 seconds = 897.43 MB/sec Timing buffered disk reads: 62 MB in 3.04 seconds = 20.39 MB/sec
/dev/sda: Timing cached reads: 1894 MB in 2.00 seconds = 947.80 MB/sec Timing buffered disk reads: 80 MB in 3.07 seconds = 26.02 MB/sec /dev/sda: Timing cached reads: 1894 MB in 2.00 seconds = 947.61 MB/sec Timing buffered disk reads: 80 MB in 3.08 seconds = 26.00 MB/sec /dev/sda: Timing cached reads: 1886 MB in 2.00 seconds = 943.86 MB/sec Timing buffered disk reads: 78 MB in 3.00 seconds = 25.99 MB/sec
As you can see, the SSD certainly is faster; however, there is not nearly as large a margin as with some of the other tests. The bonnie++ results show a different story:
------Sequential Output------ --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP 2G 11309 52 11272 3 4921 2 10715 44 11471 2 83.8 0 ------Sequential Create------ --------Random Create-------- -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 190 2 +++++ +++ 177 1 196 2 +++++ +++ 154 1 minimus,2G,11309,52,11272,3,4921,2,10715,44,11471,2,83.8,0,16,190, ↪2,+++++,+++,177,1,196,2,+++++,+++,154,1
------Sequential Output------ --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP 2G 18155 94 23125 8 12521 8 20818 94 28149 8 1226 5 ------Sequential Create------ --------Random Create-------- -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 1128 11 +++++ +++ 1101 10 1158 10 +++++ +++ 449 4 minimus,2G,18155,94,23125,8,12521,8,20818,94,28149,8,1226.4,5,16, ↪1128,11,+++++,+++,1101,10,1158,10,+++++,+++,449,4
Well, that's certainly a lot of data. A few numbers do stand out though. On sequential output and input, the SSD's performance is almost twice that of the 4200rpm drive, except in random seeks where it is actually 14 times faster with 1,226 seeks per second! Because there is no spinning platter, random seeks are one area where a solid state drive really shines. The next level of stats compares the speed of creating files on the system sequentially and at random. It is here that we see another huge advantage for the SSD, as it is five times faster at sequential creates, six times faster at sequential deletes and almost six times faster at random creates.
Kyle Rankin is a VP of engineering operations at Final, Inc., the author of a number of books including DevOps Troubleshooting and The Official Ubuntu Server Book, and is a columnist for Linux Journal. Follow him @kylerankin.
Practical Task Scheduling Deployment
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.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
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