Transfer graphs and times

[KCK]

Inertia:

Apparently you misunderstood both my previous post and my intentions, so let me try to clarify them a little.

1. The transfer time formula developed in my first post was just a naive attempt at explaining CD Speed's graphs. Since my "black-box" approach had obvious limitations, and I couldn't find better alternatives on the Web, I decided to develop a more precise model.

2. The hardest part (at least for me) was to derive formula (6); once I got (6), the transfer time calculation became trivial. I didn't post these results immediately, because I still wanted to handle other fairly technical details.

3. Your initial post developed essentially the same transfer time calculations as a consequence of your main statement:

"As we know with CAV, when the acceleration is constant the velocity increases linearly."

Since your statement was not justified, I decided to post my derivation of (6) as an explanation for your statement.

4. Your first reaction to my model didn't mention its relation with your main statement; you just reiterated the arguments used for the consequences of your main statement.

5. Let me now address your latest answer:

"Far from being God-given, I felt that this statement would be so obvious to the technical know-how of this group that I did not expect it to be challenged. I did reference the source in my second post and in my penultimate post. It is a simple mathematical and scientific fact, and does not need justification."

Your statement was not obvious at least to me, and I was not challenging it, just asking for explanations. However, it may be useful to challenge it now in order to clarify our apparent misunderstanding. Namely, its second part:

"when the acceleration is constant the velocity increases linearly"

doesn't need justification; I guess your replies concerned this part only. However, the first part may be rephrased as

"As we know with CAV, the acceleration is constant."

I believe this statement is false; if you or other group members think otherwise, I would welcome justifications, since they would contribute to my knowledge. At least for all CAV models known to me, the acceleration is not constant. However, some models (including my second one) can be used to justify the following variant:

"As we know with CAV, the acceleration varies so slightly that we may assume that it is constant."

I apologize in advance if you felt that I had been pestering you about your main statement unnecessarily.

[KCK]

dodecahedron:

What follows is quite technical and dense, so other users beware!

The main message is that even for the "most exact" spiral model, the transfer graph is unlikely to be linear, and the acceleration is not constant.

Using the relations from my previous post:

L(Q) = a * Int_0^Q sqrt(1 + x^2) dx

= 0.5 * a * {[Q * sqrt(1 + Q^2)] + ln[Q + sqrt(1 + Q^2)]}, ___ (3)

Q = Q_0 + 2 * pi * f * t, ___ (5)

we may replace l by L in (6) to obtain the ideal model:

s = s(Q) = L(Q) - L(Q_0). ___ (6')

Note that the speed

s'(Q) = L'(Q) = a * sqrt(1 + Q^2) ___ (A)

is positive and increasing. Hence the inverse function F(y) of L(Q) is increasing and strictly concave, since F'(y) = 1 / L'(F(y)) is positive and decreasing. Therefore, s(Q) in (6') has the inverse

Q(s) = F(s + L(Q_0)).

Plugging Q(s) into the right-hand side of (A) yields

s'(Q) = G(s(Q)) for G(s) = a * sqrt(1 + F(s + L(Q_0))^2). ___ (B)

As before, let's write s(t) for s(Q(t)), so that we still have

s'(t) = (ds/dQ) * (dQ/dt) = s'(Q) * 2 * pi * f. ___ (8 )

In effect, by (B),

s'(t) = V(s(t)) for V(s) = 2 * pi * f * G(s). ___ (C)

Note that, as mentioned in my first post, V(s) in (C) should correspond to CD Speed's transfer graph. Although I have no proof so far, I believe that V(s) is concave.

Anyway, the basic question so far has been whether V(s) is linear. Again, I believe it's not. A counterexample could be constructed as follows. Choosing Q_0 < Q_1 < Q_2, compute y_i = L(Q_i) and s_i = y_i - L(Q_0) for i = 0,1,2, so that s_0 < s_1 < s_2, F(s_i + L(Q_0)) = F(y_i) = Q_i and G(s_i) = a * sqrt(1 + Q_i^2) for all i. If the point (s_1,G(s_1)) doesn't lie on the straight line passing through (s_0,G(s_0)) and (s_2,G(s_2)), then G(s) is nonlinear, and hence such is V(s).

On another note (inspired by Inertia's claim), notice that the accelerations s''(Q) = L''(Q) and

s''(t) = [2 * pi * f]^2 * s''(Q(t)),

where L''(0) = 0 and L''(Q) > 0 is increasing for Q > 0:

L''(Q) = a / sqrt(1 + 1/Q^2) for Q > 0.

Thus both accelerations aren't constant, although they are almost constant when Q and t are sufficiently large, i.e., in the ranges of practical interest.

EDIT: Inserted missing braces in (3), and replaced w by f in (5) and (8 ).

EDIT2: Corrected missing square in s''(t).

[dodecahedron]

just a small clarification to the whole "As we know with CAV, when the acceleration is constant the velocity increases linearly" issue.
or maybe my next words won't clarify anything, just stir things up even more.

"when the acceleration is constant the velocity increases linearly"
this is a true statement.

however it has nothing to do with CAV.
CAV means Constant Angular Velocity.
this means that the angular velocity is constant, and hence the angular accelaration is zero!

that the linear (tangential) velocity increases, this has nothing to do with acceleration in the "normal" sense, it's due to the increas in the radius.

i think this is why KCK "disputed" Inertia's remark. not because of it's untruthfulness but because it's not directly related to the discussion at hand.
and also the reason for my comment about the inappropriate use of an algebraic average in this context
(algebraic average of x and y = x + y divided by 2).
the algebraic average of the initial speed (at the inner hub) and the final speed (at the outside of the cd) i exactly equal to the speed at the midway point between them (radius-wise), and i don't see any natural/intuitive/simple/obvious reason to see that this is the average speed in the "normal" sense (as by cfitz) - total data transferred divided by the time to transfer.

KCK:
nice work, will go over it when i can.
my main beef is the simplification in the L(Q) formula (in the previous post, not the last one)...i'm not very satisfied with it...we'll see.

[cfitz]

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.

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.

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.

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.

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.

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...

cfitz

[cfitz]

Let me amend one observation. I really do think the total test elapsed time includes only the actual bytes transferred up to the highest even 2-disc-minute boundary, and not the entire capacity of the disc.

While carefully watching the progression of the data being plotted at the end of the test, I observed that as soon as the last data point is plotted at the 2-disc-minute boundary, the test immediately finishes and displays the total elapsed time. On my test disc, even at 50x at the outer edge it should still take over 2 seconds to finish reading the excess data past the last even 2-disc-minute boundary. A time frame of this magnitude would be easily noted by a human observer, and since I didn't note it, I conclude that it doesn't exist.

cfitz

[dodecahedron]

long discussion about average transfer speed...

cfitz, this extensive discussion wasn't really necessary, you've already convinced me (and i'm sure everyone else) with your previous explanation.

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.

no one disputes this (or has disputed it in previous posts in this topic).

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.

again, no one has said otherwise as far as i recall.

the point is:
if, when the drive is burning or reading at "CAV" mode, the RPMs aren't fixed as they should be, this could (and does!) influence the transfer rates and the CDSpeed graphs.
the idea is to understand the CDSpeed plot, and one aspect is it's concavity. assuming CDSpeed reports correct data, the RPMs are not constant as they should be. but no one is saying the CAV doesn't mean Constant Angular Velocity.

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.

first, the RPM graph is convex, not concave. the speed graph is concave.
and again no one said this has anything to do with the characteristics of true CAV.
indeed it is interestingn why the graph of the RPM isn't constant.

discussion about the buffer influencing the transfer rates and RPMs at the beginning of the scan

i'm not buying it - the part about the RPM i mean.
CAV is CAV as you have forcefully explained.
and all this stuff about some data buffered - it has no bearing on the RPM.

i'm assuming here that the CDSpeed program is getting the RPM info directly from the drive. if i'm wrong, and it's actually calculating it somehow from the data transfer speed (?!?!?!?!? ABSOLUTELY SHOCKED !!!) then of course the buffer would influence it too, but in this case i would find the RPM info of CDSpeed absolutely untrusworthy and unacceptable.

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.

thank you for giving a very nice and intuitive explanation for the concavity of the speed graph

all in all, i would like to commend you on this last post.

[KCK]

dodecahedron:

I show below that the reduced length l(Q) closely approximates the spiral length L(Q). I also give another (well-known) derivation of l(Q), which doesn't require integrals and hence should be accessible to more users.

For convenience, I first recall some of my original statements.

In polar coordinates, the disc track follows Archimedes' spiral:

r = a * Q, ___ (1)

where r is the radius (in meters), Q is the angle (Q stands for the Greek letter theta), and the parameter a determines the track pitch

p = 2 * pi * a. ___ (2)

The length of the spiral

L(Q) = a * Int_0^Q sqrt(1 + x^2) dx

= 0.5 * a * {[Q * sqrt(1 + Q^2)] + ln[Q + sqrt(1 + Q^2)]} ___ (3)

is approximated very well by the reduced length

l(Q) = 0.5 * a * Q^2 ___ (4)

for large values of Q (the ones of interest here). For CAV, Q grows linearly:

Q = Q_0 + 2 * pi * f * t, ___ (5)

where the initial angle Q_0 = r_0/a is determined by the initial radius r_0, f is the rotational frequency (the number of revolutions per second), and the time t is measured in seconds. The distance travelled along the spiral, i.e., L(Q) - L(Q_0), may be approximated by the path length

s = s(Q) = l(Q) - l(Q_0) = 0.5 * a * [Q^2 - Q_0^2]. ___ (6)

To justify the preceding statements, I now show that the relative error

e(Q) = [L(Q) - l(Q)] / l(Q) = L(Q) / l(Q) - 1

is tiny for typical values of Q. Indeed, we have

L(Q) / l(Q) = sqrt(1 + 1/Q^2) + ln[Q * (1 + sqrt(1 + 1/Q^2))] / Q^2

= A(Q) + B(Q),

where for Q large enough, A(Q) is arbitrarily close to 1 and B(Q) to 0, since B(Q) < ln(3 * Q)/Q^2 for Q > 1. In particular, for Q = 100,000, (Q) -1 = 5e-11, B(Q) = 1.22e-9 and e(Q) = 1.27e-9, and the relative accuracy is about 9 digits for Q >= 100,000.

This range of Q suffices in practice. For CD-s, the lead-in starts at r = 23 mm, the data area starts at r = 25 mm, the lead-out starts at r = 58 mm, and the disc track officially ends at r = 58.5 mm (well, at least according to some sources). For 80min CD-s, the track pitch p = 1.48 micrometers yields a = p / 2*pi = 2.35549e-7 (for 74min CD-s, p = 1.6 microns and a = 2.54648e-7, but I won't consider them).

In the following table, the values of Q = r/a =(2 * pi / p) * r are rounded to 6 places, and the values of L(Q) and l(Q) are rounded to 10 digits.

Code: Select all

r           Q       L(Q)         l(Q)
[mm]      [rad]      [m]          [m]
23        97,644  1122.907105  1122.907104
25       106,135  1326.686088  1326.686087
58       246,233  7140.755195  7140.755194
58.5     248,356  7264.402339  7264.402337

Here are various path lengths of interest:

Code: Select all

L(58.5mm/a) - L(23mm/a) = 6141.495233
L(58.5mm/a) - L(25mm/a) = 5937.716250
L(58mm/a)   - L(23mm/a) = 6017.848090
L(58mm/a)   - L(25mm/a) = 5814.069107

Nothing changes above when l(.) replaces L(.) (up to 10 digits).

To sum up, l(Q) and s(Q) are excellent approximations of L(Q) and L(Q) - L(Q_0) for the values of Q that are of interest here.

An alternative derivation of (6) proceeds as follows. Since the spiral segment corresponding to radii r_0 and r makes n =(r - r_0)/p turns, its length may be approximated by the sum s over i = 1, ..., n of the circumferences of circles of radii r_i = r_0 + p * (2*i -1) /2. Straighforward calculations yield

s = (pi / p) * (r^2 - r_0^2),

which boils down to (6) for r = a * Q and r_0 = a * Q_0.

EDIT: Inserted missing braces in (3), and replaced w by f in (5).

[cfitz]

long discussion about average transfer speed...

cfitz, this extensive discussion wasn't really necessary, you've already convinced me (and i'm sure everyone else) with your previous explanation.

Then why, after my previous explanation, did you respond with "i have to disagree. i think it makes a very big difference. it boils down to what we mean by 'average speed'".

First, there really isn't any question as to what true CAV means, is there? ... All I am saying is that true CAV exhibits fixed, constant RPM and there should be no question about that at all.

no one disputes this (or has disputed it in previous posts in this topic).

Well, it hasn't been clear to me that there was no dispute on this. For example, KCK wrote:

"As we know with CAV, the acceleration is constant."

I believe this statement is false;

In this particular example I wasn't sure if KCK was just discussing the plot of V(s) with respect to the disc-minutes coordinate system or if this was meant to imply some variability in the RPM as well. Therefore, I wanted to confirm that we are all starting from the same foundation.

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.

again, no one has said otherwise as far as i recall.

Then why did you quote me and immediately launch into a statement about not believing what manufacturers say?

first, the RPM graph is convex, not concave. the speed graph is concave.
and again no one said this has anything to do with the characteristics of true CAV.

Sorry, I'm not a mathematician by profession like some people ( ) and so I didn't have the formal definition at my fingertips, and I didn't take the time to look it up. Thanks for the correction. As for having anything to do with true CAV characteristics, I pointed it out because there has been discussion about the speed graph being concave, when plotted as a function of disc-minutes, as a natural characteristic of CAV (which is true), and I wanted to point out that this does not apply to the RPM graph.

i'm not buying it - the part about the RPM i mean.
CAV is CAV as you have forcefully explained.
and all this stuff about some data buffered - it has no bearing on the RPM.

i'm assuming here that the CDSpeed program is getting the RPM info directly from the drive. if i'm wrong, and it's actually calculating it somehow from the data transfer speed (?!?!?!?!? ABSOLUTELY SHOCKED !!!) then of course the buffer would influence it too, but in this case i would find the RPM info of CDSpeed absolutely untrusworthy and unacceptable.

Then I think you should prepare to be shocked, because I believe your assumption is wrong. I have searched through MMC1, 2, 3 and 4 and they contain no commands for reading the RPM of a drive directly. I personally don't find that to be surprising, since the point of a data interface is to transfer data, not to measure the physical parameters of the underlying device.

Furthermore, it is unlikely that drive designers bother to include a method for directly reporting the drive RPM since, again, the point of the drive is to transfer data, not to report its internal physical parameters. However, even if they did provide such a method, the command for getting that information would be unique for each drive or manufacturer, since there is no standard MMC command for doing so. I doubt that Erik Deppe has coded a custom command for every drive out there, and I also doubt that such commands exist, period. That leaves calculating the RPM based on the data transfer rates and LBA position as the only alternative I can think of.

Perhaps an email to Erik Deppe regarding the source of the RPM information would be in order to resolve this particular issue with absolute certainty, but I know where I am placing my bet.

Now I will add one more point.

I believe that everyone has made peace with the correctness of Inertia's method for calculating the average transfer speed of a CAV graph based on the speeds at the end points, but there is still some dispute as to whether or not this method is intuitively obvious. Let me try to explain it in a way that I feel is intuitive.

First, we all agree that with constant RPMs, the physical tangential linear velocity is directly proportional to the radius from the center of the disc:

physical speed(r) = 2*pi*r*RPM

I'm not going to worry about specific units here. The above ends up being in meters per minute, for example, but you can easily scale in a linear fashion to any other units.

Since CDs are written with constant linear density (call it D bytes per m), the data transfer speed is also directly proportional to the radius:

V(r) = 2*pi*r*RPM*D

Thus, it is clearly evident that the data transfer speed is a linear function of the radius. Again, I don't think this is any amazing news, and I believe everyone already accepts this. But the point is, if it is a linear function of the radius, then the average speed can be calculated as the simple arithmetic mean of the speeds at the two extreme radii. And that is all that Inertia has said, in so many words.

If this still isn't obvious, then consider the innermost and outermost tracks at radii RI and RO. The amount of data transferred in one rotation of the disc is 2*pi*RI*D and 2*pi*RO*D respectively. One rotation of the disc takes 1/RPM minutes for both radii. Then the transfer speed for each individual track is given by my now infamous formula bytes/time:

2*pi*RI*D*RPM and 2*pi*RO*D*RPM

The average for transferring both is:

( 2*pi*RI*D + 2*pi*RO*D ) / ( 1/RPM + 1/RPM ) =
( 2*pi*RI*D*RPM + 2*pi*RO*D*RPM ) / 2

which, of course, is the average of the two individual speeds. Do the same for the next two adjacent tracks, which are separated by the track width tw, and you find that the average for transferring both tracks is:

( 2*pi*(RI+tw)*D + 2*pi*(RO-tw)*D ) / ( 1/RPM + 1/RPM ) =
( 2*pi*RI*D*RPM + 2*pi*RO*D*RPM ) / 2

which, again, is the average for the two outermost tracks because the tw terms cancel out. You can then continue in this way all the way to the centerline between the two extreme radii, and all of the tracks average out to the same value - that of the average of the outermost tracks, so that the total average over all radii is also equal to the average of the outermost tracks.

Now, all of the above is based on the simplification that the track width is negligible compared to the radius of the track so that the individual tracks can be treated as circles rather than spirals. Obviously this is not strictly true, but the error it introduces is extremely small. At the innermost track where the error would be largest, it is on the order of 1.5 microns compared to 2.3 cm, or less than one part in ten-thousand error. That is far smaller than anything that would be visible on CD Speed and also far smaller than the measurement noise.

The concavity that you and KCK are worrying about is due to plotting the data in the disc-minute coordinate system rather than the physical radius coordinate system. I think this has introduced a lot of unneeded complexity. It is not an uncommon phenomenon for a problem to be nearly intractable in one coordinate system but almost trivial in another. Anyway, you and KCK might want to try working in the radius coordinate system and use my simplification to see if that makes things easier.

all in all, i would like to commend you on this last post.

Thank you.

cfitz

[cfitz]

Ah, I see that while I was typing my response KCK has posted his own response. I have to start writing shorter replies to be more timely...

Anyway, it looks like KCK is coming around to the simpler way of doing things. Glad to see it.

I got there back in my freshman year of college when my father, who repairs clocks for a hobby, needed to purchase a replacement spring for a clock. He didn't know how long it should be, and he couldn't unwind it to measure it directly. He could measure the inner and outer radii when the spring was wound tight as well as the thickness of the spring, and asked me to derive a formula for calculating the length based on those numbers.

I whipped out my calculus texts, developed a complex model based on the spring being a spiral, fought my way through the integrals, and eventually wound up with a formula that contained a very simple dominant term along with a couple of tiny but complex correction factors. The magnitudes of these correction factors were negligible for the thin springs, so I scratched my head for a bit and then it hit me. Doh! With a tightly packed thin spring, the length could be easily and accurately approximated by dividing the area of the annulus (a trivial geometry calculation) by the thickness of the spring.

Ever since then I have always tried to find the easy way out, and these particular simplifications apply quite well to this CD problem ...

cfitz

[cfitz]

And with that, I think I will try to exit from this thread. I think Shakespeare had a good line that would apply to much of this thread...

cfitz

[dodecahedron]

KCK:
you convinced me with the argument that l(Q) is a good enough approximation for L(Q).

a couple of minor corrections:

1. in eq. 3, the factor 0.5*a should multiply both terms , not only the left one. this didn't influence your calculations because the right term is neglected in your approximation.

2. your w (omega) is not the rotational velocity but rather the rotational frequency (revolutions per unit time).
the rotational velocity is 2*pi*w.
(in traditional nomenclature, you should've used f - f is for frequency, w (omega) is for velocity. thus w=2*pi*f).

[dodecahedron]

I whipped out my calculus texts, developed a complex model based on the spring being a spiral, fought my way through the integrals, and eventually wound up with a formula that contained a very simple dominant term along with a couple of tiny but complex correction factors. The magnitudes of these correction factors were negligible for the thin springs, so I scratched my head for a bit and then it hit me. Doh! With a tightly packed thin spring, the length could be easily and accurately approximated by dividing the area of the annulus (a trivial geometry calculation) by the thickness of the spring.

had you studied physics (elementary physics - 1st year mechanics & electomagnetic theory) you would've hit on it right aways. it's the kind of calculations you do all the time in exercises in such courses.

[dodecahedron]

cfitz:

long discussion about average transfer speed...

cfitz, this extensive discussion wasn't really necessary, you've already convinced me (and i'm sure everyone else) with your previous explanation.

Then why, after my previous explanation, did you respond with "i have to disagree. i think it makes a very big difference. it boils down to what we mean by 'average speed'".

when i wrote "i have to disagree", i mean i disagree with your words: "The shape of the curve is irrelevant."
i think from my own words (just before that, in the same post):

cfitz, sorry for my stupid mistake.
the integral under the speed graph = the total number of bytes transferred, in theory at least.
so the two calculations should yield the same result."

it's clear that i came around and agreed with you on the matter of average speed.

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.

again, no one has said otherwise as far as i recall.

Then why did you quote me and immediately launch into a statement about not believing what manufacturers say?

i think if you read all my comments my position would be clear:
the "again, no one has said otherwise" was again meant at the CAV issue, this was a repetition of what i had said twice just before that.
about the manufacturers etc. like i said i take their claims with a grain of salt.

As for having anything to do with true CAV characteristics, I pointed it out because there has been discussion about the speed graph being concave, when plotted as a function of disc-minutes, as a natural characteristic of CAV (which is true)...

"which is true": well, i'm pretty sure it is true, i think i was the first to point this issue out (in this topic at least) (notwithstanding the matter of the CAV not actually having constant RPMs), but i have'nt seen a "proof" yet. that is, KCK didn't proove it in his analysis and no-one gave a convincing explanation. nevertheless i do think it's true. maybe when i'll have time to work this model more thoroughly i'll try to show it.

i'm not buying it - the part about the RPM i mean.
CAV is CAV as you have forcefully explained.
and all this stuff about some data buffered - it has no bearing on the RPM.

i'm assuming here that the CDSpeed program is getting the RPM info directly from the drive. if i'm wrong, and it's actually calculating it somehow from the data transfer speed (?!?!?!?!? ABSOLUTELY SHOCKED !!!) then of course the buffer would influence it too, but in this case i would find the RPM info of CDSpeed absolutely untrusworthy and unacceptable.

Then I think you should prepare to be shocked, because I believe your assumption is wrong. I have searched through MMC1, 2, 3 and 4 and they contain no commands for reading the RPM of a drive directly. I personally don't find that to be surprising, since the point of a data interface is to transfer data, not to measure the physical parameters of the underlying device.

Furthermore, it is unlikely that drive designers bother to include a method for directly reporting the drive RPM since, again, the point of the drive is to transfer data, not to report its internal physical parameters. However, even if they did provide such a method, the command for getting that information would be unique for each drive or manufacturer, since there is no standard MMC command for doing so. I doubt that Erik Deppe has coded a custom command for every drive out there, and I also doubt that such commands exist, period. That leaves calculating the RPM based on the data transfer rates and LBA position as the only alternative I can think of.

yes. after my previous post i had given this issue some thought and came to the same conclusions you just gave.
and yes i am shocked!. well, what i mean is that henceforth, i will eye this RPM data with a much more suspicious eye. and consequently, my previous comments and discussions about the RPMs not being constant and the effect of this on the discussion of this model - well, i guess i can just chuck it all away... since i don't trust this RPM data anymore..

I believe that everyone has made peace with the correctness of Inertia's method for calculating the average transfer speed of a CAV graph based on the speeds at the end points, but there is still some dispute as to whether or not this method is intuitively obvious. Let me try to explain it in a way that I feel is intuitive.

well, my point is (and i've written it before in this topic) is that Inertia simply took the algebraic average of the starting and ending speeds. there's no intuitive and "immediate" explanation for this IMO, and Inertia's justification for this (the formulae for constant acceleration, which he linked to) do not explain or justify his computation. again, IMO. however KCK first and now you do give a derivation of this, which is fine by me.

The concavity that you and KCK are worrying about is due to plotting the data in the disc-minute coordinate system rather than the physical radius coordinate system.

just my point (which i alluded to when i first raised the issue of the concavity of the graph). and like i said above, i believe that this is indeed the reason (or one of the reasons) for the concavity of the graph, but am not 100% convinced.
i will be when someone shows a mathematical proof or an intuitive explanation.

[Inertia]

I guess you just can't trust those science teachers. No wonder our schools are in trouble.

seeing as i'm a science teacher (math), should i be offended ?

Yes.

See Understanding of the Speed and Acceleration Formulas.
<snip>
Also, see Acceleration Formulas.

believe you me, i've no need for those references, i know all these formulae by heart! i guess you do get something from a B.Sc. in physics!

Ah yes, you are not happy when I provide references which you consider redundant for a learned scientist as yourself. KCK is not happy when I don't provide references which he considers essential to a proof. What a fun group.

"As we know with CAV, when the acceleration is constant the velocity increases linearly."
Far from being God-given, I felt that this statement would be so obvious to the technical know-how of this group that I did not expect it to be challenged.

i quite agree, this requires no derivation, this is obviously true.

You didn't quite agree with this obvious truth for very long, did you. Refer to http://www.cdrlabs.com/phpBB/viewtopic. ... c&start=27 which I will answer separately.

Concave graph?? to my eyes it is so negligible as to be unremarkable and not an issue. Have you considered that the graph may be distorted? As cfitz has explained, either we are dealing with CAV or not. I don't think anyone is claiming to have evidence that the burner manufacturers are lying to us about using CAV because someone imagines they see something different in a CD Speed graph. As I have stated, the fixed RPM of CAV provides constant acceleration in a linear fashion, i.e., a straight line, from the inner hub to the outer edge of the disc. This is a fact, and not a matter of opinion.

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...
since when have we questioned the accuracy of the CDSpeed graphs? this is the first i see of it in these forums after more than a year browsing through them.
why are all the CLV and ZCLV graphs "really straight" lines, but the RPM not? if the drive manufacturers can make a drive that does maintain a fixed linear velocity, why can't the RPM be fixed too?
if the CDSpeed graph of a CLV and ZCLV is indeed a straight horizontal line, it seems to me that CDSpeed is accurate enough. so if the RPM is not, why are you questioning CDSpeed now?
if you go this way, why trust any of the data from CDSpeed? why trust the starting and ending speeds, the total time etc. etc. ?
i take these graphs at face value. and they all show that the RPM isn't really constant. this is in reference to KCK's comments and mine about non-fixed RPMs. it should be true CAV, but apparently, according to the empirical data supplied by CDSpeed, it's not.

and this could be another possible explanation for the speed graph not being linear.

cfitz has already addressed the "RPM issue" to my satisfaction, which I felt to be a nonissue to begin with. My reason for addressing this point is that there is a prejudice involved in suspecting the veracity of drive manufacturers, whose word you state elsewhere that you "always take with a grain of salt". On the other hand, the CD Speed graph is treated as if it were the Holy Grail of CD testing, to be trusted implicitly in the face of opposing evidence. I, too have used this program for several years and commend it highly, but it has had its share of bugs and inaccuracies along the way. Placing blind faith in any freeware testing program/graph can be risky, as it may be not intended to be used for rigorous analysis. At this point, I think that we are fairly well agreed that the Average Speed shown on the CD Speed CAV graphs is inaccurate and does not comply with a standard definition.

As cfitz has alluded, sometimes those that are used to complicated issues may have difficulty with an uncomplicated approach and a simple solution. To my knowledge, there is only one way of calculating an average speed for a CAV data transfer. In the example given, the test disc was exactly 74 minutes. It took 2:04 minutes to transfer the data. 74 / 2:04 is equivalent to an average transfer rate of 35.835x. This average transfer rate was the same rate that was calculated without benefit of minutes in my earlier post, so this is a proof of the average rate. An average transfer rate should be equivalent to a CLV rate that would produce a 74 minute data transfer in a given amount of time. At at (theoretical) CLV rate of 35.835x, a 74 minute disc would be completed in 2:04.

The fact that the transfer was completed in 2:04 minutes is a virtual proof that there can be no "concave" speed curve or RPM change in the CAV transfer. If the provided starting and ending speeds are used, linear acceleration is the only model that fits the completion time of 2:04 minutes. Any variation from constant acceleration would produce a different time.

i still disagree about some of the average speed issues.
granted, dividing the total number of bytes transferred by the time to transfer, will give the speed of an equivalent CLV transfer of the same data at the same time. and this is the "formula" for average speed that cfitz has advocated.

Programs may use cfitz's bytes transferred method to derive average transfer speed or in process speed measurements (or not). For the user, average transfer speed is easily calculated as a time measurement comparing the read or write time to the total time recorded on the disc. A 1x recording takes 80 minutes, 10x takes 8 minutes, 40x takes 2 minutes, etc.. What other "formula" for average speed is there?

however, this most definitely does not proove your calculation that the average speed is the algebraic average of the starting and ending speeds. not does it proove, as you claim, that there is no concavity. and to claim that "linear acceleration is the only model that fits the completion time of 2:04 minutes. Any variation from constant acceleration would produce a different time." is patently a false statement.
i'm looking and the empirical CDSpeed data. the plot is concave. you can't ignore it, i'ts visible to the eye. if i can see it with my eyes, it's significant enough that i can't just ignore it.

Yes, this must be driving you crazy. You have staked out a position against something that works, and now you dismiss it because you don't consider it a scientific "proof". It may not be the rigorous mathematical proof that you prefer, but a formula that provides accurate and repeatable empirical results is usually considered to be proof enough for nonquibblers.

If the plot were concave or convex and the speed increase was not linear and slowed down or speeded up, the total reading time would be affected. Why is this "patently a false statement"? Theoretically, perhaps if a sine wave were plotted over the midpoint or symmetrically along the curve so that the speed increases/decreases cancelled out, then the same elapsed time would obtain. Otherwise, the time would change. The average speed formula that I offered only provides accurate results when there is constant acceleration and linear velocity. It has worked so far on every CAV graph tested, although admittedly a very small sample. If this method has flaws, they are insignificant, and if it offends you with its simplicity try to see it as a useful empirical tool.

[cfitz]

had you studied physics (elementary physics - 1st year mechanics & electomagnetic theory) you would've hit on it right aways. it's the kind of calculations you do all the time in exercises in such courses.

If this way of thinking about the problem and the simplifications it brings are so straight away obvious, then for goodness sake lets make use of the them (which KCK has begun to do so) and stop filling up pages with complex equations and stop giving Inertia a hard time for recognizing and using simplifications early on.

By the way, I did take first year physics, but I don't recall solving any problems like my spring problem. Of course, that is really neither here nor there, since I simply may have forgotten them...

when i wrote "i have to disagree", i mean i disagree with your words: "The shape of the curve is irrelevant."
i think from my own words (just before that, in the same post):

cfitz, sorry for my stupid mistake.
the integral under the speed graph = the total number of bytes transferred, in theory at least.
so the two calculations should yield the same result."

it's clear that i came around and agreed with you on the matter of average speed.

Yes, but then two paragraphs later you turned around again and wrote "it boils down to what we mean by 'average speed'," suggesting that there is at least one other correct definition for the average speed. Because of this I was confused as to whether or not you actually did agree with my definition.

By the way, the integral under the speed graph isn't actually the total number of bytes transferred for the graphs shown by CD Speed. The reason for this is that the 'time' on the CD Speed graph isn't the real wall clock time that was used to measure the 'instantaneous' speed at each point on the graph. Instead, the 'time' units on the CD Speed graph merely represent the position along the data spiral of the CD, and could more accurately be thought of as a proxy for the total number of bytes transferred. In order for the intergral to yield the actual number of bytes transferred the curve of bytes/unit time must be plotted against true time (unless, of course, you toss in the ds/dt relationship as part of the integral, where t is true time and s is the disc time - I think this is KCK's nomenclature - but this is brings on hideous complexity again).

This is the reason for the concave nature of CD Speed's graph when plotting CAV results. The further to the right you go, the less real physical time that corresponds to each 2-minutes of disc-time plotted by CD Speed. This effectively stretches the true time axis of the right side of the graph, and causes the slope of the transfer speed curve to taper off when plotted using this coordinate system. You can see this in the numbers I reported in my earlier post where the first 38 disc-minutes of the graph took 77 true seconds to collect while the last 40 disc-minutes took only 54 true seconds.

It is probably also the reason that CD Speed reports a higher average speed than the true average speed. The more I look at this and see what CD Speed is plotting, the more it appears that Erik Deppe averages the individual samples of transfer speed as you suggested at one point. This would work if the samples were collected at equal intervals of true time, but instead they are collected at equal intervals of disc time (equal numbers of byte transferred). With CAV the speed keeps going up, so the true time per unit chunk of bytes transferred keeps going down, leading to an artificial emphasis of the higher speeds (a fixed true-time interval of high speed transfer is spread over more and more disc-minutes giving more weight to those samples).

This may also be the reason that you are having/did have a hard time accepting Inertia's simple justification for his method of calculating the average transfer speed for a true CAV curve. CD Speed's method of plotting the graph hides the fact that the transfer speed is a true linear function of true time. With CAV, the RPM is constant. Thus, every rotation of the disc takes the same fixed interval of time. And every rotation of the disc moves the pickup head the same fixed distance. That is, it moves one track pitch outward with each rotation. Thus, the change in radius is equivalent, to within a scale factor, to the change in true time.

Now, we have already established in an earlier post to no one's surprise that the transfer speed is a linear function of the radius, so that if we plot transfer speed as a function of radius we will have a strictly linear curve. Again, this is no surprise. And we just established that the radius is equivalent (to a scale factor and fixed offset) to true time, so a plot of transfer speed against true time will also be strictly linear. Inertia's formula follows easily from this and your own (slightly amended) statement that the area under the curve gives the total bytes transferred.

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.

again, no one has said otherwise as far as i recall.
<snip of cfitz's confusion regarding dodecahedron's last statement>
i think if you read all my comments my position would be clear:
the "again, no one has said otherwise" was again meant at the CAV issue, this was a repetition of what i had said twice just before that.
about the manufacturers etc. like i said i take their claims with a grain of salt.

Okay, I guess you are trying to say that although you quoted two of my sentences, the first that was the main point of my statement and a second that was merely a subordinate sentence elaborating on the first, your comment was only directed towards the subordinate second sentence and had nothing to do with my first sentence. I hope you understand my confusion. That is a lot to try to figure out based on your original single comment. If you didn't mean to comment on my first sentence, you shouldn't have included it in the quotation.

well, my point is (and i've written it before in this topic) is that Inertia simply took the algebraic average of the starting and ending speeds. there's no intuitive and "immediate" explanation for this IMO, and Inertia's justification for this (the formulae for constant acceleration, which he linked to) do not explain or justify his computation. again, IMO.

I guess we will just disagree on this. In my opinion, a speed that increases linearly with time as I described above seems to be pretty clearly constant acceleration, and I do find the explanation to be intuitive.

As for having anything to do with true CAV characteristics, I pointed it out because there has been discussion about the speed graph being concave, when plotted as a function of disc-minutes, as a natural characteristic of CAV (which is true)...

"which is true": well, i'm pretty sure it is true, i think i was the first to point this issue out (in this topic at least) (notwithstanding the matter of the CAV not actually having constant RPMs), but i have'nt seen a "proof" yet. that is, KCK didn't proove it in his analysis and no-one gave a convincing explanation. nevertheless i do think it's true. maybe when i'll have time to work this model more thoroughly i'll try to show it.

and

The concavity that you and KCK are worrying about is due to plotting the data in the disc-minute coordinate system rather than the physical radius coordinate system.

just my point (which i alluded to when i first raised the issue of the concavity of the graph). and like i said above, i believe that this is indeed the reason (or one of the reasons) for the concavity of the graph, but am not 100% convinced.
i will be when someone shows a mathematical proof or an intuitive explanation.

Didn't I already give an intuitive explanation about which you commented:

thank you for giving a very nice and intuitive explanation for the concavity of the speed graph

(from http://www.cdrlabs.com/phpBB/viewtopic. ... 2176#72176 )



cfitz

[cfitz]

For the user, average transfer speed is easily calculated as a time measurement comparing the read or write time to the total time recorded on the disc. A 1x recording takes 80 minutes, 10x takes 8 minutes, 40x takes 2 minutes, etc.. What other "formula" for average speed is there?

I agree, but then I would because it is another way of expressing the formula I offered. We are both saying the same thing here.

cfitz

[cfitz]

I don't know, but maybe this exaggerated picture will help to explain the time stretching (or dilation) effect of CD Speed's graphs of CAV transfers and the subsequent concave graph and inflated reported average (don't mind the exact values of the numbers, they are for illustrative purposes only):



The top figure shows the true linear nature of CAV speed progression when plotted against true time, as I explained in my earlier post. The cyan, yellow and red lines show the true elapsed wall-clock time at 4, 8 and 12 seconds along with the corresponding transfer speed.

The bottom figure shows the same curve plotted using CD Speed's coordinate system, where the x-axis is disc minutes. In other words, every division of the x-axis corresponds to a constant, fixed number of bytes on the disc (18,000 KiBytes for a data disc).

Now, I have transferred the cyan, yellow and red true time markers down to the bottom graph as well. Notice that they are stretched out, comparatively, the further to the right you go. This is because at the higher transfer speeds towards the edge of the disc, the more blocks of 18,000 KiBytes (2 disc-minutes worth of data) can be transferred per unit of true wall-clock time.

In my example I started with a transfer of one block of data at 12x that took 4 wall-clock seconds. Then the next two blocks of data are being transferred twice as fast at 24x, so they two of them can go in the next 4 wall-clock seconds. The final four blocks of data are being transferred at 48x, four times as fast as the first, so four of them can go in the final 4 wall-clock seconds. Again, don't get hung up on the actual numbers. I know I have played a little fast and loose here, selectively and somewhat inconsistently chose my speed numbers, and true figures won't work out quite this neatly. But this example does illustrate the general idea, and that idea is sound.

You can clearly see from the lower graph how plotting against disc time the way CD Speed does introduces concavity to the CAV curve, even though it isn't there when plotted in true wall-clock time. You can also see how it would lead to an inflated estimate of the average speed if the average is found (incorrectly) by calculating the average of the samples at each 2 disc-minute mark. The speeds from 36 to 48 would get four samples weighted into the average, which is four times what the actual weighting should be.

cfitz

[Inertia]

just a small clarification to the whole "As we know with CAV, when the acceleration is constant the velocity increases linearly" issue.
or maybe my next words won't clarify anything, just stir things up even more.

You got that right!

"when the acceleration is constant the velocity increases linearly"
this is a true statement.

however it has nothing to do with CAV.
CAV means Constant Angular Velocity.
this means that the angular velocity is constant, and hence the angular accelaration is zero!

That's right, when CAV is operative, Angular Acceleration is zero. Angular Acceleration is the rate of change of angular velocity with time. This absence of AA is what provides the linear speed increase with constant acceleration of the read speed (obviously not AA).

that the linear (tangential) velocity increases, this has nothing to do with acceleration in the "normal" sense, it's due to the increas in the radius.

Yes, annoying isn't it. But for all practical purposes it works the same way, including constant acceleration.

i think this is why KCK "disputed" Inertia's remark. not because of it's untruthfulness but because it's not directly related to the discussion at hand.

Huh? I thought this discussion was about formulas to determine average speed using CAV starting and ending points. KCK objects from a purist point as you do, that this formula is used for "normal" straight line acceleration and average speeds, not circular motion. If it happens to happily work with accurate and repeatable results in a CAV environment, this seems to be disturbing from a purist view. I don't have that problem.

and also the reason for my comment about the inappropriate use of an algebraic average in this context
(algebraic average of x and y = x + y divided by 2).
the algebraic average of the initial speed (at the inner hub) and the final speed (at the outside of the cd) i exactly equal to the speed at the midway point between them (radius-wise), and i don't see any natural/intuitive/simple/obvious reason to see that this is the average speed in the "normal" sense (as by cfitz) - total data transferred divided by the time to transfer.

To my understanding, the average speed method proposed by cfitz is not the "normal" sense as much as dividing the total disc time by the read or write time. This is the "normal" sense to me, but they are really the same thing expressed in different ways and should give exactly the same result if calculated accurately. There is absolutely no question that total disc time divided by read or write time is a (the) standard method of determining average speed.

Look at it from a common sense point of view. If all you knew was that a disc had exactly 74 minutes of data and took exactly 2:04 minutes to read, you probably would have no problem at all in agreeing that the average reading speed was 74 / 2.065 = 35.835x.

But, when the known start and ending speeds are added and divided by 2, and though the result agrees exactly with the normal method of determining read/write speed, you have a problem with this??? because it doesn't seem natural/intuitive/simple/obvious to you. Try to get over it and use your mathematician's discipline to overcome your distaste. Remember, if it walks like a duck, quacks like a duck or looks like a duck, then it's a duck. And even if it's not a duck, it's close enough to one to provide a empirical working model.

If it's any consolation, it seems very natural to me. In fact, I normally avoid threads like this, because they are usually just platforms for ego manifestation, nitpicks, and quibbles, with no real purpose or utility other than to flaunt skills using some obscure point as a pretext. The purpose is usually not to elucidate or educate, but to show off. cfitz is an exception to this, as he usually makes an effort to write with clarity and to make concepts comprehensible. KCK invited me to comment on this thread, or else I wouldn't have joined in.

Not being a mathaholic, and out of my element in this pure environment, I felt if I was to contribute it would have to be in a straightforward common sense way of addressing the question in a way that would solve the problem and be understandable to other members of these forums. So I took an intuitive approach. Acceleration was the first thing that came to mind, since the linear read speed slope of a CAV drive seemed to be accelerating at a constant rate. Thus, I looked up acceleration formulas, and they worked to provide the accurate average speed results I was looking for. There is some confusion about acceleration, because I had always meant read speed acceleration, not angular acceleration.

In any event, I realize that this unscientific approach is distasteful to some, but the results speak for themselves. If it's any solace, I would propose a model which could be used to visualize the concept with which I am working using the starting and ending speeds of Graph #1:

5328 meters to travel in spiral grooves of a 74 minute CDR (3.3 miles)
1.2 m/s scanning (reading) velocity @ 1x
26.484 m/s starting velocity @ 22.07x (59 mph)
59.52 m/s ending velocity @ 49.60x (133 mph)
33.036 m/s velocity increase over 5328 meters traversed

V = Vo +AT where V = ending velocity, Vo is starting velocity, A is acceleration, and T is time. (The math wizards don't need this, but this is not for them).

A = (V - Vo) / T = 7.44E-03 m/sec²

Thus, in this model the start speed is 22.07x or 26.484 m/s and increases with constant acceleration at a rate of 7.44E-03 m/sec² for 4,440 sec. (74 min.) This provides the necessary elements to use this model as an analog for "normal" acceleration.

See Constant Acceleration Motion.

I hope that my elementary math and simplifications don't overly offend scientific sensibilities, but it's the best I can do.

Sorry for my irascibility, but I have a hard time with threads like this.

1. fixed spelling
2. fixed total seconds and acceleration rate

[cfitz]

Here is a more realistic example of the time dilation caused by plotting CAV transfer speeds against disc-minutes rather than true wall-clock time:



For ease of round numbers I am presenting 72 disc-minutes worth of data burned on a 74-minute disc. It takes 120 true wall-clock seconds to read the 72 disc-minutes of data on a theoretical drive whose instantaneous reading speed varies from 24x to 48x over the span of the 72 disc-minutes worth of data. These figures aren't precisely correct for a real drive, but they do match up very close to my actual physical drive.

As with my first example, the top figure shows the true linear nature of CAV speed progression when plotted against true time. The speed varies linearly over the full 120 true wall-clock seconds from 24x to 48x, and I have selected four points, 0, 40, 80 and 120 true wall-clock seconds, to plot as points on the graph.

To plot these same points on the lower CD Speed style graph where the time axis is not true wall-clock time but rather disc-minutes, we need to calculate how far along the disc the drive reads in each of the true 40 wall-clock second intervals.

Over the first 40 true wall-clock seconds the speed varies from 24x to 32x for an average value of 28x. Since we are reading data on average 28 times faster than true wall-clock time, the amount of disc-minutes worth of data read is:

( 40 true-sec ) * ( 28 disc-sec / 1 true-sec ) * ( 1 disc-min / 60 disc-sec ) =
18.6667 disc-minutes, or 18:40

Thus, we plot the cyan mark of 32x at 18:40 disc-minutes as shown on the lower graph.

Over the second 40 true wall-clock seconds the speed varies from 32x to 40x for an average value of 36x. Repeating the calculation we have:

( 40 true-sec ) * ( 36 disc-sec / 1 true-sec ) * ( 1 disc-min / 60 disc-sec ) =
24 disc-minutes

Thus, we plot the yellow mark of 40x at 18:40 + 24 = 42:40 disc-minutes as shown.

Similarly, the average speed for the last 40 true wall-clock seconds is 44x, and the amount of disc-minutes read is:

( 40 true-sec ) * ( 44 disc-sec / 1 true-sec ) * ( 1 disc-min / 60 disc-sec ) =
29.3333 disc-minutes, or 29:20

And we plot the last red mark of 48x at 42:40 + 29:20 = 72 disc-minutes, as it should be.

I have drawn a gray straight line on the disc-minute coordinate system of the lower graph to highlight the concave nature of the transfer speed curve in this coordinate system, because it is a little harder to see with the naked eye in this more realistic, less exaggerated example.

Note that despite the time dilation, the end points are still accurate, and thus can be used to accurately calculate the average transfer rate when the curve is, in fact, true CAV. What one can not accurately do is integrate the sample points over the disc-minute axis to obtain an average speed, which I suspect is what CD Speed is doing. By the way, integrating over disc-minutes would be accurate for a CLV transfer curve, because in that case disc-minutes and true wall-clock minutes would correspond directly to within a constant scale factor.

Does this help?

cfitz

[Inertia]

Very well done, cfitz. This is an excellent explanation and clears up some misconceptions about the CD Speed CAV graph results.

Something useful did come from this thread, after all.

[cfitz]

Thanks Inertia. I just edited it to make the various units in the equations more explicit. That should make it easier to follow the translations between the different units and hopefully make it even clearer what is going on.

For those who aren't familiar with dimensional analysis, an easy way (in my opinion) to read the equations is (using the first as an example):

40 true-sec, times for every 1 true-sec there are 28 disc-sec, times for every 60 disc-sec there is 1 disc-minute.

The 40 true-sec is the wall-clock time we are starting with and wish to convert to disc-minutes while the 28, of course, comes from the fact that the average speed is 28x. The purpose of the final 1:60 ratio should be self evident.

cfitz

[MediumRare]

Wow, this has become a long thread! I looked at it several times over the weekend and started to prepare answers but then kept finding that most of what I wanted to say had already been said. It just happened again. I'll make this one post now anyway and then get on to other matters. On the whole, I'm glad I stayed out of most of it (this is not to say that these exercises can't be fun ).

One point to start off- these formulas are awful without the proper symbols. I wrote everything on paper (with thetas and omegas etc.) before trying to go through the math.

I don't want to leave my previous post completely uncorrected (way back- it's really ancient history now). It had many errors in it and my only excuse is that it was Friday evening after a long week. The brain becomes sluggish and opaque.

Apart from +/* problems, my formula was incorrect as posted. The correct form is

Code: Select all

s(T) = 0.5*(V_0 + V_T) * T

This can be solved for T:

Code: Select all

T = s(T) / 0.5*(V_0 + V_T)

which is precisely what Inertia used (and what I used to calculate the total times I posted).

The reference to the spin-up time was a "red herring" from trying to understand the average speed.

My "derivation" was also incorrect in several ways, primarily because I mixed up the 2 usages of "minutes" in this problem.
- the amount of data on the disk (1 min = 60*75*2352 Bytes raw data)
- the elapsed time.

This has been amply discussed. In particular, cfitz said it well and got to the crux of the matter:

By the way, the integral under the speed graph isn't actually the total number of bytes transferred for the graphs shown by CD Speed. The reason for this is that the 'time' on the CD Speed graph isn't the real wall clock time that was used to measure the 'instantaneous' speed at each point on the graph. Instead, the 'time' units on the CD Speed graph merely represent the position along the data spiral of the CD, and could more accurately be thought of as a proxy for the total number of bytes transferred. In order for the intergral to yield the actual number of bytes transferred the curve of bytes/unit time must be plotted against true time (unless, of course, you toss in the ds/dt relationship as part of the integral, where t is true time and s is the disc time - I think this is KCK's nomenclature - but this is brings on hideous complexity again).

Let me defend KCK's derivation, however. He wasn't just trying to derive the formula for data transfer at constant angular velocity. He actually used the speed graph as shown by CD Speed as a basis for his examination, and the complexity is there.

On the other hand, I don't think that any tractable model (V(s) or V(t)) can predict the total transfer time (I'm avoiding the term "average speed" here) for anything beyond the classical cases of CLV/CAV/PCAV, not even the ZCLV cases cfitz dug up (remember when those were the "bees' knees"?). How about trying to analyze a graph like this one:

(excuse the quality- it was scanned from a magazine for another purpose). We'll have to leave this to the test tools.

Incidentally, there is an alternative to CD-Speed: the "Performance/Transfer rate" Option in KProbe. I tested one disk with both tools (stopping the total time in KProbe manually, with a choice of 1 min. sampling) and the results were identical, down to the reported "average speed".

Peace.

G

[KCK]

Apologies to everybody for my recent lack of feedback. I had other duties, and I spent most of my spare time on writing up both models.

I'll comment separately on the recent interesting work of cfitz and others.

Although I'm still trying to polish both models (mostly fighting with notation), I'd like to announce a basic result on CD Speed's graphs.

My model for the graph produced by CD Speed has the following form:

h(d) = sqrt[k_0^2 + (k_T^2 - k_0^2) * d / d_T],

where d is the disc length (in Minutes) varying between 0 and d_T, whereas the parameters are those reported by CD Speed:

d_T = total disc length in Minutes,

k_0 = starting speed in 1x,

k_T = ending speed in 1x.

In particular, d_T = xx + (yy + zz / 75) / 60 when CD Speed reports a Disc Length of the form xx:yy:zz in the MSF format.

Note that h(d) is concave; this should whet the appetite of the scientific-minded members for the forthcoming analysis.

For the unscientific members, it's enough to compare graphs of h(d) with CD Speed's pictures, such as those in the CDFreaks' review of Plextor Premium referenced in my initial post:

http://www.cdfreaks.com/article/112/4

Actually the CD Speed pictures should be slightly expanded in the horizontal direction to compensate for the fact that apparently the ending speed is displayed at length d' instead of d_T, where usually d' <= d_T - 2 (as discussed by cfitz); e.g., for the first picture with d' = 72 and d_T = 74, the expansion factor is d' / d_T = 74/72.

Unfortunately I can't post pictures; hence it would be nice if other members (e.g., cfitz or MediumRare) could post CD Speed's pictures and the corresponding graphs of h(d) (or just the graphs of h(d) for the first three CDFreaks' pictures).

Finally, for guessing the value of CD Speed's Average Speed, we may consider the mean value of h(d) over the interval [0, d_T]:

M_h = (1 / d_T) Int_0^(d_T) h(x) dx = 2/3 * (k_T^3 - k_0^3) / (k_T^2 - k_0^2)

and its various discretizations. The simplest approximation via the (two-point) trapezoidal rule yields the `true' average speed:

M_T = 0.5 [h(0) + h(d_T)] = [k_0 + k_T] / 2,

which underestimates M_h because h(x) is concave. Hence we should consider more sophisticated discretizations. Since complications arise when d_T is not even, let's consider a simple example.

For the first picture, Average Speed = 37.57, whereas M_h = 37.597478. Recalling that d_T = 74, consider the discrete averages:

M_l = (2/74) Sum_{i=0}^36 h(2i) = 37.223941,

M_t = (2/74) {[h(0) + h(d_T)] / 2 + Sum_{i=1}^36 h(2i) = 37.595968,

M_u = (2/74) Sum_{i=1}^37 h(2i) = 37.967995.

Note that M_l < M_t < M_h < M_u by the concavity of h(x). My current bet is that CD Speed employs something similar to M_h or M_t.

The same numbers were computed from the two equivalent forms of h(d):

h(d) = k_0 * sqrt{1 + [(k_T / k_0)^2 - 1] * d / d_T},

h(d) = sqrt{[k_T^2 - k_0^2] / d_T} * sqrt{d + d_T/[(k_T / k_0)^2 - 1]}.

EDIT: Removed the comment on inaccuracy (in fact due to a bug).

[cfitz]

I'm glad to see you are back, KCK. I didn't intend for my presentation of alternative ways to look at the problem to drive you off.

Anyway, here are the comparison graphs you wanted. The results of your model are plotted in purple (ignore the purple rectangular frame - that was just to help me line up the curve on the existing scale).

I didn't stretch the time axis after the fact as you suggested, but instead used the tested length of the disc for d_T (i.e. 72 or 74 minutes) rather than the actual recorded size of the disc.

Agreement appears to be very good for all the charts except the last, where it is thrown off by the irregularity at the beginning of the test. I don't hold this against your model, since it obviously isn't intended to model such effects, but included the chart as contrast to illustrate the good match of the other four charts. The green of the measured transfer speed is not visible under the curve of your model in the first four charts.











cfitz

[KCK]

The only reason why I delayed posting my results was that I wanted to be accurate enough to clear up some misunderstandings, at least for myself. Your presentation of alternative viewpoints certainly helped; more on that later.

Anyway, thanks a lot for the comparison graphs. When I wrote about expanding the CD Speed graphs, this was meant as a mental exercise, not a demand for anybody who would care to provide pictures. However, your idea of shrinking d_T in h(d) to the final length displayed on the CD Speed graph is very nice. Like everybody, I'm still wondering what CD Speed actually displays, and gathering titbits like this one may help in the long run.

For the final picture, of course a CAV-based model can't handle the initial non-CAV behavior. Note, however, that the model could be used for the `stable' part. For instance, let k_0 be the speed read of the CD Speed graph at 6 Minutes, and use d_T = 74 - 6 = 68.

BTW, I edited my previous post to include some average speed results.