[time-nuts] Long measurements and Timelab (was: Framework for simulation of oscillators)

Attila Kinali attila at kinali.ch
Mon Mar 28 06:11:02 EDT 2016


Moin,

On Sun, 27 Mar 2016 19:25:30 -0700
"Tom Van Baak" <tvb at LeapSecond.com> wrote:

> > BTW: I discovered that Timelab stops processing after 10'000'000 datapoints,
> > which is kind inconvenient when doing a long term measurment...

> I've collected a day of TimeLab/TimePod data at tau 0.001 which is 
> 86'400'000 datapoints. Should be no problem.

I guess it's a bug in the ASCII file import subsystem then..

> My command line tools have no sample limit (well, just malloc() limited)
> and can be orders of magnitude faster than Stable32 or Timelab since they
> are batch and not GUI.

Yes. I didn't had the time to look closely at your tools and those
that John Ackermann wrote. This will probably happen after EFTF.


(Side note: the measurements discussed below are of a fault tolerant clock 
synchronization system prototype, built using of the shelf FPGA boards.
Measuring the phase difference of two nodes of a system consisting of
four nodes)


> But this begs the question -- what are you doing with 10M datapoints? 
> Once you get beyond a couple of decades of data it's often better to compute
> statistics in segments and display all the segments of the whole as a time
> series.

Currently, it's just data collection. Until now we have mostly run the
system for a couple of hours at a time. The longest measurements we have
done were just two days. So, we are now running a measurment that should
go for at least two weeks, to see if something funny happens.
The data collection is done using some small, hacked together c program
that interfaces with the E5810. I use Timelab to have a look at the
data once in a while to see if the data collection is still ok and whether
anything noteworthy is going on. This is especially important as the
measurements are done in Vienna (ie ~800km away) by a friend who,
unfortunately, is not an electrical engineer.



> So, for example, don't compute a single stddev or ADEV number from the
> entire 10M data set. While this gives an apparently "more precise"
> measurement due to sampling, it will also hide key factors like trends,
> periodicity, spectral components, outliers, and glitches.

I've not really done any in depth analysis of the data yet. But so far
it seems like that the data set is very regular, safe for two things:

1) We get a couple of outliers of ~700ps (in average 2 a day) that result
from some issue within the DTS-2075. We have not seen these earlier, so
couldn't investigate them yet. What we see is, that the DTS-2075 reports
measurments of exactly 0 for a couple of 10ms (at one time even up to 100ms),
then the next measurement is in the range of 600-700ps.

2) There are short periods (1-2h) of time when the "noise" increases by
a factor of 1.2-1.5. As I wrote in a previous mail, my guess is that we
get some interaction of the nodes when their oscillatof frequenies get
close to each other. Sofar this happend only three times.

Other than that, we have an almost textbook like behavior. The TDEV
decreases with tau^-0.5 up to 100s, from where it flattens out at 5e-13s
and then rises with bumps where one would expect them from temperature
variations. When using a stretch of measurment where 2) does not happen,
the TDEV goes even further down to ~2e-13s.

Just for fun, I also did a plot of sample/bin density of the phase differences
and got a very nice Gaussian bell. A fit of a real Gaus function, revealed
though, that the density distribution is ever so slightly slanted into the
positive direction.

> I'm not sure if you got your answer on synthetic data, but Stable32 has a
> data noise generator, where you get to specify alpha from -2 to +2.
> I created 1M samples of each of the 5 noise types and use those cached
> files as a noise reference.

Thanks. We might use that as a reference.

I got a student who will implement a simulation framework (including the
noise generation) for me over spring/summer, with the goal of making
it public under GPL as license.


> http://www.leapsecond.com/pages/allan/Exploring_Allan_Deviation_v2.pdf
> http://www.leapsecond.com/pages/allan/

Oh.. nice! That's a good reference to have!

			Attila Kinali

-- 
Reading can seriously damage your ignorance.
		-- unknown


More information about the time-nuts mailing list