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.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Petros Koutoupis' RapidDisk
- ServersCheck's Thermal Imaging Camera Sensor
- The Italian Army Switches to LibreOffice
- Linux Mint 18
- Oracle vs. Google: Round 2
- The FBI and the Mozilla Foundation Lock Horns over Known Security Hole
- Varnish Software's Varnish Massive Storage Engine
- Privacy and the New Math
Until recently, IBM’s Power Platform was looked upon as being the system that hosted IBM’s flavor of UNIX and proprietary operating system called IBM i. These servers often are found in medium-size businesses running ERP, CRM and financials for on-premise customers. By enabling the Power platform to run the Linux OS, IBM now has positioned Power to be the platform of choice for those already running Linux that are facing scalability issues, especially customers looking at analytics, big data or cloud computing.
￼Running Linux on IBM’s Power hardware offers some obvious benefits, including improved processing speed and memory bandwidth, inherent security, and simpler deployment and management. But if you look beyond the impressive architecture, you’ll also find an open ecosystem that has given rise to a strong, innovative community, as well as an inventory of system and network management applications that really help leverage the benefits offered by running Linux on Power.Get the Guide