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 systems architect; and the author of DevOps Troubleshooting, The Official Ubuntu Server Book, Knoppix Hacks, Knoppix Pocket Reference, Linux Multimedia Hacks, and Ubuntu Hacks.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Nice article, thanks for the
9 min 38 sec ago
- I once had a better way I
5 hours 55 min ago
- Not only you I too assumed
6 hours 13 min ago
- another very interesting
8 hours 6 min ago
- Reply to comment | Linux Journal
9 hours 59 min ago
- Reply to comment | Linux Journal
16 hours 53 min ago
- Reply to comment | Linux Journal
17 hours 9 min ago
- Favorite (and easily brute-forced) pw's
19 hours 57 sec ago
- Have you tried Boxen? It's a
1 day 52 min ago
- seo services in india
1 day 5 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?