Discussion:
Cheap jitter measurements
(too old to reply)
Gary E. Miller
2018-04-03 17:47:37 UTC
Permalink
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
***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Attila Kinali
2018-04-03 18:39:49 UTC
Permalink
On Tue, 3 Apr 2018 10:47:37 -0700
"Gary E. Miller" <***@rellim.com> 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

--
<JaberWorky> The bad part of Zurich is where the degenerates
throw DARK chocolate at you.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Lars Walenius
2018-04-04 17:33:03 UTC
Permalink
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<mailto:***@kinali.ch>
Sent: den 3 april 2018 21:04

On Tue, 3 Apr 2018 10:47:37 -0700
"Gary E. Miller" <***@rellim.com> 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

--
<JaberWorky> The bad part of Zurich is where the degenerates
throw DARK chocolate at you.
_______________________________________________
time-nuts mailing list -- time-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Gary E. Miller
2018-04-04 22:41:58 UTC
Permalink
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
***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Bob Bownes
2018-04-03 18:54:25 UTC
Permalink
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 <***@rellim.com> 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
> ***@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-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Tom Van Baak
2018-04-03 19:04:00 UTC
Permalink
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" <***@rellim.com>
To: "time-nuts" <time-***@febo.com>
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
***@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-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Bob kb8tq
2018-04-03 20:51:02 UTC
Permalink
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 <***@leapsecond.com> 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" <***@rellim.com>
> To: "time-nuts" <time-***@febo.com>
> 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
> ***@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-***@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-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Jeremy Nichols
2018-04-03 22:32:28 UTC
Permalink
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 <***@n1k.org> 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 <***@leapsecond.com> 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" <***@rellim.com>
> > To: "time-nuts" <time-***@febo.com>
> > 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
> > ***@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-***@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-***@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-***@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 list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
ew via time-nuts
2018-04-03 20:17:18 UTC
Permalink
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, ***@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
***@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-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Gary E. Miller
2018-04-04 23:22:29 UTC
Permalink
Hal!

On Tue, 03 Apr 2018 13:06:43 -0700
Hal Murray <***@megapathdsl.net> 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
***@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
Mark Sims
2018-04-05 02:42:10 UTC
Permalink
The TICC is a very nice device. A LOT of bang for the buck. Highly recommended.

Lady Heather supports it (you can actually connect two for 4 channel operation) and can run under Linux. It provides most of the basic functionality of Timelab (with less pretty plots).
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Hal Murray
2018-04-06 02:09:51 UTC
Permalink
>> 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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Bob kb8tq
2018-04-06 03:13:58 UTC
Permalink
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 <***@megapathdsl.net> 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-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Tom Van Baak
2018-04-08 19:36:52 UTC
Permalink
>>> 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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Bob kb8tq
2018-04-08 20:05:41 UTC
Permalink
Hi

Ok, I’ll bite ….

> On Apr 8, 2018, at 3:36 PM, Tom Van Baak <***@leapsecond.com> 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-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Tom Van Baak
2018-04-08 21:18:39 UTC
Permalink
>> 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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Achim Gratz
2018-04-09 18:19:48 UTC
Permalink
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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Bob kb8tq
2018-04-09 20:08:50 UTC
Permalink
Hi

> On Apr 9, 2018, at 2:19 PM, Achim Gratz <***@nexgo.de> 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-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Gary E. Miller
2018-04-09 23:03:24 UTC
Permalink
Yo Hal!

On Mon, 09 Apr 2018 13:53:21 -0700
Hal Murray <***@megapathdsl.net> 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
***@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
Gerhard Hoffmann
2018-04-10 02:23:27 UTC
Permalink
Am 10.04.2018 um 01:03 schrieb Gary E. Miller:
> Yo Hal!
>
> On Mon, 09 Apr 2018 13:53:21 -0700
> Hal Murray <***@megapathdsl.net> 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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
John Ackermann N8UR
2018-04-08 21:29:22 UTC
Permalink
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-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Dana Whitlow
2018-04-08 22:01:40 UTC
Permalink
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 <***@febo.com> 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-***@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-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Adrian Godwin
2018-04-09 01:18:26 UTC
Permalink
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 <***@gmail.com> 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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Tisha Hayes
2018-04-09 02:52:19 UTC
Permalink
" 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 <***@gmail.com> 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 <***@gmail.com>
> 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-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
John Hawkinson
2018-04-08 22:14:37 UTC
Permalink
Tom Van Baak <***@LeapSecond.com> wrote on Sun, 8 Apr 2018
at 12:36:52 -0700 in <***@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.

--***@mit.edu
John Hawkinson
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Bob kb8tq
2018-04-09 00:37:05 UTC
Permalink
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 <***@MIT.EDU> wrote:
>
> Tom Van Baak <***@LeapSecond.com> wrote on Sun, 8 Apr 2018
> at 12:36:52 -0700 in <***@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.
>
> --***@mit.edu
> John Hawkinson
> _______________________________________________
> time-nuts mailing list -- time-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
David J Taylor via time-nuts
2018-04-09 07:26:35 UTC
Permalink
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-***@blueyonder.co.uk
Twitter: @gm8arv

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Trevor N.
2018-04-09 06:53:25 UTC
Permalink
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.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Bob kb8tq
2018-04-09 12:59:17 UTC
Permalink
Hi

> On Apr 9, 2018, at 2:53 AM, Trevor N. <***@comcast.net> 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-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Loading...