bandwidth for a single 15K RPM disk ? 10MBps or 100MBps?
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.
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.
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.
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.
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.