Question gives me following parameters:
track seek time = 10ms (milli-second).
The rotation speed of disk= 9000 revs per minute
Sectors on each track = 600
Each sector can store 512 bytes of data.
Question asks me to calculate the average time to read 1024 bytes.
I need to know if I have done it right. I would be grateful if someone could please take a look at my solution.
To read 1024 bytes (1024 / 512 = 2 sectors) you need:
Total: 10+3.33+5+3.33 ~ 21.7 ms
PS. Do not think "If no seek between sectors, waiting time is 0". Nobody says the sectors are adjacent.
I'm going to assume for the moment, you are really trying to gain an understanding of partially what determines real-world data rates, and not just theoretical. Generally, unless you are writing device drivers for the OS as my company once did, or writing the database engine itself, all these details are a bit mundane today. These actual details are mostly masked, filtered, compensated for, and hidden by many hardware and OS factors factors, so you can't usually observe what's happening directly.
Still understanding what causes, and does not cause performance problems can be important.
The average "read data rate" for databases will be mostly dependent on the size of the IO you are moving at one time, and if it is contiguous or not. It is also dependent on the disk itself, reporting its true hardware parameters, which are often only simulated. (For example, are there really 600 sectors per track? Since the outside track of a disk is much larger, any disk in the past 30 years will have many more sectors on the outside track than the inside.) Here are some performance examples if these were the true parameters:
Database reads: Usually means the sector numbers will read randomly all over the disk, (of presumably 1024 bytes of 2 consecutive 512 sectors), and none of the sectors are in memory or any other cache: In this case, your average data rate is going to be:
10 MS = Head Seek repositioning: (Note, that this means you can only do 100 seeks in 1 sec, and so 100 KB / Sec is going to be the FASTEST that you can ever read 1024 randomly.)
1 ? MS = Command overhead = unknown: This used to be significant, up to 8 MS. Today, it is likely to be more dependent on your OS, processing your requests efficiently. So, if your system is also swapping many MB out to disk, your system will incur a significant slowdown. The IO to and from the disks today, are likely less than a MS. This could be tested easily with an SSD to simulate a spinning HD's bus and firmware overhead. Included here, would typically be the time to switch read heads, assuming you were already on the correct track or cylinder. This also includes returning the moved data to the OS. Watch your total CPU interrupt time stays < 1%, which can indicate a disk hardware problem. Wild guess? < 1 MS, which could still be significant.
3.3 MS = Rotate until sector is under the heads: 9000 RPM / 60 sec = 6.67 MS. Odds of being nearest or farthest is 50%, so its a 3.33 MS delay for each IO. Note: That means that a random read if the head is already positioned over the correct track will still be 3.33 MS, and means your max data rate could never exceed 300 KB / Sec., at 1k IO.
0.022 MS = Head Read Time: 6.67 MS / 600 Sectors * 2 = 1024 read ==> 0.022 MS. This means that the max data rate of this disk is 1 / 0.022 MS = 45,000 * 1024 = 46 MB / sec. For database reads / queries, this is completely insignificant, while if moving the whole database, it would be the most significant factor.
So, in this case, your "database read" rate is going to be, ~14.355 MS = 70 KB / sec. Note that if the IO was 512, (ignoring the .022 MS), the rate is half that. Using 2,048 and the rate is double. So the most significant parameter is the size of the contiguous sectors, up until you get to a full track read, (assuming all the disk sectors themselves are contiguous.)
