How fast is your disk?

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

AttachmentSize
seeker5.27 KB
seeker.c1.54 KB

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Ram - tmpfs is slower??

On MacBook with Slackware running in parallels hdparm reports slower ramdrive than HD SSD. Weird...

MacBook Air 13” - mid 2012 - PCIe SSD

./seeker-30sec /dev/sda
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [65536MB], wait 30 seconds..............................
Results: 9993 seeks/second, 0.10 ms random access time

hdparm -tT /dev/sda
/dev/sda:
Timing cached reads: 14112 MB in 2.00 seconds = 7069.13 MB/sec
Timing buffered disk reads: 3570 MB in 3.00 seconds = 1189.63 MB/sec

MacBook Air 13” - mid 2012 - tmpfs ( ram )

./seeker-30sec /dev/loop0
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/loop0 [496MB], wait 30 seconds..............................
Results: 897873 seeks/second, 0.00 ms random access time

hdparm -tT /dev/loop0
/dev/loop0:
Timing cached reads: 13524 MB in 2.00 seconds = 6773.97 MB/sec
Timing buffered disk reads: 496 MB in 2.21 seconds = 224.52 MB/sec

Is that because /dev/loop0 is

Is that because /dev/loop0 is 496MB and thus maxed out?

What about RAM?

Hey,
thank you for your program.
I checked it on my system and found interesting results:

1) My physical machine - 250Gb, 4Gb ram. 52 seeks/sec, 19.7 ms
2) Virtual machine with 512 Mb RAM and 10Gb disk. 133 seeks/sec, 7.5 ms
3) Virtual machine with 3.5 Gb RAM and 10Gb disk. 85 seeks/sec, 11.72 ms

Both VMs are on another physical machine with the same ram and disk.

Why it happens this way? I thought results for both VMs would be the same, despite their different memory size?

Probably the VM images are on

Probably the VM images are on different parts of the disk. Or the latter one is (more) fragmented. Disks are faster at the beggining, and gets slower as you go towards the end. Also, the more you fill them, more fragmentation ensues. Try copying images around (not moving) and see if it changes anything.

Yes, thank you. It seems to

Yes, thank you.
It seems to depend on the disks. VMs are on different machines actually, I thought they are the same, but the latter has more used space and yes, fragmented. But still I did not understood, VM has 10 Gb separate disk space, derived from free space of native disk, but when the program is launched, it turns out that current native disk status affect on the result? Because VMs itself are the same, inside them I did not installed or download something.

I'm not following you, what

I'm not following you, what do you mean by "current native disk status"?

Of course the speed of the native disks reflects on the results, even though you're running test under VM you're still measuring the speed of the native disk, or part of it, right? So, if your native disk is slower, you get worse results in VM. If your VM image is on the slow part of the disk (far from the beggining), you'll get worse results. If your VM image is fragmented, if your native disk is loaded... you guessed it, you get worse results.

seeks/sec is IOPS??

Can I assume seeks/sec is same as IOPS (input output per sec)? Please correct me if am wrong.

Not exactly

Because:

- seeker only does read operations, so it's not really I/O, only I :)
- the operations are conducted under worst possible conditions, so any real world I(O)PS would be higher.

So, the number of seeks/sec could be interpreted like "guaranteed IOPS for the worst possible read-only workload".

Samsung SSD 840 Pro running

Samsung SSD 840 Pro running Arch Linux

sudo hdparm -t /dev/sda

/dev/sda:
Timing buffered disk reads: 764 MB in 3.00 seconds = 254.60 MB/sec

./seeker /dev/sda
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [244198MB], wait 30 seconds..............................
Results: 10845 seeks/second, 0.09 ms random access time

after enabling TRIM and using

after enabling TRIM and using the noop scheduler these are the new results:

sudo hdparm -t /dev/sda

/dev/sda:
Timing buffered disk reads: 802 MB in 3.01 seconds = 266.72 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 [244198MB], wait 30 seconds..............................
Results: 11148 seeks/second, 0.09 ms random access time

Virtual disk on SSD, External 2,5"

I was quite impressed seeing these values on the virtual disk of a VM running in VMWare Player on a Lenovo W520 notebook with Samsung SSD drive:

Benchmarking /dev/sda1 [19455MB], wait 30 seconds..............................
Results: 2179 seeks/second, 0.46 ms random access time

/dev/sda1:
Timing buffered disk reads: 694 MB in 3.00 seconds = 231.21 MB/sec

In contrast, the results I found on a Western Digital 2,5" external drive connected to a Raspberry Pi:

/dev/sda1:
Timing buffered disk reads: 86 MB in 3.02 seconds = 28.46 MB/sec

Benchmarking /dev/sda1 [305242MB], wait 30 seconds...........................
Results: 48 seeks/second, 20.42 ms random access time

Looking at the tool's

Looking at the tool's output:

Benchmarking /dev/sda [117231408 blocks, 60022480896 bytes, 55 GB, 57241 MB, 60 GiB, 60022 MiB]

shouldn't those decimal units (MB, GB) be swapped with their binary counterparts (MiB, GiB)? A 60 GB disk has 55 GiB.

Yep, they should.

Yep, they should.

Yes, this is a obvious

Yes, this is a obvious bug/typo. I hope you understand. I hope will prepare seeker 4.0 shortly (will be on http://github.com/baryluk/seeker), as I have few fixes somewhere around.

How to check SAS HDD negotiated link rate

Is there a direct command to show the link rate of interface?

SAS HDD@ 150 MB/s or 300,600 MB/s?

hdparm -t /dev/hda is good, but it do tell the actual speed,

how about the " Programmed minimum link rate"???

USB-based RAID

Dell Inspiron 1525 with Pentium T2370

The onboard SATA controller is fried so this has three Sandisk Fit USB drives of 8G each arranged into a 24G RAID 0 array. I thought it would be an interesting setup for this utility to benchmark.

$ sudo ./seeker /dev/md0

Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/md0 [22608MB], wait 30 seconds..............................
Results: 650 seeks/second, 1.54 ms random access time

360K floppy seek times, just for fun.

# seeker /dev/fd1
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/fd1 [0MB], wait 30 seconds................
Results: 1 seeks/second, 576.92 ms random access time

amazon EC2 EBS drives -- faster then your floppy!

amazon EC2 1T EBS drives in one availability zone:

Benchmarking /dev/sdp [1048576MB], wait 30 seconds..............................
Results: 71 seeks/second, 13.99 ms random access time

Benchmarking /dev/sdq [1048576MB], wait 30 seconds.............................
Results: 84 seeks/second, 11.90 ms random access time

Benchmarking /dev/sdr [1048576MB], wait 30 seconds..............................
Results: 91 seeks/second, 10.94 ms random access time

Benchmarking /dev/sds [1048576MB], wait 30 seconds...........................
Results: 70 seeks/second, 14.12 ms random access time

similar Ec2 1T EBS drives in another availability zone... WTF? I think they really want you to buy their IOPs now

Benchmarking /dev/xvdm [1048576MB], wait 30 seconds..........................
Results: 3 seeks/second, 260.87 ms random access time

Benchmarking /dev/xvdm [1048576MB], wait 30 seconds..........................
Results: 3 seeks/second, 267.86 ms random access time

Benchmarking /dev/xvdm [1048576MB], wait 30 seconds..........................
Results: 3 seeks/second, 319.15 ms random access time

Benchmarking /dev/xvdm [1048576MB], wait 30 seconds.........................
Results: 3 seeks/second, 303.03 ms random access time

Ha, ha, nice one! Seriously.

Ha, ha, nice one! Seriously. :)

how to change runtime? a.k.a TIMEOUT

I changed timeout to 120 and recompiled the seeker.c.

#define TIMEOUT 120
but with the new compiled seeker it still shows "Wait 30 seconds...."

what is the trick to change the run time?

you might be the only s/w

you might be the only s/w geek who loves to wait more :)..jokes apart, I did change it to 5 seconds and it worked perfectly :)

Memory disk - aka ramdisk

root@newton:/home/pat# mount -t tmpfs tmpfs /tmp

root@newton:/home/pat# dd if=/dev/zero of=/tmp/700mb count=1400k
1433600+0 records in
1433600+0 records out
734003200 bytes (734 MB) copied, 1.66981 s, 440 MB/s

root@newton:/home/pat# mke2fs -j /tmp/700mb
mke2fs 1.41.12 (17-May-2010)
/tmp/700mb is not a block special device.
Proceed anyway? (y,n) y
Filesystem label=
...
...

root@newton:/home/pat# mkdir /tmp/qqq

root@newton:/home/pat# mount -oloop /tmp/700mb /tmp/qqq

root@newton:/home/pat# ./seekerNat /dev/loop0
Seeker v2.0(Nat1), 2007-12-18, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/loop0 [1433600 blocks, 734003200 bytes, 0 GiB], wait 30 seconds
..............................
Results: 46574 seeks/second, 0.02 ms random access time (385 < offsets < 734002812)

root@newton:/home/pat#

how do you analyse seek - continued

my point is , depending on size of the disk i.e number of blocks, the degree of randomness in random read varies.-
ie a 10G disk and 1000G disk , the randomness of the read varies, which could translate in favor or against one of these because one of the disk could recieve more heads movement than other because of the physical location of the blocks on the disk media.

So people who use this utility should understand how the utility works before making comments that an XX model of disk has better seek time than YY model.

That is true! If you make a

That is true! If you make a small partition in the front of the disk, of course you will get better results (smaller seek time). But the numbers will be correct for that partition (unless it is really small, when caching would interfere with the results). Of course, if you want to compare different hardware, the only correct way is to test the whole disk (eg. /dev/sda instead of /dev/sda1).

how do you analyse seek

for measuring seek time , i would think you need to ensure that all your reads actually cause a head movement and not a disk rotation i.e ensure the reads are all from different tracks in a straight line ie without causing a rotational delay. I know its no easy coding since most disks dont export the actual geometry via ioctls.

and based on my test the results are inaccurate if ran on any disk which is behind a raid controller (with or without caching)
i ran a test on 10g XP24k and 100G XP24k disk (both Raid7 7D+1P) LDEVS
my seek time on 10g was 10ms and on 100g was 0.02 ms.

is this the case that "seeker" is meant only for single standalone hard disk and not any thing which is behind another raid controller

The program measures random

The program measures random seek time, so it generates random list of blocks and reads them, it's that simple. Where you say "no easy coding", that is actually impossible. And has been for a long time (a decade at least). Modern disks know only about LBA, and whichever C/H/S you read from hdparm means nothing (fake numbers).

Also the program doesn't make difference between physical disks and RAID arrays, as long as you can supply a correct device file (/dev/sda, /dev/md0, etc...). The problem you observed with 100g partition is actually a bug, I think someone supplied a patch to fix it in comments (problem with very big partitions, I couldn't test it at the time I wrote the program).

Hitachi AMS200 Raid 5 with 7

Hitachi AMS200 Raid 5 with 7 15k Disks with HEAVY workloads

/dev/sda1:
Timing cached reads: 17538 MB in 1.99 seconds = 8793.97 MB/sec
Timing buffered disk reads: 1048 MB in 3.00 seconds = 349.18 MB/sec

Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda1 [78555MB], wait 30 seconds..............................
Results: 2158 seeks/second, 0.46 ms random access time

Netapp FAS2050 with Raid 5 and 7 7.2k SATA Disks with HEAVY workloads

/dev/sda1:
Timing cached reads: 14286 MB in 2.00 seconds = 7150.81 MB/sec
Timing buffered disk reads: 92 MB in 3.07 seconds = 29.96 MB/sec

Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda1 [117843MB], wait 30 seconds..............................
Results: 211 seeks/second, 4.73 ms random access time

Raid 10 sata

Raid 10 sata drives:
root@srv1 [~]# ./seeker /dev/sda1
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda1 [101MB], wait 30 seconds..............................
Results: 1091110 seeks/second, 0.00 ms random access time

Is that even correct?

It is, but the result is

It is, but the result is useless. Because your partition is so small (only 0.1GB) it is easily cached in RAM completely, so what you're measuring is _memory_ speed, not disk speed. For seeker to provide meaningful results, you need to have a big partition, much bigger than the installed RAM.

SAMSUNG 1TB HD103SJ 32mb Cache 7200 rpm

sudo hdparm -tT /dev/sdd1

/dev/sdd1:
Timing cached reads: 10432 MB in 2.00 seconds = 5219.09 MB/sec
Timing buffered disk reads: 444 MB in 3.01 seconds = 147.47 MB/sec

Portable implementation in Python

I prepared a portable seeker.py.
It is written in Python and works on Linux, FreeBSD, Mac OS X.

You don't need to use it on a disk device. Seeking in a very big file gives also informative results.

threaded

A-ha! I wrote a threaded version of this (from scratch), which is super useful because it will show you split seeks on RAID arrays. This seeker.c is nice, but it seeks serially.

I need to clean up the code a tad and then I'll publish it on my site, I've dubbed it seekmark, but here is a taste:


SEEKER:
one of the underlying disks:
Benchmarking /dev/sda4 [467398MB], wait 30 seconds..............................
Results: 75 seeks/second, 13.28 ms random access time

md raid device:
Benchmarking /dev/md3 [1168497MB], wait 30 seconds..............................
Results: 75 seeks/second, 13.19 ms random access time

SEEKMARK:
one of the underlying disks, ONE thread:
[root@server mlsorensen]# ./seekmark -t 1 -s 1000 -f /dev/sda4
Spawning worker 0
thread 0 completed, time: 13.522000, 73.95 seeks/sec
total time: 13.522000, 73.95 seeks/sec, 73.95 seeks/sec/thread

one of the underlying disks, TWO threads:
[root@server mlsorensen]# ./seekmark -t 2 -s 1000 -f /dev/sda4
Spawning worker 0
Spawning worker 1
thread 1 completed, time: 27.438000, 36.45 seeks/sec
thread 0 completed, time: 27.453000, 36.43 seeks/sec
total time: 27.454000, 72.85 seeks/sec, 36.42 seeks/sec/thread

md raid device, ONE thread:
[root@server mlsorensen]# ./seekmark -t 1 -s 1000 -f /dev/md3
Spawning worker 0
thread 0 completed, time: 13.265000, 75.39 seeks/sec
total time: 13.265000, 75.39 seeks/sec, 75.39 seeks/sec/thread

md raid device, TWO threads:
[root@server mlsorensen]# ./seekmark -t 2 -s 1000 -f /dev/md3
Spawning worker 0
Spawning worker 1
thread 0 completed, time: 13.248000, 75.48 seeks/sec
thread 1 completed, time: 13.486000, 74.15 seeks/sec
total time: 13.486000, 148.30 seeks/sec, 74.15 seeks/sec/thread

md raid device, FOUR threads:
[root@server mlsorensen]# ./seekmark -t 4 -s 1000 -f /dev/md3
Spawning worker 0
Spawning worker 1
Spawning worker 2
Spawning worker 3
thread 3 completed, time: 15.160000, 65.96 seeks/sec
thread 2 completed, time: 15.244000, 65.60 seeks/sec
thread 1 completed, time: 15.512000, 64.47 seeks/sec
thread 0 completed, time: 15.634000, 63.96 seeks/sec
total time: 15.634000, 255.85 seeks/sec, 63.96 seeks/sec/thread

seekmark

Published seekmark, if anyone is interested.

Uploaded to the AUR

Excellent work! I have uploaded your package to the Arch Linux AUR also.
http://aur.archlinux.org/packages.php?ID=47016

seekmark update

I've updated my code at the provided web address above:

  • write test via “-w” flag, with a required argument of “destroy-data”
  • allows for specification of io size via the “-i” flag, from 1byte to 1048576 bytes (1 megabyte). The intended purpose of the benchmark (which is to test max iops and latency) is still best fulfilled by the default io size of 512, but changing the io size can be useful in certain situations.
  • added “-q” flag per suggestions, which skips per-thread reporting and limits output to the result totals and any errors that possibly arise

Results with Intel Intel X25-M 120GB SSD

I tried your tests with my new Intel Intel X25-M 120GB SSD. Minimal but generic Debian build and I actually have a Windows XP virtual machine running in vmware workstation and it has a ton of stuff running. I am curious what is going to happen when I can actually shut everything down and spend some time tweaking. I was expecting a speed boost but this is a bit nuts.

sudo hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 450 MB in 3.00 seconds = 149.95 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 [114473MB], wait 30 seconds..............................
Results: 7186 seeks/second, 0.14 ms random access time

And I wanted to bye a SSD ...

And I wanted to bye a SSD ... Now I will stick with my WD Blue 2x1TB Raid 0 ...

/dev/mapper/pdc_heajfafgc1:
Timing cached reads: 6612 MB in 2.00 seconds = 3307.50 MB/sec
Timing buffered disk reads: 726 MB in 3.00 seconds = 241.91 MB/sec

No tuning done just a "simple" fake Raid

ANS-9010 16 GB - single SATA 3.0 Gbps

# ./seeker /dev/sde
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sde [16383MB], wait 30 seconds..............................
Results: 12831 seeks/second, 0.08 ms random access time

# hdparm -t /dev/sde1

/dev/sde1:
Timing buffered disk reads: 488 MB in 3.00 seconds = 162.47 MB/sec

I remain disappointed about that last figure... That is only 1.36 Gbps, not 3.0 GBps.

4x Seagate ST1000528AS, ESXi, Software Raid, 413.26 MB/Sec

Setup:

Core2 Quad, Q9550 @ 2.83GHz
Asus P5Q-E
2x2GB Corsair Dominator 1066 in dual channel
4x Seagate ST1000528AS (7200 RPM, 32MB Buffer 1TB each)

no hardware raid

Installed VMWare ESXi 4.1

Created 4 datastores, 1 on each disk.

Created an Ubuntu 10.10 server VM; Gave it 4x256GB VMDK's. (1 in eachdatastore).

Configured software raid:
Created a 4.9GB primary partition on each virtual disk.
Created a 7GB primary partition on each virtual disk.
Created a 241GB primary partition on each virtual disk.

Created a software raid 10 using 2 active and 2 spare disks; Selected each of the 4.9GB Partitions.
Created a software raid 10 using 2 active and 2 spare disks; Selected each of the 7GB Partitions.
Created a software raid 10 using 2 active and 2 spare disks; Selected each of the 241GB Partitions.

Mounted the 4.9GB partitions as /boot
Mounted the 7GB Partitions as *swap*
Mounted the 241GB Partitions as /

#hdparm -t /dev/md0 ! this is /boot
Timing buffered disk reads: 1240 MB in 3.00 seconds = 413.26 MB/sec
#hdparm -t /dev/md1 ! this is swap space
Timing buffered disk reads: 2326 MB in 3.00 seconds = 774.94 MB/sec

hdparm -tT

hdparm -tT /dev/sda3

/dev/sda3:
Timing cached reads: 3478 MB in 2.00 seconds = 1738.97 MB/sec
Timing buffered disk reads: 576 MB in 3.00 seconds = 191.80 MB/sec

Corsair F120 SSD disk with ext4 and trim support.

Linux debian 2.6.32.27-grsec #1 SMP Tue Dec 28 09:10:23 EST 2010 i686 GNU/Linux
The result should be 250MB/s but maybe there is something wrong with my SSD or I
just need to tune it more.

ESX4i Whitebox

Ubuntu 10.04 (x86-64) Virtual Machine (3GB vmdk ext4 formatted) on a VMware vSphere whitebox, using a Samsung Spinpoint F3 1TB on an Intel H55 chipset:

Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [3072MB], wait 30 seconds..............................
Results: 249 seeks/second, 4.00 ms random access time

# hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 444 MB in 3.01 seconds = 147.51 MB/sec

Keep in mind with something

Keep in mind with something like this, that you're really only testing a 3GB file on a 1TB drive, so the seek time will be a little better than if it had to seek across the entire platter. Also, while the seeker application doesn't really do cached reads, part of your vmdk could be cached on the host.

Lots of weird things to take into account when you're benchmarking VMs.

Seagate 7200.10 320 Gb SATA

On a single disk:

Benchmarking /dev/sda [305244MB], wait 30 seconds..............................
Results: 72 seeks/second, 13.88 ms random access time

hdparm: Timing buffered disk reads: 220 MB in 3.01 seconds = 73.06 MB/sec

A RAID-1 array across three of these drives:

Benchmarking /dev/md0 [20481MB], wait 30 seconds..............................
Results: 108 seeks/second, 9.22 ms random access time

hdparm: Timing buffered disk reads: 196 MB in 3.02 seconds = 64.89 MB/sec

Seeker

Kingston 64GB SSDNow V-Series Drive - 64GB, SATA2 2.5, Desktop
seeker /dev/sda
Seeker v3.0, 2009-06-17, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [125045424 blocks, 64023257088 bytes, 59 GB, 61057 MB, 64 GiB, 64023 MiB]
[512 logical sector size, 512 physical sector size]
[1 threads]
Wait 30 seconds..............................
Results: 4221 seeks/second, 0.237 ms random access time (2971148 < offsets < 64023248710)

Western Digital WD1600AAJS Caviar Blue Hard Drive - 160GB, 7200RPM, 8MB, SATA-300
seeker /dev/sdb
Seeker v3.0, 2009-06-17, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sdb [312581808 blocks, 160041885696 bytes, 149 GB, 152627 MB, 160 GiB, 160041 MiB]
[512 logical sector size, 512 physical sector size]
[1 threads]
Wait 30 seconds..............................
Results: 66 seeks/second, 15.129 ms random access time (61903405 < offsets < 159801535085)

OCZ-VERTEX

bash-4.1# hdparm -tT /dev/sda

/dev/sda:
Timing cached reads: 2136 MB in 2.00 seconds = 1068.89 MB/sec
Timing buffered disk reads: 374 MB in 3.01 seconds = 124.12 MB/sec
bash-4.1# hdparm -i /dev/sda

/dev/sda:

Model=OCZ-VERTEX, FwRev=1.5, SerialNo=MY4JD63UB7L62L52X6IS
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=12288
BuffType=unknown, BuffSize=unknown, MaxMultSect=1, MultSect=1
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=62531183
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=no WriteCache=enabled
Drive conforms to: Unspecified: ATA/ATAPI-5,6,7

* signifies the current active mode

bash-4.1# ./seeker
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Usage: seeker
bash-4.1# ./seeker /dev/sda
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [30532MB], wait 30 seconds..............................
Results: 5699 seeks/second, 0.18 ms random access time

md0, usb-sata drive, sata drive

just for comparison, on the same system:

-- 2 sata drives
bash-4.1# ./seeker /dev/md0
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/md0 [1907734MB], wait 30 seconds..............................
Results: 69 seeks/second, 14.38 ms random access time

-- usb drive (sata, not esata)
bash-4.1# ./seeker /dev/sdd
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sdd [953869MB], wait 30 seconds..............................
Results: 66 seeks/second, 14.98 ms random access time

-- single sata drive
bash-4.1# ./seeker /dev/sdc
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sdc [953869MB], wait 30 seconds..............................
Results: 69 seeks/second, 14.37 ms random access time

Tested seeker.c with a

Tested seeker.c with a software raid in Slackware Linux 13.1
2x Seagate Cheetah 15K.4 147GB RAID 1.

Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/md0 [140010MB], wait 30 seconds..............................
Results: 165 seeks/second, 6.04 ms random access time

Results are consistently a little bit slow

First off, seeker is a great tool... and I like the clean, simple code, which is easy to understand.

My 3.5" 7200 RPM drives are consistently giving me slower-than-expected random access times. These are a 2006 200gb Seagate drive, a 2008 250gb Seagate drive, and a 2008 500gb Hitachi drive. I'm getting random access times of 15-16ms for all of these, though the manufacturers and benchmarks on Tom's Hardware suggest that I should be getting more like 11-12ms. Is there any reason to think that random access time might degrade as a disk ages, or is there possibly a problem with seeker?

By comparison, my brand new 5900 RPM Seagate LP 2tb drive gives a random access time of 16.07 ms, which is right in line with the 16 ms that Seagate quotes.

Hmmm...

Patch to allow user-specified duration

Hi, I made a few small changes to the code to allow the user to specify the test duration, in seconds, on the command line. Feel free to distribute this modified version if you'd like: seeker.c

BSD version?

Hello - your seeker is a great tool but it is seems to heavy linux dependet.
Any chanse what you make a Free(BSD) version? It wiil be nice to have one tool on cross systems.

FreeBSD

Hi,

I will look at FreeBSD problems. current version uses some linux-specific ioctls for retriving sector size and block device size. Will try to fix it.

I'm sorry, but I don't have

I'm sorry, but I don't have access to any FreeBSD system. I guess somebody else will have to do it.

I added "seeker" to the Arch Linux AUR (Arch User Repository)

I included your program as official AUR package for Arch Linux! Arch users can now download, compile, and install to their system(s) using standard package management procedures. I found that this program was useful, so hopefully it'll be useful for others too :) -Max a.k.a. Synthead

URL: http://aur.archlinux.org/packages.php?ID=35535

PKGBUILD:

# Contributor: Max Pray a.k.a. Synthead
pkgname=seeker
pkgver=0 #author didn't declare a version (yet)
pkgrel=1
pkgdesc="A non-destructive tool for benchmarking disk access time via a random access pattern"
arch=(i686 c86_64)
url="http://www.linuxinsight.com/how_fast_is_your_disk.html"
license=('GPL')
source=(http://www.linuxinsight.com/files/$pkgname.c)
md5sums=('e3b70f67ca60e8f5ea3a8d237b423f9a')

build() {
mkdir -p $pkgdir/usr/bin
gcc -O2 $srcdir/seeker.c -o $pkgdir/usr/bin/seeker || return 1
}

Yes, I saw the typo too,

Yes, I saw the typo too, haha. I changed c86_64 to x86_64.

# Contributor: Max Pray a.k.a. Synthead

pkgname=seeker
pkgver=0 #author didn't declare a version (yet)
pkgrel=1
pkgdesc="A non-destructive tool for benchmarking disk access time via a random access pattern"
arch=(i686 x86_64)
url="http://www.linuxinsight.com/how_fast_is_your_disk.html"
license=('GPL')
source=(http://www.linuxinsight.com/files/$pkgname.c)
md5sums=('e3b70f67ca60e8f5ea3a8d237b423f9a')

build() {
mkdir -p $pkgdir/usr/bin
gcc -O2 $srcdir/seeker.c -o $pkgdir/usr/bin/seeker || return 1
}

License for "seeker" program?

The source code for the seeker program you posted doesn't have any license info with it. Would you be willing to release it under GPLv2 or later?

You're free to use it under

You're free to use it under the terms of GPLv2.

2x 7200RMP 250GB western

2x 7200RMP 250GB western digital HDs in raid0:
Benchmarking /dev/md5 [476945MB], wait 30 seconds..............................
Results: 71 seeks/second, 13.99 ms random access time

2x 10k RPM 74GB western digital RAPTORS in raid0:
Benchmarking /dev/md4 [106132MB], wait 30 seconds.............................
Results: 123 seeks/second, 8.08 ms random access time

1x Intel X-25 G2 160GB SSD:
Benchmarking /dev/sde7 [108492MB], wait 30 seconds..............................
Results: 7238 seeks/second, 0.14 ms random access time

Here is an Ubuntu Server 9.10

Here is an Ubuntu Server 9.10 based standard PC with AMD X425, 2.7 Ghz triple core processor, 2 GB of DDR2 667 in ganged mode, PCB Gigabyte MA75GM-S2 and 4 x ST3250318AS 250 GB SATA drives.

It is hosting virtual machines on KVM and iSCSI devices. This is test environment.
/dev/md1 is an RAID10 device for the system, images of machines and other
/dev/md2 is an RAID0 device for SWAP because of low main memory of this machine.

root@virtserver:~# ./seeker /dev/md1
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/md1 [474937MB], wait 30 seconds..............................
Results: 72 seeks/second, 13.72 ms random access time
root@virtserver:~# ./seeker /dev/md2
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/md2 [3451MB], wait 30 seconds..............................
Results: 156 seeks/second, 6.38 ms random access time
root@virtserver:~# ./seeker_baryluk /dev/md2 16
Seeker v3.0, 2009-06-17, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/md2 [7067648 blocks, 3618635776 bytes, 3 GB, 3451 MB, 3 GiB, 3618 MiB]
[512 logical sector size, 512 physical sector size]
[16 threads]
Wait 30 seconds..............................
Results: 860 seeks/second, 1.162 ms random access time (104854 < offsets < 3618263189)
root@virtserver:~# ./seeker_baryluk /dev/md1 16
Seeker v3.0, 2009-06-17, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/md1 [972671232 blocks, 498007670784 bytes, 463 GB, 474937 MB, 498 GiB, 498007 MiB]
[512 logical sector size, 512 physical sector size]
[16 threads]
Wait 30 seconds..............................
Results: 395 seeks/second, 2.526 ms random access time (74138195 < offsets < 497893328047)

and below is my brand new laptop HDD - ST9500420ASG:
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [476940MB], wait 30 seconds..............................
Results: 56 seeks/second, 17.75 ms random access time
sudo ./seeker_baryluk /dev/sda 16
Seeker v3.0, 2009-06-17, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [976773168 blocks, 500107862016 bytes, 465 GB, 476940 MB, 500 GiB, 500107 MiB]
[512 logical sector size, 512 physical sector size]
[16 threads]
Wait 30 seconds..............................
Results: 101 seeks/second, 9.814 ms random access time (98866779 < offsets < 499729568233)

X-25M G2 (2CV102HD firmware)

[512 logical sector size, 512 physical sector size]
[1 threads]
Results: 17207 seeks/second, 0.058 ms random access time (976057 < offsets < 160041797532)

[512 logical sector size, 512 physical sector size]
[4 threads]
Results: 30561 seeks/second, 0.033 ms random access time (12669 < offsets < 160041879435)

[512 logical sector size, 512 physical sector size]
[8 threads]
Results: 34017 seeks/second, 0.029 ms random access time (141672 < offsets < 160041801184)

[512 logical sector size, 512 physical sector size]
[16 threads]
Results: 37704 seeks/second, 0.027 ms random access time (222383 < offsets < 160041700575)

Yay, that shit is really

Yay, that shit is really fast. And obviously only gets better if loaded properly, it seems it would be great even for server workloads. At least before MLC cells getting destroyed due to too many writes. ;)

seeker and Linux MD results

Hi, I have 2 sets of SATA disks (all same model,same batch number). NCQ-none
Set A - Disk 0 and 2 - Linux MD RAID-1 /dev/md1 - boot.root,swap partition
Set B - Disk 1 and 3 - Linux MD RAID-0 /dev/md2 - fully dedicated to MD

when running seeker against the /dev/md2 with 4 threads
seeker /dev/md2 4
I got around 136 seeks/sec and 7.34ms seek.

when running seeker against the /dev/md1 with 4 threads
seeker /dev/md1 4
I got around 163 seeks/sec and 6.13ms seek.

Question 1: I am surprised RAID-1 number is better than RAID-0. I must miss some understanding of RAID.

I also got a pair of old WD and Maxtor 40GB IDE hard disks in Linux MD RAID-1
I got around 167 seeks/sec and 5.98ms seek.

This result also surprise as seem they perform about the same or even better than the new SATA disks.

RAID1 vs RAID0 performance

RAID1 (mirror) has twice the number of heads available for reading. Reads are from only one disk, whichever one is positioned more near where you're seeking.

RAID0 depends on your stripe size, but a seek into it may hit multiple disks due to read ahead.

My testing

On my 20x1TB in raid6 I get with the multi threaded version:

1 thread:


root@sabayonx86-64: 07:58 PM :~# ./seeker_baryluk /dev/sdc
Seeker v3.0, 2009-06-17, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sdc [34951163904 blocks, 17894995918848 bytes, 16666 GB, 17065998 MB, 17894 GiB, 17894995 MiB]
[512 logical sector size, 512 physical sector size]
[1 threads]
Wait 30 seconds..............................
Results: 77 seeks/second, 12.876 ms random access time (5637745772 < offsets < 17888415385014)

128 threads:

root@sabayonx86-64: 07:58 PM :~# ./seeker_baryluk /dev/sdc 128
Seeker v3.0, 2009-06-17, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sdc [34951163904 blocks, 17894995918848 bytes, 16666 GB, 17065998 MB, 17894 GiB, 17894995 MiB]
[512 logical sector size, 512 physical sector size]
[128 threads]
Wait 30 seconds..............................
Results: 2152 seeks/second, 0.465 ms random access time (247348641 < offsets < 17894841441567)

hdparm:


/dev/sdc3:
Timing buffered disk reads: 2264 MB in 3.00 seconds = 754.65 MB/sec

Maybe my raid controller is really messing with this? I also have 4 OCZ 256 GB SSDs in raid0 (so 1 TB of SSD storage) and I get:

1 thread:

root@sabayonx86-64: 08:02 PM :~# ./seeker_baryluk /dev/sdd
Seeker v3.0, 2009-06-17, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sdd [2015623168 blocks, 1031999062016 bytes, 961 GB, 984191 MB, 1031 GiB, 1031999 MiB]
[512 logical sector size, 512 physical sector size]
[1 threads]
Wait 30 seconds..............................
Results: 4968 seeks/second, 0.201 ms random access time (3276471 < offsets < 1031991201463)

128 threads:

root@sabayonx86-64: 07:48 PM :~# ./seeker_baryluk /dev/sdd 128
Seeker v3.0, 2009-06-17, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sdd [2015623168 blocks, 1031999062016 bytes, 961 GB, 984191 MB, 1031 GiB, 1031999 MiB]
[512 logical sector size, 512 physical sector size]
[128 threads]
Wait 30 seconds..............................
Results: 22070 seeks/second, 0.045 ms random access time (2591190 < offsets < 1031996738979)

hdparm:

/dev/sdd:
Timing buffered disk reads: 1938 MB in 3.00 seconds = 645.55 MB/sec

Or does it have to do with the fact its got 4 drives in raid so its getting ~4x the result and earlier I had 20 drives in raid so its getting ~20x the result? I wish I had software raid with no controller cache to help test this theory. A single g.skill 64 GB SSD gives me:

1 thread:

hptc ~ # ./seeker_baryluk /dev/sda
Seeker v3.0, 2009-06-17, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [125206528 blocks, 64105742336 bytes, 59 GB, 61136 MB, 64 GiB, 64105 MiB]
[512 logical sector size, 512 physical sector size]
[1 threads]
Wait 30 seconds..............................
Results: 4373 seeks/second, 0.229 ms random access time (401473 < offsets < 64105171544)

128 Threads:

hptc ~ # ./seeker_baryluk /dev/sda 128
Seeker v3.0, 2009-06-17, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [125206528 blocks, 64105742336 bytes, 59 GB, 61136 MB, 64 GiB, 64105 MiB]
[512 logical sector size, 512 physical sector size]
[128 threads]
Wait 30 seconds..............................
Results: 4446 seeks/second, 0.225 ms random access time (71375 < offsets < 64103094054)

hdparm:

/dev/sda:
Timing buffered disk reads: 410 MB in 3.00 seconds = 136.52 MB/sec

Also the link is broken for seeker_baryluk and i had to track down the source from an rpm so I put it on my server for people who need it:

http://box.houkouonchi.jp/seeker_baryluk.c

Compile Errors

seeker_baryluk.c doesn't compile on CentOS 5.

[root@zdrivetest ~]# gcc -o seeker_baryluk seeker_baryluk.c
/tmp/ccUp3jHT.o: In function `main':
seeker_baryluk.c:(.text+0x88f): undefined reference to `pthread_create'
seeker_baryluk.c:(.text+0x913): undefined reference to `pthread_join'
collect2: ld returned 1 exit status

Is there a way to fix this?

Try it like this: gcc -o

Try it like this: gcc -o seeker_baryluk seeker_baryluk.c -lpthread and it will work.

Old server is offline

This should work http://smp.if.uj.edu.pl/~baryluk/seeker_baryluk.c

(Old address http://tsk.ch.uj.edu.pl/~baryluk/seeker_baryluk.c is now offline completly)

Samsung SpinPoint F1 RAID results

System: Ubuntu 9.10 AMD 64 on MSI P55-GD65 / Intel Core i7 860 / 8 GM RAM.
Disks: 4 x Samsung SpinPoint F1 (RAID edition), in Intel Matrix raid (dmraid driver), RAID 10 configuration.

RAW DISK DEVICE
---------------
$ sudo ./seeker /dev/sdb
Results: 71 seeks/second, 13.96 ms random access time

$ sudo ./seeker_baryluk /dev/sdb 64
Results: 129 seeks/second, 7.748 ms random access time

$ sudo hdparm -t /dev/sdb
Timing buffered disk reads: 338 MB in 3.00 seconds = 112.60 MB/sec

DISKS IN RAID 10
----------------
$ sudo ./seeker /dev/mapper/isw_dhdcdfdjag_Volume0
Results: 71 seeks/second, 13.97 ms random access time

$ sudo ./seeker_baryluk /dev/mapper/isw_dhdcdfdjag_Volume0 64
Results: 254 seeks/second, 3.936 ms random access time

$ sudo hdparm -t /dev/mapper/isw_dhdcdfdjag_Volume0
Timing buffered disk reads: 524 MB in 3.01 seconds = 174.16 MB/sec

Regards

-- Otto

Intel X25M stats

/dev/md0 = raid0 with 3 Intel X25M drives

./seeker_baryluk /dev/md0 8
Seeker v3.0, 2009-06-17, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/md0 [937728000 blocks, 480116736000 bytes, 447 GB, 457875 MB, 480 GiB, 480116 MiB]
[512 logical sector size, 512 physical sector size]
[8 threads]
Wait 30 seconds..............................
Results: 33511 seeks/second, 0.030 ms random access time (653500 < offsets < 480116475091)

./seeker /dev/md0
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/md0 [457875MB], wait 30 seconds..............................
Results: 16477 seeks/second, 0.06 ms random access time

hdparm -t /dev/md0

/dev/md0:
Timing buffered disk reads: 718 MB in 3.01 seconds = 238.76 MB/sec

on a single drive:

./seeker_baryluk /dev/sdd 8
Seeker v3.0, 2009-06-17, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sdd [312581808 blocks, 160041885696 bytes, 149 GB, 152627 MB, 160 GiB, 160041 MiB]
[512 logical sector size, 512 physical sector size]
[8 threads]
Wait 30 seconds..............................
Results: 16779 seeks/second, 0.060 ms random access time (248690 < offsets < 160041616212)

./seeker /dev/sdd
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sdd [152627MB], wait 30 seconds..............................
Results: 17435 seeks/second, 0.06 ms random access time

hdparm -t /dev/sdd

/dev/sdd:
Timing buffered disk reads: 686 MB in 3.01 seconds = 228.02 MB/sec

no tuning and tweaking yet....
I'll post results later after reading a little bit more about it.

after putting 120Gb in 6819090 files on this drive tests slowed down to:
./seeker /dev/md0 <-- md0 = XFS, noatime
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/md0 [457875MB], wait 30 seconds..............................
Results: 4793 seeks/second, 0.21 ms random access time

"after putting 120Gb in

"after putting 120Gb in 6819090 files on this drive tests slowed down to:"

This is really interesting result! It shows that internal SSD fragmentation in time and poor (isn't this the case even in intel case) ssd controller can really affect performance.

Samsung F3 500GB

Very nice tool !

System is Core i7 on GB p55m-ud4 FYI even though purpose here is HDD.

Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [476940MB], wait 30 seconds..............................
Results: 71 seeks/second, 14.03 ms random access time

Seeker v3.0, 2009-06-17, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [976773168 blocks, 500107862016 bytes, 465 GB, 476940 MB, 500 GiB, 500107 MiB]
[512 logical sector size, 512 physical sector size]
[32 threads]
Wait 30 seconds..............................
Results: 120 seeks/second, 8.303 ms random access time (133393231 < offsets < 500096231013)

Will post in RAID-0 LVM soon hopefully ;-)

500GB WD single platter SATA on old Abit BP6

processor : 0
model name : Celeron (Mendocino)
cpu MHz : 551.304
processor : 1
model name : Celeron (Mendocino)
cpu MHz : 551.304

2x366MHz PPGA Celerons w/locked 5.5 multipliers on a 100MHz bus
384MB PC133 (1x256 + 2x64)

00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03)
00:11.0 RAID bus controller: Silicon Image, Inc. SiI 3512 [SATALink/SATARaid] Serial ATA Controller (rev 01)

ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata1.00: ATA-8: WDC WD5000AAKS-00V1A0, 05.01D05, max UDMA/133
ata1.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata1.00: configured for UDMA/100
scsi 0:0:0:0: Direct-Access ATA WDC WD5000AAKS-0 05.0 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB)

Linux greer 2.6.31.1 #1 SMP Tue Dec 8 13:24:02 CST 2009 i686 GNU/Linux
Debian 5.0.3 (Lenny)

Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [476940MB], wait 30 seconds.............................
Results: 65 seeks/second, 15.22 ms random access time

Timing cached reads: 264 MB in 2.00 seconds = 131.72 MB/sec
Timing buffered disk reads: 174 MB in 3.04 seconds = 57.32 MB/sec
Timing O_DIRECT disk reads: 252 MB in 3.00 seconds = 83.98 MB/sec

A new SATA controller and HD have revived this Frankenstein machine once again. ;)
Given my CPU type/count, a multi-threaded version of seeker would probably pump my numbers up a bit. In most modern systems the disk subsystem is the bottleneck. In this case, I think the rest of the system is a bottleneck to the disk. ;) Just so people don't get the wrong idea, this machine is not my workstation. It's a headless server, MX SMTP firewall/gateway for my vanity domain, soon to be a POP/IMAP and CIFS server due to the new disk, and is always a Swiss Army Knife server, shell tools, a little FTP and what not as needed. I purchased most of the parts used long ago, and this machine has paid for itself multiple times over, and still has years of use left in it, when deployed for the proper uses.

deadline scheduler doubles threaded seeker throughput

I changed my kernel I/O scheduler from the default cfq scheduler to the deadline scheduler, and it doubled my seek throughput for high thread counts and cut my seek times in half.

CFQ scheduler:
Seeker v3.0, 2009-06-17, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [976773168 blocks, 500107862016 bytes, 465 GB, 476940 MB, 500 GiB, 500107 MiB]
[512 logical sector size, 512 physical sector size]
[128 threads]
Wait 30 seconds..............................
Results: 69 seeks/second, 14.486 ms random access time (149125731 < offsets < 500062007073)

deadline scheduler:
Seeker v3.0, 2009-06-17, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [976773168 blocks, 500107862016 bytes, 465 GB, 476940 MB, 500 GiB, 500107 MiB]
[512 logical sector size, 512 physical sector size]
[128 threads]
Wait 30 seconds..............................
Results: 129 seeks/second, 7.714 ms random access time (232648455 < offsets < 500089641882)

My sata controller, a Silicon Image 3512, doesn't support ncq, so using the deadline I/O scheduler helps tremendously for threaded and/or muti-user/process I/O. This is because it does aggressive request reordering, similar to what good NCQ implementations do.

Check to see if your kernel has all 4 I/O schedulers built in by executing:

cat /sys/block/[device_name]/queue/scheduler
cat /sys/block/sda/queue/scheduler

You should see output such as:

noop anticipatory [deadline] cfq

The one in [] brackets is your current default I/O scheduler.

If have all four you can test each one on your system by executing:

echo [scheduler] > /sys/block/[device_name]/queue/scheduler
echo deadline > /sys/block/sda/queue/scheduler

You can confirm the change by running the cat command above. If the change took effect, you'll see that the [] are now around one of the other scheduler names. Now test each one with seeker and/or hdparm and/or dd.

The four I/O schedulers are:

Completely Fair Queuing—elevator=cfq
Deadline—elevator=deadline
NOOP—elevator=noop
Anticipatory—elevator=as

Anticipatory also gave me good threaded results as it does request reordering, but I chose to go with deadline as it has lower I/O latency.

A good read of all this can be found at:
http://www.redhat.com/magazine/008jun05/features/schedulers/

I use Debian, but it also uses CFQ as the default. Or, I should say, the 2.6.31.1 kernel source from kernel.org defaults to including all four scheduler in the kernel, and sets CFQ as the default. I compile all my own kernels, so I'm not sure if this is a kernel source default or a Debian default. I lean toward it likely being a kernel source default.

Anyway, switching from CFQ to deadline doubled my threaded seeker performance, and that's really something--doubling disk throughput with a simple kernel tweak.

I missed the fact someone had

I missed the fact someone had already created a threaded version. I just ran it with 1,2,4,32,64 threads and it made no difference on my system.

I'd still like to understand why O_DIRECT gives ~85MB/s and buffered reads gives only ~55MB/s. I've been searching for this information for 3 days and can't find any definitive answers. Obviously going through the kernel buffers is going to cause some performance penalty, but ~30MB/s worth of penalty compared to O_DIRECT? If my math is correct, that's a ~38% difference in throughput. Why is the kernel getting in the way to this degree? Is this normal? I compile my own kernels from kernel.org sources. Did I hose something in my kernel config that's causing this 38% difference between raw reads and buffered reads? If a single thread is enough to drive my disk to full boogy, then the speed of my CPU/memory subsystem shouldn't be the cause of this 38% difference.

Why is the kernel throwing up such a massive speed bump here? Or, is hdparm not accurate in what it's reporting?

O_DIRECT

That's normal and why most databases use directIO, asyncIO, or concurrentIO (all ways to bypass kernel buffering).

Some of it is buffer alignments, and some of it is latency incurred at multiple steps. It's like the difference between using DMA vs PIO (which can actually be upwards of 70% improvement).

AIO doesn't bypass kernel

AIO doesn't bypass kernel buffering. AIO only bypass buffering with connjunction with DIRECT IO,

160gb intel ssd g2

A single intel 160gb g2 SSD - running on an nVidia ION chipset with dual core ATOM
Ubuntu 9.10 - with some SSD optimizations like noatime and elevator=noop

sudo ./seeker /dev/sda
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [152627MB], wait 30 seconds..............................
Results: 9108 seeks/second, 0.11 ms random access time

sudo ./seeker_baryluk /dev/sda 64
Seeker v3.0, 2009-06-17, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [312581808 blocks, 160041885696 bytes, 149 GB, 152627 MB, 160 GiB, 160041 MiB]
[512 logical sector size, 512 physical sector size]
[64 threads]
Wait 30 seconds..............................
Results: 24444 seeks/second, 0.041 ms random access time (154118 < offsets < 160041723230)

sudo hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 416 MB in 3.00 seconds = 138.44 MB/sec

my test look

my test look strange:

./seeker_baryluk /dev/sda 2
Seeker v3.0, 2009-06-17, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [1250263728 blocks, 640135028736 bytes, 596 GB, 610480 MB, 640 GiB, 640135 MiB]
[512 logical sector size, 512 physical sector size]
[2 threads]
Wait 30 seconds..............................
Results: 89 seeks/second, 11.115 ms random access time (138686347 < offsets < 639926786977)

this is the baseline ... now, my lvm raid0 setup of 4 disk like this:

sudo ./seeker_baryluk /dev/vg1/p2p 2
Seeker v3.0, 2009-06-17, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/vg1/p2p [251658240 blocks, 128849018880 bytes, 120 GB, 122880 MB, 128 GiB, 128849 MiB]
[512 logical sector size, 512 physical sector size]
[2 threads]
Wait 30 seconds..............................
Results: 202 seeks/second, 4.931 ms random access time (8129940 < offsets < 128793447000)

sudo ./seeker_baryluk /dev/vg1/p2p 4
Seeker v3.0, 2009-06-17, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/vg1/p2p [251658240 blocks, 128849018880 bytes, 120 GB, 122880 MB, 128 GiB, 128849 MiB]
[512 logical sector size, 512 physical sector size]
[4 threads]
Wait 30 seconds..............................
Results: 300 seeks/second, 3.332 ms random access time (25011300 < offsets < 128847923580)

sudo ./seeker_baryluk /dev/vg1/p2p 12
Seeker v3.0, 2009-06-17, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/vg1/p2p [251658240 blocks, 128849018880 bytes, 120 GB, 122880 MB, 128 GiB, 128849 MiB]
[512 logical sector size, 512 physical sector size]
[12 threads]
Wait 30 seconds..............................
Results: 464 seeks/second, 2.153 ms random access time (3934260 < offsets < 128826077520)

sudo ./seeker_baryluk /dev/vg1/p2p 24
Seeker v3.0, 2009-06-17, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/vg1/p2p [251658240 blocks, 128849018880 bytes, 120 GB, 122880 MB, 128 GiB, 128849 MiB]
[512 logical sector size, 512 physical sector size]
[24 threads]
Wait 30 seconds..............................
Results: 575 seeks/second, 1.738 ms random access time (8817660 < offsets < 128841963000)

sudo ./seeker_baryluk /dev/vg1/p2p 64
Seeker v3.0, 2009-06-17, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/vg1/p2p [251658240 blocks, 128849018880 bytes, 120 GB, 122880 MB, 128 GiB, 128849 MiB]
[512 logical sector size, 512 physical sector size]
[64 threads]
Wait 30 seconds..............................
Results: 686 seeks/second, 1.456 ms random access time (2064300 < offsets < 128837962620)

look like with bigger thread numbers come an increased performance on my lvm setup ... so nice!

;-D

ram = 4 GiB DDR II 800
cpu = Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz
motheboard = ip35 chipset northbridge

iSCSI openfiler

Hi !

just for fun I installed OpenFiler on a server with 14x72gb fiberchannel 1gig disk connected to it.
installing CentOS in VMware on the iscsi target that OpenFiler shared and did a test..

sudo hdparm -t --direct /dev/sda

/dev/sda:
Timing O_DIRECT disk reads: 232 MB in 3.03 seconds = 76.69 MB/sec

here without DIRECt

sudo hdparm -t /dev/sda

/dev/sda:
Timing buffered disk reads: 116 MB in 3.03 seconds = 38.33 MB/sec

./seeker /dev/sda
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [194560MB], wait 30 seconds..............................
Results: 6190 seeks/second, 0.16 ms random access time

./seeker_baryluk /dev/sda 32
Seeker v3.0, 2009-06-17, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [398458880 blocks, 204010946560 bytes, 190 GB, 194560 MB, 204 GiB, 204010 MiB]
[512 logical sector size, 512 physical sector size]
[32 threads]
Wait 30 seconds.........................
Results: 12214 seeks/second, 0.082 ms random access time (845215 < offsets < 204010761120)

hdparm

One question for all the noobs who read this:
If I run hdparam -t on my hard disc won't it write all over it, which would be a problem for the O/S! ^^

Of course NOT. hdparm -t only

Of course NOT. hdparm -t only READS from disk. In sequential manner, starting at the beginning.

super fast

Intel x25e (32g SSD) raid 10 over 8 drives connected to a dell Perc6e SAS controller

Seeker v3.0, 2009-06-17, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sdg [306708480 blocks, 157034741760 bytes, 146 GB, 149760 MB, 157 GiB, 157034 MiB]
[512 logical sector size, 512 physical sector size]
Wait 30 seconds..............................
Results: 19021 seeks/second, 0.053 ms random access time (272683 < offsets < 157034496133)

19,021 seeks/second!!! This box is the ultimate db server.

iodrives are 6 times faster

iodrives are 6 times faster then the fastest x25 to yours is not the best

RAID0: 2 x MemoRight GT 32

That sure is an excellent RAID array. Although a bit expensive. ;)

Could you please send the output of hdparm -t too?

Here's my system disk, software (MD) RAID0 of two Memoright GT 32 SSD disks, 64GB of plenty fast storage.

Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/md0 [61310MB], wait 30 seconds..............................
Results: 5358 seeks/second, 0.19 ms random access time

hdparm -t /dev/md0

/dev/md0:
Timing buffered disk reads: 644 MB in 3.00 seconds = 214.34 MB/sec

here you go

[root@server ~]# hdparm -t /dev/sdg

/dev/sdg:
Timing buffered disk reads: 718 MB in 3.01 seconds = 238.81 MB/sec

Hi, i prepared multithreaded version

Hi,

i made multithreaded version o seeker.c

http://smp.if.uj.edu.pl/~baryluk/seeker_baryluk.c

i also fixed few problems, and added additionall diagnostics.

compile with:
gcc -o seeker_baryluk -O2 -march=native seeker_baryluk.c -pthread

run:

./seeker_baryluk device number_of_threads

(default 1 thread)

example: md0(mirror sda2+sdb2)

./seeker /dev/sda2 1: 115 r/s
./seeker /dev/sdb2 1: 113 r/s
./seeker /dev/sda2 2: 113 r/s
./seeker /dev/sdb2 2: 114 r/s
./seeker /dev/sda2 128: 117 r/s
./seeker /dev/sdb2 128: 118 r/s
./seeker /dev/md0 1: 115 r/s
./seeker /dev/md0 2: 225 r/s
./seeker /dev/md0 4: 213 r/s
./seeker /dev/md0 8: 218 r/s
./seeker /dev/md0 16: 214 r/s
./seeker /dev/md0 32: 215 r/s
./seeker /dev/md0 32: 225 r/s
./seeker /dev/md0 64: 221 r/s

(on different console one can run: 'iostat md0 sda2 sdb2 -x 1', and analyze load)

interepretation depends on exact setup, and needs knowledge of some mechanisms used in kernel.

here is an direct i/o version

Hi, here's a version that uses direct i/o for testing it, patched one of my colleages. Also, i've been told that it wasn't testing it accurately because it was choosing its starting location as a random number of bytes into the disk, then the most of the time you will need to read two sectors to get 512 bytes.
only if you choose a starting byte divisible by 512 will you read your whole 512 bytes from a single sector. Using direct i/o with memory and buffer alignment fixes this issue as well.

#gcc -o seeker_shez -O2 -march=x86-64 seeker_shez.c -pthread

it gives a warning at the end of the compiling but will be fine.

-------------- cut here -----------------------
#define _LARGEFILE64_SOURCE

#ifndef _REENTRANT
#define _REENTRANT
#endif
#include

#include
#include
#include
#include
#include
#include
#include
#include
#include
#include

#define BLOCKSIZE 512
//#define TIMEOUT 30
#define O_DIRECT 00040000

pthread_mutex_t muteks = PTHREAD_MUTEX_INITIALIZER;

int count;
int TIMEOUT;
time_t start;
off64_t maxoffset = 0;
off64_t minoffset = 249994674176000uLL;

int threads;

typedef struct {
int id;
int fd;
int run;
char* filename;
unsigned int seed;
unsigned long long numbytes;
char* buffer;
int count;
off64_t maxoffset;
off64_t minoffset;
} parm;

parm *p;

void done() {
int i;
time_t end;

time(&end);

if (end < start + TIMEOUT) {
printf(".");
alarm(1);
return;
}

for (i = 0; i < threads; i++) {
p[i].run = 0;
}
}

void report() {
if (count) {
printf(".\nResults: %d seeks/second, %.3f ms random access time (%llu < offsets < %llu)\n",
count / TIMEOUT, 1000.0 * TIMEOUT / count, (unsigned long long)minoffset, (unsigned long long)maxoffset);
}
exit(EXIT_SUCCESS);
}

void handle(const char *string, int error) {
if (error) {
perror(string);
exit(EXIT_FAILURE);
}
}

void* f(void *arg) {
int retval;
off64_t offset;

parm *p = (parm*)arg;

srand(p->seed);

/* wait for all processes */
pthread_mutex_lock(&muteks);
pthread_mutex_unlock(&muteks);

while (p->run) {
offset = (off64_t) ( (unsigned long long) (p->numbytes * (rand_r(&(p->seed)) / (RAND_MAX + 1.0) )));
// do blocksize aligned seeks
offset = offset & (~((off64_t) 0) & (~(BLOCKSIZE-1))) ;
//printf("%d %x\n", p->id, (unsigned long long )offset);
retval = lseek64(p->fd, offset, SEEK_SET);
handle("lseek64", retval == (off64_t) -1);
retval = read(p->fd, p->buffer, BLOCKSIZE);
handle("read", retval < 0);

p->count++;
if (offset > p->maxoffset) {
p->maxoffset = offset;
} else if (offset < p->minoffset) {
p->minoffset = offset;
}
}

//pthread_exit(NULL);
return NULL;
}

int main(int argc, char **argv) {
int fd, retval;
int physical_sector_size = 0;
size_t logical_sector_size = 0ULL;
unsigned long long numblocks, numbytes;
unsigned long long ull;
unsigned long ul;
pthread_t *t_id;
pthread_attr_t pthread_custom_attr;
int i;

setvbuf(stdout, NULL, _IONBF, 0);

printf("Seeker v3.0, 2009-06-17, "
"http://www.linuxinsight.com/how_fast_is_your_disk.html\n");

if (!(argc == 3 || argc == 4)) {
printf("Usage: %s device seconds [threads]\n", argv[0]);
exit(1);
}

TIMEOUT = atoi(argv[2]);

threads = 1;
if (argc == 4) {
threads = atoi(argv[3]);
}

//pthread_mutex_init(&muteks, NULL);

fd = open(argv[1], O_RDONLY | O_LARGEFILE | O_DIRECT);
handle("open", fd < 0);

#ifdef BLKGETSIZE64
retval = ioctl(fd, BLKGETSIZE64, &ull);
numbytes = (unsigned long long)ull;
#else
retval = ioctl(fd, BLKGETSIZE, &ul);
numbytes = (unsigned long long)ul;
#endif
handle("ioctl", retval == -1);
retval = ioctl(fd, BLKBSZGET, &logical_sector_size);
handle("ioctl", retval == -1 && logical_sector_size > 0);
retval = ioctl(fd, BLKSSZGET, &physical_sector_size);
handle("ioctl", retval == -1 && physical_sector_size > 0);
numblocks = ((unsigned long long)numbytes)/(unsigned long long)BLOCKSIZE;
printf("Benchmarking %s [%llu blocks, %llu bytes, %llu GB, %llu MB, %llu GiB, %llu MiB]\n",
argv[1], numblocks, numbytes, numbytes/(1024uLL*1024uLL*1024uLL), numbytes / (1024uLL*1024uLL), numbytes/(1000uLL*1000uLL*1000uLL), numbytes / (1000uLL*1000uLL));
printf("[%d logical sector size, %d physical sector size]\n", physical_sector_size, physical_sector_size);
printf("[%d threads]\n", threads);
printf("Wait %d seconds", TIMEOUT);

t_id = (pthread_t *)malloc(threads*sizeof(pthread_t));
handle("malloc", t_id == NULL);
pthread_attr_init(&pthread_custom_attr);
p = (parm *)malloc(sizeof(parm)*threads);
handle("malloc", p == NULL);

time(&start);

pthread_mutex_lock(&muteks);

srand((unsigned int)start*(unsigned int)getpid());

for (i = 0; i < threads; i++) {
p[i].id = i;
p[i].filename = argv[1];
p[i].seed = rand()+i;
p[i].fd = dup(fd);
handle("dup", p[i].fd < 0);
p[i].buffer = memalign(512*8, sizeof(char)*BLOCKSIZE);
printf("\n%x\n", (int)(&(p[i].buffer)));

p[i].numbytes = numbytes;
handle("malloc", p[i].buffer == NULL);
p[i].run = 1;
p[i].count = 0;
p[i].minoffset = minoffset;
p[i].maxoffset = maxoffset;

retval = pthread_create(&(t_id[i]), NULL, f, (void*)(p+i));
handle("pthread_create", retval != 0);
}

sleep(1);

time(&start);
signal(SIGALRM, &done);
alarm(1);

pthread_mutex_unlock(&muteks);

for (i = 0; i < threads; i++) {
pthread_join(t_id[i], NULL);
}

for (i = 0; i < threads; i++) {
count += p[i].count;
if (p[i].maxoffset > maxoffset) {
maxoffset = p[i].maxoffset;
}
if (p[i].minoffset < minoffset) {
minoffset = p[i].minoffset;
}
}

report();

/* notreached */
return 0;
}

Multi-thread, multi-processor, RAID

Thanks for posting this version.
I get more accurate results of how
my database will access my disks
with it because of the multi-threading.

One interesting note: on an internal
drive array, my seek times have reduced
from over 10ms to 0.02ms as I add more
threads. This only happens for one of
my drive arrays, and I think it may be
because each run looks at the same
set of sectors and therefore the blocks
get cached in the RAID controller and
served directly from its RAM and not
from a disk seek. Is that possible?
(Sorry, I can't tell from the code.)

My mistake

It was serving from the cache -- because I ran it on the 100 MB partition, not the 568 GB partition . . .

other results

other test:

mirror using hp controler (2x160):
threads seeks/s
1 78
2 132
4 132
8 166
16 194
32 196
64 218
128 232
256 242
512 254

raid5 (10 disks, each 160GB, 2 parity)

1 66
2 125
4 218
8 346
16 493
32 645
64 780
128 864
256 866
512 888

nice.

not 10 disks

Small error, it is 9 disks (8 data + 1 parity + 1 spare)

Multithreaded version

Hey Witold, this is great news! You did something I always wanted to do but got distracted with life. :) Now, I'm currently on vacation where I don't have any real hardware to test this, but I'll surely give this some real testing next month, stay tuned.

Although your simple mirror test already reveals very interesting data, for instance that Linux md driver definitely works great, not that we thought otherwise. :)

Good job!

Single drive performance

Actually for single drive with lots of threads i was expecting better behaviour, because even if requests are random, they should queue in kernel nicly, and can be ordered. Mayby still track-to-track latency is too high. My disk is sata2, but is connected to sata1 controler, so NCQ isn't used, this can also be problem (and it will be instructive to check how good it works).

This is a wrong expectation.

This is a wrong expectation. You would've been right if we were talking about writing to the disk, but reading is synchronous and thus not queued, but executed immediately. So, the disk head (after a kernel call) goes to satisfy your first request before it even returns control to your program and lets it submit another request. Because CPU is much faster than disk, that makes disk 100% busy. If you dispatch two threads, both of them get close to 50% of disk utilization. When you add the numbers, you typically get the same result as you would if you only run one thread. That's just how it works, disk has only one arm and can satisfy only one request at a time, basically.

Sure about that?

My threaded numbers above say otherwise. Unless seeker.c is flawed. I think what you're failing to take into account is that the more threads you have with requests outstanding, the more the kernel I/O driver and/or the NCQ logic on the drive itself can optimize the head sweep pattern to satisfy all the queued requests with the least amount of head movement. The more requests you can queue, the better the optimization, and thus, the better the throughput. To generate sufficient queued requests often requires multiple process threads. With a single thread you end up with serial I/O requests being queued, such as "read sector 1, read sector 2, read sector 3, ... read sector 16384". With this scenario, the disk head is going to move in exactly that order to satisfy the queued requests, which are "in order". Lets say sectors 1-16384 cover exactly 4 disk cylinders. Now, if we parallelize this with 16 threads, you end up with an I/O queue something like

read sector:
1,16,32,48,64,80,96,112,128,144,160,176,192,208,224,240,256
2,17,33,49,65,81,97,113,129,145,161,177,193,209,225,241,257
3,18,34,50,66,82,98,114,130,146,162,178,194,210,226,242,258
...
...

With the first, sequential, queue above, the drive firmware will only move the head to start reading sectors on cylinder 2 after all the requests for the sequential sectors on cylinder 1 have been read. So, on your 7200 rpm disk, hundreds of opportunities to read sectors on adjacent cylinders during each revolution are lost because the queue says to read 1,2,3,4,5...

Now, with the threaded parallel example above, the drive firmware has the opportunity to read many adjacent cylinder sectors on the same revolution of the disk platter.

Obviously the voice coil actuator that moves the head isn't fast enough to grab adjacent sectors across, say 16 cylinders, and still get back to cylinder 1 and not miss grabbing the next sequential sector on cylinder 1 in the queue. But, it is fast enough to grab a nearby sector on an adjacent cylinder on occasion.

This is basically exactly what NCQ, TCQ, and similar techniques do to increase single disk throughput. The "deadline" kernel I/O buffer code I mentioned in another post today does this as well. This is why you typically don't see substantial performance increases with NCQ on single user workstation apps and benchys. You really need a multiuser or multi-service workload such as busy databases or high volume smtp mail in order to see the benefits of I/O queuing. SCSI disks and controllers have had I/O queuing for over a decade specifically to speed up multi-user workloads, and this is one of the reasons why SCSI has been so coveted in the enterprise server space for over a decade. This queuing technology finally filtered down to the desktop drives and controllers, and to operating system that run on them. But, it takes a multi-thread or multi-process workload to see the benefits. The threaded version of seeker.c generates this type of workload, and that's why you're seeing the substantially better numbers as folks here test with higher and higher thread counts. That is until they hit an upper limit on the number of threads, where there is no more queuing optimization to be had in their hardware or OS.

You're right!

> I think what you're failing to take into account is that the more threads you have with requests outstanding, the more the kernel I/O driver and/or the NCQ logic on the drive itself can optimize the head sweep pattern to satisfy all the queued requests with the least amount of head movement. The more requests you can queue, the better the optimization, and thus, the better the throughput.

Actually, both you and Witek are completely right! I reread the thread, and it seems I missed the "with lots of threads" part in Witek's reply, staying in my mind with my single-threaded seeker. Yes, with more threads and NCQ enabled, kernel elevator should help to obtain slightly better result even with only one spindle under test.

Your whole reply is great, explains things really really well, and I share your thoughts completely.

Fun thing is, if SSD's overtake the market from the mechanical disks in, say 10 years(?) all this knowledge we collected and implemented through the years (all kinds of I/O schedulers, elevators and such) will become obsolete and we will spend time optimizing something else (programming for multiple cores, maybe?).

And that is not unlike what happened on the memory management front, I remember doing stuff with kswapd code, optimizing things and so... And now I'm typing this on a desktop which not only doesn't have swap, but also has all that heavily tuned kswapd code compiled out from the kernel. :) Memory just got cheap enough, so there's no excuse for not buying as much as you need, and 4GB ought to be enough for anyone. :)

hmm

I was talking about asynchonous reading from multiple threads. Disk had one arm, and my requests are random, but, i new kernel have 2 or 100 random requests and the same time to server, and doesn't do any optimalisation it is still random. I was thinking that kernel actually reorders this requests, to make arm moving less random, and more in small steps beetwen tracks.

/i new/if

/i new/if now/

http://en.wikipedia.org/wiki/Shortest_seek_first
http://en.wikipedia.org/wiki/C-SCAN
http://en.wikipedia.org/wiki/Shortest_seek_first

Only few of the many disk scheduling algorithms. I don't know how CFQ works exactly.

Was also have ncq http://en.wikipedia.org/wiki/NCQ

BTW. If i do single read from single thread but to large buffer (few megabytes), mirroring layer actually puts parts of the buffer to be readed from different disks.

Seeker & hdparm results for new G.Skill Falcon FM-25S2S-128GBF1

Wow...

$ sudo ./seeker /dev/sda
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [122104MB], wait 30 seconds..............................
Results: 5108 seeks/second, 0.20 ms random access time

$ sudo hdparm -t --direct /dev/sda
/dev/sda:
Timing O_DIRECT disk reads: 392 MB in 3.00 seconds = 130.64 MB/sec

System Details:

$ uname -a
Linux 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux
$ dmesg | grep FALCON
[ 2.016566] ata1.00: ATA-7: G.SKILL FALCON 128GB SSD, 1370, max UDMA/133
[ 2.032548] scsi 0:0:0:0: Direct-Access ATA G.SKILL FALCON 1 1370 PQ: 0 ANSI: 5

$ sudo fdisk -l
Disk /dev/sda: 128.0 GB, 128035676160 bytes
32 heads, 32 sectors/track, 244208 cylinders
Units = cylinders of 1024 * 512 = 524288 bytes

Is the standard seeker a good tool to check random access time?

After reading this article I was using seeker to benchmark my hd partition.
I discovered that in the same hd running seeker on a partition of 20 GB I got 5 ms random access time
while running it on a partition of 1.6 TB I got 14 ms random access time.
I gave a look at the seeker code and I found out the point.
Seeker randomly access on the whole hd surface.
So one should compare same capacity hd to have correct comparisons.
Or at least try to access the same "real disk data occupancy" in order to compare the results.
I modified seeker to access always to the first 1 GB of the hd, it is enough to add this line:

if (numblocks > 2048*1000) {numblocks=2048*1000;}

just after

printf("Benchmarking %s [%luMB], wait %d seconds",
argv[1], numblocks / 2048, TIMEOUT);
In this way the two partitions gave the same results.

In the case of your test could you redo it asking to access to the first 18 GB of your hard disks
(in such a way you will compare random access on the same data area for all the hd)?
That means putting:
if (numblocks > 2048*18000) {numblocks=2048*18000;}
just after
printf("Benchmarking %s [%luMB], wait %d seconds",
argv[1], numblocks / 2048, TIMEOUT);

In fact the throughput of the HD (in MB/s) and not how fast the head reach a given point on the surface is relevant.

thanks,

Biagio

heare I paste the modified code of seeker:
#define _LARGEFILE64_SOURCE

#include
#include
#include
#include
#include
#include
#include
#include
#include

#define BLOCKSIZE 512
#define TIMEOUT 30

int count;
time_t start;

void done()
{
time_t end;

time(&end);

if (end < start + TIMEOUT) {
printf(".");
alarm(1);
return;
}

if (count) {
printf(".\nResults: %d seeks/second, %.2f ms random access time\n",
count / TIMEOUT, 1000.0 * TIMEOUT / count);
}
exit(EXIT_SUCCESS);
}

void handle(const char *string, int error)
{
if (error) {
perror(string);
exit(EXIT_FAILURE);
}
}

int main(int argc, char **argv)
{
char buffer[BLOCKSIZE];
int fd, retval;
unsigned long numblocks;
off64_t offset;

setvbuf(stdout, NULL, _IONBF, 0);

printf("Seeker v2.0, 2007-01-15, "
"http://www.linuxinsight.com/how_fast_is_your_disk.html\n");

if (argc != 2) {
printf("Usage: seeker \n");
exit(EXIT_SUCCESS);
}

fd = open(argv[1], O_RDONLY);
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);
if (numblocks > 2048*18000) {numblocks=2048*18000;}

time(&start);
srand(start);
signal(SIGALRM, &done);
alarm(1);

for (;;) {
offset = (off64_t) numblocks * random() / RAND_MAX;
retval = lseek64(fd, BLOCKSIZE * offset, SEEK_SET);
handle("lseek64", retval == (off64_t) -1);
retval = read(fd, buffer, BLOCKSIZE);
handle("read", retval < 0);
count++;
}
/* notreached */

This is because on smaller

This is because on smaller partition head arm don't need to move such long distance as on whole disk.

I think you patch makes comparission harder. Orginal seeker was trying to simulate worst case behaviour under full disk. It isn't worst case possible, but near it and is easier.

Not really true

Look at it this way, whenever you provide a partition for some of your file systems, your data can be scattered throughout it all. Thus the access time of the whole partition will decide how fast you can access your data, when the access pattern gets close to random. /var/lib/dpkg/info folder on Debian based machines comes to mind. It's awfully slow after some time because that folder has so many files and they get scattered throughout your whole partition, not only the first 1GB! So with your change, you're measuring something else.

Think of it in another way, who uses only the first 1GB of their brand new x00 GB disk? Nobody I know. Yeah, it would be fast, but that's just not how disks are used, you use all the space and normally your disk head visits ALL the tracks on the disk. seeker measures how much time typically (on average) passes before you get to your data in such cases.

Believe me, every mechanical hard disk performance degrade very easily to only few hundreds of KB/s in real world workloads, I see it every day. Your modification of the simple benchmark would claim that on such disk you have some high xy MB/sec, but it would lie. Unless you really ever use only the first one percent or less of your disks?

Time to buy SSD. ;) It's fast, cold and completely silent. 0.1ms access time says seeker, and it knows. :)

seeker

answering "admin"

You are right .But if you want to benchmark different support
at least you should be sure that they have the same size.
Reading the first GB (or the last as you like) gives a fair
comparison among them.Comparing an hd of 20 GB and one of 120 GB is incorrect for the second (at least you should compare the two reading the first 20 GB of both).

WD Raptor 2 x2 RAID 0 + WD 2TB RAID0

3Ware 9650SE RAID Controller
/dev/sda is a WD Raptor2 (10Krpm) RAID0 with 2 Drives:
hdparm-
Timing cached reads: 19582 MB in 2.00 seconds = 9804.29 MB/sec
Timing buffered disk reads: 580 MB in 3.00 seconds = 193.15 MB/sec
seeker-
[poeticrpm@builtbeast testseek]$ sudo ./seeker /dev/sda
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [286082MB], wait 30 seconds..............................
Results: 139 seeks/second, 7.18 ms random access time

/dev/sdb is a WD 2TB RAID0 with 2 drives (1TB each):
hdparm-
/dev/sdb:
Timing cached reads: 19364 MB in 2.00 seconds = 9696.45 MB/sec
Timing buffered disk reads: 612 MB in 3.01 seconds = 203.53 MB/sec
seeker-
[poeticrpm@builtbeast testseek]$ sudo ./seeker /dev/sdb
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sdb [1907328MB], wait 30 seconds..............................
Results: 81 seeks/second, 12.30 ms random access time

If I understand this correctly, im not going to get much better seek time adding more drives to a RAID (just more MB/sec). Im also guessing that the TB RAID is faster MB/sec wise because of a larger cache size? Not that it really matters.. Im really fortunate to be rolling around with this desktop...

Seek time (RAID0 case)

Well, GSF1200S, it depends. If you have (mostly) single user tasks, then your RAID0 really is like a single (twice as big) disk. 139 seeks/sec and that's it. seeker is single-threaded, so it mostly resembles what you would get out in such an environment.

But, if you run two disk intensive applications, then each of it could get close to that 139 seeks/sec and that makes a difference.

In other words, if you run something like "seeker & sleep 1; seeker" (two seekers at a time, and don't forget that sleep, it's important!) on a single disk from your first RAID, each of it would get close to 70 seeks/sec. But running them on a RAID0, each of them should come close to 139 seeks/sec.

All the above is applying only to a random workload. When you manipulate (read, write, copy) big files, RAID0 is helpful even in a single-threaded case, because readahead mechanism works for you. While your application (cp or whatever) consumes blocks read from one disk, readahead is already pulling blocks from the next disk, so they're ready sooner. So both disks can be utilized at a same time giving you twice the bandwidth of a single disk.

Toshiba MK2051GS (200GB laptop drive)

My numbers for what it's worth:

Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [190782MB], wait 30 seconds.............................
Results: 63 seeks/second, 15.71 ms random access time

$ sudo hdparm -tT /dev/sda

/dev/sda:
Timing cached reads: 5344 MB in 2.00 seconds = 2677.56 MB/sec
Timing buffered disk reads: 210 MB in 3.02 seconds = 69.43 MB/sec

...and thanks for the utility and the effort put in!

Cheers.

Western Digital - WD5000BEVT (5400 rpm)

Numbers for my new laptop drive:

Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [476940MB], wait 30 seconds..............................
Results: 60 seeks/second, 16.46 ms random access time

$ sudo hdparm -tT /dev/sda

/dev/sda:
Timing cached reads: 6706 MB in 2.00 seconds = 3361.37 MB/sec
Timing buffered disk reads: 238 MB in 3.01 seconds = 79.05 MB/sec
$

How about the "promised" table with all the results ;-)

Thanks again & regards!

My drivespeeds

500Gb Samsung SATA disk from Q2/2008:
Benchmarking /dev/sdd1 [476937MB], wait 30 seconds.............................
Results: 57 seeks/second, 17.48 ms random access time

----------------------
150Gb WD Velociraptor (10000rpm SATA II/300 disk) from Q1/2009
Benchmarking /dev/sda1 [137234MB], wait 30 seconds..............................
Results: 143 seeks/second, 6.99 ms random access time

-----------------------
1Tb Samsung SATA II disk from Q1/2009
Benchmarking /dev/sdb1 [953867MB], wait 30 seconds.............................
Results: 57 seeks/second, 17.27 ms random access time

------------------------
60Gb OCZ CoreV2 SSD from Q1/2009
Benchmarking /dev/sdc1 [61130MB], wait 30 seconds..............................
Results: 3479 seeks/second, 0.29 ms random access time

So ... yes. Velociraptor lives up to it's reputation. Hence it has the privilege of being a systems disk. But the OCZ SSD vastly outperforms all the other disks.

Intel SSD Disks

Hi there
I've got 2 Intel SSD Disks as Raid1 in a SAN System connected over 4GB Fibre Channel and also 12 SAS Disk also conneceted over FC in the SAN configured as Raid1+0

Results:
2x Raid1 80GB Intel SSD Disks:
./seeker /dev/mapper/2228f000155171c41
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/mapper/2228f000155171c41 [75340MB], wait 30 seconds..............................
Results: 3955 seeks/second, 0.25 ms random access time

12x 15k 300GB SAS Disks Raid1+0:
./seeker /dev/mapper/2225e0001558e52af
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/mapper/2225e0001558e52af [706560MB], wait 30 seconds.............................
Results: 171 seeks/second, 5.82 ms random access time

It appears your SAN storage

It appears your SAN storage controller was a bit busy at the time of your test. What make/model is it? 12xSAS RAID 10 with assuming at least 512MB cache in the SAN controller-- those numbers on an idle SAN would be _MUCH_ higher than what you've posted here. See if you can test late on a Saturday night. Your numbers will likely be 10x greater if not more.

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

You need to run your DD's w/ O_DIRECT

W/O Direct I/O, you're seeing caching effects. DD has a flag for O_DIRECT.

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

upgraded to Crucial 64 GB RealSSD C300 (ubuntu 10.10 laptop)

the specs for the ssd claim:
seq. read: up to 355 MB/s
seq. write: up to 75 MB/s
iops:
* random 4k read: 60k
* random 4k write: 15k

here's what i measured:

sudo ./seeker /dev/sda

Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [61057MB], wait 30 seconds..............................
Results: 7119 seeks/second, 0.14 ms random access time

sudo hdparm -tT /dev/sda

/dev/sda:
Timing cached reads: 13656 MB in 1.99 seconds = 6851.98 MB/sec
Timing buffered disk reads: 778 MB in 3.00 seconds = 259.11 MB/sec

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 1 while 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

2002 Seagate Barracuda IV

2002 Seagate Barracuda IV ATA100/2M/7200
66 seeks/sec, 14.9 ms RAT, 40MB/sec

2006 Samsung SP2504C SATAII/8M/7200
68 seeks/sec, 14.7 ms RAT, 70MB/sec

The Samsung is known for it's low noise, not performance.
Both disks are 1-1.5 ms slower than manufacturer specs.

Raptor WD1500ADFD-0 result

Here the result of a WD1500ADFD-0 150GB Raptor drive with NCQ enabled:

Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [143089MB], wait 30 seconds..............................
Results: 112 seeks/second, 8.90 ms random access time

Here's my numbers from a

Here's my numbers from a raptor 74G:

Timing buffered disk reads: 138 MB in 3.01 seconds = 45.81 MB/sec

Results: 123 seeks/second, 8.09 ms random access time

I was actually wondering if they lived up to the hype...and still am kinda. The seeker output looks pretty normal, but my hdparm is way lower than others have posted. That's the average number there, I've had some higher and some lower. I've noticed my drive not performing as well as newer 3.0gb/s sata drives when using bonnie++ to benchmark.

74GB 10K rpm Raptor

I was very impressed by my drives perfomance.

Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sdb [70911MB], wait 30 seconds..............................
Results: 124 seeks/second, 8.05 ms random access time

Coool!

Thank you! For the record, here are the exact numbers for the 10krpm SCSI:

Results: 118 seeks/second, 8.43 ms random access time

Very, very close. So, after all, Raptors live up to the expectations. At least in single threaded tasks (the utility should be made multithreaded if and when I find time to write the additional functionality).

hdparm and seeker with EVMS md devices?

Hi,

Thank you for this fantastic discussion and the very cool seeker utility. It seems that most of these arrays are being built using mdadm. However, I am using EVMS. My understanding is that EVMS is strictly a management layer...that EVMS uses md as well to create RAIDs, etc. However, when I use evms_query, for example, it will tell me that the device is md0. However, running seeker on /dev/md0 does not work...seeker reports the device is 0MB and some incorrect value for seeks (like 650343). So what is the proper path to use to point to this EVMS-create md device?

Thank you for any help!
-Thomas

/dev/evms/* ?

Haven't used EVMS personally, so I can't know for sure, but I see /dev/evms/volx or similar devices mentioned when people talk about EVMS. So, try something like that.

The other problem could be that your device is too big, seeker still has some bug that makes it fail on very big devices (in TB area). Can you try smaller partition, if that's the case (something like 100GB for test)?

hdparm -t result

And hdparm -t for this drive:

Timing buffered disk reads: 250 MB in 3.01 seconds = 83.13 MB/sec

Can some one do this with

Can some one do this with more recent drives? All of the drives in this test are at least 3 years old. Current SATA 7200 drives have STRs of 75MB/s while I am told that SCSI disks have STRs of over 90MB/s.

I disagree with the conclusion. It is true that the seek times have not changed much but each new generation of drive that has a higher aerial density and thus have a higher STR.

Recent drives

Device: SEAGATE ST373455SS (SAS, 15000tpm, 73GB)
seeker /dev/sda
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [70007MB], wait 30 seconds..............................
Results: 169 seeks/second, 5.90 ms random access time
hdparm -tT /dev/sda
/dev/sda:
Timing cached reads: 4492 MB in 2.00 seconds = 2244.32 MB/sec
Timing buffered disk reads: 378 MB in 3.01 seconds = 125.50 MB/sec

Device Maxtor 6H400F0 (SATA, 7200tpm, 400GB)
seeker /dev/sdb
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sdb [381554MB], wait 30 seconds..............................
Results: 69 seeks/second, 14.49 ms random access time
hdparm -tT /dev/sdb
/dev/sdb:
Timing cached reads: 4356 MB in 2.00 seconds = 2177.83 MB/sec
Timing buffered disk reads: 204 MB in 3.01 seconds = 67.83 MB/sec

SCSI RAID 10 Array.

Okey, here you have some RAID 10 (stripe + mirror, with 4 disks) configs and tests.

First one is a Dual Opteron 250, 4Gb RAM with SCSI RAID 10 on hardware card. (Total 70Gb Space)
4 x SEAGATE 36Gb 15.000 RPM SCSI

Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/md2 [70006MB], wait 30 seconds..............................
Results: 177 seeks/second, 5.64 ms random access time

Second one is a Dual Xeon 2.4 Ghz, 4Gb RAM, with SATA RAID 10 on a 3ware Hardware card, I got many different values depending on what partition I tested.

On the bigger partition: (/home at 175Gb)
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda8 [175491MB], wait 30 seconds..............................
Results: 76 seeks/second, 13.12 ms random access time

On a not so big one: (/var at 20Gb)
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [20158MB], wait 30 seconds..............................
Results: 103 seeks/second, 9.65 ms random access time

Hope it helps someone :)

Regards.
CAS company :: www.cascompany.com

Results on Hitachi

Results on Hitachi HDS721612PLA380 (120 GB SATA):

/dev/sda: Timing buffered disk reads: 166 MB in 3.02 seconds = 55.01 MB/sec

WD2500KS SATA /dev/sda:

WD2500KS SATA
/dev/sda:
Timing cached reads: 1342 MB in 2.00 seconds = 671.04 MB/sec
Timing buffered disk reads: 182 MB in 3.00 seconds = 60.58 MB/sec
Benchmarking /dev/sda [238475MB], wait 30 seconds.............................
Results: 72 seeks/second, 13.82 ms random access time

Kingston DT2 4GB
/dev/sdb:
Timing cached reads: 1350 MB in 2.00 seconds = 675.55 MB/sec
Timing buffered disk reads: 28 MB in 3.16 seconds = 8.85 MB/sec

Benchmarking /dev/sdb [3936MB], wait 30 seconds..............................
Results: 324 seeks/second, 3.08 ms random access time

How fast is your disk?

Apr 11 19:58:22 trac ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Apr 11 19:58:22 trac ata3.00: ATA-7: Maxtor 6V250F0, VA111900, max UDMA/133
Apr 11 19:58:22 trac ata3.00: 490234752 sectors, multi 0: LBA48 NCQ (depth 31/32)
Apr 11 19:58:22 trac ata3.00: configured for UDMA/133
Apr 11 19:58:22 trac ata7.00: ATA-7: Maxtor 6V250F0, VA111900, max UDMA/133
Apr 11 19:58:22 trac ata7.00: 490234752 sectors, multi 0: LBA48 NCQ (depth 31/32)
Apr 11 19:58:22 trac ata7.00: configured for UDMA/133
Apr 11 19:58:22 trac ata8: SATA link down (SStatus 0 SControl 300)
Apr 11 19:58:22 trac scsi 2:0:0:0: Direct-Access ATA Maxtor 6V250F0 VA11 PQ: 0 ANSI: 5
Apr 11 19:58:22 trac scsi 6:0:0:0: Direct-Access ATA Maxtor 6V250F0 VA11 PQ: 0 ANSI: 5

[root@trac ~]# time dd if=/dev/zero of=/home/test bs=1M count=1024 1024+0 records in
1024+0 records out
1073741824 bytes (1,1 GB) copied, 15,9879 s, 67,2 MB/s

real 0m16.277s
user 0m0.000s
sys 0m2.740s
[root@trac ~]# hdparm -Tt /dev/md2

/dev/md2:
Timing cached reads: 2190 MB in 2.00 seconds = 1095.29 MB/sec
Timing buffered disk reads: 210 MB in 3.03 seconds = 69.40 MB/sec

Seeker

Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/md2 [225623MB], wait 30 seconds..............................
Results: 68 seeks/second, 14.61 ms random access time

Old SCSI IBM SERVERRAID II PCI Controller

[root@wpdev pacman.d]# hdparm -Tt /dev/sda3

/dev/sda3:
Timing cached reads: 568 MB in 2.00 seconds = 283.49 MB/sec
Timing buffered disk reads: 34 MB in 3.17 seconds = 10.74 MB/sec

[root@wpdev home]# time dd if=/dev/zero of=/home/test bs=1M count=1024

1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 95.0537 s, 11.3 MB/s

real 1m35.091s
user 0m0.004s
sys 0m5.352s

Seeker

Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda3 [34769MB], wait 30 seconds..............................
Results: 110 seeks/second, 9.03 ms random access time

hdparm -tT /dev/md0 && dd

hdparm -tT /dev/md0 && dd if=/dev/zero of=/home/temp/tmp bs=1M count=1024 && ./seeker && cat /proc/scsi && cat /proc/mdstat

/dev/md0:
Timing cached reads: 7444 MB in 2.00 seconds = 3725.76 MB/sec
Timing buffered disk reads: 386 MB in 3.01 seconds = 128.36 MB/sec
1024+0 poster in
1024+0 poster ut
1073741824 byte (1,1 GB) kopierade, 5,70896 s, 188 MB/s
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/md0 [953874MB], wait 30 seconds.............................
Results: 48 seeks/second, 20.52 ms random access time
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: ATA Model: SAMSUNG HD501LJ Rev: CR10
Type: Direct-Access ANSI SCSI revision: 05
Host: scsi1 Channel: 00 Id: 00 Lun: 00
Vendor: ATA Model: SAMSUNG HD501LJ Rev: CR10
Type: Direct-Access ANSI SCSI revision: 05
Host: scsi4 Channel: 00 Id: 00 Lun: 00
Vendor: ATA Model: SAMSUNG HD501LJ Rev: CR10
Type: Direct-Access ANSI SCSI revision: 05
Host: scsi5 Channel: 00 Id: 00 Lun: 00
Vendor: ATA Model: SAMSUNG HD501LJ Rev: CR10
Type: Direct-Access ANSI SCSI revision: 05
Personalities : [raid10]
md0 : active raid10 sdc1[0] sda1[3] sdd1[2] sdb1[1]
976767872 blocks 64K chunks 2 near-copies [4/4] [UUUU]

unused devices:

Well, not the fastest around.

Kingston DT2 4GB results

This is nice and what I would expect from a memory stick:

Buffered disk reads: 28 MB in 3.16 seconds = 8.85 MB/sec
Results: 324 seeks/second, 3.08 ms random access time

Slower sequential access than modern disks, but faster random access time.

Does anybody have one of those new solid state driver (16-64GB)? It would be VERY interesting to see what's their performance.

I believe we're all waiting for prices to come down to replace our system/boot disks with those beasts. :)

Mtron SSD results

While I don't have the exact results, I benchmarked a Mtron 32GB SSD a few weeks ago with seeker. Ended up doing right around 5000 to 6000 seeks / second, at a random access time of 0.10 ms. Needless to say I was pretty impressed :)

Gentoo 64 Raptor 150 raid 0

Gentoo 64 Raptor 150 raid 0 Qx6700 @ 3,2

Timing cached reads: 11894 MB in 2.00 seconds = 5957.47
MB/sec

Timing buffered disk reads: 188 MB in 1.14 seconds = 165.56 MB/sec

Gentoo Linux is the fastest

Gentoo Linux is the fastest Linux distro

some nice results! on which

some nice results!
on which chipset/mobo?

Nvidia nForce 680i SLI on a

Nvidia nForce 680i SLI on a Asus Striker extreme.

(With watercooled chipset)

How fast is your disk?

Seeker is a really great tool ! thanks for it

this is a bench for a gigabyte i-ram (under ubuntu 8.04.1)

sudo hdparm -t /dev/sda1
/dev/sda1:
Timing buffered disk reads: 346 MB in 3.01 seconds = 114.87 MB/sec

sudo seeker /dev/sda1
Benchmarking /dev/sda1 [4094MB], wait 30 seconds..............................
Results: 13266 seeks/second, 0.08 ms random access time

Cool

Remember.. with this Gun if drink don't drive!

changed for large volumes such has greater than 2TB

now the thing is, I cant figure out that ioctl can find the blksize for greater than 2TB. So i decided to circumvent this limitation.

rather than post a patch I am pasting the full code.
compiles on centos 5.4 (redhat 5.4)
use gcc -std=gnu99 seeker_large.c

Here is the catch u need to retrieve the blocksize yourself
from either cat /prod/mdstat for mdX devices
or dmesg | grep /dev/sd[a-z] devices.
put # of blocks in the line: numblocks=15628115968LL
make sure to leave the LL at end since it indicates long long int.
Also Im dividing it by 1024 not 2048


#define _LARGEFILE64_SOURCE

#include
#include
#include
#include
#include
#include
#include
#include
#include
#include

#define BLOCKSIZE 512
#define TIMEOUT 30

int count;
time_t start;

void done()
{
time_t end;

time(&end);

if (end < start + TIMEOUT) {
printf(".");
alarm(1);
return;
}

if (count) {
printf(".\nResults: %d seeks/second, %.2f ms random access time\n",
count / TIMEOUT, 1000.0 * TIMEOUT / count);
}
exit(EXIT_SUCCESS);
}

void handle(const char *string, int error)
{
if (error) {
perror(string);
exit(EXIT_FAILURE);
}
}

int main(int argc, char **argv)
{
char buffer[BLOCKSIZE];
int fd, retval;
unsigned long long numblocks;
//off64_t offset;
unsigned long long offset;

setvbuf(stdout, NULL, _IONBF, 0);

printf("Seeker v2.0, 2007-01-15, "
"http://www.linuxinsight.com/how_fast_is_your_disk.html\n");

if (argc != 2) {
printf("Usage: seeker \n");
exit(EXIT_SUCCESS);
}

fd = open(argv[1], O_RDONLY);
handle("open", fd < 0);

numblocks=15628115968LL;
//numblocks=1951170560;
//retval = ioctl(fd, BLKGETSIZE, &numblocks);
//handle("ioctl", retval == -1);
printf("Benchmarking %s [%luMB], wait %d seconds",
argv[1], numblocks / 1024 , TIMEOUT);
printf("Unsigned long min: 0 max: %llu\n",
ULLONG_MAX);

time(&start);
srand(start);
signal(SIGALRM, &done);
alarm(1);

for (;;) {
//offset = (off64_t) numblocks * random() / RAND_MAX;
offset = numblocks * random() / RAND_MAX;
//printf("offset value: %llu", offset);
retval = lseek64(fd, BLOCKSIZE * offset, SEEK_SET);
handle("lseek64", retval == (off64_t) -1);
retval = read(fd, buffer, BLOCKSIZE);
handle("read", retval < 0);
count++;
}
/* notreached */
}

For a noob friendly version

For a noob friendly version of this you can find it at http://vpstip.com/how-to-check-disk-speed-easily-in-linux/