Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

bandwidth for a single 15K RPM disk ? 10MBps or 100MBps?

share|improve this question

closed as not a real question by RobM, ThatGraemeGuy, Tom O'Connor, Chris S, jscott Oct 13 '10 at 12:34

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

add comment

2 Answers 2

up vote 7 down vote accepted

Not sure what you're trying to ask, but here's a rundown on a typical 15k drive like a Seagate 15k.7: (PDF) Depending on what you want to do with your drive, the actual performance will vary substantially.

Sequential Access

The listed performance for the drive is 122-204MB/sec off the drive. The drive records bits at higher densities further out on the disk to increase the total storage capacity, so reading off the outer regions of the disk is a bit faster than reading of inner regions. If your disk cache segmenting and read-ahead is set up appropriately on the disk you should be able to achieve pretty close to this on a streaming workload such as video editing.

Random Access

The platters revolve at 15,000 RPM or so, which works out to 250 revolutions per second. Average latency is listed as 2.0ms. A single rotation takes 4ms, so on a random load the sector will be an average of half a revolution from the head when you initiate the operation. Average seek time is listed as 3.4ms including the time for the heads to move. A single track-track seek is listed as taking 0.2ms.

The 3.4ms average seek time (+ 2ms average rotational latency) means that you might expect to get around 150-200 random access I/O operations per second for small data items off a single disk.

Access in an array

The streaming throughput on the array is a function of the disk RPM and RAID stripe size. Typically you will read close to one stripe per revolution of the disk unless your workload is highly scattered. For example, a 15k disk rotates 250 times per second; a 64k stripe size would allow you to read 16MB per second off the drive or a 256k stripe size would permit reading 64MB/sec off the drive.

If you have a heavily random access workload, then you might expect to get one stripe every few milliseconds, depending on the disk seek pattern. This means you would read a stripe on average slightly more slowly than the peak throughput, so the figure of 150 IOPS per disk is a reasonable rule of thumb. The array would have multiple drives, so the aggregate throughput is the total throughput of the drives unless constrained by some other factor like a slow or inappropriately tuned controller.

Writing to an array is more complex, as redundant information has to be written out. Depending on the RAID type, several additional I/O operations may be necessary for each write; the exact number depends on the type of RAID layout. Typically a write on a RAID-5 requires four IO operations (two reads, which may be cached, and two writes) and a write on a RAID-10 requires two writes (one to each side of the mirror).

Access in a SAN

Physical disk throughput is not usually the constraining factor in SAN performance. Many, many factors feature in SAN performance and the setup of the controllers and even disk parameters like cache segmentation and read-ahead policy can significantly affect performance.

Disk performance characteristics in a SAN are much the same as in a RAID controller, but there are more layers and some choke points not typically found in host-based RAID controllers. SAN performance is not a one-size-fits-all situation and different workloads may place conflicting requirements on a SAN.

One fairly common situation is that a SAN tuned for a general purpose workload often performs poorly on data warehouse ETL or reporting tasks, which tend to have very different disk access patterns to transactional or file service workloads.

One rep I knew at a major SAN vendor reckoned that many of their customers used direct attach storage for their data warehouse systems as it was much faster than a SAN for this type of workload. I've also seen this phenomenon a few times on sites I've worked on, and even ran one benchmark where a modestly equipped server outperformed a blade/SAN setup by a factor of two on the same ETL job.

share|improve this answer
    
sorry for a dumb question. I was in a hurry to figureout what contributes to a SAN performance, trying to see how do SATA vs SAS disk based SANs compare. Somebody told me 15K RPM disk could do 10MB/sec thru-put and 150 IOPS...so compute this for number of diks in an array to get aggregate thruput. thats the backgorund ! –  John-ZFS Oct 14 '10 at 10:18
add comment

This makes almost literally no sense as a question sorry.

10Mbps and 100Mbps are typical Ethernet speeds (along with it's 1Gbps, 10Gbps and 40Gbps friends) - disks don't use Ethernet - not as a primary interface anyway. Typically they use ATA/SATA, SCSI/SAS or Fibre-Channel intefaces, these run typically at 1.5/3/6Gbps, 3/6Gbps and 1/2/4/8Gbps speeds respectively.

These are you the physical interface speeds, it doesn't mean the disk will hit that speed, just an upper limit. To define the overall performance of a disk we often look at average seek time, sequential and random read and write speeds, plus IOPS which is the stat that most SAN building like myself care about.

If you have a particular problem or question why not ask that rather than this rather malformed question.

share|improve this answer
    
sorry for a dumb question. I was in a hurry to figureout what contributes to a SAN performance, trying to see how do SATA vs SAS disk based SANs compare. Somebody told me 15K RPM disk could do 10MB/sec thru-put and 150 IOPS...so compute this for number of diks in an array to get aggregate thruput. thats the backgorund ! –  John-ZFS Oct 14 '10 at 10:17
    
With a 3.3ms average seek time, 10MB/Sec and 150 IOPS throughput is a reasonable statistic for a 15K drive in a busy array with a 64k stripe size (a common default setting) and a random access workload. –  ConcernedOfTunbridgeWells Oct 14 '10 at 10:22
    
Great comment CoTW :) - maruti, that 10MB/s is for random reads/writes - for sequential it's often much higher, perhaps 80-100MB/sec for a spinning disk and even 200-250MBps for flash/SSD-based ones - thought you should know. –  Chopper3 Oct 14 '10 at 11:14
    
thanks, Chopper3 & CoTW. This is what i was looking for.I dont care that my question is closed or voted down. It is guys like you who keep SF working ! –  John-ZFS Oct 15 '10 at 9:37
    
Well actually it's all of us that keep SF working, it should include you, you've only ever answered a single question, try not to be 'all take and no give' please. –  Chopper3 Oct 15 '10 at 9:48
show 1 more comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.