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 director of engineering operations in the San Francisco Bay Area, the author of a number of books including DevOps Troubleshooting and The Official Ubuntu Server Book, and is a columnist for Linux Journal.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
|My Network Go-Bag||Aug 24, 2015|
|Doing Astronomy with Python||Aug 19, 2015|
|Build a “Virtual SuperComputer” with Process Virtualization||Aug 18, 2015|
|Firefox Security Exploit Targets Linux Users and Web Developers||Aug 17, 2015|
- Concerning Containers' Connections: on Docker Networking
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- My Network Go-Bag
- Firefox Security Exploit Targets Linux Users and Web Developers
- Doing Astronomy with Python
- A Project to Guarantee Better Security for Open-Source Projects
- Build a “Virtual SuperComputer” with Process Virtualization
- diff -u: What's New in Kernel Development
- Three More Lessons
- Calling All Linux Nerds!