KCK wrote:The fact that quadratics approximate `sufficiently nice' functions closely doesn't mean that the whole world can be described in quadratics alone.
I don't recall ever making such a broad statement. I only said that CAV transfer rate curves for CD's can be described by a simple quadratic.
KCK wrote:Without going into the issues of mathematical modelling of complex phenomena...
The constant acceleration model is an exact model based on the physical geometry of the disc, subject to a few very minor simplifications (e.g. it ignores the wobble in the spiral due to the ATIP signal, which your model ignores as well). I would thus tend to disagree with your characterization of the model as "brute force", and could, but won't, argue that it validates and delineates the strengths and weaknesses of the extended model rather than the other way around.
Even allowing for a "brute force" characterization of the constant acceleration model, which I don't agree with, I still find it to be an acceptable approach. Maybe it is just my engineering background biasing me, but I find that starting with the simplest model is generally the most productive route. If it adequately explains the observed behavior, then there isn't any need to go further. Moreover, simpler models tend to be easiest to grasp and thus use to predict further behavior.
Of course, I'm not advocating blind reliance on simple models for complex systems. Even when a simple model does suffice under some conditions, one does have to have a good grasp of the underpinnings of the model so as not to be fooled into using a simple model under other conditions where it no longer applies.
But, in this case the constant acceleration model is quite exact, it is simple because it matches simple underlying physical characteristics rather than because it ignores complex underlying characteristics, and it is quite up to the task of analyzing CDSpeed's behavior.
I'm sorry if you feel that I overreacted in an emotional manner. That was not my intention.
KCK wrote:In one of my earlier posts, I mentioned that the final length displayed on the CD Speed graph can be more than three minutes short of the reported Disc Length (see the fourth CDFreaks picture). This doesn't agree with your explanation that CD Speed `always stops at the last even 2-minute boundary before the capacity of the disc'.
If you re-read my explanation, you will see that you have incompletely quoted it, and thus left out the second half which explains the "more than three minutes short" condition to which your refer. Using my explanation and the example you cite, we have the following:
Disc size = 77:45:70
Next lowest two-minute boundary = 76:00:00
Plotted position two-minutes before that boundary = 74:00:00
This agrees with the CDSpeed chart.
KCK wrote:Further, also in contrast with your explanation, I guess that the blue progress bar might be intended as a general percentage progress indicator, with no direct meaning in terms of minutes of length covered.
Absolutely it shows the percentage of the test completed, not the minutes completed. Thus, at minute 10 of a 20-minute disc, it will be halfway filled. And this is not in contrast with my explanation, as I am about to explain.
KCK wrote:It is not true that two blue rectangles correspond to two minutes; just watch the blue progress bar above 50 minutes.
I never claimed that it did, because I know that it corresponds to percentage complete, not minutes complete, as I noted above. Looking back I can see that I should have made my original presentation more explicit, and I can understand how you could have been confused, but your interpretation that I was equating bars on the progress meter with disc-minutes in the test is incorrect. My conclusions were based solely on the fact that the progress meter increments one time for every 2 disc-minutes worth of data collected, regardless of how many blue bars are displayed with each increment. This is based on careful observation of entire test runs. It is just a happy (or unhappy, depending on one's point of view) coincidence that for a disc of this size one increment of the progress meter happens to have a width of two blue bars, at least at the beginning of the disc.
KCK wrote:Thus I am not sure that the point plotted at minute x covers the data on disc from minute x to x + 2.
If you are still not convinced, then perhaps another look at those two snapshots of the beginning of the test will help:
In the fist snapshot, where one increment of the progress meter is displayed (you will either have to trust me that this is one increment or do it yourself and see for yourself), the starting speed is already displayed in the numeric boxes on the right. Thus, it is obvious that one data point has been collected. However, it has not yet been plotted, since two points are needed to plot a line segment.
In the second snapshot, another increment to the progress meter has been added. We now also have a second data point, whose value is listed as the new current speed in the numeric boxes, and a line segment connecting those two points has been drawn. The first point is drawn at the starting speed of 22.90x and the second at the current speed of 23.42x, just as shown in the numeric boxes (subject, of course, to the granularity of the chart, which can not display to four significant digits of precision).
In actual real-time, it took about 10 total seconds from the start of the test to collect these two data points and increment the blue progress meter twice, 5 for the first, and 5 for the second. Five seconds corresponds to reading 2 minutes of disc data at 24x.
Finally, at the very end of the test the blue progress meter is incremented for the final time, the very last point of the graph is plotted, and the end and average speeds are displayed in the numeric boxes all simultaneously and immediately after the last 2-disc-minutes of data are collected (based on timing the real wall-clock seconds).
Putting it all together, it seems quite clear to me that the transfer speed for disc-minutes 0-2 is plotted at 0, 2-4 at 2, and, in general, x to x+2 at x.
In other words, it could be misleading to assume that CD Speed plots the data as soon as they become available. Of course, only Eric Deppe knows what CD Speed does, but my point here is that we can't really take anything for granted.
In general, of course, anything is possible. But it would be quite an odd choice to arbitrarily hold back data on an otherwise real time display and not plot it as it becomes available. Thus, I don't think this is very likely. Of course, if you wish to be a stickler and won't make this reasonable, but admittedly not 100% certain assumption, I feel that you can still reach my conclusion. I think that careful observation of the actual progress of real tests as I observed them and attempted to explain above and in my previous post will lead you to conclude, as I did, that CDSpeed does plot the data as soon as it is available, that it is available at the end of every two disc-minutes, and that the data point for disc-minutes x to x+2 is plotted at x.
KCK wrote:Well, our uncertainty about KProbe's Performance | Transfer Rate is similar. ... However, it reported the Start Speed before displaying anything in its graph, as if the graph were updated with a delay of one minute.
It's a little harder to tell with KProbe because Karr never changes his "Spin up" label to "Testing", so I can't really pinpoint exactly when his test is starting, but I think this is the same behavior as CDSpeed. Points are plotted at the end of each collection interval (which defaults to 1 disc-minute in KProbe rather than the 2 disc-minutes of CDSpeed, although you can manually select 2-disc-minute intervals in KProbe), and the first point isn't plotted until the second is also available to make a complete line segment. Also, just like CDSpeed, the speed for the first point is displayed in the numeric box as soon as it is collected even though it isn't plotted until the second point is also collected.
Further, for the disc length being 79:03:34, the final length on the graph was close to 79 minutes (definitely not 78 minutes).
Part of this is due to the default 1-disc-minute collection interval of KProbe. I am guessing that the other piece of this puzzle is that KProbe continues to the very end of the disc to plot one more point of data. Thus, it calculates the speed to be plotted at minute 79 from as much as an interval is left beyond minute 79.
More importantly, the graph between 0 and 1 minutes was horizontal. I don't know how to explain this.
This may be due to the effects of the drive's buffer as I hypothesized in an earlier post. With a one-disc-minute collection interval, it becomes more pronounced. Change KProbe to a two-disc-minute interval, and it will look more like a CDSpeed plot in this area.
KCK wrote:On another note, I'm developing a strong suspicion that the yellow line plotted by CD Speed might have relatively little to do with the actual rotational frequency; maybe Eric Deppe is using some formula to compute it from other data.
That is what I suspect also, as I explained in an earlier post directed towards dodecahedron.
I did get a chance to take a look at your averages. My numbers don't quite agree with yours, but do agree quite closely with CDSpeed's. I think this has something to do with the fact that you are using a larger disc size than is plotted on the CDSpeed graph. In your example calculation for the first graph you use 74 minutes for d_T, while I used 72 because that is what is actually plotted.
Here are my figures for a simple average of the discrete samples collected every 2 disc-minutes from 0 to 72, inclusively (I'm a little unclear on your notation, but I think this is what you are getting at with M_I):
- Code: Select all
picture sample avg CDSpeed avg
1 37.55 37.57
2 38.43 38.45
3 39.70 39.71
4 25.24 25.25
To me that is superb agreement, with a maximum error of 0.05%. I don't know how one could reasonably ask for anything better, and I think it confirms my earlier suspicion that Erik Deppe is reporting the sample average as the overall average rather than the true average calculated using wall-clock time.
In my mind we have a very good characterization of what CDSpeed is doing. We know how it calculates the average speed, we know that the average it calculates is wrong, and we know how to fix it (I think we have all said it, but Inertia's formulation may be easiest to understand and implement: divide the number of disc-minutes worth of data transferred during the test by the number of real wall-clock minutes required to complete the test). You may feel that you want to do additional refinement, but I think Seabiscuit is crying "Uncle!" already, and it is time to write Erik an email and explain the bug in his program. I think you ought to take the honors, since if you hadn't started this thread no one would have bothered looking into this.
This is Erik Deppe's email for bug reports: