[time-nuts] ADEV vs. OADEV

Magnus Danielson magnus at rubidium.dyndns.org
Fri Jan 23 00:35:59 UTC 2009


Tom Van Baak skrev:
>> One point of confusion is that AVAR(tau) should not be directly 
>> interpreted as Allan Variance in general, it is actually already defined 
>> and reserved to mean a chosen Allan Variance estimator. This is an 
> 
> Sorry if I'm jumping into this thread late, but this statement
> confuses me.

Feel free to join in...

> Since when is "AVAR" not simply short-hand
> for "Allan Variance"?

Good question. My point being that yes... AVAR is a handy short-hand for 
Allan Deviation, but it is also actually a standardised quantity and 
several standards actually define it consistently as a particular 
estimator. It's a good estimator for being of the Allan Variance family 
and CPU-cycles should not prohibit us from using it.

Recall that they are all estimators. I think this is a crutial point to 
learn really. Once one has accepted that fact, then taking a look at 
which estimator serves me the best becomes the issue of interest, not 
"which is the right one?" which is actually an incorrect question in 
this context.

So, feel free to short-hand Allan Variance as AVAR, but there are 
context in which this is going to be interpreted as being the 
overlapping Allan variance estimator and not any other estimator, and 
hence using that short-hand can be ambiguous. If we want an unambiguous 
use of AVAR, do not use AVAR as short-hand for Allan Variance when using 
other estimators than the overlapping one. Do as you please, but now you 
are aware of the issue.

Also, look at the NIST SP 1065 for instance, where it is clearly 
indicated that the "original" is being superseded in most practical use 
for the benefit of the overlapping, giving improved confidence 
intervals. Also, Modified Allan Variance and Theo should be considered 
as better alternatives.

The SP 1065 should be a good read for many, as it gives a modern 
overview and also addresses several practical implementational issues 
such as software test-sequences etc. The TN 1337 is a more classic view 
and collection of articles.

So... we could argue all we want about "which is the correct Allan 
Variance" but it doesn't really help. The original estimator is flawed. 
the overlapping estimator improves confidence and the Theo family should 
provide even better results.

> Next you'll tell me SDEV isn't Standard Deviation because some
> self-important standards organization decided otherwise.

I could probably find a standard defining it to something completely 
different and totally out of context which would not help.

But the reaction is natural, but one must realize that there is not real 
"right" here, so sometimes putting down the foot and say "this is what 
we define it to be" is needed so that everyone at least do it according 
to the same procedures and with known errors... until you realize that 
you need something better and move over to some other measurement which 
you define in a similar fashion. It's like say the meter standard. "This 
is the meter... until we say something different".

Cheers,
Magnus



More information about the time-nuts mailing list