How fast is your disk?
Submitted by admin on Tue, 2007-01-16 00:23
With a little bit of torturing, and some fun on the way, find out how fast your hard disk drive really is.
Introduction
1-Terabyte hard disk drives are slowly coming to the market, so I suppose we can't complain that we don't have enough space to save (the ever increasing amount of) our precious data. But, it's also a known fact that although disk storage capacities are improving at an impressive rate, disk performance improvements are occurring at a rather slower rate. Unfortunately, larger disk doesn't always mean faster disk. What follows is an explanation of two techniques for measuring disk performance in Linux.
Methodology
As an example, I've tested three different disks, one standard ATA (IDE) drive, and two SCSI disks with different rotational speed:
Disk 1: ATA 120GB, Seagate Barracuda 7200.7 Plus (ST3120026A), 8MB cache, 7200 rpm
Disk 2: SCSI 36GB, Seagate Cheetah 10K.6 (ST336607LC), 8MB cache, 10000 rpm
Disk 3: SCSI 18GB, IBM Ultrastar 36Z15 (IC35L018UCPR15-0), 4MB cache, 15000 rpm
IMPORTANT! When running the below explained benchmarks, your disk should be as idle as possible. Otherwise, you'll get wrong (worse) numbers. Don't run any other disk intensive program at the same time when you are running benchmarks. And, BTW, don't worry about your data, both benchmarks are only reading from disk, meaning, they're not destructive.
Sequential access
Sequential access is when you're reading or writing disk blocks in sequential order, that is, one block after another. Rarely will you do exactly that (unless you're copying raw partitions, of course), but every time you're moving big files (for example ISO images) around, your disk access pattern comes close to sequential access. This is also where your disk truly shines, because disk head movement is minimal, so you can get high disk transfer speeds.
Measuring sequential disk performance is easy, every modern Linux distribution comes with a little tool called hdparm, which is primarily used to tune and optimize disk parameters, but also has a switch to use it as a simple benchmark tool. Run it like this:
% sudo hdparm -t /dev/hda
/dev/hda:
Timing buffered disk reads: 140 MB in 3.02 seconds = 46.28 MB/sec
Substitute /dev/hda with the name of your raw disk device, of course (for example, it might be /dev/sda if you're using libata, or something else).
It's impossible to get higher transfer rate from the disk than that (but on that particular disk, computer, and if disk is setup optimally!). hdparm -t is reading the very start of the disk (which is the fastest area of every disk) and with an optimal access pattern. You can't beat that!
Let's see what our test disks are made of:
While there is some fluctuation, I wouldn't say that there are big differences among the disks. But, you probably noticed that the supposedly fastest 15000 rpm disk is slower than the other two. That's because it's a quite old disk (from 2002). So there was some improvement in disk transfer speeds through time, after all, but nothing groundbreaking.
Random access
Random access is where you access your disk at random. In that case the disk head moves rapidly from one place to another. Because that involves mechanical operation, this type of access is much slower than sequential access. Unfortunately, many real world workloads involve access patterns that are much closer to random access than sequential access. That's why I think it's much more interesting to measure and see how disk behaves under random access pattern, than sequential.
There's no standard tool to measure the random access time, so I have written a simple utility that you can find attached at the bottom of this article. I've named it seeker and it has a simple job: to read small pieces of data from a raw disk device, in a random access pattern. It is important to run it on the whole disk (not on a single partition!) if you want to compare results of your disk with others!
Compile the utility like this:
% gcc -O2 seeker.c -o seeker
or if you're lazy or don't have compiler at hand, you can also download the binary below. Then run it like this:
% sudo seeker /dev/hda
Just like hdparm, it needs superuser privileges to access the raw disk device. The output looks like this:
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [17501MB], wait 30 seconds..............................
Results: 167 seeks/second, 5.95 ms random access time
Allow seeker to run for 30 seconds (you might hear some ugly noises if your disk doesn't have so called acoustic management capability or if it's not turned on), and you'll get the average number of seeks per second, and calculated random access time of the disk. Now, the utility reads only 512 bytes of data per one read operation, but internal kernel readahead mechanisms translate that to 4096 byte I/O operations. Multiplying 167 with 4096, you can estimate that disk is reading only 668 KB/sec (or you can use iostat utility to monitor that in realtime). And that is true, this is the absolute worst case scenario, and your disk should always perform better than that, in every real scenario. But, compare that with the numbers we got from the sequential case, and you'll see how rapidly disk performance degraded when the disk arm started moving!
Finally we see some difference among disks, it's now obvious that disks that are rotating faster are better performers. 15000 rpm SCSI is now on top, it doesn't matter it's so old, it leaves the ATA drive far behind.
The above numbers are actually the same data presented in another way. Random access time is a metric that represents the typical time it takes disk to go read a random block. If you have disk manufacturers data with you, that time should be close to the sum of the manufacturers average seek time and average latency time. They declare average seek time as a typical time to move head arm from one position to another, and average latency time is time needed for wanted data block to come below the head (disk is constantly rotating, right?). Is the calculation right for your disk?
Conclusion
If you have some older and some newer disk, and run the above tests on them, you'll soon discover that hard disk performance hasn't improved much over time. The bigger cache on modern disks helps a little bit, but only on some specific workloads. But, don't listen to everything I say, run your own tests and report results as a comment below. If we get enough results, I could even summarize them in a useful graph. And, I would really really love to see the numbers for those Western Digital Raptors, is their performance really comparable to the expensive SCSI drives?
Related:
iostat - Linux I/O performance monitoring utility
| Attachment | Size |
|---|---|
| seeker | 5.45 KB |
| seeker.c | 1.54 KB |
»
- Add new comment
- 122043 reads
MTRON 7500 32gb
finally here's some results for my mtron 7500 ssd @ ich9:
/dev/sda:
Timing buffered disk reads: 366 MB in 3.01 seconds = 121.75 MB/sec
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [30520MB], wait 30 seconds..............................
Results: 11675 seeks/second, 0.09 ms random access time
it's sustained reads might not be the highest available, but the very short access times and sustained writes of around 115 MB/s make it a delight to use. for comparison my "old" samsung spinpoint f1 (320gb)
/dev/sdb:
Timing buffered disk reads: 208 MB in 3.00 seconds = 69.25 MB/sec
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sdb [305245MB], wait 30 seconds..............................
Results: 74 seeks/second, 13.37 ms random access time
something's fishy here with the reads...it used to score some 90s before, i'm gonna look into that.
last but not least - ram (patriot pc6400)
/dev/ram0:
Timing buffered disk reads: 64 MB in 0.04 seconds = 1820.35 MB/sec
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/ram0 [64MB], wait 30 seconds..............................
Results: 1393078 seeks/second, 0.00 ms random access time
Laptop with $109 Solid State 32gb Flash Drive
I got it from http://transcendstore.com/ts32gssd25s-m.html...what a disk! It beats everyone, even though it's speed may not be quite the same, as it's in a laptop, and it allows me 50% more battery life with faster speed than most sata laptop drives, anyway...
/dev/sda:
Timing buffered disk reads: 380 MB in 3.01 seconds = 126.28 MB/sec
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [28832MB], wait 30 seconds..............................
Results: 2371 seeks/second, 0.42 ms random access time
When I put Archlinux back on the thing with partimage, it copied back to the disk at over 1Gb per second.
Fusion IO Drive
O. M. G.
hdparm -t /dev/fioa1 && ./seeker /dev/fioa1
/dev/fioa1:
Timing buffered disk reads: 872 MB in 3.00 seconds = 290.54 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/fioa1 [76567MB], wait 30 seconds..............................
Results: 33941 seeks/second, 0.03 ms random access time
:O
I also ran the two copies of the seeker program at once -- both reported back ~ 23,000 seeks/second.
And the ram on this machine:
hdparm -t /dev/ram0 && ./seeker /dev/ram0
/dev/ram0:
Timing buffered disk reads: 16 MB in 0.01 seconds = 1239.83 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/ram0 [16MB], wait 30 seconds..............................
Results: 1244751 seeks/second, 0.00 ms random access time
Wow. Just. Wow.
And, of course, the dink 120gb HD...
hdparm -t /dev/sda1 && ./seeker /dev/sda1
/dev/sda1:
Timing buffered disk reads: 248 MB in 3.01 seconds = 82.43 MB/sec
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda1 [135085MB], wait 30 seconds..............................
Results: 124 seeks/second, 8.01 ms random access time
Fusion IOdrive 80GB
/sbin/hdparm -tT /dev/fioa
/dev/fioa:
Timing cached reads: 14532 MB in 2.00 seconds = 7280.21 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device
Timing buffered disk reads: 1330 MB in 3.00 seconds = 443.15 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/fioa [76569MB], wait 30 seconds..............................
Results: 29592 seeks/second, 0.03 ms random access time
File vs. Raw IO on Fusion IOdrive - Jaw dropping!
A couple dd read tests on files and raw devs. My box has 4Gb of memory so I use a 4Gb file to hopefully defeat the buffer cache.
File IO ( IOdrive )
dd if=dvd.iso of=/dev/null bs=1M count=4000
4000+0 records in
4000+0 records out
4194304000 bytes (4.2 GB) copied, 5.29184 seconds, 793 MB/s
Raw dev IO ( IOdrive )
dd if=/dev/fioa of=/dev/null bs=1M count=4000
4000+0 records in
4000+0 records out
4194304000 bytes (4.2 GB) copied, 8.57171 seconds, 489 MB/s
I'm amazed to see a file read run faster than a raw device read. I'm guessing that the raw device doesn't get any readahead benefits.
Same tests on a SATA drive.
File IO ( SATA )
dd if=/tmp/dvd.iso of=/dev/null bs=1M count=4000
4000+0 records in
4000+0 records out
4194304000 bytes (4.2 GB) copied, 65.7586 seconds, 63.8 MB/s
Raw dev IO ( SATA )
dd if=/dev/sda2 of=/dev/null bs=1M count=4000
4000+0 records in
4000+0 records out
4194304000 bytes (4.2 GB) copied, 59.9944 seconds, 69.9 MB/s
Here's a doc on some read ahead code at ACM.
On the design of a new Linux readahead framework
ouch
these are fairly nice results...i'm pretty eager to get my hands on those fusion io drives.
can you tell me when you got that drive and if it already supports booting from? did you run any real life benchmarks on it yet, like copying of a large number of small files from one directory to another, startup and running applications off it etc?
answers are VERY VERY MUCH appreciated!!!
cheers,
roots
> these are fairly nice
> these are fairly nice results...i'm pretty eager to get my hands on those fusion io drives.
Found elsewhere on the web, Fusion IO seems to cost around $2400, so it's quite expensive. bitbucket, would you be so kind to reveal us the exact price you paid for the drive?
But, must admit myself, a fantastic technology!
>Found elsewhere on the web,
>Found elsewhere on the web, Fusion IO seems to cost around $2400, so it's quite >expensive. bitbucket, would you be so kind to reveal us the exact price you paid for >the drive?
it's very likely that he paid exactly those 2.4k USD, because in a reply to an email request i sent a week ago, i/o staff told me that atm the drives are only available directly from them at that given price. however, as they stated they currently seem to be setting up international resellers.
Re: ouch
Copied /usr to the iodrive then copy that on the iodrive.
$ time cp -r usrdir usrdir2
real 0m18.195s
user 0m0.793s
sys 0m10.915s
$ du -s usrdir
2682140 usrdir ....... 2.68 Gb
$ find usrdir2 -print | wc -l
203018 ........ 203K files & directories
vmstat peaked at about 420K bi+bo/sec
I've found that benchmark results are subject to ALOT of variables. I watched vmstat while running iozone. NOT ONE read request was made from the device being tested. Iozone uses a single data file in auto mode
so ALL the reads were satisfied from the buffer cache ( 1G file ). You have to crank up the file sizes in alot of the benchmarks and then you're really just playing a numbers game on your cache hit ratio instead of measuring the raw speed of the device.
I got the drive a couple weeks ago and don't have any word on when it will be purely bootable. I heard of someone running /root off the iodrive but still needs /boot on the spindle. That's not a concern for me right now, the OS files and such get a tiny fraction of IOs compared to hot apps running on the iodrive.
did i get you right about
did i get you right about the iodrive having a 1gig buffer?! still, the transfer rate is impressive, my mtron 7.5k is doing something like 25% of that for a like-sized directory.
could you do me another big favour and run tiotest for a look at multi-threaded i/o?!
tiotest -t 8 -f 1024 /dev/younameit
tiotest -t 8 -f 224 -r 500 -b 4096 /dev/younameit -TTT
btw., what file system and i/o scheduler are you using on the io? i found that using noop scheduler instead of cfq on my ssd will give me a plus of about 10..15% on both synthetic and real-world performance.
BIG cheers in advance,
roots.
Follow up with -Tt
hdparm -Tt /dev/fioa1
/dev/fioa1:
Timing cached reads: 19420 MB in 2.00 seconds = 9725.68 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device
Timing buffered disk reads: 868 MB in 3.00 seconds = 288.86 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device
:D
SAMSUNG Spinpoint F1 1TB (HD103UJ)
The honorable (for a single desktop class drive) read results...
plut@ubuntubox:~$ sudo hdparm -tT /dev/sda
/dev/sda:
Timing cached reads: 13146 MB in 2.00 seconds = 6581.02 MB/sec
Timing buffered disk reads: 296 MB in 3.02 seconds = 98.11 MB/sec
And the slightly less impressive access time...
plut@ubuntubox:~$ sudo ./seeker /dev/sda
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [953869MB], wait 30 seconds..............................
Results: 56 seeks/second, 17.73 ms random access time
Western Digital VelociRaptor WD3000GLFS-0
hdparm -Tt /dev/sda
/dev/sda:
Timing cached reads: 3496 MB in 2.00 seconds = 1747.81 MB/sec
Timing buffered disk reads: 356 MB in 3.02 seconds = 117.84 MB/sec
seeker
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [286168MB], wait 30 seconds..............................
Results: 138 seeks/second, 7.22 ms random access time
Wow, this is one helluva
Wow, this is one helluva disk for home setups and it damn sure is pretty fast. Thanks for the contribution, I was wondering what this baby can do.
Fujitsu MAU3073NC SCSI 15K RPM 73GB Performance
Fujitsu MAU3073NC 73GB 15K RPM Drive (I got this drive for 25 Euro. I think it's best Performance/Price someone can get :) )
./seeker /dev/sdb
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sdb [70136MB], wait 30 seconds..............................
Results: 173 seeks/second, 5.76 ms random access time
hdparm -tT /dev/sdb
/dev/sdb:
Timing cached reads: 448 MB in 2.00 seconds = 223.80 MB/sec
Timing buffered disk reads: 272 MB in 3.02 seconds = 90.19 MB/sec
Yes, it's definitely a fast
Yes, it's definitely a fast disk. But, notice how the number of seeks your disk is capable of is practically the same as the older 15k disk could do. So it's a mechanical limit. And I believe we'll never see faster mechanical disks. At least I haven't heard that anybody is planning to produce 20k rpm disk or similar. SSD's are definitely the future.
Of course, if you make a small partition on your disk, it would be much faster than a partition on a smaller disk. Less head excursion. 90 MB/sec sequential is also nice...
5x Raid-5 Compaq 18.2Gb Scsi-3 15K
This is on an older Compaq DL380 G3 w/3Gb Ram using integrated SCSI 5i controller on Centos 5.2. The old gal is still hanging in there reasonably well:
hdparm -tT /dev/cciss/c0d0 && ./seeker /dev/cciss/c0d0
Timing cached reads: 1844 MB in 2.00 seconds = 921.95 MB/sec
Timing buffered disk reads: 258 MB in 3.00 seconds = 86.00 MB/sec
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Results: 158 seeks/second, 6.30 ms random access time
12x1TB seagate raid5
12x1TB seagate raid5 (ARC-1231ML):
sabayonx86-64 ~ # hdparm -Tt /dev/sdc
/dev/sdc:
Timing cached reads: 7214 MB in 2.00 seconds = 3609.42 MB/sec
Timing buffered disk reads: 2176 MB in 3.00 seconds = 724.80 MB/sec
sabayonx86-64 ~ # ./seeker /dev/sdc
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sdc [10390278MB], wait 30 secondslseek64: Invalid argument
sabayonx86-64 ~ # ./seekerNAT /dev/sdc
Seeker v2.0(Nat1), 2007-12-18, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sdc [21279289856 blocks, 10894996406272 bytes, 10894 GiB], wait 30 seconds
.............................
Results: 79 seeks/second, 12.53 ms random access time (9475314811 < offsets < 10894731941220)
This oddly gives me much worse results than running seeker on one of my other 'virtual' drives on the same raid array:
sabayonx86-64 ~ # ./seekerNAT /dev/sdb
Seeker v2.0(Nat1), 2007-12-18, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sdb [41012224 blocks, 20998258688 bytes, 20 GiB], wait 30 seconds
..............................
Results: 151 seeks/second, 6.60 ms random access time (1762263 < offsets < 20996880028)
These results pretty much match up with what I get running regular seeker:
sabayonx86-64 ~ # ./seeker /dev/sdb
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sdb [20025MB], wait 30 seconds..............................
Results: 153 seeks/second, 6.51 ms random access time
Does the large size slow down the program for some reason? I don't see why since all 3 virtual drives I have are the same speed when testing them with other programs.
1 x mtron ssd mobi 3000 32 GB SATA on Ubuntu 8.04 (no raid)
$ sudo hdparm -tT /dev/sda
/dev/sda:
Timing cached reads: 1520 MB in 2.00 seconds = 759.60 MB/sec
Timing buffered disk reads: 212 MB in 3.02 seconds = 70.29 MB/sec
$ sudo ./seeker /dev/sda
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [30520MB], wait 30 seconds..............................
Results: 5216 seeks/second, 0.19 ms random access time
yeah boyeeeeeee!!! the crazy thing is that the disk states that it is capable of 100 MB/s, but i guess the current driver(s) only allow for around 70 MB/s rw. it's a well known ICH cap (my motherboard controller is ICH version 8).
Nice page btw, thanks =)
Cheers,
Nick
My result for 10K SCSI drives...
sda: SEAGATE ST336607LC 36GB 10K
sdb: ModusLnk MXJ3073SC800600X (Fujitsu MAT3073NC) 73.5GB 10K
Both drives tested in SGI 1200 server (Dual P3-700)
cat /proc/scsi/aic7xxx/0
Adaptec AIC7xxx driver version: 7.0
Adaptec aic7896/97 Ultra2 SCSI adapter
aic7896/97: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs
Allocated SCBs: 12, SG List Length: 128
Linux: Debian etch 2.6.18-5-xen-686
Tests made in XEN Dom0...
hdparm -tT /dev/sda
/dev/sda:
Timing cached reads: 308 MB in 2.00 seconds = 153.93 MB/sec
Timing buffered disk reads: 158 MB in 3.03 seconds = 52.21 MB/sec
hdparm -tT /dev/sdb
/dev/sdb:
Timing cached reads: 308 MB in 2.01 seconds = 153.45 MB/sec
Timing buffered disk reads: 194 MB in 3.03 seconds = 64.08 MB/sec
seeker /dev/sda
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [34732MB], wait 30 seconds..............................
Results: 124 seeks/second, 8.03 ms random access time
seeker /dev/sdb
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sdb [70136MB], wait 30 seconds..............................
Results: 128 seeks/second, 7.77 ms random access time
Solid State and Some interesting SD results
I found this article when looking for something to test disk throughput on my laptop - Dell XPS M1330. It's equipped with a 32GB SSD and was interested to see what the results were like:
Devices
/dev/sda1 - 32GB SATA Solid State Drive
/dev/sdb1 - 500GB USB 2.0 My Book Pro
/dev/mmcblk2p1 - 4 GB SD Sandisk Extreme III in internal reader
/dev/sdc1 - same 4gb SDHC Sandisk Extreme III in San Disk Micromate reader
Commands run
hdparm -t /dev/...
seeker /dev/...
time dd if=/dev/urandom of=/path/to/1GiB_file bs=1M count=1024
sda1
Timing buffered disk reads: 172 MB in 3.19 seconds = 53.94 MB/sec
Results: 87292 seeks/second, 0.01 ms random access time
1073741824 bytes (1.1 GB) copied, 188.558 seconds, 5.7 MB/s
real 3m8.561s
user 0m0.004s
sdb1
Timing buffered disk reads: 82 MB in 3.01 seconds = 27.23 MB/sec
Results: 67 seeks/second, 14.92 ms random access time
1073741824 bytes (1.1 GB) copied, 195.283 seconds, 5.5 MB/s
real 3m20.531s
user 0m0.004s
mmcblk2p1
Timing buffered disk reads: 4 MB in 3.88 seconds = 1.03 MB/sec
Results: 356 seeks/second, 2.80 ms random access time
1073741824 bytes (1.1 GB) copied, 293.407 seconds, 3.7 MB/s
real 4m53.413s
user 0m0.004s
sdc1
Timing buffered disk reads: 48 MB in 3.04 seconds = 15.77 MB/sec
Results: 673 seeks/second, 1.48 ms random access time
1073741824 bytes (1.1 GB) copied, 187.927 seconds, 5.7 MB/s
real 3m7.932s
user 0m0.004s
sys 3m1.571s
As you can see, the SSD has insane seek times but that's to be expected. Interestingly enough the external USB 2.0 SD card Reader performed better than the internal reader and both performed badly in the write and read tests.
I was hoping that the SD card could be levered as some kind of caching device but it looks like the throughput is simply to far down on the HDD / SSD to bother.
dd test flawed
RobDudley,
Your dd test is flawed. By using /dev/urandom, you are asking the system to do a difficult calculation for just raw data. This is most likely the cause of all write delays, not the disk. You'd be better off to try /dev/zero. Even then, you'll have some system/cpu load. You can try these two tests if you want to verify this:
time dd if=/dev/zero of=/dev/null bs=1M count=1024
time dd if=/dev/urandom of=/dev/null bs=1M count=1024
my stats
-------------------------------------
Debian Etch, 2.6.18
Areca ARC-1110 controller
4 Western Digital 500 GB SATA, RAID 5
-------------------------------------
hdparm -Tt /dev/sda
Timing cached reads: 2476 MB in 2.00 seconds = 1238.85 MB/sec
Timing buffered disk reads: 618 MB in 3.01 seconds = 205.35 MB/sec
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [1430511MB], wait 30 seconds..............................
Results: 73 seeks/second, 13.53 ms random access time
-------------------------------------
same hardware, but testing against LVM volume
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/vg1/vm-storage [10240MB], wait 30 seconds..............................
Results: 137 seeks/second, 7.28 ms random access time
Interesting.. Running the test against the LVM volume on the same hardware really improved the seek times..
SAMSUNG SP1604N
hdparm -Tt /dev/sda
Timing cached reads: 610 MB in 2.00 seconds = 304.94 MB/sec
Timing buffered disk reads: 178 MB in 3.02 seconds = 58.99 MB/sec
/tmp/seeker /dev/sda
Results: 58 seeks/second, 17.21 ms random access time
Random access time is too slow, dont know why, all settings should be ok. Manufacturer promise is better: Samsung's SP1604N is a 160 GB ATA/133 hard drive, with a 2 MB buffer and rotating at 7,200 rpm. Access time: 8.9 ms
ST3120023A WD2500JB-00GVA0
ST3120023A: 15.56 ms random access time
WD2500JB-00GVA0: 20.11 ms random access time
IC25N040ATMR04-0: 20.62 ms random access time
For > 2TB devices
Here is a patch (mainly for running it on a 2.4 TB RAID):
--- seeker.c 2007-08-25 23:48:06.000000000 +0200
+++ seekerNat.c 2007-12-18 02:31:52.000000000 +0100
@@ -16,6 +16,9 @@
int count;
time_t start;
+off64_t maxoffset=0;
+off64_t minoffset=249994674176000;
+
void done()
{
time_t end;
@@ -29,8 +32,8 @@
}
if (count) {
- printf(".\nResults: %d seeks/second, %.2f ms random access time\n",
- count / TIMEOUT, 1000.0 * TIMEOUT / count);
+ printf(".\nResults: %d seeks/second, %.2f ms random access time (%lu < offsets < %lu)\n",
+ count / TIMEOUT, 1000.0 * TIMEOUT / count, minoffset, maxoffset);
}
exit(EXIT_SUCCESS);
}
@@ -47,12 +50,12 @@
{
char buffer[BLOCKSIZE];
int fd, retval;
- unsigned long numblocks;
+ unsigned long numblocks, numbytes;
off64_t offset;
setvbuf(stdout, NULL, _IONBF, 0);
- printf("Seeker v2.0, 2007-01-15, "
+ printf("Seeker v2.0(Nat1), 2007-12-18, "
"http://www.linuxinsight.com/how_fast_is_your_disk.html\n");
if (argc != 2) {
@@ -60,13 +63,14 @@
exit(EXIT_SUCCESS);
}
- fd = open(argv[1], O_RDONLY);
+ fd = open(argv[1], O_RDONLY | O_LARGEFILE);
handle("open", fd < 0);
retval = ioctl(fd, BLKGETSIZE, &numblocks);
handle("ioctl", retval == -1);
- printf("Benchmarking %s [%luMB], wait %d seconds",
- argv[1], numblocks / 2048, TIMEOUT);
+ numbytes=numblocks*BLOCKSIZE;
+ printf("Benchmarking %s [%lu blocks, %lu bytes, %lu GiB], wait %d seconds\n",
+ argv[1], numblocks, numbytes, numbytes/1000000000L, TIMEOUT);
time(&start);
srand(start);
@@ -74,12 +78,21 @@
alarm(1);
for (;;) {
- offset = (off64_t) numblocks * random() / RAND_MAX;
- retval = lseek64(fd, BLOCKSIZE * offset, SEEK_SET);
+ offset = (off64_t) ( (unsigned long) numbytes * (random() / (RAND_MAX + 1.0) ));
+ //printf("DEBUG: go %lu\n", offset);
+ retval = lseek64(fd, offset, SEEK_SET);
handle("lseek64", retval == (off64_t) -1);
retval = read(fd, buffer, BLOCKSIZE);
handle("read", retval < 0);
count++;
+ if (offset>maxoffset)
+ {
+ maxoffset=offset;
+ }
+ else if(offset
Re: For > 2TB devices
Nat, care to post the rest of that patch? The bottom was clipped.
Disk information using smartctl
Lot of disk details can be collected from smartctl (like speed rpm, temperature, errors etc)
More information on : http://unixfoo.blogspot.com/2007/11/disk-information-using-smartctl.html
no-name compact flash in ide-cf adapter
Benchmarking /dev/hda [3871MB], wait 30 seconds..............................
Results: 1054 seeks/second, 0.95 ms random access time
Timing buffered disk reads: 44 MB in 3.09 seconds = 14.25 MB/sec
SATA/IDE/SCSI :-)
WDC WD5000AAKS-00TMA0 (SATA-150, 500GB, 16MB CACHE, 7200RPM)
# hdparm -t /dev/sda && seeker /dev/sda
/dev/sda:
Timing buffered disk reads: 218 MB in 3.01 seconds = 72.40 MB/sec
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [476940MB], wait 30 seconds..............................
Results: 76 seeks/second, 13.07 ms random access time
ST3500630A (IDE UDMA100, 500GB, 16MB CACHE, 7200RPM)
# hdparm -t /dev/hde && seeker /dev/hde
/dev/hde:
Timing buffered disk reads: 232 MB in 3.01 seconds = 76.98 MB/sec
Benchmarking /dev/hde [476940MB], wait 30 seconds..............................
Results: 68 seeks/second, 14.56 ms random access time
SEAGATE ST318452LW (ULTRA-3 SCSI, 16GB, 8MB CACHE, 15000RPM)
# hdparm -t /dev/sdg && seeker /dev/sdg
/dev/sdg:
Timing buffered disk reads: 174 MB in 3.02 seconds = 57.59 MB/sec
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sdg [17501MB], wait 30 seconds..............................
Results: 165 seeks/second, 6.03 ms random access time
Equallogic PS100e
This is on a Equallogic PS100e (14 SATA disks in RAID 50) over iSCSI and 1gbit LAN.
Benchmarking /dev/sdb [204810MB], wait 30 seconds..............................
Results: 319 seeks/second, 3.13 ms random access time
Seems to be the fastest so far, excluding flash based storage of course.
And this one is with 2x WD Raptor 74GB 10.000rpm SATA (latest version) in 3Ware RAID0.
Benchmarking /dev/sda1 [139227MB], wait 30 seconds..............................
Results: 115 seeks/second, 8.68 ms random access time
Final result on Equallogic
Ok, final result for today. The array was still building in the previous results. This are the results after the build was complete.
Again, 10 instances at the same time.
Results: 728 seeks/second, 1.37 ms random access time
Results: 739 seeks/second, 1.35 ms random access time
Results: 722 seeks/second, 1.38 ms random access time
Results: 715 seeks/second, 1.40 ms random access time
Results: 695 seeks/second, 1.44 ms random access time
Results: 703 seeks/second, 1.42 ms random access time
Results: 691 seeks/second, 1.45 ms random access time
Results: 715 seeks/second, 1.40 ms random access time
Results: 700 seeks/second, 1.43 ms random access time
Results: 727 seeks/second, 1.37 ms random access time
Best result for a single instance is:
Results: 824 seeks/second, 1.21 ms random access time
More testing with Equallogic
I did some more tuning on the Equallogic and tested with 10 seeker instances at the same time. Same setup as above.
Results: 359 seeks/second, 2.78 ms random access time
Results: 369 seeks/second, 2.71 ms random access time
Results: 364 seeks/second, 2.75 ms random access time
Results: 387 seeks/second, 2.58 ms random access time
Results: 377 seeks/second, 2.65 ms random access time
Results: 383 seeks/second, 2.61 ms random access time
Results: 368 seeks/second, 2.71 ms random access time
Results: 362 seeks/second, 2.76 ms random access time
Results: 364 seeks/second, 2.74 ms random access time
Results: 378 seeks/second, 2.64 ms random access time
This is still over 1gbit and not an ideal network setup. I will test some more the coming weeks with Cisco switches and better network cards.
Just for fun, the new db
Just for fun, the new db server I'm building.
6 drive raid 10, Fujitsu max 15k 73gb SAS, Lsi Megaraid card.
sudo hdparm -tT /dev/sdc
/dev/sdc:
Timing cached reads: 4602 MB in 2.00 seconds = 2303.12 MB/sec
Timing buffered disk reads: 806 MB in 3.00 seconds = 268.53 MB/sec
and 10x seeker:
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sdc [208854MB], wait 30 seconds..............................
Results: 148 seeks/second, 6.75 ms random access time
Results: 148 seeks/second, 6.73 ms random access time
Results: 150 seeks/second, 6.65 ms random access time
Results: 142 seeks/second, 7.00 ms random access time
Results: 146 seeks/second, 6.85 ms random access time
Results: 144 seeks/second, 6.93 ms random access time
Results: 145 seeks/second, 6.87 ms random access time
Results: 147 seeks/second, 6.77 ms random access time
Results: 145 seeks/second, 6.89 ms random access time
Results: 148 seeks/second, 6.72 ms random access time
Results: 151 seeks/second, 6.61 ms random access time
for ~ 1500 seeks/sec.
That a little higher than bonnie for this setup, I was seeing 800-1200 seeks/second there, and about 200 megs/sec continuous read. Bonnie can't do random access fast enough in a single process, so I've got to start more than one.
Noname brand 16GB cf & Seagate 750GB
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sdd [15487MB], wait 30 seconds.............................
Results: 622 seeks/second, 1.61 ms random access time
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sdc [715403MB], wait 30 seconds..............................
Results: 69 seeks/second, 14.31 ms random access time
Looks like i'm the only one getting good speeds w` cf
Random write speeds would be much worse
You're getting quite good results because you're only reading. SSD's are slow when it comes to random small writes. The theory is: every time you change even a single bit of data, SSD must first erase quite a big block of memory, and then write original contents back, with that bit changed of course. It's so slow at that, that modern SATA disks (like your Seagate, for example) are faster, go figure.
Hopefully, write times will improve as the technology matures...
Big thanks for Tool and all
Big thanks for Tool and all the Information!
Here is what im able to add.
Hitachi HDT72503
bash-3.2# hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 206 MB in 3.00 seconds = 68.60 MB/sec
bash-3.2# hdparm -t /dev/sda1 (ext2)
/dev/sda1:
Timing buffered disk reads: 100 MB in 1.38 seconds = 72.39 MB/sec
bash-3.2# ./seeker /dev/sda
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [305245MB], wait 30 seconds..............................
Results: 77 seeks/second, 12.98 ms random access time
USB2 HDD SAMSUNG MP0804H
bash-3.2# hdparm -t /dev/sdc
/dev/sdc:
Timing buffered disk reads: 74 MB in 3.06 seconds = 24.15 MB/sec(shouldnt it be a bit more?)
bash-3.2# ./seeker /dev/sdc
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sdc [76319MB], wait 30 seconds.............................
Results: 43 seeks/second, 22.78 ms random access time
And for fun 1g Single Channel DDR2 @ 744MHZ
hdparm -t /dev/ram0
/dev/ram0:
Timing buffered disk reads: 4 MB in 0.00 seconds = 897.06 MB/sec
./seeker /dev/ram0
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/ram0 [4MB], wait 30 seconds..............................
Results: 745647 seeks/second, 0.00 ms random access time
:D
Amazon EC2
I was playing around with a EC2 instance, and I got this great idea that I should benchmark the disk subsystem. I had expected pretty standard performance for the disk at /mnt, but I was wrong:
Benchmarking /dev/sda1 [1537MB], wait 30 seconds
Results: 1014 seeks/second, 0.99 ms random access time
Benchmarking /dev/sda2 [152704MB], wait 30 seconds
Results: 4494 seeks/second, 0.22 ms random access time
Thats pretty damn fast. To get this sort of performance out of a RAID-5 set I think you need a hole lot of disks, maybe 20 or so? It sure as hell beats any disk I have at home with a factor of about between 15 and 60.
I don't know if this could be a Xen problem with this particular benchmark, but if it is true I actually just found a use for EC2: to run my DB-intensive information extraction jobs on. Though they are still most likely better solved by just buying a new machine with 4 or 8GB of RAM. It is pretty cheap now.
I believe amazon does some
I believe amazon does some lazy-allocation - until you write to a sector, the host will mask it out with zeros in software to avoid leaking information from a previous user. Try overwriting the entire partition before doing the benchmark, you'll probably get more realistic results.
Note also that EC2's transient storage is not S3-backed, and EBS uses S3 for offline/backup storage only. It would be interesting to compare performance between the transient storage and EBS, but again, be sure to force the entire partition to be allocated.
Well, I got thinking about
Well, I got thinking about this: seeker is sequential and so should never be able to actually use multiple spindles, I think, since it will not issue more reads while waiting for the first one.
Then I benchmarked with a modified seeker that did writes, and that showed a ~25ms access time for writes. I am still getting good times for reads, although not consistently: sometimes they went up to about 4ms.
The very simple explanation for this behavior is probably that Xen uses a copy-on-write sparse diskimage format, hence when reading from unmodified, random sectors I am actually hitting the same physical sector over and over. Its fairly easy to test, write random data to the entire disk and see if performance stays the same. I will try this tonight.
Quite interesting
I never heard of EC2 until now, but from what I see, it uses Amazon S3 as a storage device. So, if tests really went OK, that could only mean that S3 really is fast. Or has some quite clever caching built in.
What happens if you rerun seeker, do you always get the same (similar) numbers? Also, that first partition (/dev/sda1) is a little bit small and could get cached in RAM completely, so I would concentrate on the bigger one. Which, surprisingly shows as even faster, looks very much like your I/O requests are actually satisfied from some kind of memory (RAM, flash...), not typical magnetic media.
Yes, you calculated it right, you would need many spindles to get such great performance from the standard disks.
FUJITSU MAX3036NC
Some results from a server @ work (all Linux Software RAIDs)
FUJITSU MAX3036NC
Timing cached reads: 2940 MB in 2.00 seconds = 1470.42 MB/sec
Timing buffered disk reads: 270 MB in 3.02 seconds = 89.34 MB/sec
Results: 174 seeks/second, 5.72 ms random access time
2x FUJITSU MAX3036NC RAID-0
Timing cached reads: 2872 MB in 2.00 seconds = 1436.51 MB/sec
Timing buffered disk reads: 536 MB in 3.01 seconds = 178.08 MB/sec
Results: 171 seeks/second, 5.83 ms random access time
2x FUJITSU MAX3036NC RAID-1
Timing cached reads: 2652 MB in 2.00 seconds = 1326.41 MB/sec
Timing buffered disk reads: 268 MB in 3.00 seconds = 89.21 MB/sec
Results: 175 seeks/second, 5.70 ms random access time
4x FUJITSU MAX3036NC RAID-0
Timing cached reads: 2888 MB in 2.00 seconds = 1444.64 MB/sec
Timing buffered disk reads: 652 MB in 3.00 seconds = 216.99 MB/sec
Results: 174 seeks/second, 5.72 ms random access time
4x FUJITSU MAX3036NC RAID-1 (Four drive mirror)
Timing cached reads: 2888 MB in 2.00 seconds = 1442.97 MB/sec
Timing buffered disk reads: 272 MB in 3.02 seconds = 90.16 MB/sec
Results: 176 seeks/second, 5.66 ms random access time
4x FUJITSU MAX3036NC RAID-0 on 2xRAID-1 (RAID 10 the hard way)
Timing cached reads: 2848 MB in 2.00 seconds = 1423.17 MB/sec
Timing buffered disk reads: 368 MB in 3.01 seconds = 122.16 MB/sec
Results: 176 seeks/second, 5.68 ms random access time
4x FUJITSU MAX3036NC RAID-10 (RAID10 the Kernel way)
Timing cached reads: 2836 MB in 2.00 seconds = 1417.65 MB/sec
Timing buffered disk reads: 382 MB in 3.01 seconds = 126.93 MB/sec
Results: 176 seeks/second, 5.66 ms random access time
4x FUJITSU MAX3036NC RAID-5
Timing cached reads: 2792 MB in 2.00 seconds = 1395.33 MB/sec
Timing buffered disk reads: 470 MB in 3.01 seconds = 156.15 MB/sec
Results: 174 seeks/second, 5.72 ms random access time
This is running Centos 5 on an Intel Server Board SE7520JR2 server, Dual Xeon CPUs @ 3Ghz, 10GB RAM, Adaptec 39160 Dual-Port controller, and the drives are (two each) in two Compaq StorageWorks 4314R external enclosures. In the 2-drive runs, the two drives were in different enclosures, each drive on it's own U160 SCSI Bus.
Actually that last point is quite significant for the RAID-0, probably due to Ultra160 Limitations. Here's a run where the two drives are in the same enclosure:
2x FUJITSU MAX3036NC RAID-0 (Same external enclosure)
Timing cached reads: 2904 MB in 2.00 seconds = 1451.19 MB/sec
Timing buffered disk reads: 386 MB in 3.01 seconds = 128.20 MB/sec
Results: 174 seeks/second, 5.73 ms random access time
2x FUJITSU MAX3036NC RAID-1 (Same external enclosure)
Timing cached reads: 2844 MB in 2.00 seconds = 1420.98 MB/sec
Timing buffered disk reads: 272 MB in 3.01 seconds = 90.38 MB/sec
Results: 175 seeks/second, 5.69 ms random access time
P.S. I almost forgot to wait for the arrays to sync before getting results out of them.
P.P.S. I should be getting 4 more of these drives today, I'll try to post some eight drive RAID-0 tests, but I think it will hit the U160 bus bandwidth limit.
IBM-DKLA-24320 Laptop HDD
IBM-DKLA-24320
Timing cached reads: 144 MB in 2.01 seconds = 71.56 MB/sec
Timing buffered disk reads: 8 MB in 3.02 seconds = 2.65 MB/sec
Results: 39 seeks/second, 25.62 ms random access time
Compaq Armada 1700 Laptop Xubuntu 7.04
Wow, a 4GB disk and still working?
And not really a speed demon, right? :)
It's always nice to see how Linux can revive old hardware. What processor and how much RAM do you have in that laptop? And how usable it is under Xubuntu?
Definitely not a speed
Definitely not a speed demon. I had my hotdogs cooked by the time I was logged in :)
This Armada 1700 has a Pentium II @ 233 Mhz and I got the big RAM upgrade (128MB) to a whopping maximum of 160MB. The biggest limitation is the 800x600 screen, nothing expects such a low resolution nowadays.
It will run Firefox and I'm able to use D-Link DWL-G650 wireless PC Card or a SMC USB to Ethernet adapter for network connectivity.
If it were just a tiny bit faster, I could use it as a MythTV Front-end, I've tried, I get about 1 second of video and 0.25 sec of pause.
._.
Time for solid states to
Time for solid states to come in. :)
A bit larger device (~6TB)
# hdparm -t /dev/sdc
/dev/sdc:
Timing buffered disk reads: 554 MB in 3.00 seconds = 184.43 MB/sec
Had to tweak seeker.c to get this (it's not designed to handle large disks)...
# ./seeker /dev/sdc
Seeker v2.0, 2007-01-15 (cjc modded for big drives), http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sdc [5500GB], wait 30 seconds..............................
Results: 148 seeks/second, 6.72 ms random access time
Seagate Barracuda 320GB SATA
Seagate Barracuda 7200.10 ST3320620AS (Perpendicular Recording Technology) 320GB 7200 RPM 16MB Cache SATA 3.0Gb/s
hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 232 MB in 3.03 seconds = 76.68 MB/sec
Not bad!
I'm planning to buy two of those in the near future. Can't beat MB/$ ratio at that size.
Would you be so kind to post the seeker numbers, too?
Problem with LARGE Arrays
I just wanted to try the seeker on an 2,4TB raid array made of 16 300 GB disks in raid 10 but it just fails: ioctl: File too large
Any patch for it?
Oh well...
Bloody hell :), I tried hard to support as big arrays as possible (using off64_t ugliness), but obviously I failed. Didn't have anything that big to test.
I'll look into it, but not soon, probably when I get some time to work on a multithreaded version of the utility.
Samsung HD120IJ 120GB 7200rpm NCQ Serial ATA-II-300 Hard Drive
Timing cached reads: 3200 MB in 2.00 seconds = 1600.19 MB/sec
Timing buffered disk reads: 180 MB in 3.00 seconds = 59.97 MB/sec
# ./seeker /dev/sdb
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sdb [114473MB], wait 30 seconds..............................
Results: 72 seeks/second, 13.84 ms random access time
/dev/hda (SAMSUNG SP2014N,
/dev/hda (SAMSUNG SP2014N, 250GB 7200RPM IDE)
Timing buffered disk reads: 132 MB in 3.03 seconds = 43.59 MB/sec
Results: 60 seeks/second, 16.61 ms random access time
/dev/hdb (SAMSUNG SP1614N, 200GB 7200RPM IDE, AAM ON)
Timing buffered disk reads: 142 MB in 3.00 seconds = 47.29 MB/sec
Results: 71 seeks/second, 14.04 ms random access time
/dev/hdc (IBM-DTLA-307030, 30GB IDE)
Timing buffered disk reads: 108 MB in 3.06 seconds = 35.35 MB/sec
Results: 80 seeks/second, 12.45 ms random access time
/dev/sdd (KINGSTON 2.0GB SD CARD _USB1_)
Timing buffered disk reads: 6 MB in 3.62 seconds = 1.66 MB/sec
Results: 142 seeks/second, 7.01 ms random access time
/dev/sda (SANDISK 2.0GB COMPACT FLASH _USB1_)
Timing buffered disk reads: 4 MB in 4.40 seconds = 929.88 kB/sec
Results: 34 seeks/second, 28.60 ms random access time
Extremely slow Compact-flash, and newer drives more latent than older ones. Not even SD impresses in terms of latency... if one calculates what 4K takes to transfer at 1.66MB/s though .. that is about 2.35 ms. So we can probably subtract _atleast_ 1ms off of these seek times if we go USB 2.
Ok, I just had to redo
Ok, I just had to redo these, but this time on my faster laptop with a USB 2 controller, and in win32 though...-
I used something called h2benchw:
ftp://ftp.heise.de/pub/ct/ctsi/h2benchw.zip
PRETEC 256MB USB STICK: Lesen... 1.78 ms (Min. 0.44 ms, Max. 2.76 ms)
LAPTOP DISK:
Messung der mittleren Zugriffszeit (gesamte Platte):
Lesen... 20.91 ms (Min. 4.40 ms, Max. 62.98 ms)
Zugriffszeit innerhalb der ersten 504 MByte
Lesen... 11.22 ms (Min. 0.27 ms, Max. 44.62 ms)
2GB SD: Lesen... 2.25 ms (Min. 2.00 ms, Max. 4.24 ms)
2GB CF:
Messung der mittleren Zugriffszeit (gesamte Platte):
Lesen... 24.51 ms (Min. 1.60 ms, Max. 39.73 ms)
Zugriffszeit innerhalb der ersten 504 MByte
Lesen... 17.39 ms (Min. 1.59 ms, Max. 39.79 ms)
Don't ask about the crappy CF times, dont know how that happened.
Anyway, USB2 >> USB1 !!
/dev/sda (PRETECT TINY usb
/dev/sda (PRETECT TINY usb stick, USB1)
Timing buffered disk reads: 4 MB in 4.50 seconds = 910.71 kB/sec
Results: 139 seeks/second, 7.18 ms random access time
Why am I so interested in these flas memories? Because I am thinking of building a flash-based intermediate cache between my disk and RAM for a database-intensive application I am building.
Cache between disk and RAM
Yup, that's a very interesting idea. Actually, I was thinking about that, too.
But, I have always wandered about one thing. I've heard that flash memory wear and tear quite fast. So, is it actually suitable for data caching? Has it improved in the meantime?
Also, I'm quite dissapointed with low numbers of seeks you got from it. It's memory, it should be much faster.
RAM-based SSD's Are Toast
SSDs have one overwhelming advantage: speed. Data I/O rates of many thousands of random IOPS because access times are measured in microseconds (millionths) instead of milliseconds (thousandths). They leave short stroked 15k FC drives in the dust.
...
All flash drives contain wear-leveling algorithms to ensure that all cells get similar usage.
...
http://storagemojo.com/?p=281
ssd
1. First of all, disks are not fast. Disks are just about the slowest thing in the computer. And the reason disk performance hasn't improved much is because there is a limit to how much faster you can make a relatively macroscopic read head swing around.
2. Not very long ago, several gigabytes was a large hard disk. Now we have as much as 32 or 64 gigabytes of RAM available. To me, the most interesting solid state replacement for mechanical disks is volatile RAM based because RAM is much faster than Flash. I think what we need is to come up with some open source ways to take a second computer with a large bank of RAM and use it basically as a gigantic cache that saves to disk safely. Use an uninterruptable power supply with a backup uninterruptable power supply, and add to it some software that writes the data to the hard (flash?) disk in journal fashion as fast as possible. You would connect this second storage system to your main machine using a high performance bus like Infiniband or something. Basically this is sort of like your own personal solid-state SAN.
3. See gigabyte i-ram, texas ram-san, etc.
RE: SSD -> large RAM based filesystems
Um...have you heard of "ramfs"? Linux uses RAMFS filesystems all the time. It's childs play to create a RAM based filesystem, check out the article here:
http://www.tldp.org/linuxfocus/English/November1999/article124.html
The only major issue, you have to define the size of your RAMFS at boot time, and it's not changeable "on the fly".
RAMFS filesystems have been used for eons in many different Unix/Linux distributions. I've run them for small Databases - put a MySQL database on a RAMFS, some *Nix distros use a RAMFS for the /tmp/ filesystem. Lots of uses.
RAMFS requires nothing at
RAMFS requires nothing at boot time. The old "RAMDISK" kernel mechanism is entirely different.
RAMFS for a database -- I'm about to do it for my first try. My concern is what sort of key buffer MySQL may try to use -- seems pointless to store indexes in RAM that are already in RAM.
Running seeker on LVM lv's
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [239372MB], wait 30 seconds..............................
Results: 65 seeks/second, 15.16 ms random access time
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda1 [239366MB], wait 30 seconds..............................
Results: 66 seeks/second, 14.94 ms random access time
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/vg0/lv [10240MB], wait 30 seconds.............................
Results: 100 seeks/second, 9.93 ms random access time
Can someone explain why the performance is better with the lv than the actual device?
Size matters
My runs are similar on a Seagate Barracuda 7200.10 ST3250410AS 250GB 7200 RPM 16MB Cache SATA 3.0Gb/s:
# ./seeker /dev/sda
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [238475MB], wait 30 seconds..............................
Results: 65 seeks/second, 15.36 ms random access time
# ./seeker /dev/mapper/lizard-var
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/mapper/lizard-var [2932MB], wait 30 seconds..............................
Results: 143 seeks/second, 6.98 ms random access time
# ./seeker /dev/mapper/lizard-tmp
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/mapper/lizard-tmp [392MB], wait 30 seconds.............................
Results: 178 seeks/second, 5.61 ms random access time
However:
# ./seeker /dev/mapper/lizard-home
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/mapper/lizard-home [227088MB], wait 30 seconds..............................
Results: 66 seeks/second, 14.99 ms random access time
Probably it matters how big the area covered by the seeks is. I have not looked at closely the code, but I suspect that you would get the same result if you restricted the area covered while working with /dev/sda. I do not think that the LVM has anything to do with it.
Simply this benchmark depends on the coverage of the random seeks...
It may make sense to add the area (max) as a parameter. Then, I theorize that you get a nice monotone function from area to random access times.
Even better, if the code can do the test for several sizes. In my case I have the data points:
392MB -> 5.61ms
2932MB -> 6.98ms
227088MB-> 14.99ms
How many disks you have in the volume group?
If you have more than one, then probably LVM is able to spread load among them, thus you get better results.
But if your volume group is only on /dev/sda then I really don't know. Be sure to flush caches before measuring (to be absolutely sure caching is not getting in a way, reboot your computer and run seeker immediately after it).
Intel SRCS16 HW raid5
Intel SRCS16 HW raid5 (5xSEAGATE NL35 400GB 7200rpm SATA300 NCQ) Debian.
hdparm -tT /dev/sda
/dev/sda:
Timing buffered disk reads: 76 MB in 3.03 seconds = 25.12 MB/sec
Timing cached reads: 5052 MB in 2.00 seconds = 2525.12 MB/sec
/seeker /dev/sda
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [1525876MB], wait 30 seconds..............................
Results: 67 seeks/second, 14.83 ms random access time
there _is_ a standard benchmark
Just use bonnie++ (or bonnie if you insist), see e.g. Multi-Disk HOWTO.
I don't think so
No, bonnie creates a file on disk which is *much* smaller than todays disk drives. So it can't really measure what seeker does (the whole disk).
bonnie++ sizes are
bonnie++ sizes are configurable.
PC HPCompaq d530 SFF
hdparm -t /dev/hda
Timing buffered disk reads: 16 MB in 3.07 seconds = 5.21 MB/sec
seeker /dev/hda
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/hda [38166MB], wait 30 seconds..............................
Results: 70 seeks/second, 14.27 ms random access time
Asus A6Tc notebook. HDD: HTS541080G9AT00
(amd64-smp)
# hdparm -tT /dev/hdc
/dev/hdc:
Timing cached reads: 2244 MB in 2.00 seconds = 1121.53 MB/sec
Timing buffered disk reads: 102 MB in 3.00 seconds = 33.96 MB/sec
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/hdc [76319MB], wait 30 seconds..............................
Results: 58 seeks/second, 17.06 ms random access time
LAPTOP (Dell Inspiron
LAPTOP (Dell Inspiron 600m):
hda: PATA IC25N060ATMR04-0
Timing cached reads: 1292 MB in 2.00 seconds = 645.48 MB/sec
Timing buffered disk reads: 74 MB in 3.01 seconds = 24.62 MB/sec
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/hda [57231MB], wait 30 seconds..............................
Results: 47 seeks/second, 21.19 ms random access time
DESKTOP (Dell OptiPlex GX280):
sda: SATA WDC WD400JD-75HK
Timing cached reads: 1888 MB in 2.00 seconds = 944.15 MB/sec
Timing buffered disk reads: 178 MB in 3.03 seconds = 58.76 MB/sec
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [38146MB], wait 30 seconds.............................
Results: 51 seeks/second, 19.47 ms random access time
Seeker utility
Who is the author of the seeker utility ? Under what license is it available ? And could the author make it available and maintain it as a real project ? (eg. maintained on Sourceforge)
I'm interested to packages this tool, but I need to be sure that it is supported by the author before I make it available. (eg. we could have a man-page, ChangeLog, AUTHORS, TODO so people know where to send improvements/bugfixes)
ChangeLog, AUTHORS, TODO...
Well, I don't have plans to make this a full blown package at this time, because of the utter lack of free time, sorry. But in time, yes, why not. The trigger event could be when I have time to make it multithreaded. Then it should become much more useful.
In the meantime, put this on the top of seeker.c:
# Seeker v2.0, 2007-01-15, by linportal@gmail.com
# http://www.linuxinsight.com/how_fast_is_your_disk.html
# Distributed under the terms of the GNU General Public License v2
And then you can do whatever you like with it. If it's not against GPL rules, of course. ;)
Acer Aspire1520 laptop IDE disk
~ $ sudo hdparm -t /dev/hda
/dev/hda:
Timing buffered disk reads: 92 MB in 3.01 seconds = 30.58 MB/sec
Almost two years old laptop.
Why not use iozone or iometer?
Hi,
Just wondering why you didn't use tools that are already available such as IOMeter or iozone? IOMeter allows you to create random reads as well as random writes, define their sizes, define the percentages (ex. 75% writes and 25% reads) and much more. Also, how many applications actually read in 512 bytes? Most applications that do random I/O read either 2/4 or 8K blocks, with most databases reading 8K blocks.
This is a low level test
I was expecting this question sooner. ;)
seeker is very low level, it tests exactly the whole disk, where other tools test some mix of files on the disk. So results from the other tools are inconclusive and quite hard to compare at times. That's the main reason I decided to write seeker.
So yes, if you want to know how fast you can write to disk, go use some of the popular tools like iozone or bonnie, but seeker is quite unique in what it does.
And about those 512 bytes reads, well, although the utility dispatches only 512 byte I/O requests, thanks to the kernel readahead mechanism you actually read 4K block from disk at a time. So it's actually quite close to the most common real life scenarios. You can check this fact by running
iostat -x 1while the seeker is doing it job./dev/sda:
/dev/sda: Maxtor-6V080E0
/dev/sdb: HDS728080PLA380
/dev/sdc: USB attached Maxtor-6-L300R0
/dev/sda:
Timing buffered disk reads: 198 MB in 3.03 seconds = 65.35 MB/sec
/dev/sdb:
Timing buffered disk reads: 174 MB in 3.02 seconds = 57.62 MB/sec
/dev/sdc:
Timing buffered disk reads: 98 MB in 3.02 seconds = 32.41 MB/sec
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [78167MB], wait 30 seconds..............................
Results: 66 seeks/second, 14.93 ms random access time
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sdb [78533MB], wait 30 seconds..............................
Results: 77 seeks/second, 12.88 ms random access time
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sdc [286188MB], wait 30 seconds..............................
Results: 68 seeks/second, 14.53 ms random access time
How fast is your disk?
A combined score for hd speed was suggested some years ago by Red Hill as Speed = k * log(DSA / sqrt(seek + latency)).
Results for dual 74GB Raptors and RAID0
I would've expected the same results from RAID0, but the seeker numbers are slightly better on the RAID device.
# /down/seeker /dev/sdb
Results: 120 seeks/second, 8.27 ms random access time
# /down/seeker /dev/sda
Results: 120 seeks/second, 8.27 ms random access time
# /down/seeker /dev/md1
Results: 125 seeks/second, 7.98 ms random access time
# hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 206 MB in 3.02 seconds = 68.10 MB/sec
# hdparm -t /dev/sdb
/dev/sdb:
Timing buffered disk reads: 206 MB in 3.02 seconds = 68.21 MB/sec
# hdparm -t /dev/md1
/dev/md1:
Timing buffered disk reads: 410 MB in 3.00 seconds = 136.62 MB/sec
TCQ/NCQ disabled. Abit AV8 w/ 2.8GHz 3700+,
2x WD740GD-00FLC0
Nice RAID setup!
But, yes, to test RAID setups properly, we definitely need a multithreaded version of the utility.
Here's what you can do now, run two instances of seeker at the same time, but be careful. They must not be started in a very short succession, but rather make a one second pause. That's because I'm using very simple way of seeding the random number generator (good old time()) to keep the utility simple and readable at this time. Otherwise, both instances would ask disk for exactly the same block sequence, and one of them wouldn't touch disk at all, but read from the buffer cache instead.
So, do something like this to test your RAID0:
# seeker /dev/md1 & sleep 1; seeker /dev/md1
It's easiest to monitor progress like this (in another window):
% iostat md1 -x 1
extended device statistics
device mgr/s mgw/s r/s w/s kr/s kw/s size queue wait svc_t %b
md1 0 0 66.3 0.0 265.3 0.0 4.0 0.0 0.0 0.0 0
md1 0 0 66.0 0.0 264.0 0.0 4.0 0.0 0.0 0.0 0
Watch the r/s column, it shows how many reads per second your array is doing.
Of course, you could start even more seekers in parallel (but be careful with that needed delay in between starts!).
RAID Tests, done the iostat way.
Hello again, I done some tests on the SCSI RAID 10 Setup (4x36Gb 15k Seagate disks on hardware card)
So well, so far I checked with various seekers, and it goes growing and growing and growing... so here are the results.
Seekers / AVERAGE / MAX (r/s from iostat)
2 / 341 / 356
3 / 344 / 379
4 / 372 / 400
5 / 407 / 436
6 / 430 / 457
So it's like the more seekers I put, the more it can read, this thing is really fast :)
Example of result:
device mgr/s mgw/s r/s w/s kr/s kw/s size queue wait svc_t %b
md1 0 0 454.0 0.0 1816.0 0.0 4.0 0.0 0.0 0.0 0
extended device statistics
Please, someone post another results of that to compare.
Nice array!
Yes, you have 4 fast drives in an optimal setup (raid10). If every of your drives can provide around 167 ios, and if your raid card can spread loads on every disk in raid 10 array (most do) you should go even above 4 * 167 (668) if you start enough seekers in parallel. That's because SCSI disks are optimal for such (server like) loads, they can queue requests, and optimize head movement. Don't be afraid to start even 40 of them and see what your array is built of. :)
IDE drives, OTOH, can't do things like that, as you saw in your other experiment. That is one of the reasons why SCSI's are better than IDE/SATA for server loads. SATA-II with NCQ ought to improve the situation for SATA in server environment, but I don't have any such drives/controllers, so I can't check for myself. But, you can't buy 15k SATA, so SCSI still rules.
Not so nice array (but cheap)
I couldn't afford nice kit, so here is what I have just bought
Highpoint 2320
8*Samsung HD321KJ 320Gb NCQ SATA II drives, one as hot swap the rest as 7 drive RAID5.
Drives were £30 each, controller £160 and 2* IcyDock MB455 SPF 5 drive enclosures were £70 each. That equates to £540 for just under 2Tb.
fox ~ # uname -a
Linux fox 2.6.18-028stab053 #3 SMP Wed Jun 11 02:05:39 BST 2008 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ AuthenticAMD GNU/Linux
Cheap server is running OpenVZ.
The performance is fine for me WRT transfer, but understandably poor on seeks.
fox ~ # ./seeker /dev/sda
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [1830912MB], wait 30 seconds.............................
Results: 27 seeks/second, 36.14 ms random access time
fox ~ # hdparm -Tt /dev/sda
/dev/sda:
Timing cached reads: 2678 MB in 2.00 seconds = 1339.59 MB/sec
Timing buffered disk reads: 418 MB in 3.01 seconds = 138.75 MB/sec
You pays your money and you takes your choice :-)
Wilf.
About multithreaded...
Just to add....
I tested a single 120Gb SATA Disk, with 3 seekers at a time, and you dont get any gains.
It was like 75 r/s for a single seeker, and 78 r/s for the 3 seekers.
Also as a comparission, the RAID 10 SCSI setup was like 5 times faster :)
Regards.
CAS company :: www.cascompany.com