Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?

[Dan Drown]

Quoting Daniel O'Connor :
If you are using it for NTP then GPS+PPS over USB is quite adequate  
(from personal experience).


Ian Lepore (RIP) who worked for Micro Semi and worked on FreeBSD did  
a bunch of tests on a PPS over USB setup and found it more than
acceptable for keeping a PC in (good) time. Here's the thread:  
https://lists.freebsd.org/pipermail/freebsd-arm/2019-August/020263.html


That ntpq snapshot is a little bit misleading, the latency added by  
USB will vary depending on the offset between when the PPS happens and  
the next USB poll. The USB polls are relatively stable in the short  
term, depending on the host frequency driving USB. So the snapshot  
will only tell you the offset between all the PPS sources in that  
short timeframe, not how they wander over time.


Here's a measurement of that wandering from the USB device's perspective:
https://blog.dan.drown.org/content/images/2017/07/usb-cdc-latency-zoom3.png

As long as you are ok with your time having an offset between ~0ms and  
~1ms, PPS over USB (USB fullspeed) is acceptable. There are plenty of  
uses where that would be "good enough".


I have more info on my blog post: https://blog.dan.drown.org/pps-over-usb/
--
This is questions@lists.ntp.org
Subscribe: questions+subscr...@lists.ntp.org
Unsubscribe: questions+unsubscr...@lists.ntp.org

Re: [ntp:questions] Realistic Performance Expectation for GPS PPS fed ntpd jitter

[Dan Drown]

Quoting Andreas Mattheiss :

I wonder what's a realistic ballpark for the jitter I can expect when
feeding a GPS PPS into ntpd?


Assuming Linux, and using pps-ldisc or pps-gpio, I'd expect reported  
jitter to be around 1us


:

The jitter values I get do, sorry, jitter. I guess it's a lot to do with
the poor view to the sky, mainly. PPS from GPS is claimed to be accurate
to say 10's of ns; my jiitter values are around 10 micro s approximately,
on avarege, for a well settled system set up as described. They do zoom
up, occasionally, to 60 micro s though. I would assume that it's
unrealistic to expect ns accuracy from ntpd on a non-designated system.

What do you think, is my 10 micro jitter within experience?


What are your GPS signal levels during these times?  Does your module  
lose lock?  What are your minpoll/maxpoll settings on your refclock?


You can try changing your timesource.  Many Linux systems will default  
to the TSC timesource, which is much quicker to read but is less  
stable in frequency compared to HPET.


The timesource settings are here:

/sys/devices/system/clocksource/clocksource0/available_clocksource  
/sys/devices/system/clocksource/clocksource0/current_clocksource

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Performance estimation

[Dan Drown]

Quoting David Taylor:

The clock on a Raspberry Pi ranges from 700 to 1500 MHz, so clock
resolution is in the nanosecond range.  There is mention of 250 MHz as
well, which would be 4 nanoseconds.  It would be nice to see numbers
which distinguish a little better than earlier RPi is "3" and more
recent ones are "1"!


The system's time (kernel "clocksource") on the RPI is actually not  
running at the same speed as the CPU clock.


From dmesg: arch_timer: cp15 timer(s) running at 19.20MHz (phys).

This gives you around 52ns of resolution.  I believe it's the same on  
all the rpi models.



I would also like to see whether the characteristics of the GPS and its
location make a measurable difference to the RPi's timekeeping.  For
example: is it better to have a GPS with 3 service capability at a
location where the signal is poor, or is it masked by the RPi's
performance?  All this with kernel-mode PPS.


What I've used for this is a percentile of offsets.  Looking at the 1%  
and 99% values on a histogram is an estimate of the system's stability.


For instance (not an rpi):  
https://dan.drown.org/cheese/run3/offset-histogram.png


So from that graph, I can say that 98% of the time, the system clock  
is within +/-80ns of the PPS.


I believe you're using ntpd, and my code to generate that graph from  
ntpd logs is here: https://github.com/ddrown/chrony-graph/tree/ntpd



Quoting William Unruh:

The question then is how rapidly the system can respond to an
interrupt,. This at least used to be of the order of a microsecond.
Also, how logd does it take to read the clock with the kernel gettime
routines. They all limit the accuracy of your clock using gps refclock
(and also how long the wire is between the gps unit and the computer)


On different ARM hardware (beaglebone black), I've measured interrupt latency:

https://blog.dan.drown.org/content/images/2014/Dec/interrupt-latency.png

I'd expect the rpi to have a similar magnitude.  Somewhere around  
+10us delay and 1us jitter.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] help with setting up NTP on windows with a USB GPS

[Dan Drown]

On 07/30/19 03:48, Jakob Bohm wrote:

USB-to-RS-232 converters generally completely loose the precision timing
abilities of traditional serial port circuits (a 16550 or equivalent
chip connected to the main CPU bus like in the serial adapters for the
original 1981 IBM PC).

This is because the standard for USB-to-RS-232 is all about transferring
the data over an essentially "polled" USB 1.1/2.0 bus that polls once
per ms, with the conversion chip buffering stuff until the next
available 1ms USB frame.

:

As a transitional solution for such a technique, one could use an
enhanced USB-to-RS-232 adapter including a timestamp in its reporting of
"modem-control" inputs, such as "CD line went high 2.3456ms before the
start of this USB frame" (because it happened 0.3456ms before a frame,
but 2 frames were busy).

:

I took pretty much this strategy with my project here:  
https://blog.dan.drown.org/pps-over-usb/


It's custom USB-to-serial firmware, that measures the delay between  
the PPS and the USB poll.  The kernel timestamps the CD transition in  
the USB interrupt handler, and the Linux software combines that with  
the firmware's delay message before reporting it to ntp via SHM.


It works, but it's not as good timing quality as just using a platform  
that supports pps-gpio or PPS on the NIC's 1588 timers.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Garmin LVC 18x jitter problem

[Dan Drown]

Quoting David Taylor :
I'm not an expert in this, but the timing seems to be the same in  
both graphs, the problem occurring around 8000.  Could that be due  
to someone with a GPS jammer parking nearby?


To expand on this: what were your GPS satellite signal strengths like  
during this time period ($..GSV messages)?


Did the GPS report anything different in terms of lock status ($..GSA  
messages)?


Did the system transition to another time source before or after this point?
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP using server IPV6 address instead of IPV4

[Dan Drown]

Quoting "Potter, Timothy   CCS" :
I have a laptop running a version of Linux ( 3.12 ). I have ntpd  
installed and configured to sync with time.google.com. The problem I  
am having is if I am plugged into a network that only provides an  
IPV4 address, ntp's dns is using the ipv6 address:

:
Now, if I force ntpd to use only ipv4 DNS with the -4 option,  
everything works fine

:
But I don't want to do this because if I go to a network that only  
gives ipv6 addresses this will fail. Is there a way to configure ntp  
to only use ipv4 ( or ipv6 ) if my interface actually has an ip  
address in that family?


What about using the pool option instead of the server option for the  
time.google.com hostname?

http://doc.ntp.org/current-stable/discover.html#pool

ntpd will automatically replace sources that it can't reach.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Long term disciplining against 1PPS reference only

[Dan Drown]

Quoting "Charbonneau, André" :
Recently I've been trying to get one of my NTP server (a Raspberry  
Pi), to stay synchronized to a 1PPS signal coming from a Rb clock  
over long periods of time when all other sources are unavailable.   
The NTP server on the RPi is configured to have a couple upstream  
stratum 2 servers, plus the 1PPS driver, and a local clock driver.

:
Reading more about this, it is documented (Computer Network Time  
Synchronization 2nd edition, by D. L. Mills, section 3.11.4) that I  
should be using the following command to tell NTP to keep the 1PPS  
synchronization even if no other sources are present:


"tos minsane 0"

:

Looks like this code was added around 2 years ago to ntpd/ntp_config.c:

case T_Minsane:
val = tos->value.d;
if ((int)tos->value.d < 1)
tos->value.d = 1;
l_minsane = (int)tos->value.d;
break;

I've verified that changing the minimum from 1 to 0 in that code lets  
this feature work again.  Can you give that a try?

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Time syncing with something other than ntpd

[Dan Drown]

Quoting Jakob Bohm :

1. Do you know if anyone has tried using the real-time coprocessors on
  the BBB to more accurately track the PPS signal?


I have a driver for the BBB's input capture timer hardware here:  
https://github.com/ddrown/pps-gmtimer


There's a bug in the recent BBB kernels (4.4.17-ti) that I haven't  
been able to track down.  When you enable timer2, the ethernet  
hardware loses link.  So this driver only works on the older  
3.8.x-bone kernels.


The results were 30%-50% better offsets with pps-gmtimer vs pps-gpio.   
Both numbers are dwarfed by the network interface jitter for NTP  
clients (which is in the 15us-20us range for my environment).


There's some more info here (including a histogram comparing pps-gpio  
vs pps-gmtimer):  
https://blog.dan.drown.org/beaglebone-black-timer-capture-driver/



___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Atheros AR9331 w/GPS + PPS

[Dan Drown]

Quoting Gabs Ricalde :
...

You can also improve the stability of the local clock by avoiding rapid
temperature changes. This is the loopstats of a TL-WR841N placed inside
a box where the temperature doesn't change that fast.
https://imgur.com/a/eNT0k



Rapid temperature changes also affects the GPS module itself.  The GPS  
modules usually have a TCXO on it along with assumptions in the  
firmware about how far the TCXO can drift in a short time period.   
I've noticed if the AC blows directly on an uncovered GPS module,  
it'll often lose lock.  So keep GPS module temperature changes in mind  
as well.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Atheros AR9331 w/GPS + PPS

[Dan Drown]

Quoting Joachim Fabini :
:

I'm really surprised, that's excellent. Do you have any figures how ntpd
performs when using this PPS source? My earlier comment was relying on
the assumption that the diagram displays the ntp log (loopstats)
statistics. Until now, with Linux, desktop computers and rather
expensive GPS equipment I couldn't get the system clock's offset better
than +-5µs over some hours. Publications point out that the CPU
performance has major influence on the ntp timesync accuracy, too. The
PPS reporting is a different story but still a main prerequisite. Can
you share some results on ntp loopstats based offset?


Here's some data from my systems.  I'm using chrony, but this is from  
the equivalent logfile to ntp's loopstats.  These are histograms of  
all local clock offsets over the past 7 days.


Beaglebone Black + NS-T GPS + pps_gmtimer.ko:  
http://dan.drown.org/bbb/run23/offset-histogram.png


50% of the time, the local clock's offset is between -0.03us and  
+0.02us.  98% of the time, it's between -0.34us and +0.36us.  The  
maximum offsets were -3.28us and +2.91us



Raspberry Pi + Navspark-GL GPS + pps_gpio.ko:  
http://dan.drown.org/rpi/run6/offset-histogram.png


50% of the time, the local clock's offset is between -0.12us and  
+0.17us.  98% of the time, it's between -1.63us and +1.04us.  The  
maximum offsets were -5.69us and +3.18us

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] measuring os latency for pps

[Dan Drown]

Quoting folkert folk...@vanheusden.com:

Not sure if it is interesting for you guys but I wrote a simple program
for e.g. Linux (or any other system with the pps api implemented) that
listens on a pps source waiting for a pulse and then toggles a gpio
pin. That way you can measure the latency introduced by the the kernel
when listening from userspace. Note that there's a little extra latency
due to the gpio-pin handling.

You can also use it e.g. blink a led :-)

It is on github: https://github.com/flok99/pps2gpio


What sort of latency have you seen?

This is a histogram (200ns bins) of interrupt latencies I've seen on  
the BeagleBone Black:


http://blog.dan.drown.org/content/images/2014/Dec/interrupt-latency.png

Over 6.5 days worth of samples, 99% were under 8.62us, and 1% were  
under 6.04us.  The mean was 6.92us and the stddev was 1.72us.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions