5
If you know the transfer rate, how do you calculate the bytes per track?
5
If you know the transfer rate, how do you calculate the bytes per track?
6
Bytes per track depends totally on how the manufacturer laid out the disk internally, which you will not know. All modern disks use LBA (logical block addressing), in which the OS addresses the drive on a sector-by-sector basis, not knowing or caring how or where the sectors are physically located on the platters (nor how many platters there actually are).
Not only that, but the number of sectors per track depends on how far out from the spindle motor you are at the time; it's not a spiral like on a CD. The further from the spindle you are, the more sectors per track (and thus the higher the transfer rate).
The following diagram explains it, but note that the diagram is partially incorrect -- instead of the sectors getting bigger as you go outwards from the spindle, the sectors remain the same size and there are more of them per track the further from the spindle you go (which causes your number of bytes per track, sectors per track, etc to go up).
Since the heads will be over a certain track for only one revolution, and you don't know where on disk you are, you cannot know if the next track will have more or fewer sectors, and therefore your transfer rate will fluctuate.
That said, it will only fluctuate if you are reading directly from disk and not out of cache; modern drives have advanced caching algorithms which will prefetch content it thinks you'll ask for next. As a result, if you were measuring transfer rate, you have no idea if it's coming off the platters or out of cache, making such measurements unrepeatable and totally useless.
In other words, you don't. Period.
There should be a way to calculate it if certain assumptions are made. This question is part of a study guide for my class. – Phenom – 2010-03-13T05:12:02.587
@Phenom: See above; I added an image and some text after it to further illustrate the point. – Alex – 2010-03-13T08:10:19.783
What you said might be true but I still think that theoretically there should be a way to calculate the bytes per track because we're probably going to be asked to do so on a test. – Phenom – 2010-03-13T09:06:16.543
You can, but it would be an average across the surface, since bytes per track depends on how many sectors exist on a track, and that is NOT THE SAME at the inside of the disk, in the middle, and at the outside. – Alex – 2010-03-13T09:35:49.563
The old-school sectors per track, heads, tracks, etc are no longer used. The numbers are for backwards-compatibility only. Everything uses LBA now. http://en.wikipedia.org/wiki/Logical_block_addressing
– Alex – 2010-03-13T09:36:33.477So if we use an average track size, then what would be the equation? – Phenom – 2010-03-13T17:44:11.233
1@Phenom: (DRIVE_CAPACITY / NUMBER_OF_SURFACES) / NUMBER_OF_TRACKS_PER_SURFACE = AVERAGE_CAPACITY_PER_TRACK
. Pretty straightforward -- but you're having to make a ridiculous number of assumptions and averages to compute this, so the end result is essentially meaningless. – Alex – 2010-03-15T11:45:34.927
See this set of 6 closely related questions: http://superuser.com/questions/119446/sectors-and-clusters http://superuser.com/questions/119051/transfer-time-for-a-file http://superuser.com/questions/107723/hard-drive-sectors-vs-tracks http://superuser.com/questions/119048/number-of-tracks http://superuser.com/questions/119026/rotational-latency http://superuser.com/questions/119030/bytes-per-track
– Jonathan Leffler – 2010-03-16T11:05:45.920And http://superuser.com/questions/120461/transfer-time-of-a-cylinder
– Jonathan Leffler – 2010-03-16T11:14:12.343