Let me begin with a couple of general comments.
First, there really isn't any question as to what true CAV means, is there? As I stated earlier, it must
, by definition, have constant
RPM. Otherwise it would not be constant
angular velocity. It would be "variable angular velocity" or "almost constant angular velocity" or some such. If we can't even agree on this, then "constant" has no meaning and there is no sense in going further.
Now, I'm not at this point saying that manufacturers do or do not implement true CAV exactly or that CD Speed does or does not introduce measurement artifacts that distort true CAV. All I am saying is that true CAV exhibits fixed, constant RPM and there should be no question about that at all.
Second, I'm hoping that everyone agrees that the proper definition for the average speed, a quantity we measure in bytes per second, is the definition I gave earlier: total bytes transferred divided by total time required to transfer those bytes. I agree that one could define other so-called "averages", but they do not correspond to the common understanding and usage of the term.
For instance, one could define the average to be the mean of the measured "instantaneous" speed points plotted on the CD Speed graph as dodecahedron suggested earlier, but this would not necessarily give a meaningful number for doing data transfer rate calculations. As an extreme example, imagine a 24x burner that is nominally CLV but for some strange reason pauses for 10 minutes at the 350 MiByte mark to recalibrate its laser. Without the pause it would take 3:20 to burn an 80-minute disc. With the pause it takes 13:20 to burn an 80-minute disc.
Now, CD Speed plots a data point every 2-minutes of disc time (18,000 KiBytes for a data disc). For the bizarre burner I described, CD Speed would show 39 points with speed of 24x, and 1 point with a speed of roughly 0.2x. Using dodecahedron's one proposed "average" calculation, the average speed for this burner would be:
( 39 points * 24x + 1 point * 0.2x ) / 40 points = 23.4x
Using my proposal, the average speed would be:
80 minutes / 13.3333 minutes = 6x
(I've skipped a number of steps in both these calculations, but the result should be clear.)
So, which is correct? Well, let me pose the question this way: if one reseller advertised this burner as having a 23.4x average burn speed, and another advertised it as having a 6x average burn speed, which one would have a line of angry customers at the door demanding to know why their burners take so long to complete a disc?
Ask any grade school child (okay, maybe junior-high school child) what Johnny's average speed was if he rode his bicycle 20 miles to grandma's house in 2 hours, and that child will tell you 10 miles per hour. That is the commonly accepted definition of an average speed, and anything else is just not right, or at the very least needs to be thoroughly annotated to explain how it differs from the commonly understood definition of an average speed.
Now, I'm not saying that CD Speed calculates the average the way I have defined it. It may calculate it the way dodecahedron suggested or by some other way. All I am saying is that the real, meaningful average for a speed measured in bytes per second is the total number of bytes transferred divided by the total seconds required to transfer those bytes. Anything else is at best non-standard.
Now to address some specific points.
dodecahedron wrote:i understand your position, but i do think the shape of the curve is important and of much interest.
When I said that the shape of the curve is irrelevant, I was only referring to the specific application of calculating the average transfer speed. I was not dismissing the shape of the curve in general, and I agree that the shape of the curve has interest in its own right independent of calculating the average transfer speed. For example, a 24x CAV drive may actually exhibit better overall performance than a 24x CLV drive in an application that constantly and rapidly shifts the position of the laser head (e.g. packet writing). Why? Because the drive doesn't have to wait while the disc spins up or down to match 24x CLV RPM's every time the laser shifts positions.
cfitz wrote:True CAV (constant angular velocity) by definition requires that RPM be constant. Otherwise the angular velocity would not be constant. So if you are developing a complex model of true CAV that requires a non-constant RPM, then you are going down the wrong path. Regroup.
well, come now. because a manufacturer says so and so, that makes it true??? i can't belive i'm hearing this...
I never made any claim as to what manufacturers are or are not implementing. My comment was directed solely at the characteristics of true CAV that are fixed by definition.
KCK wrote:2. The final point on the horizontal axis is always at least 2 minutes short of the displayed Disc Length; e.g., 74 min vs 77:45:70 in the fourth CDFreaks picture, where I would expect the final point to be 76 minutes. BTW, for one of my discs, CD Speed displays 79:01:35 in Disc Length and the graph stops at 76 min, whereas KProbe reports 79:03:34 and the final tested MSF = 79:03:23.
First, if you watch the test as it progresses, you will see that CD Speed plots a point every 2 minutes of disc time ( 18,000 KiBytes for a data disc). Since CD Speed's test granularity is 2 minutes, it always stops at the last even 2-minute boundary before the capacity of the disc. Second, if you look carefully you will see that the data point plotted at position x gives the average speed for the data transferred from minute x to minute x + 2. The following two screenshots illustrate:
In the first picture you can see that the first 2-minutes of disc data have been read, as indicated by the blue progress bar beneath the chart, but nothing has been plotted. Or rather, a point has been collected, but it has no lines connecting it to other points so it isn't actually drawn.
In the second picture you can see that the second 2-minutes of disc data have been read, as indicated by the movement of the progress bar. Also, the first visible lines are drawn on the chart. At this instant 4 total minutes of data have been read, the average speeds for that data have been calculated, and the results plotted. As you can see, they are plotted at minutes 0 and 2. Thus, my contention that the point plotted at minute x covers the data on the disc from minute x to minute x + 2.
Now, back to your original question. We have already established that the granularity of CD Speed causes it to stop at the next lower 2-minute boundary below the disc's capacity. In the two examples you have given those boundaries are 76 and 78 minutes, respectively. Now combine this with the fact that the point plotted at minute x covers the data on the disc from minute x to minute x + 2, and you can see that CD Speed will plot the end of the tests on the chart at 74 and 76 minutes, respectively, exactly as you have observed.
KCK wrote:3. It's not clear whether the Elapsed Time and the final speed correspond to the final displayed length or the larger Disc Length. I don't think the Elapsed Time includes the spin-up time.
No, I agree that it is not. I'm not sure that this can be answered by anyone but Erik Deppe. You are correct that it does not include the spin-up time.
I will add that I suspect CD Speed's general algorithm is to time how long it takes to collect 2 disc-minutes worth of data (18,000 KiBytes for a data disc) and then divide that time into the amount of data transferred, just as I suggested for the overall average, to find the "instantaneous" speed (actually short-term average) for any 2-disc-minute interval. I suspect this because of the way I observed that data is plotted as I explained above. CD Speed is obviously waiting to read the 2 disc-minutes worth of data before it calculates the transfer speed, which leads me to believe that it is timing the transfer and calculating the speed as I suggested. If it had a true instantaneous value available to it, it would not need to wait to start plotting data. It could begin plotting data for the 0'th minute right at the start of the test.
dodecahedron wrote:from my (little) experience with CDSpeed, when you do the test the progression along the x axis (location on the disc) is constant with respect to time. i mean the speed at which the test progresses along the x axis is fixed.
however if the reading (or writing) is really true CAV, it souldn't be! because the radius (proportional to the velocity in true CAV) is not linear with the location on the disc. this is what i noted in one of my previous posts.
Not true. Observe a test a little more carefully, and use a watch to time it. You will see that the graph does complete faster towards the end where the transfer speeds are higher. It just isn't so dramatic as to be immediately obvious.
Take the following graph, for example:
I timed the start of the test to the plotting of the point at the 36-minute mark, which as I explained above actually encompasses minutes 0 to 38, or 334 MiBytes. It took 77 seconds, for an average speed of about 30x. The remainder of the disc (minutes 38 to 78 = 352 MiBytes) took only 54 seconds, for an average speed of about 44x.
When I eyeball the "instantaneous" speeds at the start, middle and end, I get 23x, 38x and 50x. Using Inertia's average speed calculation method for CAV that KCK verified, the average speeds for the two segments calculated from these endpoints should be (23 + 38 )/2 = 30.5x and (38 + 50)/2 = 44x, both in good agreement with my calculations.
Using my method for calculating the overall average of transferring 78 disc-minutes worth of data in 131 seconds, I get 35.7x. Using Inertia's average method, I get 36.2x. There is some slop in my calculation, since as noted earlier it is unclear whether or not the elapsed test time includes the chunk of data past the last even 2-minute boundary. However, even including it, my average speed is 36.4x, which agrees pretty will with Inertia's method but is still less than what CD Speed reports. Thus, it may be that CD Speed uses some other method, such as the one proposed by dodecahedron, for calculating the "average" speed. If so, this would be interesting to know because it does differ from the commonly accepted definition of average speed that I gave earlier.
As for whether or not the graph of RPM is concave, I have to say that the curvature is clearly visible to me in the above graph. However, this has nothing to do with the characteristics of true CAV. It is either an odd characteristic of the drive or an anomaly introduced by the testing method. I tend to agree that maintaining a constant RPM should be a fairly easy task for the drive designers. This leads to me to guess that either there is some obscure reason the designers deliberately make it vary ever so slightly, or it is a testing artifact.
One possible hypothesis for the cause of a testing artifact would be the drive's buffer. Take a reading test, for example. If the drive pre-fills the buffer during the time the drive is spinning up, then the first 2 disc-minutes of data that are read would not take the normal amount of time required to fetch from the disc itself because transfer of some of the data has been accelerated by the pre-fetch. This would artificially inflate both the data transfer rate and the perceived RPM.
In the example I displayed above, two disc-minutes of a data disc contain 18,000 KiBytes while the drive's buffer can hold at most 2,048 KiBytes. If the full buffer were devoted to the first 2-disc-minute transfer, only 15,952 KiBytes would actually have to be transferred to disc.
Assume that the drive truly is CAV, and the actual RPM is maintained constant at the 10,500 RPM figure shown at the end of the disc. Then the initial transfer rate from the disc itself (not counting the buffer) would be 21x (1x = 500 RPM at the beginning of the disc as I derived in an earlier post). Thus, it would take 5.06 seconds to transfer the 15,952 KiBytes that actually came from disc. Assuming the buffer transfer time is negligible, then the total transfer of 18,000 KiBytes would also take about 5.06 seconds, for a black-box measured transfer rate of 23.7x (11,850 RPM), a difference of 13% from the assumed true speed of 10,500 RPM.
This doesn't match up exactly with the observed values of 23x and 11,500 RPM, but it is close. And it may be that the first transfer doesn't get the full benefit of the entire buffer due to the sizes of data transfer chunks that CD Speed uses for testing. It may be that the buffer's benefit is spread among all the transfers, with most going to the first transfer and less and less going to each subsequent transfer, giving the gently falling off curve that we observe.
Why didn't we see the same effect with Z-CLV drives? Perhaps they handled their buffers differently due to the demands placed on them by shifting zones. Looking back at a few older Z-CLV drives, they do show much flatter RPM curves for their CAV reading modes to go along with the flat data transfer rates on their Z-CLV burning:
It is just a thought.
By the way, using 21x as the true inner transfer speed would give an overall average of 35.5x using Inertia's method, comparing well to my first calculation of 35.7x. It all hangs together, at least.
Finally, there isn't any doubt that V(s) (the instantaneous transfer speed as function of disc-minutes) is not a linear function, even when the RPM is held constant. KCK's math should show this with exactitude, assuming it is correct, but you don't need to resort to such complexity if you just want to get an intuitive feel for this fact. A simple mind-experiment will suffice.
Looking at the earlier graph I displayed in this post, you can clearly see that the transfer rate varies significantly over the 703 MiBytes of an 80-minute disc, going from roughly 23x to 50x. The curve is substantially linear, but even in this graph there is an observable trend of the curve flattening as the outer edge of the disc is reached.
Now imagine a really, really big CD. Lets say we are going to blow away HD-Burn, GigaRec, DVD and even Blue-Ray. We will make our CD 1.825 km in diameter, giving it a circumference of 5734 m (I'd like to see the walkman designed to play that CD...
). At this size the circumference is equal to the entire spiral of an 80-minute CD. In other words, one turn of the data track spiral at 1.825 km diameter holds a full 703 MiBytes. Moreover, the data transfer rate will be virtually constant over this full 703 MiBytes because the percentage difference in the radius from the beginning to the end of the track is miniscule (a couple of microns compared to 0.9 km). Thus, the transfer rate would be essentially flat from very_many_minutes to very_many_minutes + 80, compared to the pronounced change we see from 0 to 80 minutes. This means the slope is not constant, and thus the curve is not linear.
Hmmm, I wonder how high that almost flat transfer rate would be?? Sticking with 10,500 RPM CAV means one revolution takes 5.7 thousandths of a second, so 703 MiBytes per 5.7 thousandths of a second equals 840,000x!
I smell success for this wonderful product...
Just my thoughts...