Re: [time-nuts] Cheap jitter measurements

[Magnus Danielson]

Hi,

On 04/26/2018 12:35 AM, Tom Van Baak wrote:
> Hi Gary,
> 
>> As requested, here is my raw data: http://pi5.rellim.com/1d.log.gz
> 
> I'm having a close look. These are quite a few bad data points and that 
> partly explains why your ADEV plots were off. Trim the file at, say, line 
> 71000 and try again; the results will be much better.
> 
> I'll post an in-depth report later. There are interesting things in the data. 
> You're going to have lots of fun with your new TICC and GPS boards...
> 
>> I'd love to use TimeLab, or Stable32.  But they seem to be closed source,
> 
> Nope, not closed source.
> 
> John Miles includes all the source in the TimeLab installation.
> http://www.ke5fx.com/timelab/readme.htm
> Ask him for a zip of the installation if you can't/won't run the setup exe.

It installs nicely with wine.

> Bill Riley very recently donated his Stable32 source tree to IEEE and so that 
> tool joins the club too.
> https://ieee-uffc.org/frequency-control/frequency-control-software/stable32/
> Not sure where the source repo is but someone on the list will know, or know 
> when it will be ready. Long thread here:
> https://www.febo.com/pipermail/time-nuts/2018-January/108320.html

What you get from IEEE is the compiled format.
There is a non-public repo for the sources, with the aim of maintaining
it into the future.

In the package of sources exists a Linux port of the FrequenC library,
and Python wrapper.

Should get back to that code and effort.

> Someone who routinely uses these apps on non-Windows or non-x86 machines can 
> comment on how to do it.

I've used them both under Wine for Linux, and that helped me greatly.

Cheers,
Magnus
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Tom Van Baak]

Hi Gary,

> As requested, here is my raw data: http://pi5.rellim.com/1d.log.gz

I'm having a close look. These are quite a few bad data points and that partly 
explains why your ADEV plots were off. Trim the file at, say, line 71000 and 
try again; the results will be much better.

I'll post an in-depth report later. There are interesting things in the data. 
You're going to have lots of fun with your new TICC and GPS boards...

> I'd love to use TimeLab, or Stable32.  But they seem to be closed source,

Nope, not closed source.

John Miles includes all the source in the TimeLab installation.
http://www.ke5fx.com/timelab/readme.htm
Ask him for a zip of the installation if you can't/won't run the setup exe.

Bill Riley very recently donated his Stable32 source tree to IEEE and so that 
tool joins the club too.
https://ieee-uffc.org/frequency-control/frequency-control-software/stable32/
Not sure where the source repo is but someone on the list will know, or know 
when it will be ready. Long thread here:
https://www.febo.com/pipermail/time-nuts/2018-January/108320.html

Someone who routinely uses these apps on non-Windows or non-x86 machines can 
comment on how to do it.

/tvb

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Gary E. Miller]

Tom!

On Wed, 25 Apr 2018 04:01:10 -0700
"Tom Van Baak"  wrote:

> Hi Gary,
> 
> > A little coding later and there are nice plots.  They were compared
> > to the output of tvb's adev.c program.  Results are similar.  
> 
> Whoa there cowboy. That doesn't mean it's right. Comments:

It would not be time nuts if I did not get my head handed back to me
on a platter right away. :-)

Much to ponder.  Thanks much for the feedback.

As requested, here is my raw data: http://pi5.rellim.com/1d.log.gz

chA is the JL.  chB is the u-blox.  24 hours of data.

> I strongly, pretty please, strongly advise you to use TimeLab for a
> while before you roll your own tools and plots.

I'd love to use TimeLab, or Stable32.  But they seem to be closed source,
and only run on Windows.  I have not done Windows since 2000.  Any
suggestions for something open source and POSIX compatible?  Ideally
something that runs well on a RasPi.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Bob kb8tq]

Hi

Now that it is “free for all”, Stable-32 is another good program to run your 
data past. It will do nice plots
and a *lot* of different statistics. 

Bob

> On Apr 25, 2018, at 7:01 AM, Tom Van Baak <t...@leapsecond.com> wrote:
> 
> Hi Gary,
> 
>> A little coding later and there are nice plots.  They were compared to
>> the output of tvb's adev.c program.  Results are similar.
> 
> Whoa there cowboy. That doesn't mean it's right. Comments:
> 
>> gps.png looks as expected.
> 
> 1. No, it would appear something is wrong with your data. You show the ADEV 
> for tau 1 s to be about 1e-2. That seems off by a factor of a million. It's 
> probably not your reference, or your TICC, or the NEO-M8M, but something in 
> how you are scaling the data? or glitches in your data? Hard to say without 
> more info.
> 
> 2. The artifacts at the end of the traces are weird. That's either too small 
> a statistics sample or you have one or more bad data points that are ruining 
> your data set.
> 
> 3. It's best not to show ADEV or MDEV on the same plot as TDEV. They are 
> different concepts and have different units. Also use ADEV as a label not 
> OADEV.
> 
> 4. At this stage of being a time-nut, it's best not make canned ADEV plots 
> without first making phase and frequency plots. ADEV is just a statistic and 
> you can feed it garbage and it will still happily compute numbers. By 
> plotting phase (or phase residuals) and frequency (or relative frequency 
> error) your eye can catch most of the bugs that occur to first-time ADEV'ers. 
> Creating phase and frequency plots also makes you aware of the units, scale, 
> and magnitude of your data, something you can use as a sanity check.
> 
> 5. Since you are using batch tools instead of interactive tools, I suggest 
> showing the first few and last few raw data lines from the TICC. Also the 
> first and last few lines of the data that you input to your ADEV calculation. 
> Or just post the raw data. This is helpful to debug bad plots like this.
> 
>> GPSTLXO.png shows the quality of the JL part,
> 
> 1. Hmm, that just looks like some self-test data. I'm suspicious when I see 
> 1e-17 MDEV numbers. Something's not right. The TICC is nice, but not that 
> good.
> 
> 2. Wait, you're using the JL 10 MHz as the TICC reference and then you're 
> measuring the JL 1PPS with the TICC? So that's not really a measurement of 
> the "quality of the JL part"; it's more just a self-test of a TICC channel.
> 
> 3. Once you get correct-looking ADEV plots for NEO-M8M and JL then we can 
> talk about what effect (if any) using Rb as a TICC reference will have. 
> Remember that for time interval measurements the quality of the reference is 
> not that important.
> 
> 
> I strongly, pretty please, strongly advise you to use TimeLab for a while 
> before you roll your own tools and plots. That is, "learn to drive before you 
> design your own car". I know you have a grumpy old man aversion to using 
> Windows, but lots of people on the list seem to run TimeLab easily on their 
> non-Windows systems.
> 
> If nothing else, at least look at what TimeLab does. The PDF user manual is a 
> superb tutorial on working with time & frequency data.
> 
> Anyway, a good start to your NTP measurement project. Thanks for posting.
> 
> /tvb
> 
> 
> - Original Message - 
> From: "Gary E. Miller" <g...@rellim.com>
> To: "time-nuts" <time-nuts@febo.com>
> Sent: Tuesday, April 24, 2018 8:45 PM
> Subject: Re: [time-nuts] Cheap jitter measurements
> 
> 
> Time-nuts!
> 
> I went ahead and bought the TAPR-TICC, it is a very impressive
> instrument.  For this setup it is combined with a Jackson Labs
> GPSTLXO as the 10MHz reference.  The JL is a GPS disciplined temperature
> compensated crystal oscillator.
> 
> The first setup uses the TAPR-TICC in Period mode, outputting the PPS
> period individually for channel A and channel B.
> 
> Channel A is the PPS of a plain u-blox NEO-M8N.  Channel B is the
> PPS of the JL GPSTLXO.
> 
> Simple to get the cycle times from the USB serial port.
> 
> Then I grabbed a copy of the easy to use Python Allantools.
>https://github.com/aewallin/allantools
> 
> A little coding later and there are nice plots.  They were compared to
> the output of tvb's adev.c program.  Results are similar.
> 
> Results are attached.  gps.png is the plain NEO-M8N.  GPSTLXO is the
> JL part.
> 
> gps.png looks as expected.  GPSTLXO.png shows the quality of the JL part,
> but does have some odd divots in the plot.  Maybe artifacts of using the
> PPS derived from the reference 10MHz?  Or an artifact of the 10e

Re: [time-nuts] Cheap jitter measurements

[Tom Van Baak]

Hi Gary,

> A little coding later and there are nice plots.  They were compared to
> the output of tvb's adev.c program.  Results are similar.

Whoa there cowboy. That doesn't mean it's right. Comments:

> gps.png looks as expected.

1. No, it would appear something is wrong with your data. You show the ADEV for 
tau 1 s to be about 1e-2. That seems off by a factor of a million. It's 
probably not your reference, or your TICC, or the NEO-M8M, but something in how 
you are scaling the data? or glitches in your data? Hard to say without more 
info.

2. The artifacts at the end of the traces are weird. That's either too small a 
statistics sample or you have one or more bad data points that are ruining your 
data set.

3. It's best not to show ADEV or MDEV on the same plot as TDEV. They are 
different concepts and have different units. Also use ADEV as a label not OADEV.

4. At this stage of being a time-nut, it's best not make canned ADEV plots 
without first making phase and frequency plots. ADEV is just a statistic and 
you can feed it garbage and it will still happily compute numbers. By plotting 
phase (or phase residuals) and frequency (or relative frequency error) your eye 
can catch most of the bugs that occur to first-time ADEV'ers. Creating phase 
and frequency plots also makes you aware of the units, scale, and magnitude of 
your data, something you can use as a sanity check.

5. Since you are using batch tools instead of interactive tools, I suggest 
showing the first few and last few raw data lines from the TICC. Also the first 
and last few lines of the data that you input to your ADEV calculation. Or just 
post the raw data. This is helpful to debug bad plots like this.

> GPSTLXO.png shows the quality of the JL part,

1. Hmm, that just looks like some self-test data. I'm suspicious when I see 
1e-17 MDEV numbers. Something's not right. The TICC is nice, but not that good.

2. Wait, you're using the JL 10 MHz as the TICC reference and then you're 
measuring the JL 1PPS with the TICC? So that's not really a measurement of the 
"quality of the JL part"; it's more just a self-test of a TICC channel.

3. Once you get correct-looking ADEV plots for NEO-M8M and JL then we can talk 
about what effect (if any) using Rb as a TICC reference will have. Remember 
that for time interval measurements the quality of the reference is not that 
important.


I strongly, pretty please, strongly advise you to use TimeLab for a while 
before you roll your own tools and plots. That is, "learn to drive before you 
design your own car". I know you have a grumpy old man aversion to using 
Windows, but lots of people on the list seem to run TimeLab easily on their 
non-Windows systems.

If nothing else, at least look at what TimeLab does. The PDF user manual is a 
superb tutorial on working with time & frequency data.

Anyway, a good start to your NTP measurement project. Thanks for posting.

/tvb


- Original Message - 
From: "Gary E. Miller" <g...@rellim.com>
To: "time-nuts" <time-nuts@febo.com>
Sent: Tuesday, April 24, 2018 8:45 PM
Subject: Re: [time-nuts] Cheap jitter measurements


Time-nuts!

I went ahead and bought the TAPR-TICC, it is a very impressive
instrument.  For this setup it is combined with a Jackson Labs
GPSTLXO as the 10MHz reference.  The JL is a GPS disciplined temperature
compensated crystal oscillator.

The first setup uses the TAPR-TICC in Period mode, outputting the PPS
period individually for channel A and channel B.

Channel A is the PPS of a plain u-blox NEO-M8N.  Channel B is the
PPS of the JL GPSTLXO.

Simple to get the cycle times from the USB serial port.

Then I grabbed a copy of the easy to use Python Allantools.
https://github.com/aewallin/allantools

A little coding later and there are nice plots.  They were compared to
the output of tvb's adev.c program.  Results are similar.

Results are attached.  gps.png is the plain NEO-M8N.  GPSTLXO is the
JL part.

gps.png looks as expected.  GPSTLXO.png shows the quality of the JL part,
but does have some odd divots in the plot.  Maybe artifacts of using the
PPS derived from the reference 10MHz?  Or an artifact of the 10e6 divider?

There are adev's of Rb standards here: http://www.ke5fx.com/rb.htm

My guess is that the oadev at 1s would be about 50x better with
a Rubidium?  But similar at 10k seconds?

Comments?

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin






> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go t

Re: [time-nuts] Cheap jitter measurements

[Gary E. Miller]

Time-nuts!

I went ahead and bought the TAPR-TICC, it is a very impressive
instrument.  For this setup it is combined with a Jackson Labs
GPSTLXO as the 10MHz reference.  The JL is a GPS disciplined temperature
compensated crystal oscillator.

The first setup uses the TAPR-TICC in Period mode, outputting the PPS
period individually for channel A and channel B.

Channel A is the PPS of a plain u-blox NEO-M8N.  Channel B is the
PPS of the JL GPSTLXO.

Simple to get the cycle times from the USB serial port.

Then I grabbed a copy of the easy to use Python Allantools.
https://github.com/aewallin/allantools

A little coding later and there are nice plots.  They were compared to
the output of tvb's adev.c program.  Results are similar.

Results are attached.  gps.png is the plain NEO-M8N.  GPSTLXO is the
JL part.

gps.png looks as expected.  GPSTLXO.png shows the quality of the JL part,
but does have some odd divots in the plot.  Maybe artifacts of using the
PPS derived from the reference 10MHz?  Or an artifact of the 10e6 divider?

There are adev's of Rb standards here: http://www.ke5fx.com/rb.htm

My guess is that the oadev at 1s would be about 50x better with
a Rubidium?  But similar at 10k seconds?

Comments?

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Gabs Ricalde]

On Mon, Apr 9, 2018 at 3:36 AM, Tom Van Baak  wrote:
>
> My mental model of a black box computer running NTP is that I should be able 
> to give it a pulse (e.g., via parallel, serial, GPIO) and it tells me what 
> time it was. Use a GPSDO / Rb / picDIV to generate precise pulses. Compare 
> the known time of the pulse with the time the box says it was. Repeat many 
> times, collect data, look at the statistics; just as we would for any clock.
>
> Similarly, the box should be able to give me a pulse at a known time. In this 
> case it records the time it thinks the pulse went out, and your GPSDO / Rb / 
> TIC makes the actual measurement. Again, collect data and look at the 
> statistics; just as we would for any clock.

On Wed, Apr 11, 2018 at 2:59 AM, Hal Murray  wrote:
>
> I think that should be a reasonable project.
>
> 1) Write some code to grab the time, send a pulse, grab the time.  Log that.
> 2) Use a time-stamp counter to log the time of the pulse.
> 3) Write the software to merge the two log files.
>

Hal, tvb,

I have a Linux PPS driver that does the following:
(1) Wait for the PPS rising edge
(2) Get the time
(3) Assert a GPIO output
(4) Set a timer that runs the following after 500 ms:
(5) Get the time
(6) Clear the GPIO output
(7) Get the time

The timestamps from (2) are the ones read by ntpd and it looks like this:
1523452407.99977
1523452408.4
1523452410.00021
1523452410.99977
1523452412.00028
PPS is from a u-blox LEA-6T.

(3) is the PPS echo and we will use that to measure the PPS latency.

The timestamps from (5) and (7) look like this:
1523452408.500016042 1523452408.500016467
1523452409.57535 1523452409.57955
1523452410.57246 1523452410.57666
1523452411.58362 1523452411.58782
1523452412.59269 1523452412.500010034

I don't have a TIC so I'm using the LEA-6T external interrupt for
measuring the edges from (3) and (6). The edges are timestamped with a
23 ns accuracy and reported in the TIM-TM2 (time mark) message. The
rising/falling edge values look like this:
306808.00845 306808.500016630
306809.00957 306809.58118
306810.00904 306810.57835
306811.00850 306811.58948
306812.00963 306812.500010207

The integer part is the UTC TOW.
The fractional part of the rising edge is the upper bound of the PPS latency.

Now we can subtract the (5)/(7) timestamps and the u-blox TIM-TM2
falling edge values:
1523452408 -0.00588 -0.00163
1523452409 -0.00583 -0.00163
1523452410 -0.00589 -0.00169
1523452411 -0.00586 -0.00166
1523452412 -0.00938 -0.00173

I've attached some plots:
"pps offset.png" is (2) minus round( (2) )
"before gpio clear.png" is (5) minus TIM-TM2 falling edge
"after gpio clear.png" is (7) minus TIM-TM2 falling edge
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[J Grizzard]

It's worth noting that you can get rid of a /lot/ of the variance on a 
modern linux box:


1) Set the CPU to run at the same speed at all times (generally "max 
performance" but which way you do it doesn't really matter)
2) Set processor masks so that no processes other than your timing code 
runs on a core of your choice. On hyperthreaded processors, make sure 
nothing is scheduled on the other 'half' of that core.

3) Set your interrupts to not be scheduled onto that core
4) Make sure your timing code fits in the L1 cache
5) When possible, make sure you don't conditionally branch. The last 
means instead of doing something like this:


while true {
  if x < y {
    continue loop
  } else {
    write to hardware
  }
}

You do something more like:

while true {
compare x to y
  conditional mov 1 to hardware register on x gt y
  conditional mov 0 to hardware register on x lte y
}

(and if possible, write to memory-mapped hardware pages, rather than 
making calls into the kernel)


This guarantees that both a) latency writing to hardware is consistent 
every loop pass (though hardware-induced jitter isn't), and b) that 
there are no branch mispredicts because there are no conditional 
branches -- conditional move instructions take a constant time to 
execute (plus or minus memory access latency).


This basically removes the entire kernel from the picture, any other 
processes from the picture, and shared CPU resources from the picture, 
except for those times that you have no choice but to access the memory 
bus and such. Otherwise, your code will just sit there on its own core 
doing its own thing and nothing will interrupt it and most sources of 
unknown jitter are removed.


(It's not perfect, but it's probably the closest you'll get on a PC 
without specialized hardware. Though I _do_ wonder what could be done 
with something like the intel i210AT chips on like the apu2 hardware, 
which can do hardware PPS out and hardware event timestamping...)


-j

On 4/11/2018 4:01 PM, Hal Murray wrote:

kb...@n1k.org said:

Except that’s not the way most timers run. The silicon needed to get a
programable  divider to work at 2.4 GHz is expensive. If you dig into the
hardware descriptions,  the clock tree feeds something much slower to the
“top end� of the typical timer in a CPU or MCU. The exception is the high
perf timers in some of the Intel chips.  There the issue is getting them to
relate to anything “outside� the chip.

I think I got started in this area back in the early DEC Alpha days.  They
had a register that counted raw clock cycles.  Simple.  I got stuck thinking
that was the obvious/clean way to do things.

Many thanks for giving me a poke to go learn more about this area.

That was back before battery operation was as interesting as it is today.  I
suspect power is more likely the critical factor.  Half the power goes into
the low order bit, so counting by 4 every 4th cycle rather than 1 every cycle
saves 3/4 of the power.



That may be what the kernel does, but it implements the result as a drop /
add to a counter.

If the source of time is a register counting CPU clock ticks, and the CPU
clock (2 or 3 GHz) is faster than the resolution of the clock (1 ns) it will
be hard to see any drop/add.  However, if the time register is significantly
slower, then the drop/add is easy to spot.  But all that is lost in the noise
of cache misses and such.

Here is a histogram from an Intel Atom running at 1.6 GHz.

First pass, using rpcc.
 cycles  Hits
 24 86932
 36904825
 48  8011
 60   122
 72 1
14411
...
So it looks like the cycle counter gets bumped by 12.  That's a strange
number.  I suspect it's tangled up with changing the clock speed to save
power.  There are conflicting interests in this area.  If you want to keep
time, you need a register than ticks at a constant rate as you change speed.
If you are doing performance analysis, you want a register than counts cycles
at whatever speed the CPU is running.  Or maybe I'm confused.

Second pass, using clock_gettime.
   nSec  Hits
698 2
768 5
769 2
838 3
908 2
977 1
978 3
   1047237102
   1048383246
   1117204072
   1118172490
   1187   275
   1188   135
   1257   263
   125847
   1326 7
   1327   216
...
The clock seems to be ticking in 70ns steps.  That doesn't match 12 clock
cycles so I assume they are using something else.

>From another system:
Second pass, using clock_gettime.
   nSec  Hits
 19 45693
 20347538
 21591129
 22 15284
 2363
 2434
 2532
...
Note that this is 50 times faster than the previous example.

I haven't figured out the kernel and 

Re: [time-nuts] Cheap jitter measurements

[Hal Murray]

kb...@n1k.org said:
> Except that’s not the way most timers run. The silicon needed to get a
> programable  divider to work at 2.4 GHz is expensive. If you dig into the
> hardware descriptions,  the clock tree feeds something much slower to the
> “top end” of the typical timer in a CPU or MCU. The exception is the high
> perf timers in some of the Intel chips.  There the issue is getting them to
> relate to anything “outside” the chip.

I think I got started in this area back in the early DEC Alpha days.  They 
had a register that counted raw clock cycles.  Simple.  I got stuck thinking 
that was the obvious/clean way to do things.

Many thanks for giving me a poke to go learn more about this area.

That was back before battery operation was as interesting as it is today.  I 
suspect power is more likely the critical factor.  Half the power goes into 
the low order bit, so counting by 4 every 4th cycle rather than 1 every cycle 
saves 3/4 of the power.


> That may be what the kernel does, but it implements the result as a drop /
> add to a counter.  

If the source of time is a register counting CPU clock ticks, and the CPU 
clock (2 or 3 GHz) is faster than the resolution of the clock (1 ns) it will 
be hard to see any drop/add.  However, if the time register is significantly 
slower, then the drop/add is easy to spot.  But all that is lost in the noise 
of cache misses and such.

Here is a histogram from an Intel Atom running at 1.6 GHz.

First pass, using rpcc.
cycles  Hits
24 86932
36904825
48  8011
60   122
72 1
   14411
...
So it looks like the cycle counter gets bumped by 12.  That's a strange 
number.  I suspect it's tangled up with changing the clock speed to save 
power.  There are conflicting interests in this area.  If you want to keep 
time, you need a register than ticks at a constant rate as you change speed.  
If you are doing performance analysis, you want a register than counts cycles 
at whatever speed the CPU is running.  Or maybe I'm confused.

Second pass, using clock_gettime.
  nSec  Hits
   698 2
   768 5
   769 2
   838 3
   908 2
   977 1
   978 3
  1047237102
  1048383246
  1117204072
  1118172490
  1187   275
  1188   135
  1257   263
  125847
  1326 7
  1327   216
...
The clock seems to be ticking in 70ns steps.  That doesn't match 12 clock 
cycles so I assume they are using something else.

>From another system:
Second pass, using clock_gettime.
  nSec  Hits
19 45693
20347538
21591129
22 15284
2363
2434
2532
...
Note that this is 50 times faster than the previous example.

I haven't figured out the kernel and library software for reading the clock.  
There is a special path for some functions like reading the clock that avoids 
the overhead of getting in/out of the kernel.  I assume there is some shared 
memory.
  https://en.wikipedia.org/wiki/VDSO

Again, thanks Bob.

TICC arrived today.


-- 
These are my opinions.  I hate spam.



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Achim Gratz]

Gary E. Miller writes:
> It tests the time to do two back to back clock_gettime().  Output
> looks like this:
>
> # ./clock_test 
> samples 101, delay 1000 ns
> min 67 ns, max 302 ns, mean 176 ns, median 197 ns, StdDev 52 ns
>
> You run it a few times and you will see the granularity in the
> measurements is 10's of ns, or more, depending on your CPU.

…and it has to be 52ns since the timer that's used by the kernel on the
newer rasPi runs off the 19.2MHz clock.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Bob kb8tq]

Hi

> On Apr 11, 2018, at 4:58 AM, Hal Murray  wrote:
> 
> 
> g...@rellim.com said:
>> It tests the time to do two back to back clock_gettime().
> 
> That's the time it takes to read the clock.  That's not what I mean by 
> granularity but I think I see how you might use that word.  The comment at 
> the top of the code says "latency".
> 
> When I hear "granularity", I think of the tick size of the clock.  It's easy 
> to measure a big tick size, read the clock, spin reading until it changes, 
> subtract.

In the case of putting out a pulse, the clock to the timer you are using (or 
the i/o clock on the pin) most certainly creates granularity. 


> 
> Things get interesting if the tick size is less than the time it takes to 
> read the clock.  In that case, you may be able see the tick size with a 
> histograms of the times to read the clock.
> 
> With calibration, I can correct for the duration of time it takes to read the 
> clock.  I'm not sure how to do the calibration.  In some cases it cancels 
> out.  Cache misses may be more significant.
> 
> 
> PS: Try running that code on an ARM.  

Take a look at the clock specs on the various sub systems. If a pin is 
involved, you may have a 50 MHz clock spec. If your code is 
coming from flash then it’s got it’s own clock that might be < 30 MHz. 

Lots of nasty little gotcha’s. 

One point is that these also impact how a piece of software “self evaluates” in 
the same environment. To the degree that some
of this is very hard to detect, it might get missed. That gets us back to the 
desire for an external measurement.

Bob


> And consider reading the clock 3 times and collecting 2 sets of data.  The 
> idea is that the first read takes all the cache misses so the time for the 
> second read should be faster and cleaner.
> 
> I see a tick size of 1 microsecond on a Pi 1, and 52 ns on a Pi 2 and Pi 3.
> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Hal Murray]

g...@rellim.com said:
> It tests the time to do two back to back clock_gettime().

That's the time it takes to read the clock.  That's not what I mean by 
granularity but I think I see how you might use that word.  The comment at 
the top of the code says "latency".

When I hear "granularity", I think of the tick size of the clock.  It's easy to 
measure a big tick size, read the clock, spin reading until it changes, 
subtract.

Things get interesting if the tick size is less than the time it takes to read 
the clock.  In that case, you may be able see the tick size with a histograms 
of the times to read the clock.

With calibration, I can correct for the duration of time it takes to read the 
clock.  I'm not sure how to do the calibration.  In some cases it cancels out.  
Cache misses may be more significant.


PS: Try running that code on an ARM.  And consider reading the clock 3 times 
and collecting 2 sets of data.  The idea is that the first read takes all the 
cache misses so the time for the second read should be faster and cleaner.

I see a tick size of 1 microsecond on a Pi 1, and 52 ns on a Pi 2 and Pi 3.

-- 
These are my opinions.  I hate spam.



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Gary E. Miller]

Yo Hal!

On Tue, 10 Apr 2018 15:41:41 -0700
Hal Murray  wrote:

> > Yeah, but the granularity is much worse.  
> 
> Do you have code that demonstrates that?  (or tell me how and I'll
> try it)

Look in gpsd git head.  In the contrib directory here is a program:
clock_test.c 

It tests the time to do two back to back clock_gettime().  Output
looks like this:

# ./clock_test 
samples 101, delay 1000 ns
min 67 ns, max 302 ns, mean 176 ns, median 197 ns, StdDev 52 ns

You run it a few times and you will see the granularity in the
measurements is 10's of ns, or more, depending on your CPU.

Probably better discussed on the gpsd-users@ or NTPsec devel@ mailing
list.  67 ns not exactly time-nuts precision.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin


pgpqBySAD6eqr.pgp
Description: OpenPGP digital signature
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Hal Murray]

Gary said:
>> The API  for the kernel clock can be read to a ns.  I don't see ntpd
>> having much use for finer grain than that.  I should look at the
>> source to see what the internal details look like.

> Yeah, but the granularity is much worse.

Do you have code that demonstrates that?  (or tell me how and I'll try it)

I think most modern kernels derive time from a cycle-count register.  So the 
basic clock should be accurate to a cycle.  Yes, that's worse than a ns on 
slow CPUs.

-- 
These are my opinions.  I hate spam.



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Bob kb8tq]

Hi

> On Apr 10, 2018, at 5:05 PM, Dan Kemppainen  wrote:
> 
> Hi Bob,
> 
> The performance counter does not use the system time calls, NTP, etc. It's an 
> independent counter clocked from raw CPU clock. So you have a ~300pS 
> Timestamping counter in the processor. Why not use that hardware to do the 
> measurement? Does the signal have to exit the PC to measure it?
> 
> Yes, getting ~300pS out of the code calls is probably unrealistic for various 
> reasons, however 300nS should be easily achievable.

One point might that there is a *long* way between 300 ps and 300 ns. Another 
point would be that the CPU clock architecture is very 
different from one brand CPU to the next. If I’m on a 32 bit ARM, I have very 
different “this and that” than I do on a modern Intel CPU. 
I will not dispute the 300 ns number, it’s probably a good guess. The *hope* is 
that with some sort of software magic, the same sort of
thing can be done here as with GPS modules. You accept that positioning the 
pulse to 300 ns is “as good as it gets”. You then do this 
and that to estimate and report how far off it was. 

> 
> If you use the actual NTP PPS capture code with a few extra lines of code 
> added, you should be able to timestamp PPS and NTP values against the 
> performance counter.

The desire would be to get as far away from NTP evaluating it’s self as 
possible. Yes, this is a bit of a philosophical 
sort of thing. If NTP tells us when the pulse was, it’s still very much 
involved. With a pulse out, one can at least begin to evaluate 
what is going on independent of the clock architecture on the CPU and the 
various things the kernel is (or isn’t) doing. 

Why bother? Well, we might learn something about timing …. We might also get a 
way to produce much more accurate
time pulses out of a system. 

If I want to do this same sort of thing with 1588, there are cards out there 
that will do the job. I plug this one in here 
and that one in another system. I grab the PPS outputs from the cards and start 
testing things. Net result is that I 
*can* directly evaluate how well 1588 is doing. Right now with NTP …. not so 
much. 

Bob



> 
> 
> 
> David,
> 
> Correct me if I'm wrong, but the issue with the GetSystemTime calls is they 
> don't use the performance counters. They are system time related calls and 
> affected by UTC/NTP or other system time adjustments.
> 
> The bigger questions is how does NTP query the serial port? Is it in an 
> actual interrupt routine, or is the data captured via software driven event? 
> (I'm betting on a OS driven event).
> 
> Maybe the Dave Hart patches improve the PPS capture???
> 
> The bottom line is it all depends on now the PPS Capture event is handled, 
> and if that's even predictable enough or stable enough to prove useful. The 
> performance counter is, but getting the PPS code to read the counter is still 
> a software problem.
> 
> If you guys want to take this offline and chat about it further, I'd be happy 
> to discuss this without using up bandwidth here.
> 
> Thanks,
> Dan
> 
> 
> 
> 
> On 4/10/2018 4:01 PM, time-nuts-requ...@febo.com wrote:
>> Dan,
>> Take a look at Dave Hart's patches to the Microsoft serial port driver, that
>> does something similar.  The source may be in the NTP distribution, or
>> Meinberg may have a copy.  At one time using the QueryPerfomanceCounter call
>> was an option (look for "QPC").  With Windows-8 and later there is a much
>> more precise GetSystemTime call which NTP uses.
>> I played a little with those calls (in a non-serious way) and wrote some
>> code:
>>   http://www.satsignal.eu/ntp/TSCtime.html
>> based on:
>>   http://www.lochan.org/2005/keith-cl/useful/win32time.html
>> and just messing around!  Perhaps it's of interest or use?
>> Cheers,
>> David
>> -- SatSignal Software - Quality software written to your requirements Web: 
>> http://www.satsignal.eu Email: david-tay...@blueyonder.co.uk Twitter: @gm8arv
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Dan Kemppainen]

Hi Bob,

The performance counter does not use the system time calls, NTP, etc. 
It's an independent counter clocked from raw CPU clock. So you have a 
~300pS Timestamping counter in the processor. Why not use that hardware 
to do the measurement? Does the signal have to exit the PC to measure it?


Yes, getting ~300pS out of the code calls is probably unrealistic for 
various reasons, however 300nS should be easily achievable.


If you use the actual NTP PPS capture code with a few extra lines of 
code added, you should be able to timestamp PPS and NTP values against 
the performance counter.




David,

Correct me if I'm wrong, but the issue with the GetSystemTime calls is 
they don't use the performance counters. They are system time related 
calls and affected by UTC/NTP or other system time adjustments.


The bigger questions is how does NTP query the serial port? Is it in an 
actual interrupt routine, or is the data captured via software driven 
event? (I'm betting on a OS driven event).


Maybe the Dave Hart patches improve the PPS capture???

The bottom line is it all depends on now the PPS Capture event is 
handled, and if that's even predictable enough or stable enough to prove 
useful. The performance counter is, but getting the PPS code to read the 
counter is still a software problem.


If you guys want to take this offline and chat about it further, I'd be 
happy to discuss this without using up bandwidth here.


Thanks,
Dan




On 4/10/2018 4:01 PM, time-nuts-requ...@febo.com wrote:

Dan,

Take a look at Dave Hart's patches to the Microsoft serial port driver, that
does something similar.  The source may be in the NTP distribution, or
Meinberg may have a copy.  At one time using the QueryPerfomanceCounter call
was an option (look for "QPC").  With Windows-8 and later there is a much
more precise GetSystemTime call which NTP uses.

I played a little with those calls (in a non-serious way) and wrote some
code:

   http://www.satsignal.eu/ntp/TSCtime.html

based on:

   http://www.lochan.org/2005/keith-cl/useful/win32time.html

and just messing around!  Perhaps it's of interest or use?

Cheers,
David
-- SatSignal Software - Quality software written to your requirements 
Web: http://www.satsignal.eu Email: david-tay...@blueyonder.co.uk 
Twitter: @gm8arv

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Bob kb8tq]

Hi

> On Apr 10, 2018, at 2:59 PM, Hal Murray  wrote:
> 
> 
> kb...@n1k.org said:
>> Yes, but looping back to the start of this thread, the intent is to actually
>> measure the jitter directly.  That’s where the whole need for a stamped
>> pulse comes from. To paraphrase the earlier comments, the intent is to get
>> away from a “self reported” result and actually do a direct measurement.  
> 
> I think that should be a reasonable project.
> 
> 1) Write some code to grab the time, send a pulse, grab the time.  Log that.
> 2) Use a time-stamp counter to log the time of the pulse.
> 3) Write the software to merge the two log files.

Provided you can get NTP (and not just the kernel) to time the pulse accurately 
it 
would work. It’s a bit more cumbersome than a message out of a serial port. 

Bob


> 
> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Hal Murray]

kb...@n1k.org said:
> Yes, but looping back to the start of this thread, the intent is to actually
> measure the jitter directly.  That’s where the whole need for a stamped
> pulse comes from. To paraphrase the earlier comments, the intent is to get
> away from a “self reported” result and actually do a direct measurement.  

I think that should be a reasonable project.

1) Write some code to grab the time, send a pulse, grab the time.  Log that.
2) Use a time-stamp counter to log the time of the pulse.
3) Write the software to merge the two log files.


-- 
These are my opinions.  I hate spam.



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Bob kb8tq]

Hi


> On Apr 10, 2018, at 12:23 PM, David J Taylor via time-nuts 
>  wrote:
> 
> Hi,
> 
> Yes, but isn't generating pulses OUT of a PC with low latency/jitter one
> of the difficult issues?
> 
> If we (somebody smarter than me...) flip this around and modify a copy
> NTP to grab the QueryPerformanceCounter value when it gets a PPS pulse
> and log that count, don't we now have a way to compare the high
> resolution uncorrected counter to NTP and the external PPS?

We would still be relying on NTP to report on it’s self. I can feed the PC a 
PPS from my GPSDO
and let it report on that. Tell it to simply monitor the input, but not use it 
for disciplining. I get information,
but it’s what NTP “thinks of it’s self”. Ideally one would like to get an 
output that can be independently 
measured.

Bob


> 
> Agreed, not trivial. But maybe fun anyway!
> 
> Dan
> 
> 
> Dan,
> 
> Take a look at Dave Hart's patches to the Microsoft serial port driver, that 
> does something similar.  The source may be in the NTP distribution, or 
> Meinberg may have a copy.  At one time using the QueryPerfomanceCounter call 
> was an option (look for "QPC").  With Windows-8 and later there is a much 
> more precise GetSystemTime call which NTP uses.
> 
> I played a little with those calls (in a non-serious way) and wrote some code:
> 
> http://www.satsignal.eu/ntp/TSCtime.html
> 
> based on:
> 
> http://www.lochan.org/2005/keith-cl/useful/win32time.html
> 
> and just messing around!  Perhaps it's of interest or use?
> 
> Cheers,
> David
> -- 
> SatSignal Software - Quality software written to your requirements
> Web: http://www.satsignal.eu
> Email: david-tay...@blueyonder.co.uk
> Twitter: @gm8arv 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Bob kb8tq]

Hi



> On Apr 10, 2018, at 11:56 AM, Dan Kemppainen  wrote:
> 
> Hi,
> 
> Yes, but isn't generating pulses OUT of a PC with low latency/jitter one of 
> the difficult issues?
> 
> If we (somebody smarter than me...) flip this around and modify a copy NTP to 
> grab the QueryPerformanceCounter value when it gets a PPS pulse and log that 
> count, don't we now have a way to compare the high resolution uncorrected 
> counter to NTP and the external PPS?

Yes, but looping back to the start of this thread, the intent is to actually 
measure the jitter directly. 
That’s where the whole need for a stamped pulse comes from. To paraphrase the 
earlier comments,
the intent is to get away from a “self reported” result and actually do a 
direct measurement. 

Bob


> 
> Agreed, not trivial. But maybe fun anyway!
> 
> Dan
> 
> 
> On 4/10/2018 11:03 AM, time-nuts-requ...@febo.com wrote:
>> NTP already looks at incoming pulses and reports what it thinks is going on 
>> with them. The desire here
>> is to get a pulse*out*  of the device. Then you can toss it into a 
>> conventional set of gear. From the data
>> you can independently evaluate what’s going on.
>> So more or less:
>> 1) Generate pulse
>> 2) Work out when the pulse went out
>> 3) Compare that to what NTP thinks is going on
>> 4) Generate a message to describe the delta in time
>> No, not trivial ….
>> Bob
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[David J Taylor via time-nuts]

Hi,

Yes, but isn't generating pulses OUT of a PC with low latency/jitter one
of the difficult issues?

If we (somebody smarter than me...) flip this around and modify a copy
NTP to grab the QueryPerformanceCounter value when it gets a PPS pulse
and log that count, don't we now have a way to compare the high
resolution uncorrected counter to NTP and the external PPS?

Agreed, not trivial. But maybe fun anyway!

Dan


Dan,

Take a look at Dave Hart's patches to the Microsoft serial port driver, that 
does something similar.  The source may be in the NTP distribution, or 
Meinberg may have a copy.  At one time using the QueryPerfomanceCounter call 
was an option (look for "QPC").  With Windows-8 and later there is a much 
more precise GetSystemTime call which NTP uses.


I played a little with those calls (in a non-serious way) and wrote some 
code:


 http://www.satsignal.eu/ntp/TSCtime.html

based on:

 http://www.lochan.org/2005/keith-cl/useful/win32time.html

and just messing around!  Perhaps it's of interest or use?

Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk
Twitter: @gm8arv 


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Dan Kemppainen]

Hi,

Yes, but isn't generating pulses OUT of a PC with low latency/jitter one 
of the difficult issues?


If we (somebody smarter than me...) flip this around and modify a copy 
NTP to grab the QueryPerformanceCounter value when it gets a PPS pulse 
and log that count, don't we now have a way to compare the high 
resolution uncorrected counter to NTP and the external PPS?


Agreed, not trivial. But maybe fun anyway!

Dan


On 4/10/2018 11:03 AM, time-nuts-requ...@febo.com wrote:

NTP already looks at incoming pulses and reports what it thinks is going on 
with them. The desire here
is to get a pulse*out*  of the device. Then you can toss it into a conventional 
set of gear. From the data
you can independently evaluate what’s going on.

So more or less:

1) Generate pulse
2) Work out when the pulse went out
3) Compare that to what NTP thinks is going on
4) Generate a message to describe the delta in time

No, not trivial ….

Bob



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Bob kb8tq]

Hi


> On Apr 10, 2018, at 9:59 AM, Dan Kemppainen  wrote:
> 
> Hi,
> 
> Don't know how good they are, but there are two functions in the kernel32 lib 
> in windows that are related to a cpu performance counter, 
> QueryPerformanceCounter and QueryPerformanceFrequency. (Maybe Linux has 
> similar?)
> 
> Anyway, on most systems the frequency reported is the raw cpu clock. (Couple 
> of Ghz Range numbers, My current system is reporting 3,320,458 Hz, windows7.) 
> Supposedly these are low latency functions. It may not offer a perfect 
> solution, but at least it gives you 'low latency' access to a high speed 
> counter.
> 
> Maybe it's possible to timestamp incoming PPS pulses with this (assuming 
> they're triggering an interrupt), and learn something neat.
> 
> Some of this is subject to change with windows versions:
> 
> https://msdn.microsoft.com/en-us/library/windows/desktop/dn553408(v=vs.85).aspx
>  
> 

NTP already looks at incoming pulses and reports what it thinks is going on 
with them. The desire here 
is to get a pulse *out* of the device. Then you can toss it into a conventional 
set of gear. From the data
you can independently evaluate what’s going on. 

So more or less:

1) Generate pulse
2) Work out when the pulse went out
3) Compare that to what NTP thinks is going on
4) Generate a message to describe the delta in time

No, not trivial ….

Bob


> 
> Dan
> 
> 
> 
> 
> On 4/10/2018 8:01 AM, time-nuts-requ...@febo.com wrote:
>> kb...@n1k.org  said:
>>> The kernel clock comes from the CPU clock. That CPU clock is phase locked to
>>> a crystal. If you have a CPU that is driven by a VCXO that is a*very*
>>> unusual CPU board.  The crystal runs at an arbitrary frequency. That gives
>>> you edges that are unlikely to happen ���right on the second���.
>> I was assuming the CPU clock was fast enough that reading a cycle-count
>> register and converting to ns would be within a ns which is the resolution of
>> the clock.
>> That's obviously not true for low end SOC type setups.  A Pi-1 runs at 700
>> MHz.  The Pi 3 is up to 1.4 GHz.
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Tom Van Baak]

Dan,

I wrote a PC-based time-stamping counter (TSC) tool that uses a serial port and 
QueryPerformanceCounter:

www.leapsecond.com/tools/pctsc.exe (Win32)
www.leapsecond.com/tools/pctsc.c (source)

Give it a try.

/tvb

- Original Message - 
From: "Dan Kemppainen" <d...@irtelemetrics.com>
To: <time-nuts@febo.com>
Sent: Tuesday, April 10, 2018 6:59 AM
Subject: Re: [time-nuts] Cheap jitter measurements


Hi,

Don't know how good they are, but there are two functions in the 
kernel32 lib in windows that are related to a cpu performance counter, 
QueryPerformanceCounter and QueryPerformanceFrequency. (Maybe Linux has 
similar?)

Anyway, on most systems the frequency reported is the raw cpu clock. 
(Couple of Ghz Range numbers, My current system is reporting 3,320,458 
Hz, windows7.) Supposedly these are low latency functions. It may not 
offer a perfect solution, but at least it gives you 'low latency' access 
to a high speed counter.

Maybe it's possible to timestamp incoming PPS pulses with this (assuming 
they're triggering an interrupt), and learn something neat.

Some of this is subject to change with windows versions:

https://msdn.microsoft.com/en-us/library/windows/desktop/dn553408(v=vs.85).aspx

Dan




On 4/10/2018 8:01 AM, time-nuts-requ...@febo.com wrote:
> kb...@n1k.org  said:
>> The kernel clock comes from the CPU clock. That CPU clock is phase locked to
>> a crystal. If you have a CPU that is driven by a VCXO that is a*very*
>> unusual CPU board.  The crystal runs at an arbitrary frequency. That gives
>> you edges that are unlikely to happen ���right on the second���.
> I was assuming the CPU clock was fast enough that reading a cycle-count
> register and converting to ns would be within a ns which is the resolution of
> the clock.
> 
> That's obviously not true for low end SOC type setups.  A Pi-1 runs at 700
> MHz.  The Pi 3 is up to 1.4 GHz.
> 
> 
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Dan Kemppainen]

Hi,

Don't know how good they are, but there are two functions in the 
kernel32 lib in windows that are related to a cpu performance counter, 
QueryPerformanceCounter and QueryPerformanceFrequency. (Maybe Linux has 
similar?)


Anyway, on most systems the frequency reported is the raw cpu clock. 
(Couple of Ghz Range numbers, My current system is reporting 3,320,458 
Hz, windows7.) Supposedly these are low latency functions. It may not 
offer a perfect solution, but at least it gives you 'low latency' access 
to a high speed counter.


Maybe it's possible to timestamp incoming PPS pulses with this (assuming 
they're triggering an interrupt), and learn something neat.


Some of this is subject to change with windows versions:

https://msdn.microsoft.com/en-us/library/windows/desktop/dn553408(v=vs.85).aspx

Dan




On 4/10/2018 8:01 AM, time-nuts-requ...@febo.com wrote:

kb...@n1k.org  said:

The kernel clock comes from the CPU clock. That CPU clock is phase locked to
a crystal. If you have a CPU that is driven by a VCXO that is a*very*
unusual CPU board.  The crystal runs at an arbitrary frequency. That gives
you edges that are unlikely to happen ���right on the second���.

I was assuming the CPU clock was fast enough that reading a cycle-count
register and converting to ns would be within a ns which is the resolution of
the clock.

That's obviously not true for low end SOC type setups.  A Pi-1 runs at 700
MHz.  The Pi 3 is up to 1.4 GHz.



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Bob kb8tq]

Hi

> On Apr 10, 2018, at 6:58 AM, Hal Murray  wrote:
> 
> 
> kb...@n1k.org said:
>> The kernel clock comes from the CPU clock. That CPU clock is phase locked to
>> a crystal. If you have a CPU that is driven by a VCXO that is a *very*
>> unusual CPU board.  The crystal runs at an arbitrary frequency. That gives
>> you edges that are unlikely to happen “right on the second”.  
> 
> I was assuming the CPU clock was fast enough that reading a cycle-count 
> register and converting to ns would be within a ns which is the resolution of 
> the clock.
> 
> That's obviously not true for low end SOC type setups.  A Pi-1 runs at 700 
> MHz.  The Pi 3 is up to 1.4 GHz.


Except that’s not the way most timers run. The silicon needed to get a 
programable 
divider to work at 2.4 GHz is expensive. If you dig into the hardware 
descriptions, 
the clock tree feeds something much slower to the “top end” of the typical timer
in a CPU or MCU. The exception is the high perf timers in some of the Intel 
chips. 
There the issue is getting them to relate to anything “outside” the chip. 

> 
> 
>> And the kernel does the “adjust” by dropping or adding clock cycles to the
>> count.
> 
> I was expecting the kernel to do the clock arithmetic with lots of fractional 
> bits.
> You get things like:
>  This is a 2.4 GHz system.  That's 0.41666 ns per cycle
>  But the crystal is 12 ppm fast, so we actually use 0.416661666
>  It's been 123456 cycles since we last checked.
>  That's 51439.382637696 ns

That may be what the kernel does, but it implements the result as a drop / add
to a counter. 


> Internally, the current time has to remember the fractional bits.
> 
> If anybody is looking carefully, most PC clocks are spread spectrum.  We 
> should do some back-of-envelope work on how significant that is.
> 
> 
>> Being able to read the kernel time is only part of the process. You need to
>> generate an edge. That gets you into timers and (likely) a different set of
>> limitations as the 
> 
> If you want an output pulse, I was thinking of generating it from userland at 
> roughly the right time but recording the actual time.  That would require a 
> fixup pass in software before analyzing the data recorded by traditional 
> hardware approaches.

…… and it would require some sort of correction message out to the user to
tell them how far off that edge that just went out was ….

Bob


> 
> 
> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Hal Murray]

kb...@n1k.org said:
> The kernel clock comes from the CPU clock. That CPU clock is phase locked to
> a crystal. If you have a CPU that is driven by a VCXO that is a *very*
> unusual CPU board.  The crystal runs at an arbitrary frequency. That gives
> you edges that are unlikely to happen “right on the second”.  

I was assuming the CPU clock was fast enough that reading a cycle-count 
register and converting to ns would be within a ns which is the resolution of 
the clock.

That's obviously not true for low end SOC type setups.  A Pi-1 runs at 700 
MHz.  The Pi 3 is up to 1.4 GHz.


> And the kernel does the “adjust” by dropping or adding clock cycles to the
> count.

I was expecting the kernel to do the clock arithmetic with lots of fractional 
bits.
You get things like:
  This is a 2.4 GHz system.  That's 0.41666 ns per cycle
  But the crystal is 12 ppm fast, so we actually use 0.416661666
  It's been 123456 cycles since we last checked.
  That's 51439.382637696 ns
Internally, the current time has to remember the fractional bits.

If anybody is looking carefully, most PC clocks are spread spectrum.  We 
should do some back-of-envelope work on how significant that is.


> Being able to read the kernel time is only part of the process. You need to
> generate an edge. That gets you into timers and (likely) a different set of
> limitations as the 

If you want an output pulse, I was thinking of generating it from userland at 
roughly the right time but recording the actual time.  That would require a 
fixup pass in software before analyzing the data recorded by traditional 
hardware approaches.



-- 
These are my opinions.  I hate spam.



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Andy ZL3AG via time-nuts]

There's a "realtime" kernel available for Linux that improves timing - no idea 
if this would help in this situation.

See: linux-image-rt-amd64 in debian, for instance




___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Gerhard Hoffmann]

Am 10.04.2018 um 01:03 schrieb Gary E. Miller:

Yo Hal!

On Mon, 09 Apr 2018 13:53:21 -0700
Hal Murray  wrote:


The API  for the kernel clock can be read to a ns.  I don't see ntpd
having much use for finer grain than that.  I should look at the
source to see what the internal details look like.

Yeah, but the granularity is much worse.



And with the new generation of attacks against the prefetch queue /
instruction decoder latency that probably will be blurred even more.

I don't expect my computers' clock to be more precise than needed
for makefiles. Anything more precise is better taken care of by hardware.

regards, Gerhard



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Gary E. Miller]

Yo Hal!

On Mon, 09 Apr 2018 13:53:21 -0700
Hal Murray  wrote:

> The API  for the kernel clock can be read to a ns.  I don't see ntpd
> having much use for finer grain than that.  I should look at the
> source to see what the internal details look like.

Yeah, but the granularity is much worse.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin


pgpsOvGE7c621.pgp
Description: OpenPGP digital signature
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Bob kb8tq]

Hi

> On Apr 9, 2018, at 4:53 PM, Hal Murray  wrote:
> 
> 
> kb...@n1k.org said:
>> Somewhere in the NTP algorithm, there is a “zero error” estimate. GPS
>> modules have the same thing buried in them. A GPS module (like NTP as
>> described above) can only *express* a PPS modulo some clock rate. GPS
>> modules get around this with a firmware hack. They simply tell you what the
>> error was. It is a simple way to get out of the “I need a 10 GHz clock
>> source” problem. No need for FPGA’s or any other guck. You just do an
>> estimate and report it. It then would work on any hardware and let you do
>> the sort of measurements we’re talking about.
> 
> The GPS offset is a kludge to work around not being able to control the local 
> oscillator.
> 
>> Now - *can* that be done with NTP??  Who knows…. 
> 
> The kernel clock has a knob so the same concept doesn't apply.

The kernel clock comes from the CPU clock. That CPU clock is phase locked
to a crystal. If you have a CPU that is driven by a VCXO that is a *very* 
unusual
CPU board.  The crystal runs at an arbitrary frequency. That gives you edges 
that
are unlikely to happen “right on the second”. 

> 
> The API  for the kernel clock can be read to a ns.  I don't see ntpd having 
> much use for finer grain than that.  I should look at the source to see what 
> the internal details look like.
> 
> If ntpd decides the clock needs correcting, it tells the kernel to do the 
> work.  The kernel offsets the clock rate knob by 500 PPM, so it takes 2000 
> microseconds to adjust the clock by 1 microsecond.  It would be possible to 
> read the correction-left and adjust the time by that amount.

And the kernel does the “adjust” by dropping or adding clock cycles to the 
count. 
The result is still modulo the hardware clock period as conveyed to the kernel 
through 
a timer. Dig into the timer architecture and it has it’s limitations. What they 
are is 
very much a “that depends” from this CPU to that CPU. 

Being able to read the kernel time is only part of the process. You need to 
generate
an edge. That gets you into timers and (likely) a different set of limitations 
as the
edge makes it’s way to get to a pin. 

> 
> I think it would be possible to make similar adjustments by post processing 
> the data.  I'd have to double check to make sure I understand what is in 
> loopstats.  If now, we could fix it.

The idea is to get a second by second update of what is going on relative to an 
edge 
that comes out of the computer. Effectively you:

1) need to generate that edge
2) track it back to the NTP internals 
3) turn that track into a message that tells the user what the offset is

Now, if indeed you *can* generate edges to within 1 ns of an arbitrary point in 
time, then 
yes - the message probably has no value. I have yet to see a normal computer 
that is set
up to do that.  Putting a GHz clock into a modulo divider or 32 bit comparator 
apparently 
isn’t something there is much call for …..

Bob

> 
> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Hal Murray]

kb...@n1k.org said:
> Somewhere in the NTP algorithm, there is a “zero error” estimate. GPS
> modules have the same thing buried in them. A GPS module (like NTP as
> described above) can only *express* a PPS modulo some clock rate. GPS
> modules get around this with a firmware hack. They simply tell you what the
> error was. It is a simple way to get out of the “I need a 10 GHz clock
> source” problem. No need for FPGA’s or any other guck. You just do an
> estimate and report it. It then would work on any hardware and let you do
> the sort of measurements we’re talking about.

The GPS offset is a kludge to work around not being able to control the local 
oscillator.

> Now - *can* that be done with NTP??  Who knows…. 

The kernel clock has a knob so the same concept doesn't apply.

The API  for the kernel clock can be read to a ns.  I don't see ntpd having 
much use for finer grain than that.  I should look at the source to see what 
the internal details look like.

If ntpd decides the clock needs correcting, it tells the kernel to do the 
work.  The kernel offsets the clock rate knob by 500 PPM, so it takes 2000 
microseconds to adjust the clock by 1 microsecond.  It would be possible to 
read the correction-left and adjust the time by that amount.

I think it would be possible to make similar adjustments by post processing 
the data.  I'd have to double check to make sure I understand what is in 
loopstats.  If now, we could fix it.


-- 
These are my opinions.  I hate spam.



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Bob kb8tq]

Hi

> On Apr 9, 2018, at 2:19 PM, Achim Gratz  wrote:
> 
> Bob kb8tq writes:
>>> Similarly, the box should be able to give me a pulse at a known time.
>> 
>> how do you set up NTP to do that?
> 
> Not at all, that must be done in the kernel if you want any accuracy at
> all.  But you could modify an existing device driver (for the LPT port)
> to use GPIO instead to give you a PPS out (you'll probably want some
> offset to the true second so it doesn't interfere with the PPS input).
> I think it'd be best to combine a highres timer with some spin-loop to
> keep that PPS pulse closer to the clock (it's been done that way for
> other timing critical stuff before, not really a new idea).  Or, if it's
> only slightly offset from the PPS in anyway, you could piggyback onto
> the PPS reception.
> 
>> In both cases (pulse in and pulse out) the first step is to ask NTP
>> “when was that?”. You still have a pretty big chunk of NTP in the
>> middle of the process …. If NTP only “knows” what is happening (or can
>> control what is happening) to +/- 300 ns. The guts of your data will
>> be limited to the same 300 ns.
> 
> That's not quite how that works.  The resolution theoretically goes down
> to nanoseconds and is ultimately limited by the timer clock.  In the
> case of the rasPi that means about 52ns, but this is swamped by the
> jitter of the interrupt latency.  But you can feed NTP better timestamps
> if you figure out how to get them; on the Beaglebone you can use the RPU
> (Dan Drown has been measuring some latencies that way), on the rasPi you
> could use the VC4 (this is tricky business due to insufficient
> documentation, but the hardware should be capable of scanning the GPIO
> at 250MHz) or even an external TICC.

Somewhere in the NTP algorithm, there is a “zero error” estimate. GPS modules
have the same thing buried in them. A GPS module (like NTP as described
above) can only *express* a PPS modulo some clock rate. GPS modules get
around this with a firmware hack. They simply tell you what the error was. It 
is a
simple way to get out of the “I need a 10 GHz clock source” problem. No need
for FPGA’s or any other guck. You just do an estimate and report it. It then 
would
work on any hardware and let you do the sort of measurements we’re talking 
about.

Now - *can* that be done with NTP??  Who knows….

Bob

> 
> The other option is to use an MCU (or an FPGA) w/ Ethernet and hardware
> timestamping to build a single-purpose NTP stratum-1 box.
> 
> 
> Regards,
> Achim.
> -- 
> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
> 
> SD adaptation for Waldorf rackAttack V1.04R1:
> http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Achim Gratz]

Bob kb8tq writes:
>> Similarly, the box should be able to give me a pulse at a known time.
>
> how do you set up NTP to do that?

Not at all, that must be done in the kernel if you want any accuracy at
all.  But you could modify an existing device driver (for the LPT port)
to use GPIO instead to give you a PPS out (you'll probably want some
offset to the true second so it doesn't interfere with the PPS input).
I think it'd be best to combine a highres timer with some spin-loop to
keep that PPS pulse closer to the clock (it's been done that way for
other timing critical stuff before, not really a new idea).  Or, if it's
only slightly offset from the PPS in anyway, you could piggyback onto
the PPS reception.

> In both cases (pulse in and pulse out) the first step is to ask NTP
> “when was that?”. You still have a pretty big chunk of NTP in the
> middle of the process …. If NTP only “knows” what is happening (or can
> control what is happening) to +/- 300 ns. The guts of your data will
> be limited to the same 300 ns.

That's not quite how that works.  The resolution theoretically goes down
to nanoseconds and is ultimately limited by the timer clock.  In the
case of the rasPi that means about 52ns, but this is swamped by the
jitter of the interrupt latency.  But you can feed NTP better timestamps
if you figure out how to get them; on the Beaglebone you can use the RPU
(Dan Drown has been measuring some latencies that way), on the rasPi you
could use the VC4 (this is tricky business due to insufficient
documentation, but the hardware should be capable of scanning the GPIO
at 250MHz) or even an external TICC.

The other option is to use an MCU (or an FPGA) w/ Ethernet and hardware
timestamping to build a single-purpose NTP stratum-1 box.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Bob kb8tq]

Hi

> On Apr 9, 2018, at 2:53 AM, Trevor N.  wrote:
> 
> Bob kb8tq wrote:
>> Hi
>> 
>> Without the ability to put out a “known good” time pulse there is no quick 
>> way to 
>> check NTP. GPS modules suffer a similar issue. They put out a pulse and a 
>> “correction” (sawtooth error) to tell you what they just told you. Doing the 
>> same 
>> sort of thing with NTP may be possible. 
>> 
>> Indeed the process of correcting this sort of data is open to a bit of 
>> debate. It does 
>> give you a way to get around the “hey, all I can do is 300 ns” issue. With 
>> GPSDO’s
>> the correction is part of the standard firmware. It would be nice if one of 
>> the NTP 
>> guru’s popped up with an equivalent process. 
>> 
>> One *could* monitor various bits and pieces of the OS’s timing generation 
>> system. 
>> Somehow that does not seem quite as much fun as looking at the whole result 
>> all
>> at once. Indeed it might be the only way to get it all worked out.
>> 
>> Bob
> 
> Linux has a pps output driver (pps_gen_parport), but  I've never used
> it. A while back  I added an output mode to the Linux pps_parport
> driver: 
> https://github.com/retroman/pps_parport_polled 
> that I will eventually get around to using with the palisade(trimble)
> NTP driver.
> 
> My modified driver's polled input mode has an input-to-echo delay of
> 1.16 to 1.93 microseconds (measured with an old Keithley 775 counter)
> on my machine which has a parallel card attached directly to the pci-e
> port on a sandybridge processor.  Interrupt mode echo delay is 3.8 to
> 4.3 microseconds when the machine is lightly loaded with occasional
> spikes of 5 to 7 us. When the machine is idle delay falls to
> 3.5-4.1us.
> Port read and write delays are equal at about 820ns each. I think that
> pci-express always uses 'split transactions'  so reads can sometimes
> seem to take only half the time depending on the input pulse time
> relative to the start time of a read request.  Delays increase to
> ~1200ns when attached to the chipset pcie ports.

Does NTP generate a “correction” output that tells you when it things the 
pps went out? If the pps is just coming off the clock architecture, it will 
show you part of what’s going on, but not all of it.

Bob

> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[David J Taylor via time-nuts]

There is a program for the RPi which handles the PPS input for NTP and can 
produce an output on a GPIO pin here:


 https://vanheusden.com/time/rpi_gpio_ntp/

but it's user-mode so of limited use.  Perhaps the OP could adapt it?

Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk
Twitter: @gm8arv 


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Tisha Hayes]

" I appreciate that the clock-blessed may have doubts about the truth of his
sources. But the fact is, you need a larger sample size to better estimate
error. The man who is happy in his ignorance has not considered that
calibrated doubt can be more satisfying than unjustified certainty."

Just like being trapped in a speeding car with the in-laws; Time is
relative. And even if you are in a localized frame of reference it never
goes faster.

*Ms. Tisha Hayes*


On Sun, Apr 8, 2018 at 9:18 PM, Adrian Godwin  wrote:

> That may be an article of faith for those who haven't experienced the
> delights of time-nuttery, but to be fair, the man with n<2 clocks doesn't
> know what time it is either. Even if n=1, he only believes he knows what
> time it is.
>
> I appreciate that the clock-blessed may have doubts about the truth of his
> sources. But the fact is, you need a larger sample size to better estimate
> error. The man who is happy in his ignorance has not considered that
> calibrated doubt can be more satisfying than unjustified certainty.
>
>
> On Sun, Apr 8, 2018 at 11:01 PM, Dana Whitlow 
> wrote:
>
> > Pity the poor man who has (n>1) clocks, for he knows not what time it is.
> >
> > Dana
> >
> >
> > To unsubscribe, go to https://www.febo.com/cgi-bin/
> > mailman/listinfo/time-nuts
> > and follow the instructions there.
> >
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Adrian Godwin]

That may be an article of faith for those who haven't experienced the
delights of time-nuttery, but to be fair, the man with n<2 clocks doesn't
know what time it is either. Even if n=1, he only believes he knows what
time it is.

I appreciate that the clock-blessed may have doubts about the truth of his
sources. But the fact is, you need a larger sample size to better estimate
error. The man who is happy in his ignorance has not considered that
calibrated doubt can be more satisfying than unjustified certainty.


On Sun, Apr 8, 2018 at 11:01 PM, Dana Whitlow  wrote:

> Pity the poor man who has (n>1) clocks, for he knows not what time it is.
>
> Dana
>
>
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Bob kb8tq]

Hi

Without the ability to put out a “known good” time pulse there is no quick way 
to 
check NTP. GPS modules suffer a similar issue. They put out a pulse and a 
“correction” (sawtooth error) to tell you what they just told you. Doing the 
same 
sort of thing with NTP may be possible. 

Indeed the process of correcting this sort of data is open to a bit of debate. 
It does 
give you a way to get around the “hey, all I can do is 300 ns” issue. With 
GPSDO’s
the correction is part of the standard firmware. It would be nice if one of the 
NTP 
guru’s popped up with an equivalent process. 

One *could* monitor various bits and pieces of the OS’s timing generation 
system. 
Somehow that does not seem quite as much fun as looking at the whole result all
at once. Indeed it might be the only way to get it all worked out.

Bob

> On Apr 8, 2018, at 6:14 PM, John Hawkinson  wrote:
> 
> Tom Van Baak  wrote on Sun,  8 Apr 2018
> at 12:36:52 -0700 in <55EB8D26CCDC4B1ABFBC53F95E4C0557@pc52>:
> 
>> My mental model of a black box computer running NTP
> ...
>> Imagine the black box has two BNC connectors; one accepts an input
>> pulse to be timed; one outputs a pulse at certain times.
> 
> Theory runs into reality. The problem is that NTP is easy to set up to do the 
> former, and hard to set up to do the latter. Where "easy" means "it's 
> commonly done" and "hard" means "I'm not aware that it's ever done" (not that 
> I'm so expert that I would necessarily know if it were).
> 
>> To me this better than relying on NTP to tell you how NTP is doing,
>> which as far as I can tell from live plots on the web, is all that
>> most people do. Instead use real, external, physical
>> measurement. The internal NTP stats are fine for tracking the
>> performance of the PLL, but don't confuse that with actual timing.
> 
> One of the things that NTP does is it reports on its status with respect to 
> other NTP peers. Yes, this is still "internal" to the "NTP universe," but 
> it's also external to the device you have in front of you.
> 
> For instance, my ntp server currently reports that it is offset between .6 
> and 2.1 millisecon
> ds from 7 ntp peers it is talking to, and there's at least some reason to 
> think these are not particularly correllated. That gives me reason to infer 
> that my server's clock is probably not off by more than a few milliseconds. 
> (This is not sub-ns timing, of course. It's intended to be illustrative. And 
> for a variety of reasons this particular server's network connection is a bit 
> unstable, so most NTP users can probably do a lot better.)
> 
> Yeah, that's not truly reliable, like I was comparing it to a truly external 
> reference, but it's also not as meaningless as staring at internal parameters.
> 
> Indeed, one way in practice that ntp people measure ntp is to wire up an 
> external reference to the "input BNC" of your black box, instruct the ntp 
> server to monitor that PPS input but not use it in the clock monkeying 
> algorithm, and then compare what NTP reports for the local clock with what it 
> reports for other NTP peers. 
> 
> --jh...@mit.edu
>  John Hawkinson
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Dana Whitlow]

Pity the poor man who has (n>1) clocks, for he knows not what time it is.

Dana


On Sun, Apr 8, 2018 at 4:29 PM, John Ackermann N8UR  wrote:

> I want to jump on Tom's post, and Bob's note at 1:14 on Saturday (that
> begins with "Just to be very clear..."  They both raise an important point
> about measurements.
>
> With both NTP and GPSDO measurements a lot of folks focus heavily on what
> the "black box" is reporting about itself.  But self-contained measurements
> are really unrelated to actual performance.
>
> As Bob mentioned, in a GPSDO you can look at tempco, humidco, voltageco,
> and all sorts of other things but the overall point of the system is to
> make those meaningless: the control loop(s) compensate for them.  If those
> internal error generators are reduced, it may make the system's work
> easier, but that improvement will have no effect on the quality of the
> output if the control loop is already properly compensating for it.
>
> And in NTP, the software reports all sorts of interesting measurements,
> but none of them really tell you how close the computer's clock is to a
> local reference.  As Tom said, the real test is how the time tick coming
> out of the box compares with the time tick going into it.
>
> The bottom line is that no self-contained measurement can tell you actual
> performance.  The *only* way to do that is to compare your box with an
> external reference whose error bounds are known.
>
> After all, this is why we're time-nuts -- every time you acquire a clock,
> you also need to acquire a better clock to test it with. :-)
>
> John
> 
>
> On 04/08/2018 03:36 PM, Tom Van Baak wrote:
>
>> What do you mean by "jitter" and what do you really want to do?
>
 I mean jitter as NTP defines jitter.  Whatever that is.

>>>
>>> I think you need to figure out what you want to do so you don't fool
>>> yourself.
>>>
>>> ntpd is a PLL.  There is a low pass filter in the control loop.  It will
>>> track the low frequency wander of the source.
>>>
>>
>> Gary, Hal, Leo,
>>
>> My mental model of a black box computer running NTP is that I should be
>> able to give it a pulse (e.g., via parallel, serial, GPIO) and it tells me
>> what time it was. Use a GPSDO / Rb / picDIV to generate precise pulses.
>> Compare the known time of the pulse with the time the box says it was.
>> Repeat many times, collect data, look at the statistics; just as we would
>> for any clock.
>>
>> Similarly, the box should be able to give me a pulse at a known time. In
>> this case it records the time it thinks the pulse went out, and your GPSDO
>> / Rb / TIC makes the actual measurement. Again, collect data and look at
>> the statistics; just as we would for any clock.
>>
>> Imagine the black box has two BNC connectors; one accepts an input pulse
>> to be timed; one outputs a pulse at certain times. This allows a complete
>> analysis of NTP operation. Should be true for both client or server. If you
>> get down to nanosecond levels make sure to use equal length cables.
>>
>> To me this better than relying on NTP to tell you how NTP is doing, which
>> as far as I can tell from live plots on the web, is all that most people
>> do. Instead use real, external, physical measurement. The internal NTP
>> stats are fine for tracking the performance of the PLL, but don't confuse
>> that with actual timing.
>>
>> So this is why I'm excited to hear Gary wants a Rb timebase and a sub-ns
>> counter. Someone will finally measure NTP for real, not rely on the
>> internal numbers of NTP measuring itself. Or at least I hope that's what
>> Gary is up to.
>>
>> /tvb
>>
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/m
>> ailman/listinfo/time-nuts
>> and follow the instructions there.
>>
>> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/m
> ailman/listinfo/time-nuts
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[John Hawkinson]

Tom Van Baak  wrote on Sun,  8 Apr 2018
at 12:36:52 -0700 in <55EB8D26CCDC4B1ABFBC53F95E4C0557@pc52>:

> My mental model of a black box computer running NTP
...
> Imagine the black box has two BNC connectors; one accepts an input
> pulse to be timed; one outputs a pulse at certain times.

Theory runs into reality. The problem is that NTP is easy to set up to do the 
former, and hard to set up to do the latter. Where "easy" means "it's commonly 
done" and "hard" means "I'm not aware that it's ever done" (not that I'm so 
expert that I would necessarily know if it were).

> To me this better than relying on NTP to tell you how NTP is doing,
> which as far as I can tell from live plots on the web, is all that
> most people do. Instead use real, external, physical
> measurement. The internal NTP stats are fine for tracking the
> performance of the PLL, but don't confuse that with actual timing.

One of the things that NTP does is it reports on its status with respect to 
other NTP peers. Yes, this is still "internal" to the "NTP universe," but it's 
also external to the device you have in front of you.

For instance, my ntp server currently reports that it is offset between .6 and 
2.1 millisecon
ds from 7 ntp peers it is talking to, and there's at least some reason to think 
these are not particularly correllated. That gives me reason to infer that my 
server's clock is probably not off by more than a few milliseconds. (This is 
not sub-ns timing, of course. It's intended to be illustrative. And for a 
variety of reasons this particular server's network connection is a bit 
unstable, so most NTP users can probably do a lot better.)

Yeah, that's not truly reliable, like I was comparing it to a truly external 
reference, but it's also not as meaningless as staring at internal parameters.

Indeed, one way in practice that ntp people measure ntp is to wire up an 
external reference to the "input BNC" of your black box, instruct the ntp 
server to monitor that PPS input but not use it in the clock monkeying 
algorithm, and then compare what NTP reports for the local clock with what it 
reports for other NTP peers. 

--jh...@mit.edu
  John Hawkinson
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Hal Murray]

kb...@n1k.org said:
> In both cases (pulse in and pulse out) the first step is to ask NTP “when
> was that?”. You still have a pretty big chunk of NTP in the  middle of the
> process …. If NTP only “knows” what is happening (or can control what is
> happening)  to +/- 300 ns. The guts of  your data will be limited to the
> same  300 ns.  

NTP itself doesn't actually do any timing measurements.  That is done by the 
OS.

I'm not familiar with Windows.  All my OS comments apply to Linux and *BSD.  
Windows is probably similar is most respects but may be missing details.

The system clock runs off the CPU crystal.  The kernel has a knob for fine 
tuning the clock speed.  There is another knob that says bump the clock speed 
a bit (500 PPM) long enough to adjust the time by X seconds.  ntpd uses both.

[Many years ago, most kernels used an interrupt from the battery backed clock 
(RTC or TOY) for the main timing and interpolated using the CPU clock.]


The kernel can capture a time stamp on a PPS pulse and on packet arrivals.  I 
don't know of anything similar for packet departure.

The kernel can support more than one PPS so you could feed a GPSDO in on one 
for NTP and use another for general timing measurements.  Those measurements 
are using the kernel clock as a reference.  You can turn ntpd off so the 
system time will have more long term drift but less short term wobble as ntpd 
corrects for errors.]


I don't know of a good way to get a pulse out at a specified time.  You can 
measure the time that user code sends a pulse out and setup a timer to go off 
every second.  I don't know how to adjust or specify the offset from 
timer-going-off to system clock ticking to another second.

The Linux kernel PPS code has an option to send a pulse out when one comes 
in.  I haven't played with it.  I think it could help with measuring the 
interrupt response delays.

tvb: If I send you some data, can you turn it into pretty graphs?





-- 
These are my opinions.  I hate spam.



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[John Ackermann N8UR]

I want to jump on Tom's post, and Bob's note at 1:14 on Saturday (that 
begins with "Just to be very clear..."  They both raise an important 
point about measurements.


With both NTP and GPSDO measurements a lot of folks focus heavily on 
what the "black box" is reporting about itself.  But self-contained 
measurements are really unrelated to actual performance.


As Bob mentioned, in a GPSDO you can look at tempco, humidco, voltageco, 
and all sorts of other things but the overall point of the system is to 
make those meaningless: the control loop(s) compensate for them.  If 
those internal error generators are reduced, it may make the system's 
work easier, but that improvement will have no effect on the quality of 
the output if the control loop is already properly compensating for it.


And in NTP, the software reports all sorts of interesting measurements, 
but none of them really tell you how close the computer's clock is to a 
local reference.  As Tom said, the real test is how the time tick coming 
out of the box compares with the time tick going into it.


The bottom line is that no self-contained measurement can tell you 
actual performance.  The *only* way to do that is to compare your box 
with an external reference whose error bounds are known.


After all, this is why we're time-nuts -- every time you acquire a 
clock, you also need to acquire a better clock to test it with. :-)


John

On 04/08/2018 03:36 PM, Tom Van Baak wrote:

What do you mean by "jitter" and what do you really want to do?

I mean jitter as NTP defines jitter.  Whatever that is.


I think you need to figure out what you want to do so you don't fool yourself.

ntpd is a PLL.  There is a low pass filter in the control loop.  It will
track the low frequency wander of the source.


Gary, Hal, Leo,

My mental model of a black box computer running NTP is that I should be able to 
give it a pulse (e.g., via parallel, serial, GPIO) and it tells me what time it 
was. Use a GPSDO / Rb / picDIV to generate precise pulses. Compare the known 
time of the pulse with the time the box says it was. Repeat many times, collect 
data, look at the statistics; just as we would for any clock.

Similarly, the box should be able to give me a pulse at a known time. In this 
case it records the time it thinks the pulse went out, and your GPSDO / Rb / 
TIC makes the actual measurement. Again, collect data and look at the 
statistics; just as we would for any clock.

Imagine the black box has two BNC connectors; one accepts an input pulse to be 
timed; one outputs a pulse at certain times. This allows a complete analysis of 
NTP operation. Should be true for both client or server. If you get down to 
nanosecond levels make sure to use equal length cables.

To me this better than relying on NTP to tell you how NTP is doing, which as 
far as I can tell from live plots on the web, is all that most people do. 
Instead use real, external, physical measurement. The internal NTP stats are 
fine for tracking the performance of the PLL, but don't confuse that with 
actual timing.

So this is why I'm excited to hear Gary wants a Rb timebase and a sub-ns 
counter. Someone will finally measure NTP for real, not rely on the internal 
numbers of NTP measuring itself. Or at least I hope that's what Gary is up to.

/tvb

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Tom Van Baak]

>> Similarly, the box should be able to give me a pulse at a known time.
>
> how do you set up NTP to do that?

Don't know. That's not NTP's job. Any process that can query system time and 
get/set a GPIO bit will do. The question to be answered is how close to the 
real time (as in UTC(k), atomic clocks, GPS, etc.) is the fake time running 
inside the OS / CPU. The way you determine that is to send the fake time out, 
and/or to send real time in. A low-latency or zero-jitter GPIO pin would be 
required in either case.

> In both cases (pulse in and pulse out) the first step is to ask NTP “when was 
> that?”.
> You still have a pretty big chunk of NTP in the middle of the process …. If 
> NTP only
> “knows” what is happening (or can control what is happening)  to +/- 300 ns. 
> The guts of 
> your data will be limited to the same  300 ns. 

You don't need NTP for this experiment. That's kind of the idea. You run the PC 
/ SBC / R-Pi plain. Or you run it with NTP. Or different versions of NTP or 
different configs. Or you run it with a better xtal, or you replace the xtal 
with a GPSDO and DDS. So this isn't intended to be a hack on NTP per-se; it's 
more of a scientific testbed that you can drop NTP into. You'd get a nice set 
of phase and ADEV / TDEV / MTIE plots or something. I don't know.

I don't use NTP so take this all with a grain of salt. But from the looks of 
it, people playing (or developing) NTP fall into the same trap as some GPSDO 
developers: a focus on the performance of the PLL or other fancy internal 
colorful plots instead of real measurements of rising edges of electrons at the 
input and output.

This was easy back in the peek/poke parallel port days. Took a backseat in the 
serial and USB era. But now that many systems have GPIO ports it should be 
possible again. Anyway, Gary and Leo, et al. can report eventually what they 
find. This isn't really an NTP mailing list, but I would think some of the 
basic concepts of metrology should apply to OS timing as they do to h/w timing.

/tvb

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Bob kb8tq]

Hi

Ok, I’ll bite ….

> On Apr 8, 2018, at 3:36 PM, Tom Van Baak  wrote:
> 
 What do you mean by "jitter" and what do you really want to do?
>>> I mean jitter as NTP defines jitter.  Whatever that is.
>> 
>> I think you need to figure out what you want to do so you don't fool 
>> yourself.
>> 
>> ntpd is a PLL.  There is a low pass filter in the control loop.  It will 
>> track the low frequency wander of the source.
> 
> Gary, Hal, Leo,
> 
> My mental model of a black box computer running NTP is that I should be able 
> to give it a pulse (e.g., via parallel, serial, GPIO) and it tells me what 
> time it was. Use a GPSDO / Rb / picDIV to generate precise pulses. Compare 
> the known time of the pulse with the time the box says it was. Repeat many 
> times, collect data, look at the statistics; just as we would for any clock.
> 
> Similarly, the box should be able to give me a pulse at a known time.

how do you set up NTP to do that?

> In this case it records the time it thinks the pulse went out, and your GPSDO 
> / Rb / TIC makes the actual measurement. Again, collect data and look at the 
> statistics; just as we would for any clock.
> 
> Imagine the black box has two BNC connectors; one accepts an input pulse to 
> be timed; one outputs a pulse at certain times. This allows a complete 
> analysis of NTP operation. Should be true for both client or server. If you 
> get down to nanosecond levels make sure to use equal length cables.
> 
> To me this better than relying on NTP to tell you how NTP is doing, which as 
> far as I can tell from live plots on the web, is all that most people do. 
> Instead use real, external, physical measurement. The internal NTP stats are 
> fine for tracking the performance of the PLL, but don't confuse that with 
> actual timing.
> 
> So this is why I'm excited to hear Gary wants a Rb timebase and a sub-ns 
> counter. Someone will finally measure NTP for real, not rely on the internal 
> numbers of NTP measuring itself. Or at least I hope that's what Gary is up to.

In both cases (pulse in and pulse out) the first step is to ask NTP “when was 
that?”. You still have a pretty big chunk of NTP in the 
middle of the process …. If NTP only “knows” what is happening (or can control 
what is happening)  to +/- 300 ns. The guts of 
your data will be limited to the same  300 ns. 

Bob

> 
> /tvb
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Tom Van Baak]

>>> What do you mean by "jitter" and what do you really want to do?
>> I mean jitter as NTP defines jitter.  Whatever that is.
> 
> I think you need to figure out what you want to do so you don't fool yourself.
> 
> ntpd is a PLL.  There is a low pass filter in the control loop.  It will 
> track the low frequency wander of the source.

Gary, Hal, Leo,

My mental model of a black box computer running NTP is that I should be able to 
give it a pulse (e.g., via parallel, serial, GPIO) and it tells me what time it 
was. Use a GPSDO / Rb / picDIV to generate precise pulses. Compare the known 
time of the pulse with the time the box says it was. Repeat many times, collect 
data, look at the statistics; just as we would for any clock.

Similarly, the box should be able to give me a pulse at a known time. In this 
case it records the time it thinks the pulse went out, and your GPSDO / Rb / 
TIC makes the actual measurement. Again, collect data and look at the 
statistics; just as we would for any clock.

Imagine the black box has two BNC connectors; one accepts an input pulse to be 
timed; one outputs a pulse at certain times. This allows a complete analysis of 
NTP operation. Should be true for both client or server. If you get down to 
nanosecond levels make sure to use equal length cables.

To me this better than relying on NTP to tell you how NTP is doing, which as 
far as I can tell from live plots on the web, is all that most people do. 
Instead use real, external, physical measurement. The internal NTP stats are 
fine for tracking the performance of the PLL, but don't confuse that with 
actual timing.

So this is why I'm excited to hear Gary wants a Rb timebase and a sub-ns 
counter. Someone will finally measure NTP for real, not rely on the internal 
numbers of NTP measuring itself. Or at least I hope that's what Gary is up to.

/tvb

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Bob kb8tq]

Hi

Whatever you want to call it (jitter / wander / noise / crud ), an Rb in a 
stable temperature 
environment ( a few degrees C per hour) will have “stuff” with the dimensions 
of nanoseconds
when compared to a good GPS.

A “normal” NTP setup with a crystal on the motherboard as it’s main flywheel 
and the polling 
stretched out will have “stuff” with the dimensions of microseconds when 
compared to the Rb
or GPS. 

It’s not some defect in NTP, it’s simply the temperature coefficient of the 
crystal on the motherboard.
If it is in the 0.25 to 1 ppm/C range, 2 C will give you 0.5 to 2 ppm of 
frequency swing. Move 0.5 ppm
and you are off a microsecond one second later. Since your room temperature is 
cyclic, it does all 
average out. It’s still a “something” on your timing estimate. 

If you look at Mark’s data, he can get GPS modules to hold < 10 ns of 
“whatever” for quite a long time. 
A good Rb should be in the < 1x10^-11 /C range. It *might* cycle 2x10^-11 in 
our hypothetical 2C 
room. After 50 seconds you might pick up a nanosecond. 

The resolution that makes sense for GPS <-> Rb is *very* different than for GPS 
<-> crystal or 
Rb <-> crystal. 

Bob

> On Apr 5, 2018, at 10:09 PM, Hal Murray  wrote:
> 
>>> What do you mean by "jitter" and what do you really want to do?
>> I mean jitter as NTP defines jitter.  Whatever that is.
> 
> I think you need to figure out what you want to do so you don't fool yourself.
> 
> ntpd is a PLL.  There is a low pass filter in the control loop.  It will 
> track the low frequency wander of the source.
> 
> Assume you have a stable Rb reference.
> 
> Assume your GPSDO has a (small) day/night shift.
> 
> If you collect data with a TICC referenced to that Rb, that shift will show 
> up.  If you collect data with ntpd, you will get the filtered version of that 
> shift.  I'd expect small bumps at the day/night changes.
> 
> Ballpark for the time constant on the filter is the polling interval.  You 
> can see the results of the filter by introducing a "bump" with ntpfrob.
> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Hal Murray]

>> What do you mean by "jitter" and what do you really want to do?
> I mean jitter as NTP defines jitter.  Whatever that is.

I think you need to figure out what you want to do so you don't fool yourself.

ntpd is a PLL.  There is a low pass filter in the control loop.  It will 
track the low frequency wander of the source.

Assume you have a stable Rb reference.

Assume your GPSDO has a (small) day/night shift.

If you collect data with a TICC referenced to that Rb, that shift will show 
up.  If you collect data with ntpd, you will get the filtered version of that 
shift.  I'd expect small bumps at the day/night changes.

Ballpark for the time constant on the filter is the polling interval.  You 
can see the results of the filter by introducing a "bump" with ntpfrob.

-- 
These are my opinions.  I hate spam.



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Gary E. Miller]

Time Nuts!

TL:DR: I decided to go with the Rb and TAPR-TICC.

Long story:

Thank you to all that made such good suggestions.  I think you pretty
much covered the spectrum of options to measuring PPS very nicely.

I'm tempted by the used 5370/5371 idea.  It has 150 ps resolution and
does a ton of fun things.  But they are large, power hungry (500W), and
only talk over GPIB.  I just want a TICC and the rest is overhead.  All
the cool charts, graphs and histograms on the CRT do me no good.

Boxes like the Racal 1992 and hp 5334b are more interesting.  Most
1991 on ebay are for parts only, and there are more web pages on how
to repair them than how to use them.  They only resolve down to 1 nano
second.  I do not see any of either on ebay with rs-232.

Since I'm just working with 5V and 3.3V logic levels, I don't need a
fancy front end, and output of logic level and/or USB serial is also
nice for using on a RasPi.

So I looked at the various hobbyist solutions.  There are some
'interpolator' designs, but I'd need to build them myself and they also
only get to around 1 nano second.  Some maybe a lot better performance,
but more than some assembly required.  Also I would have to figure out
how to measure my measuring tool to see what I got.

So, I'm back to the Rb and TAPR-TICC solution.  No one will seriously
question the Rb accuracy, at least when compared to GPS.  The TAPR-TICC
comes fully assembled, tested and specified.  Easy USB serial interface.
Just a tad more expensive than other solutions.  60 picosecond
resolution and less than 100 picosecond typical jitter.  ADev below
1x10-10.  All way better than I need, so few should argue with using it
to measure GPS PPS.

A few downsides. I'll have to write my own code for pretty graphs, but
at least I can do it on UNIX.  Not a total solution, I still need to
add a GPSDO and cable it all together.

Now I just have to wait for the postman.

Once again, thanks for all the suggestions.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Gary E. Miller]

Hal!

On Tue, 03 Apr 2018 13:06:43 -0700
Hal Murray  wrote:

> > What would you guys suggest as the cheapest way to see jitter down
> > to around 1 nano second? 
> 
> What do you mean by "jitter" and what do you really want to do?

I mean jitter as NTP defines jitter.  Whatever that is.

> Jitter usually needs a reference.  Do you have one?

I have a GPSDO, but that was why I was looking to add the Rubidium
standard to the mix.

> Do you have a scope?

Yup, still got my trusty Tek 465B, and it still works fine.  Cost
almost as much as a car when I bought it.

> The Rigol DS1102E is/was quite popular and is good for close to a
> ns. 

Nice, but not quite fast enough.  I've settled on the Rb+TAPR-TICC
solution.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin


pgpM_n6RkD_uQ.pgp
Description: OpenPGP digital signature
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Lars Walenius]

I would say my implementation is simpler than Nick’s:
https://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/?all
 . It is just an Arduino+ two HCMOS and a few passive components.
>From the beginning Nick copied my interpolator. Later he added a FET that 
>might act as a constant current generator but I doubt it works very well. At 
>least the variance of the FET’s are to large. The temperature stability is not 
>that good either. So far I have not seen any tests of this. The Elektor GPS by 
>Joost Breed copied Nick’s interpolator and a graph from that shows large 
>non-linearities as I can see.
My simple interpolator that I linearize in software is not perfect but able to 
get down to about 1ns linearity by setting min-max and a square term. By using 
Tom Van Baak’s PICDIV 26 it is fairly easy to set the linearity. Information is 
in the instruction found on EEVblog. In the last pages I also enclosed ADEV, 
TDEV and a frequency plot direct from Timelab that works very well with the 
controller. ADEV at 1s is 8E-10.
Also I don’t think Nick sends out the ns direct (absolutely not linearized) on 
the serial port as I do. As I said before this works very well with timelab.
After a lot of testing I also thinks both my hardware and software is robust.
Otherwise I would recommend the TAPR-TICC that I nowadays use more than my 
5370. Good resolution and much lower power dissipation.
Lars

>From: Attila Kinali
Sent: den 3 april 2018 21:04

On Tue, 3 Apr 2018 10:47:37 -0700
"Gary E. Miller"  wrote:

>> What would you guys suggest as the cheapest way to see jitter down to
>> around 1 nano second?

Look at Nick Sayers GPSDO and his interpolator. You wont get any
cheaper than that. Next best thing is to use a TDC7200 like in
the TICC.

Of course, you will need a standard that is stable enough on the
time scales you are looking at. Which is for short taus (<100s)
a good OCXO and for 1s to 10ks an Rb, and beyond that a Cs beam
standard or hydrogen maser.

Attila Kinali

--
The bad part of Zurich is where the degenerates
throw DARK chocolate at you.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Jeremy Nichols]

On the practical side, the 5345 is HEAVY due to its older technology—doing
what it does with first-generation ICs required HP jam an enormous amount
of circuitry into a fairly small physical package.

Jeremy
N6WFO


On Tue, Apr 3, 2018 at 2:39 PM Bob kb8tq  wrote:

> Hi
>
> I would add the HP 5335 to the list of counters to look for. The surplus
> market can be really
> weird. A 5334 *should* be less than a 5335, but on any given day, that may
> not be true. The
> 5370 and 5345 are also worth looking for. Target price (at least for me)
> wold be < $150 for a
> quick buy and < $70 if I was willing to shop for a while.
>
> Getting data *out* of the older counters will involve GPIB. If you are not
> already set up to do
> that, there will be the cost of a cable and a simple adapter.
>
> If you want to move up a generation, the 53131 and 53132 are higher
> resolution devices than
> the 5334 and 5335. They give you the benefit of a serial port. No GPIB
> stuff to bother with.
> Finding one at price lower than the TAPR counter …. probably not.
>
> Bob
>
> > On Apr 3, 2018, at 3:04 PM, Tom Van Baak  wrote:
> >
> > Hi Gary,
> >
> > One solution is to look for used hp, Fluke, or Racal time interval
> counters on eBay. 1 or 2 ns is pretty easy to find with a $100 or $200
> budget. Look for Racal 1992 or hp 5334B as examples. If you plan to collect
> lots of data, you'll want GPIB (or RS232 / USB) connections to a PC and
> that will add to your net cost.
> >
> > Another solution is to homebrew your own 1 ns counter. The downside is
> you will spend a month working out the bugs before you trust the data. Plus
> if you don't already have another counter to compare it against it makes
> development even harder.
> >
> > Third solution is the TICC from TAPR. It's new and works out of the box.
> Lots of us use them. John did a very good job with the design. Highly
> recommended. It's a dual-channel *time stamping* counter so you can collect
> 1PPS data on two separate GPS receivers at the same time if you want. In
> that respect it's 2x as useful as a commercial *time interval* counter.
> >
> > You mention jitter, not ADEV. I don't think you need a fancy timebase if
> all you want to measure is jitter. You can get a good feel for the jitter
> of a GPS / 1PPS output within a few samples. Even a minute of data is
> usually enough to establish the rms jitter value. If you want a full ADEV
> plot, then yes, you'd probably want at least an Rb for your reference.
> >
> > See paragraph "Timing Stability" at http://leapsecond.com/pages/MG1613S/
> for an example of what jitter from a GPS receiver looks like; in this case
> it's primarily sawtooth.
> >
> > Right, the picPET has 400 ns resolution and so it is not the right tool
> for your nanosecond needs. I do have a 10 ns version that I use, but that's
> still a bit coarse for GPS work.
> >
> > I have spare FEI Rb here; I'll send it if you want it. That way you can
> afford a TICC.
> >
> > /tvb
> >
> >
> > - Original Message -
> > From: "Gary E. Miller" 
> > To: "time-nuts" 
> > Sent: Tuesday, April 03, 2018 10:47 AM
> > Subject: [time-nuts] Cheap jitter measurements
> >
> >
> > Time-nuts!
> >
> > With care I can measure GPS jitter on a RasPi to a bit over 300 nano sec
> > resolution.  That is the smallest increment of the RasPi 3B clock with
> > a 64-bit kernel.  That is clearly not time-nuts accuracy.
> >
> > What would you guys suggest as the cheapest way to see jitter down to
> > around 1 nano second?
> >
> > I'm thinking maybe something like a rubidium standard (FE-5680A) and
> > a TICC-TAPR?  But that would put me out around $400.
> >
> > The picPET does not look accurate enough.  Maybe a clever way to use it
> > for more accuracy?  Is there a picPET like thing cheaper than the
> > TICC-TAPR?
> >
> > Ideas?
> >
> > RGDS
> > GARY
> >
> ---
> > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> > g...@rellim.com  Tel:+1 541 382 8588
> >
> >Veritas liberabit vos. -- Quid est veritas?
> >"If you can’t measure it, you can’t improve it." - Lord Kelvin
> > ___
> > time-nuts mailing list -- time-nuts@febo.com
> > To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> > and follow the instructions there.
> >
> > ___
> > time-nuts mailing list -- time-nuts@febo.com
> > To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> > and follow the instructions there.
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
-- 
Sent from my iPad 4.
___
time-nuts mailing 

Re: [time-nuts] Cheap jitter measurements

[Bob kb8tq]

Hi

I would add the HP 5335 to the list of counters to look for. The surplus market 
can be really 
weird. A 5334 *should* be less than a 5335, but on any given day, that may not 
be true. The
5370 and 5345 are also worth looking for. Target price (at least for me) wold 
be < $150 for a
quick buy and < $70 if I was willing to shop for a while. 

Getting data *out* of the older counters will involve GPIB. If you are not 
already set up to do 
that, there will be the cost of a cable and a simple adapter. 

If you want to move up a generation, the 53131 and 53132 are higher resolution 
devices than
the 5334 and 5335. They give you the benefit of a serial port. No GPIB stuff to 
bother with. 
Finding one at price lower than the TAPR counter …. probably not. 

Bob

> On Apr 3, 2018, at 3:04 PM, Tom Van Baak  wrote:
> 
> Hi Gary,
> 
> One solution is to look for used hp, Fluke, or Racal time interval counters 
> on eBay. 1 or 2 ns is pretty easy to find with a $100 or $200 budget. Look 
> for Racal 1992 or hp 5334B as examples. If you plan to collect lots of data, 
> you'll want GPIB (or RS232 / USB) connections to a PC and that will add to 
> your net cost.
> 
> Another solution is to homebrew your own 1 ns counter. The downside is you 
> will spend a month working out the bugs before you trust the data. Plus if 
> you don't already have another counter to compare it against it makes 
> development even harder.
> 
> Third solution is the TICC from TAPR. It's new and works out of the box. Lots 
> of us use them. John did a very good job with the design. Highly recommended. 
> It's a dual-channel *time stamping* counter so you can collect 1PPS data on 
> two separate GPS receivers at the same time if you want. In that respect it's 
> 2x as useful as a commercial *time interval* counter.
> 
> You mention jitter, not ADEV. I don't think you need a fancy timebase if all 
> you want to measure is jitter. You can get a good feel for the jitter of a 
> GPS / 1PPS output within a few samples. Even a minute of data is usually 
> enough to establish the rms jitter value. If you want a full ADEV plot, then 
> yes, you'd probably want at least an Rb for your reference.
> 
> See paragraph "Timing Stability" at http://leapsecond.com/pages/MG1613S/ for 
> an example of what jitter from a GPS receiver looks like; in this case it's 
> primarily sawtooth.
> 
> Right, the picPET has 400 ns resolution and so it is not the right tool for 
> your nanosecond needs. I do have a 10 ns version that I use, but that's still 
> a bit coarse for GPS work.
> 
> I have spare FEI Rb here; I'll send it if you want it. That way you can 
> afford a TICC.
> 
> /tvb
> 
> 
> - Original Message - 
> From: "Gary E. Miller" 
> To: "time-nuts" 
> Sent: Tuesday, April 03, 2018 10:47 AM
> Subject: [time-nuts] Cheap jitter measurements
> 
> 
> Time-nuts!
> 
> With care I can measure GPS jitter on a RasPi to a bit over 300 nano sec
> resolution.  That is the smallest increment of the RasPi 3B clock with
> a 64-bit kernel.  That is clearly not time-nuts accuracy.
> 
> What would you guys suggest as the cheapest way to see jitter down to
> around 1 nano second?  
> 
> I'm thinking maybe something like a rubidium standard (FE-5680A) and
> a TICC-TAPR?  But that would put me out around $400.
> 
> The picPET does not look accurate enough.  Maybe a clever way to use it
> for more accuracy?  Is there a picPET like thing cheaper than the
> TICC-TAPR?
> 
> Ideas?
> 
> RGDS
> GARY
> ---
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> g...@rellim.com  Tel:+1 541 382 8588
> 
>Veritas liberabit vos. -- Quid est veritas?
>"If you can’t measure it, you can’t improve it." - Lord Kelvin
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[ew via time-nuts]

Gary
There is a Blast from the past the PIC TIC. Richard McCorkle did it and in its 
time was widely popular. He helped me on many projects so I included his boards 
with my board orders. Not being a time nut I never took a closer look at his 
board. Having recently revisited the subject for simple low cost monitoring of 
sources versus GPS and looking at Riley's comments found out that Richard used 
schematic capture,  not what you want to use in timing applications. Did do a 
new board with ground plane.  Also did a V drive with time chip for long term 
data recording using a USB stick. The unit is well documented.
I have boards and you are welcomed to a set, can also help with key chips, only 
one SMD, we plan to build and test but lately have been distracted with a minor 
redo of the excellent Riley Dual Mixer and my 2 channel Ping Pong counter that 
Corby loves so much that he has three. Had some interface problems that had us 
going for weeks. When you chase 1 E-13 and 14 nothing comes easy.  
Again if interested contact me off list.
Bert Kehren
 
In a message dated 4/3/2018 2:35:18 PM Eastern Standard Time, g...@rellim.com 
writes:

 
 Time-nuts!

With care I can measure GPS jitter on a RasPi to a bit over 300 nano sec
resolution. That is the smallest increment of the RasPi 3B clock with
a 64-bit kernel. That is clearly not time-nuts accuracy.

What would you guys suggest as the cheapest way to see jitter down to
around 1 nano second? 

I'm thinking maybe something like a rubidium standard (FE-5680A) and
a TICC-TAPR? But that would put me out around $400.

The picPET does not look accurate enough. Maybe a clever way to use it
for more accuracy? Is there a picPET like thing cheaper than the
TICC-TAPR?

Ideas?

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com Tel:+1 541 382 8588

 Veritas liberabit vos. -- Quid est veritas?
 "If you can’t measure it, you can’t improve it." - Lord Kelvin
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Hal Murray]

g...@rellim.com said:
> With care I can measure GPS jitter on a RasPi to a bit over 300 nano sec
> resolution.  That is the smallest increment of the RasPi 3B clock with a
> 64-bit kernel.  That is clearly not time-nuts accuracy.

> What would you guys suggest as the cheapest way to see jitter down to around
> 1 nano second?   

What do you mean by "jitter" and what do you really want to do?

Jitter usually needs a reference.  Do you have one?


> I'm thinking maybe something like a rubidium standard (FE-5680A) and a
> TICC-TAPR?  But that would put me out around $400. 

Do you have a scope?

The Rigol DS1102E is/was quite popular and is good for close to a ns.  I got 
mine several years ago for $400.  Looks like the going price is closer to 
$300 now.  It's got a USB port.  You can read the data and decode it in 
software.

They make lots of similar scopes.  The middle 2 digits are the bandwidth: 5=>
50MHz, 10=>100MHz.  The last digit is the number of channels.)

The chip in the BeagleBone series boards has extra CPUs that help with things 
like this.  I don't know how fast they go.  I haven't seen 64 bit versions or 
a lot of software activity.

-- 
These are my opinions.  I hate spam.



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Tom Van Baak]

Hi Gary,

One solution is to look for used hp, Fluke, or Racal time interval counters on 
eBay. 1 or 2 ns is pretty easy to find with a $100 or $200 budget. Look for 
Racal 1992 or hp 5334B as examples. If you plan to collect lots of data, you'll 
want GPIB (or RS232 / USB) connections to a PC and that will add to your net 
cost.

Another solution is to homebrew your own 1 ns counter. The downside is you will 
spend a month working out the bugs before you trust the data. Plus if you don't 
already have another counter to compare it against it makes development even 
harder.

Third solution is the TICC from TAPR. It's new and works out of the box. Lots 
of us use them. John did a very good job with the design. Highly recommended. 
It's a dual-channel *time stamping* counter so you can collect 1PPS data on two 
separate GPS receivers at the same time if you want. In that respect it's 2x as 
useful as a commercial *time interval* counter.

You mention jitter, not ADEV. I don't think you need a fancy timebase if all 
you want to measure is jitter. You can get a good feel for the jitter of a GPS 
/ 1PPS output within a few samples. Even a minute of data is usually enough to 
establish the rms jitter value. If you want a full ADEV plot, then yes, you'd 
probably want at least an Rb for your reference.

See paragraph "Timing Stability" at http://leapsecond.com/pages/MG1613S/ for an 
example of what jitter from a GPS receiver looks like; in this case it's 
primarily sawtooth.

Right, the picPET has 400 ns resolution and so it is not the right tool for 
your nanosecond needs. I do have a 10 ns version that I use, but that's still a 
bit coarse for GPS work.

I have spare FEI Rb here; I'll send it if you want it. That way you can afford 
a TICC.

/tvb


- Original Message - 
From: "Gary E. Miller" 
To: "time-nuts" 
Sent: Tuesday, April 03, 2018 10:47 AM
Subject: [time-nuts] Cheap jitter measurements


Time-nuts!

With care I can measure GPS jitter on a RasPi to a bit over 300 nano sec
resolution.  That is the smallest increment of the RasPi 3B clock with
a 64-bit kernel.  That is clearly not time-nuts accuracy.

What would you guys suggest as the cheapest way to see jitter down to
around 1 nano second?  

I'm thinking maybe something like a rubidium standard (FE-5680A) and
a TICC-TAPR?  But that would put me out around $400.

The picPET does not look accurate enough.  Maybe a clever way to use it
for more accuracy?  Is there a picPET like thing cheaper than the
TICC-TAPR?

Ideas?

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Bob Bownes]

Find a nice used 5370/5371? :)

There is a 5371 on ebay for $250 at the moment.

On Tue, Apr 3, 2018 at 1:47 PM, Gary E. Miller  wrote:

> Time-nuts!
>
> With care I can measure GPS jitter on a RasPi to a bit over 300 nano sec
> resolution.  That is the smallest increment of the RasPi 3B clock with
> a 64-bit kernel.  That is clearly not time-nuts accuracy.
>
> What would you guys suggest as the cheapest way to see jitter down to
> around 1 nano second?
>
> I'm thinking maybe something like a rubidium standard (FE-5680A) and
> a TICC-TAPR?  But that would put me out around $400.
>
> The picPET does not look accurate enough.  Maybe a clever way to use it
> for more accuracy?  Is there a picPET like thing cheaper than the
> TICC-TAPR?
>
> Ideas?
>
> RGDS
> GARY
> 
> ---
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> g...@rellim.com  Tel:+1 541 382 8588
>
> Veritas liberabit vos. -- Quid est veritas?
> "If you can’t measure it, you can’t improve it." - Lord Kelvin
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Attila Kinali]

On Tue, 3 Apr 2018 10:47:37 -0700
"Gary E. Miller"  wrote:

> What would you guys suggest as the cheapest way to see jitter down to
> around 1 nano second?  

Look at Nick Sayers GPSDO and his interpolator. You wont get any
cheaper than that. Next best thing is to use a TDC7200 like in
the TICC.

Of course, you will need a standard that is stable enough on the
time scales you are looking at. Which is for short taus (<100s)
a good OCXO and for 1s to 10ks an Rb, and beyond that a Cs beam
standard or hydrogen maser.

Attila Kinali

-- 
The bad part of Zurich is where the degenerates
throw DARK chocolate at you.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.