[time-nuts] σ vs s in ADEV

[Bob Camp]

HI

> On Jan 5, 2017, at 6:33 AM, Magnus Danielson <magnus at rubidium.dyndns.org> wrote:
> 
> Hi,
> 
> On 01/05/2017 01:26 AM, Tom Van Baak wrote:
>> Hi Attila,
>> 
>> The plain ADEV calculation is essentially a measure of unexpected or
>> unwanted drift in frequency; which is the 1st difference of frequency
>> error; the 2nd difference of phase error; the 3rd difference in clock
>> time itself.
> 
> ADEV is thus sensitive to linear drift, which becomes a limiting factor for higher tau.
> 

Which is *why* the standard verbal description of ADEV always includes the qualifier 
“drift corrected”. If drift is not removed from the data, ADEV is not doing what it should.
This gets overlooked when we take ADEV straight off of a cool piece of gear that is unable
to properly / automatically remove the drift.

Bob


> I can't see how clock time itself would integrate from phase. The time of a clock is just an enumeration of phase. Phase is often presented in a wrapped phase, but if you enumerate it is still just phase with larger numbers, ADEV is still just 2nd difference away, not 3rd. It's actually the time of x being used, not phase.
> 
>> When measuring the quality of a clock, the key idea is that initial
>> phase doesn't matter (you can always manually set the time), and even
>> initial frequency doesn't matter (you can often adjust the rate:
>> whether pendulum, quartz or atomic clock), and so a more honest
>> measure of intrinsic timekeeper stability is its ability to maintain
>> frequency; that is, statistically speaking, the lower the change in
>> frequency, tau to tau, the better. Change in frequency is frequency
>> drift.
> 
> Due to the second difference, phase offset and frequency offset does not affect the ADEV. Similarly for frequency measurement which is the first difference, phase offset does not affect the frequency estimation.
> 
>> If you have N phase samples, you get N-1 frequency samples and N-2
>> drift samples. The standard ADEV calculation is simply based on the
>> mean of those drift samples. (and you know Hadamard takes this one
>> step deeper).
>> 
>> If you look a the code at http://leapsecond.com/tools/adev_lib.c
>> you'll see I avoid the confusing issue of N-1, N, N+1 and simply
>> count the number of terms in the rms sum. Not only does that give the
>> correct result but IMHO it make it clear what is being averaged. The
>> code passes the official NBS ADEV sample suite, agrees with Bill's
>> Stable32, is used in John's TimeLab, and also Mark's Lady Heather.
> 
> The NIST 1000-point test-suite in NIST SP 1065 is recommended these days
> as a test sequence. That's what I used to test all my implementations.
> 
>> I've never quite understood the pedantic separation of "sample" and
>> "population" mean that statistic textbooks and academics love to
>> discuss. They clearly have never measured oscillators. In my
>> experience if you think there's an important difference between N and