Re: [ntp:questions] questions] Ntpq.exe memory issue with windows 2019

[juergen perlinger]

On 10/30/20 9:47 AM, David J Taylor wrote:
> Hi, Yes The issue goes away if I disable the execution of ntpq.exe, Please
> check the link I have shared in my earlier comment. I'm tracking the
> problem
> down and so far I have found that the issue doesn't occur if you have the
> windows time service disabled.
> ===
> 
> If running NTP, Windows Time Service should be disabled anyway.
> 

!!! s/should/MUST/ !!!

1.) two services competing for port 123/UDP is a bad idea.
2.) Two services trying to adjust the clock is an even worse idea!
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

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

[Juergen Perlinger]

Hello Matt,

On 10/15/20 7:24 PM, Matt Corallo wrote:
> I was wondering about this too, so sat down and patched kernel to pull
> timestamps right after the interrupt fires and then decide later if it
> was because of DCD change (passing the timestamp through the dcd_change
> callback, its a pretty trivial patch). It cut the jitter down some (a
> few us, maybe) and killed some peaks, but clearly wasn't the source of
> most of the jitter here, at least on an embedded AMD box with other
> things to do between interrupts and a relatively poor system clock. I do
> already get better than 10us jitter, however, closer to maybe 5.

IMHO you won't get much better on a PC. 5µs is probably very close to
the IRQ response jitter. And an ordinary rs232 level shifter for the PPS
signal adds probably another µsec or two to the jitter -- high-quality
PPS signal distribution/transmission needs coax cable and analog line
drivers with impedance matching. I'm not nerdy enough to attempt this :)
But then, even a very good PPS line does not help without a hardware
counter capture register, because the IRQ response delay will be the
major contribution to the jitter.

But if you could share your UART code mods, that would make an
interesting reading. If I only had more time...

Pearly

> Matt
> 
> On 10/15/20 1:52 AM, Juergen Perlinger wrote:
>> On 10/7/20 8:45 PM, Andreas Mattheiss wrote:
>>> Hello,
>>>
>>> I wonder what's a realistic ballpark for the jitter I can expect when
>>> feeding a GPS PPS into ntpd?
>>>
>>> My setup is: a cheap u-blox NEO6M has its PPS output connected to a
>>> MAX232
>>> level shifter, connected to a true serial port on my desktop PC. I
>>> use it
>>> at the same time for daily work, so no designated ntp server. The GPS
>>> antenna is sitting inside, close to the window, with a building
>>> opposite -
>>> suboptimal view of the sky. I do feed RTMS corrections to the GPS though
>>> (ionospheric corrections etc.). The GPS is set to "stationary" mode, so
>>> it's probably set up as good as it gets.
>>>
>>> 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? While I am
>>> writing this I just realised a post from David Taylor
>>> () showing
>>>
>>>    remote   refid  st t when poll reach   delay   offset
>>> jitter
>>> ==
>>>
>>> o127.127.22.1    .uPPS.   0 l    -   16  377    0.000    0.026
>>> 0.013
>>>
>>
>> That's quite close to what I get -- either with a GPS18xLVC, or a
>> NEO-M8T (also homegrown, with a MAX-3232 TTL<->RS232 shifter)
>>
>> I had better numbers (half the jitter) with my old Phenom-II box, but
>> with the XEON board I'm running now I see jitter in the 10usec range.
>> With both receivers active at the same time, I have a higher jitter --
>> clearly interrupt collision, and the jitter occasionally bumps up to
>> 20..30 usec, and the offset between the receivers (which is ~20usec)
>> reverses then.
>>
>> I looked into the UART code of the Linux kernel (not _too_ deep) but
>> it's clear that the handling of the DCD signal change and the assigning
>> of time stamps to a change event is not optimal. The time stamp is not
>> assigned ASAP (as it is done in the line discipline), and thanks to the
>> IRQ sharing and status register poll loop there _has_ to be some delay.
>>
>> Funny enough, with an Arduino I can create time stamps much more
>> reliable -- when I use a hardware counter with a latch-strobe signal.
>> (Here the IRQ is created _after_ the counter was value was stored in a
>> capture register!) Unfortunately, such a stratagem is not an option with
>> a PC...
>>
>> Another thing that gets into the way are the energy saving strategies
>> modern CPUs employ, like reducing the clock speed and distribute load
>> over cores. So unless you nail down the IRQ to a certain core and
>> prevent cores from going to full sleep, the interrupt rescheduling can
>> add another few usecs. 

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

[Juergen Perlinger]

On 10/7/20 8:45 PM, Andreas Mattheiss wrote:
> Hello,
> 
> I wonder what's a realistic ballpark for the jitter I can expect when
> feeding a GPS PPS into ntpd?
> 
> My setup is: a cheap u-blox NEO6M has its PPS output connected to a MAX232
> level shifter, connected to a true serial port on my desktop PC. I use it
> at the same time for daily work, so no designated ntp server. The GPS
> antenna is sitting inside, close to the window, with a building opposite -
> suboptimal view of the sky. I do feed RTMS corrections to the GPS though
> (ionospheric corrections etc.). The GPS is set to "stationary" mode, so
> it's probably set up as good as it gets.
> 
> 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? While I am
> writing this I just realised a post from David Taylor
> () showing 
> 
>   remote   refid  st t when poll reach   delay   offset
> jitter
> ==
> o127.127.22.1.uPPS.   0 l-   16  3770.0000.026
> 0.013
> 

That's quite close to what I get -- either with a GPS18xLVC, or a
NEO-M8T (also homegrown, with a MAX-3232 TTL<->RS232 shifter)

I had better numbers (half the jitter) with my old Phenom-II box, but
with the XEON board I'm running now I see jitter in the 10usec range.
With both receivers active at the same time, I have a higher jitter --
clearly interrupt collision, and the jitter occasionally bumps up to
20..30 usec, and the offset between the receivers (which is ~20usec)
reverses then.

I looked into the UART code of the Linux kernel (not _too_ deep) but
it's clear that the handling of the DCD signal change and the assigning
of time stamps to a change event is not optimal. The time stamp is not
assigned ASAP (as it is done in the line discipline), and thanks to the
IRQ sharing and status register poll loop there _has_ to be some delay.

Funny enough, with an Arduino I can create time stamps much more
reliable -- when I use a hardware counter with a latch-strobe signal.
(Here the IRQ is created _after_ the counter was value was stored in a
capture register!) Unfortunately, such a stratagem is not an option with
a PC...

Another thing that gets into the way are the energy saving strategies
modern CPUs employ, like reducing the clock speed and distribute load
over cores. So unless you nail down the IRQ to a certain core and
prevent cores from going to full sleep, the interrupt rescheduling can
add another few usecs. IRQ processing was never a high speed thing on
x86 platforms to start with, and it never kept up with speed boost all
other parts of the architecture got, AFAIK.

In short, your numbers look familiar, and I don't know how to improve
the much without dedicated hardware. I'm dreaming of some FPGA hardware
on a PCIe board at an affordable price...

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

Re: [ntp:questions] ntpd - gpsd communication

[juergen perlinger]

On 6/4/20 9:15 PM, a...@avtodoria.ru wrote:
> Hello!! 
> 
> I have time jumps made by ntpd because gpsd sometimes puts wrong data to SHM 
> because of wrong data from gps receiver(very bad chips)
> 
> I have only one time source in ntp.conf — 127.127.28.1 with PPS enabled
> 
> I want to add another two internet sources for stability but at first i want 
> to emulate wrong data from gpsd to see how ntpd will make this time jump.
> 
> As first step i read data from SHM when gpsd worked correctly at 14 p.m. 
> today UTC+3 for 30 minutes
> 
> And after that i stopped gpsd and launched my own binary at 17:30 p.m. UTC+3 
> writing that old data to SHM. I expected the great offset and the time jump 
> after some time(as it was when receiver lied) but what i saw was:
> - without binary launched ntpd had no updates — it’s correct (no data — no 
> action)
> - with binary launched ntpd had a little offset for all 30 minutes without 
> any attempt to correct system time
> 
> please give me some help!! Maybe i don’t understand ntpd — gpsd communication 
> correctly or smth else
> 
> Thank you in advance
> 

There's another way to communicate between gpsd and ntpd, using driver
46 (gpsd-json). It probably won't help with a really bad receiver, but
it is a bit more sophisticated than the SHM memory slot, even if I say
so myself. Stale data is much less of a problem with this driver. It
might give different/better results, but I won't make promises here.

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

Re: [ntp:questions] Refclock Oncore Driver Change

[juergen perlinger]

Hello all!
Please see on bottom...

On 5/6/19 7:58 AM, Terje Mathisen wrote:
> Thomas Laus wrote:
>> Group:
>>
>> The Motorola Oncore receiver has recently become non-usable because of
>> the
>> recent GPS week rollover.  The receiver year field is limited by the
>> receiver
>> to the years from 1988 to 2018.  The current driver is not able to write
>> the year 2019 successfully.
>>
>> I have looked overr the refclock_oncore.c driver program and have some
>> thoughts.
>> The is a section of the code that makes a conversion of Unix time to
>> GPS time.
>> There is a 70 year constant applied to the message sent to the
>> receiver and
>> received from the refclock.  I think that this constant could be
>> 'fudged' to
>> either add or subtract hex 0x24ea (decimal 619315200) for the
>> number of
>> seconds in a 1024 GPS week.  I looked at the date in my Oncore and
>> converted
>> it to Unix time.  I subtracted this factor from my system date and the
>> numbers
>> matched.
>>
>> I send an email to the person that last made a change to the
>> refclock_oncore
>> driver program and have not received a reply yet.  I ask this group if
>> my idea
>> has any hidden 'gotchas'.  The Oncore driver already has sections for the
>> different models.  I am proposing using the conversion factor for
>> the 6 and 8 channel receivers and leave the code alone for the M12
>> receiver.
>> Are there any model VT, VP, GT, UT receivers that handled the recent
>> rollover
>> correctly?  Are there any M12 receivers that need this fix?
>>
>> The code is a little complicated in ntp_unixtime.h because of the size
>> of the
>> number is greater than a 32 bit INT and my 'C' skills are a little rusty.
>> I plan on working on this next week and see if my idea is valid.  It
>> would
>> be great to have my Oncore back in operation for another 19 years and not
>> requiring a replacement receiver.  I am going to concentrate on making
>> the chage to the ntp_unixtime.h file because other refclocks might
>> require
>> a similar fix.  Am I on the right path or is there a better way?  The
>> receiver
>> will still think that the year is in the correct range, but all date
>> in and
>> out of ntp will be correct.
> 
> I really do think this should work, i.e. adding 1024 weeks to the
> returned date value, but I would at least make it configurable, i.e. use
> a mode value in the server statement or a fudge flag to indicate that
> this hack is to be added.
> 
> Take a look at the NMEA refclocks to see how this works for them. Afaik
> the Oncore refclock is currently not using any such mode/flag values?
>

There is some code in the NMEA driver to not trust the GPS time stamps
to deliver a valid absolute date, and the driver effectively uses a
rolling GPS era of 1024 weeks to map the NMEA date (either in y/m/d or
in GPS week/time scale) into the indicated GPS era.

> You could also add this as extra item in the oncore-specific config
> file, something like
> 
> LAT 39 45.3753  # Positive is North.
> LONG -75 04.27187   # Negative is West
> HTGPS 18.28 M   # Height in meters.
> SHMEM  /var/log/ntpstats/ONCORE.0
> TRAIM YES   # May need this if bad antenna pos
> ## Extra hack for week counter fix:
> EPOCH 2    # Can also be 3, 4 etc
> 
> This would indicate that the time returned should be forced into the
> second (counting from zero) GPS WEEK epoch, i.e. between week 2048 and
> 3071 inclusive, but only if less than this.
> 
> If the gps firmware is correct this would do nothing, not even after the
> next rollower nearly 20 years from now, but for all those that got left
> behind and thinks it is currently 1999 (or even 1980) you would add 1024
> to the week value until it was >= both the current (compiled-in) date
> and the EPOCH value given in the config file.
> 
> Terje
> 

We have opened Bug 3576/3577 for this topic, as it affects all GPS based
clocks. I'm waiting to have these integrated, but the fix for 3576 would
provide the necessary canned routines to give any driver the tools to
fix the issue without doing all the calendar math themselves.

It would also ensure all drivers use the same rolling epoch, derived
either from the build date by default or by explicitely using a 'tos
basedate' statement in the config.

The solution works with the NMEA driver, Zyfer driver and I dared to
touch the Jupiter driver. I did not touch the oncore driver, as I'm not
feeling confident enough to do that blind and I have no hardware to test.

But I'm happy to assist once we have the fixes for the infrastructure in
place. It should put a plug into the problem for once and ever. I hope,
at least.

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

Re: [ntp:questions] ntpd: malloc deadlock with signal io

[juergen perlinger]

Hello Anthony!

I don't have an answer to all of your questions, but see below:

On 10/21/2017 01:00 AM, Anthony Amaro Jr wrote:
> Hello! I am compiling ntp for QNX 6.5 and have run into a deadlock issue.
> 
> Here is how I am compiling ntp:
> 
> LD=ntoppc-ld ./configure CC="qcc -Vgcc_ntoppcbe_cpp-ne" CFLAGS="-O0
> -g" --host=powerpc-unknown-nto-qnx6.5.0 CXX=ntoppc-g++
> --with-yielding-select=yes --build=i386-pc-nto-qnx6.5.0 --with-sntp=no
> 
> Then I call "make -i" so it doesn't stop (expectedly) when making the man 
> pages.
> 
> Here is the call stack:
> 
> 20 SyncMutexLock_r()  0xfe33fde0
> 19 T.61()  0xfe32ca0c
> 18 malloc()  0xfe32bf74
> 17 recvmsg()  0xfe3a610c
> 16 read_network_packet() D:\ntpd\ntp-4.2.8p10\ntpd\ntp_io.c:3465 0x480549c4
> 15 input_handler_scan() D:\ntpd\ntp-4.2.8p10\ntpd\ntp_io.c:3790 0x480554fc
> 14 input_handler() D:\ntpd\ntp-4.2.8p10\ntpd\ntp_io.c:3649 0x48055058
> 13 sigio_handler() D:\ntpd\ntp-4.2.8p10\libntp\iosignal.c:303 0x480c18f8
> 12 ()  0xfe31b6dc
> 11 __flist_enqueue_bin()  0xfe32bcc0
> 10 _list_resize()  0xfe32a81c
> 9 __realloc()  0xfe32c288
> 8 realloc()  0xfe32cea4
> 7 ereallocz() D:\ntpd\ntp-4.2.8p10\libntp\emalloc.c:43 0x480c1024
> 6 clock_select() D:\ntpd\ntp-4.2.8p10\ntpd\ntp_proto.c:3105 0x4807bf74
> 5 clock_filter() D:\ntpd\ntp-4.2.8p10\ntpd\ntp_proto.c:3039 0x4807bdcc
> 4 process_packet() D:\ntpd\ntp-4.2.8p10\ntpd\ntp_proto.c:2455 0x4807a408
> 3 receive() D:\ntpd\ntp-4.2.8p10\ntpd\ntp_proto.c:2114 0x480792dc
> 2 ntpdmain() D:\ntpd\ntp-4.2.8p10\ntpd\ntpd.c:1331 0x4805ead8
> 1 main() D:\ntpd\ntp-4.2.8p10\ntpd\ntpd.c:394 0x4805dd0c
> 
>>From what I can tell it seems that clock_select calls realloc() which
> takes out the libc heap lock. While it's got the lock and performing
> heap operations, we receive a signal for a network packet. This signal
> handler then calls recvmsg() which calls malloc() which tries to take
> out the heap lock again... causing the deadlock.
> 
> So a few questions:
> 
> 1) I can probably get around this by not using signalled io. Is there
> a way to compile ntpd without using signalled IO via the configure
> script? I really do not want to modify any code (config.h) for this
> since I don't know what other bugs I could be introducing by touching
> the code. Maybe there is a command line switch somewhere I can use to
> ensure HAVE_SIGNALLED_IO is not defined?
> 
> 2) It seems like this must have been hit before, even in Linux,
> because recvmsg() is not signal handler safe. Is there some other
> guard I am not seeing here to protect against this?

That's the bummer. POSIX requires recvmsg to "be either reentrant or
non-interruptible by signals and be async-signal-safe". See
http://pubs.opengroup.org/onlinepubs/007904975/functions/xsh_chap02_04.html

Both Linux and BSD confirm in their docs this is the case. But if the
QNX implementation calls malloc, then this implementation would require
'malloc()' to be async-signal-safe, which is *not* required by
ANSI/POSIX. (And a signal-safe malloc would be really hard to implement,
IMHO!)

So, IMHO the recvmsg implementation on QNX violates the POSIX spec, and
you should indeed refrain from using signal-driven IO with ntpd.

> 
> 3) I tried creating an account on bugzilla to report this but it seems
> that new account creation has been disabled :(

Harlan Stenn just told me he created an account for you -- I guess you
got a direct mail along that line.

> 4) What is the best avenue to contribute to helping make ntpd cross
> compile for QNX? I'd love to help out!
> 
> Anyway, thank you all so much for your time and effort on this!
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions
> 

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

Re: [ntp:questions] How to get shared memory access from gpsd to ntpd to work?

[juergen perlinger]

On 08/16/2017 02:52 PM, Etaoin Shrdlu wrote:
> Hi all, 
> 
> I've been battling for some time with getting ntpd to set the date/time
> from gpsd's shared memory locations. My GPS device is on the network
> and sends GPS messages every minute over UDP. This is picked up by gpsd
> and it appears I get a good fix with all the required data. It also
> looks as if the shared memory locations are being set up correctly. But
> whatever I do, ntpd time source "reach" stubbornly remains at zero,
> even when running ntpd as root. I would be most grateful if someone
> could cast their eyes on the configurations and log output below, and
> let me know if you can see were it's going wrong! 

I didn't look to close, but there's an alternative using driver 46 and
the JSON API of GPSD. It's a bit easier to set up.

> 
> P.S. This has been cross-posted from gpsd-us...@nongnu.org, where I
> failed to get any response to my query. 
> 
> 
> # syslog gpsd startup: 
> 
> Aug  6 19:28:16 computer gpsd[374]: gpsd:INFO: launching (Version 3.11)
> Aug  6 19:28:16 computer gpsd[374]: gpsd:INFO: listening on port gpsd
> Aug  6 19:28:16 computer gpsd[374]: gpsd:PROG: NTPD shmat(0,0,0) succeeded, 
> segment 0
> Aug  6 19:28:16 computer gpsd[374]: gpsd:PROG: NTPD shmat(32769,0,0) 
> succeeded, segment 1
> Aug  6 19:28:16 computer gpsd[374]: gpsd:PROG: NTPD shmat(65538,0,0) 
> succeeded, segment 2
> Aug  6 19:28:16 computer gpsd[374]: gpsd:PROG: NTPD shmat(98307,0,0) 
> succeeded, segment 3
> Aug  6 19:28:16 computer gpsd[374]: gpsd:PROG: successfully connected to the 
> DBUS system bus
> Aug  6 19:28:16 computer gpsd[374]: gpsd:PROG: shmat() succeeded, segment 
> 131076
> Aug  6 19:28:16 computer gpsd[374]: gpsd:PROG: shared-segment creation 
> succeeded,
> Aug  6 19:28:16 computer gpsd[374]: gpsd:INFO: stashing device 
> udp://192.168.13.100:10110 at slot 0
> Aug  6 19:28:16 computer gpsd[374]: gpsd:INFO: opening UDP feed at 
> 192.168.13.100, port 10110.
> Aug  6 19:28:16 computer gpsd[374]: gpsd:ERROR: UDP device open error can't 
> connect to host/port pair.
> Aug  6 19:28:16 computer gpsd[374]: gpsd:ERROR: initial GPS device 
> udp://192.168.13.100:10110 open failed
> Aug  6 19:28:16 computer gpsd[374]: gpsd:INFO: running with effective group 
> ID 20
> Aug  6 19:28:16 computer gpsd[374]: gpsd:INFO: running with effective user ID 
> 110
> Aug  6 19:28:16 computer gpsd[374]: gpsd:INFO: startup at 
> 2017-08-06T19:28:16.000Z (1502047696)
> 
> # syslog ntpd startup:
> 
> Aug  6 19:28:24 computer ntpd[609]: ntpd 4.2.6p5@1.2349-o Mon Jul 25 22:35:28 
> UTC 2016 (1)
> Aug  6 19:28:24 computer ntp[582]: Starting NTP server: ntpd.
> Aug  6 19:28:24 computer ntpd[652]: proto: precision = 0.781 usec
> Aug  6 19:28:24 computer ntpd[652]: Listen and drop on 0 v4wildcard 0.0.0.0 
> UDP 123
> Aug  6 19:28:24 computer systemd[1]: Started LSB: Start NTP daemon.
> Aug  6 19:28:25 computer ntpd[652]: Listen and drop on 1 v6wildcard :: UDP 123
> Aug  6 19:28:25 computer ntpd[652]: Listen normally on 2 lo 127.0.0.1 UDP 123
> Aug  6 19:28:25 computer ntpd[652]: Listen normally on 3 eth0 192.168.13.100 
> UDP 123
> Aug  6 19:28:25 computer ntpd[652]: Listen normally on 4 lo ::1 UDP 123
> Aug  6 19:28:25 computer ntpd[652]: Listen normally on 5 eth0 
> fe80::6a89:f1d3:7ec0:510 UDP 123
> Aug  6 19:28:25 computer ntpd[652]: peers refreshed
> Aug  6 19:28:25 computer ntpd[652]: Listening on routing socket on fd #22 for 
> interface updates
> 
> # syslog gpsd sample: 
> 
> Aug  6 19:56:42 computer gpsd[374]: gpsd:IO: <= GPS: 
> $GPGGA,185748.0,1234.567890,N,00012.345678,E,1,10,0.9,13.6,M,47.0,M,,*6B
> Aug  6 19:56:42 computer gpsd[374]: gpsd:PROG: GPGGA sentence timestamped 
> 185748.00.
> Aug  6 19:56:42 computer gpsd[374]: gpsd:PROG: GPGGA starts a reporting cycle.
> Aug  6 19:56:42 computer gpsd[374]: gpsd:IO: <= GPS: 
> $GPRMC,185748.0,A,1234.567890,N,00012.345678,E,0.0,,060817,0.0,E,A*2B
> Aug  6 19:56:42 computer gpsd[374]: gpsd:PROG: GPRMC sentence timestamped 
> 185748.00.
> Aug  6 19:56:42 computer gpsd[374]: gpsd:PROG: GPRMC ends a reporting cycle.
> Aug  6 19:56:42 computer gpsd[374]: gpsd:IO: <= GPS: 
> $GPVTG,,T,0.0,M,0.0,N,0.0,K,A*0D
> Aug  6 19:56:42 computer gpsd[374]: gpsd:IO: <= GPS: 
> $GPGSA,A,2,01,03,06,09,11,17,19,22,23,31,,,1.2,0.9,0.8*31
> Aug  6 19:56:42 computer gpsd[374]: gpsd:PROG: GPGSA sets mode 2
> Aug  6 19:56:42 computer gpsd[374]: gpsd:IO: <= GPS: 
> $GPGSV,4,1,13,01,31,136,41,03,67,068,35,06,32,303,31,09,34,202,41*78
> Aug  6 19:56:42 computer gpsd[374]: gpsd:PROG: Partial satellite data (1 of 
> 4).
> Aug  6 19:56:42 computer gpsd[374]: gpsd:IO: <= GPS: 
> $GPGSV,4,2,13,11,09,153,39,17,40,243,40,19,42,272,30,22,42,082,40*78
> Aug  6 19:56:42 computer gpsd[374]: gpsd:PROG: Partial satellite data (2 of 
> 4).
> Aug  6 19:56:42 computer gpsd[374]: gpsd:IO: <= GPS: 
> $GPGSV,4,3,13,23,61,174,46,31,19,047,36,12,04,329,,14,00,039,*76
> Aug  6 19:56:42 computer gpsd[374]: gpsd:PROG: Partial satellite data (3 of 
> 4).
> Aug  6 

Re: [ntp:questions] NEED_PTHREAD_WARMUP section in ntpd/ntpd.c

[juergen perlinger]

On 02/22/2017 06:06 PM, Sundeep Lal wrote:
> Starting with ntp-4.2.8p4 a new section was added to ntp-4.2.8p4/ntpd/ntpd.c 
> at line 273:
> 
> #ifdef NEED_PTHREAD_WARMUP
> static void*
> my_pthread_warmup_worker(void *thread_args)
> {
> ..
> ..
> }
> 
> ..
> ..
> #endif
> 
> The my_pthread_warmup_worker() thread function does not make use of 
> pthread_setcancelstate()
> and pthread_setcanceltype(), and in some uclibc based systems this
causes the pthread_cancel()
> call on line 299 to take no effect. Then, in line 300 when pthread_join() is 
> invoked, ntpd forever
> remains in my_pthread_warmup_worker() thread. For such uclibc systems,
we should add the following
> lines to my_pthread_warmup_worker():
> 
> static void*
> my_pthread_warmup_worker(void *thread_args)
> {
>   pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL);
>   pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, NULL);
>   (void)thread_args;
>   ..
>   ..
> }
> 
> My question is: has the above already been reported in any bug? I could not 
> find any pull request for the same.

This has several aspects:

http://pubs.opengroup.org/onlinepubs/9699919799/ clearly states

"""
The cancelability state and type of any newly created threads, including
the thread in which main() was first invoked, shall be
PTHREAD_CANCEL_ENABLE and PTHREAD_CANCEL_DEFERRED respectively.
"""

So uClibc is definitely not conforming to the POSIX standard. Things
like this happen, but that might explain why nobody has filed a bug
against this yet.

The other aspect is that asynchronous cancellation is a *BAD* idea
in 99.9995% of all cases. I'm not adverse to enabling the cancellation,
but using asynchronous cancellation? Is there compelling reason to do so?

If it is really needed for some/all versions of the lib this could be
packed in an '#ifdef' that enables this only for the systems that need it.

But according to the standard, 'sleep()' is a thread cancellation point.
If it is not so in uClibc, we might sleep for a much shorter interval
and use 'pthread_testcancel()'. This would still be portable and cause
little problems, as far as I can tell.

So can you perhaps come up with a solution that does not use
asynchronous cancellation, or a preprocessor conditional that does limit
the effect to uClibc?

Maybe even better, do you *need* the warm-up? It is needed to get parts
of the GCC runtime into the executable *before* the resource limits and
page locks are engaged. This is an issue with gcc/glibc, mostly. If you
don't need that, maybe we could make the preprocessor conditional more
specific / less general?

Some more input on this would be warmly welcomed. Asynchronous
cancellation is generally not :)

Cheers,
Pearly

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

Re: [ntp:questions] 1000s offset between GPS module and NTP servers

[juergen perlinger]

Hi Lloyd,

> Hi all.
> I'm using this GPS module with a MTK3339 chipset. Bought from here:
> https://www.adafruit.com/product/790
> And I'm using ntpd with have PPS support compiled-in.
> 
> Juergen, thanks for pointing out the documentation. I've understood more
> about NMEA receivers now.
> 
> I've tried Brian's and Juergen's server and fudge configuration, using
> time2 to align with the NMEA data-stream and now getting better results.
> I don't have a scope, so how do you suggest I determine the correct values
> to use for time2 ?

It's a bit of a chicken-egg problem. An easy way would be to have some
decent time servers (you seem to have that) and mark you cklock to
calibrate as 'noselect'. Take a note of the offset every hour or every
other hour, and after some time (1/2 day or so -- the longer, the
better) you have enough samples to get a decent correction for your
initial estimate. (don't forget to remove the noselect statement after
setting the final fudge value ;)

There are also some more hints about fudge calibration in the ntp docs,
but that needs some digging. I guess there are more elaborate ways, but
this worked for me.

Note that the serial timing (time2) is only critical if there is no PPS
signal. Fine tuning of the PPS delay (time1) needs more equipment, I'm
afraid. I never went into that -- for my purposes 50usec is definitely
close enough. (That's a guesstimate, of course. Most of it will be
caused by interrupt latency.)

> 
> server 127.127.20.0 mode 17 prefer minpoll 4 maxpoll 4
> fudge  127.127.20.0 flag1 1 flag3 1 time2 0.500 # pps kernel msg offset .5s
> 
> 
>  remote   refid  st t when poll reach   delay   offset
> jitter
> ==
> *GPS_NMEA(0) .GPS.0 l   15   16  3770.000  -49.176
> 25.007
> +time.sunrise.ne 195.141.230.78   2 u   22   64  3778.357  114.864
> 17.534
> +192.33.214.47   129.194.21.195   2 u   23   64  377   13.382  115.777
> 18.286
> +ntp0.as34288.ne 85.158.25.74 2 u   32   64  3776.914  113.929
> 17.013
> +eudyptula.init7 217.147.223.78   3 u   26   64  3779.683  115.067
> 17.673
> 

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

Re: [ntp:questions] 1000s offset between GPS module and NTP servers

[juergen perlinger]

Hi all,

On 01/23/2017 05:43 PM, Lloyd Dizon wrote:
> Hi.
> See below.
> 
> On Mon, Jan 23, 2017 at 4:54 PM, Jan Ceuleers 
> wrote:
> 
>> On 23/01/17 12:25, Lloyd Dizon wrote:
>>> I've installed a GPS module on a Raspberry Pi and I'm getting 1000ms
>>> offsets between the GPS readings and network NTPs.
>>
>> Could you show us the relevant extracts from your ntp.conf file related
>> to the GPS source? That is: at least the server line and any fudge lines?
>>
> 
> enable mode7
> 
> # Local
> #server 127.127.1.0
> #fudge 127.127.1.0 stratum 10
> 
> # GPS with PPS enabled
> server 127.127.20.0 mode 17 minpoll 6 maxpoll 6 iburst true prefer
> fudge 127.127.20.0 time1 1 flag1 1 refid GPS

Why do you add one full second time correction to the time PPS stamp?

I admit that having the output of ntpq in millisecs and the config vaues
in seconds is confusing, but 'time1 1' adds a full second to the PPS
time stamp. This shouldn't be needed -- PPS delay correction is in the
sub-millisecond range if it's used at all.

If you have problems with a huge delay between PPS and your first NMEA
sentence of a new burst, use fudge time2 (!!) to compensate for that.
This can just lead to assigning a wrong second to the PPS value, see

http://support.ntp.org/bin/view/Support/ConfiguringNMEARefclocks
https://support.ntp.org/bin/view/Support/ConfiguringGarminRefclocks
http://doc.ntp.org/current-stable/drivers/driver20.html

I'm using a GPS18x-LVC with the following settings:

server 127.127.20.0 mode 33 noselect minpoll 4 maxpoll 8
fudge 127.127.20.0 flag1 1 time2 0.51 refid GPSc

Note the time2 offset of 510msec that I need to get the NMEA data stream
aligned with the PPS signal. If I don't do this, I end up with the wrong
second assigned to the PPS signal, too.

> 
> # Internet time servers for sanity
> server 0.ch.pool.ntp.org iburst prefer
> server 1.ch.pool.ntp.org iburst
> server 2.ch.pool.ntp.org iburst
> server 3.ch.pool.ntp.org iburst
> 
> # By default, exchange time with everybody, but don't allow configuration.
> restrict default kod limited nomodify notrap nopeer noquery
> restrict -6 default kod limited nomodify notrap nopeer noquery
> 
> # Local users may interrogate the ntp server more closely.
> restrict 127.0.0.1
> restrict -6 ::1
> 
> # Drift file etc.
> driftfile /var/lib/ntp/ntp.drift
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions
> 

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

Re: [ntp:questions] 4.2.8p9 build issue on windows with openssl 1.0.2g

[juergen perlinger]

On 01/20/2017 06:57 AM, sneha b wrote:
> Hi,
> 
> I am not able to build 4.2.8p9 on windows7.
> Seeing build error conflicting types for 'EVP_MD_CTX'.
> I came across a mail regarding this but I am not able to get whats the work
> around for this.
> 
> Can some one please help me in resolving this.
> 
> Openssl I used is 1.0.2g and I also  tried with openssl1.0.2j.
> 
> Both the cases I am seeing the error conflicting types for 'EVP_MD_CTX'.

I'm not sure if
https://bugs.ntp.org/show_bug.cgi?id=3144
https://bugs.ntp.org/show_bug.cgi?id=3359

is related to this, but it's definitely worth a try. Bug3359 has
symptoms that sound similar to what you are observing.

The change is in
https://bugs.ntp.org/attachment.cgi?id=1481
In case you cannot access the diff, I attached it here.

This staged for 4.2.9p10, but not yet in the published source tree.

Please tell me if this helps or not.

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

Re: [ntp:questions] ntp.4.2.8 not supporting sha1

[juergen perlinger]

On 12/09/2016 07:20 AM, sneha b wrote:
> Hi All,
> 
> I am building ntp.4.2.8, source code I got from ntp.org.
> We have openssl1.0.2, but the ntpd.exe is not supporting sha1.
> Its only supporting MD5 till key id 10.
> Can some one point me what are all the openssl libraries needed for
> supporting SHA1 and also openssl version is correct.
> 
> OS I am testing on is windowss7.

You didn't mention the release patch level -- OpenSSL 1.1.0 support
starts with NTPv4.2.8p9. OpenSSL 1.0.2 should not be a problem for any
4.2.8 release, though.

For Windows the easiest way to get the OpenSSL binaries is the download
from Shining Light Productions
(https://slproweb.com/products/Win32OpenSSL.html) unless you want to
build OpenSSL from source. Which is not entirely trivial on Windows.
Choose 32/64 bit full version (*not Light!), depending on your target.

Make sure that you set the following environment Variables:

for 32bit:
OPENSSL_LIB -> installation directory of openssl libs
OPENSSL_INC -> installation of openssl header tree

for 64bit:
OPENSSL64_LIB -> installation directory of openssl libs
OPENSSL64_INC -> installation of openssl header tree

That should be all you need...
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] 4.2.8p9 build issue on ARM running Ubuntu 14.04

[juergen perlinger]

On 12/01/2016 03:37 PM, Paul wrote:
> [conflicting types for 'EVP_MD_CTX']
> 
> I've been able to build every version for some time but I can't build
> 4.2.8.p9/ARM/Ubuntu 14.04 because of the changes to a_md5encrypt.  I don't
> cross-compile.
> 
> Before I start trying to figure this out I thought I'd ask if there's
> something obvious I've missed.

Not your fault -- see https://bugs.ntp.org/show_bug.cgi?id=3144

You can either download the patch and apply it, then building without
OpenSSL should work again, or you install the 'libssl-dev' package and
build with crypto support (you don't have to *use* the crypto
options...) which should work without patching the source.

If both approaches fail, please add that to bug 3144! But the symptom is
well-known to me by now, so I'm confident that's the right track.

"We apologise for the inconvenience."

Cheers,
Pearly


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

Re: [ntp:questions] reference clock, shm and ntpd

[juergen perlinger]

On 05/27/2016 05:15 AM, Stuart Maclean wrote:
> Thanks for the info Dan,  I have to concede I don't even know what the
> 'frequency' is or what it means, much less know why the value is 500.

The correction, in PPM, to apply to the clock frequency. (More below...)

> How might I reduce that value?  I am fairly sure my reference clock is
> good, and that my Linux system clock ticks slow compared to the ref clock.

The other way round, I assume ;)

> 
> I am beginning to wonder if I am actually populating the shm segment
> correctly.  I shall write a reader app in place on NTP, just to see if
> the data transfer is working as I hoped it would.  I may have usecs and
> nsecs fields mixed up.
> 
> Or perhaps my cross compile to Arm produced different code layouts for
> ntp and my daemon app, in which case my data xfer is way off.  I note
> that the struct shmTime is not written in terms of stdint.h types like
> uint32_t, but as general ints.  I suppose since the producer and
> consumer are by definition on the same machine, they should at least
> agree on the struct layout no matter how it is defined.  Hmm, maybe
> padding could be in play here, or maybe I need to look at memory
> barriers for my producer's writes??
>

>From far away, I don't think that's the problem here. Both NTPD and your
service daemon agree on the offset, so the data in the SHM segment is
interpreted in a consistent way on both sides.

So as long as both apps (NTPD and the acquisition daemon) are compiled
with the same infrastructure, alignment issues in the SHM wouldn't be my
prime suspects.

This could be an issue for the call to adjtimex, in theory. After 'man 2
adjtimex' and reading /usr/include/linux/timex.h I don't think that's an
issue for a 32-bit system. I have a kernel 4.4, and my sources need not
necessarily to match yours, but this structure seems to be pretty stable
over the last 20 years.

> Regards
> 
> Stuart
> 
> 
> On 05/26/2016 02:50 PM, d...@drown.org wrote:
>> > mintc=3, offset=25.970500, frequency=500.000, sys_jitter=0.00
>> ,

I missed that frequency=500 statement initially, but IMHO that's an
indication that points into the direction of the clock/adjtimex handling
in the kernel.

NTPD tries to speed up the clock by 500ppm already, that is, change the
clock time for 0.0005s over the next second. If the kernel does not
apply any adjustment in the next second, the adjustment is applied
again, cancelling the old request. Again to no effect...

IMHO the most useful thing to do would be to assert that adjtimex (it's
disguised as 'ntp_adjtime' in the source) works properly -- This
involves checking the call sites in NTPD (what flags/parameters are used
etc) and see if they are all implemented and handled on the kernel side.

This could become a real headache.

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

Re: [ntp:questions] reference clock, shm and ntpd

[juergen perlinger]

On 05/26/2016 07:23 PM, Stuart Maclean wrote:
> Hi Pearly,
> 
> based on your suggestion on the use of ntpq, I indeed ran those commands
> and the offset does indeed say about 26ms, see here:
> 
> associd=0 status=0418 leap_none, sync_uhf_radio, 1 event, no_sys_peer,
> 
> version="ntpd 4.2.8p4@1.3265 Mon May 23 20:45:07 UTC 2016 (1)",
> 
> , leap=00, stratum=1,
> precision=-15, rootdelay=0.000, rootdisp=26.313, refid=csac,
> 
> reftime=daf1adb7.a5581391  Thu, May 26 2016 17:15:35.645,
> 
> clock=daf1adbd.54fb354f  Thu, May 26 2016 17:15:41.331, peer=6499, tc=4,
> 
> mintc=3, offset=25.970500, frequency=500.000, sys_jitter=0.00,
> 
> clk_jitter=1.029, clk_wander=12.000
> 


 (*grunt*) Instructive, and rules out a few possibilities.

> 
> 
> I shall have to see if my ntp build process was flawed.  Our deployment
> target is a legacy Linux 2.6.10 system on Arm, and we have a fairly
> dated cross compiler toolchain.  So getting ntp to cross-compile at all
> took a bit of effort, my exact sequence was this:
> 
> $ mkdir arm-linux
> $ cd arm-linux
> $ ../configure --host=arm-linux --disable-GPSD --with-yielding-select
> $ make
> 
> Perhaps those extra configure options, without which the build failed,
> introduce some offset of 26ms ??

That sounds unlikely to me... which proofs nothing, of course. But
omitting the GPSD/JSON protocol support won't do any harm, and the
method for multiplexed IO shouldn't do anything bad, either.

But a few thoughts start to connect... And one thing would be *really* bad:

Are you sure the implementation of 'adjtimex' is fully operational? You
said you have a 32kHz crystal (probably a 32768Hz wrist watch
oscillator), and properly implementing the adjtimex syscall is probably
tricky with such a low frequency. But even if this call is properly
implemented, there's still the interaction with the close loop
controller in NTPD.

AFAIR ntpd does not accumulate the residual correction that is returned
after setting a slew with this call. So if your implementation of
adjtimex needs a certain threshold to start working actively, there's a
good chance that the FLL/PLL closed loop controller will not issue a
correction that exceeds this limit once the deviation is small enough --
e.g., 26msec! (The same could happen if there's no real threshold: If at
least part of the correction does not happen in the next second, nothing
will happen at all: NTPD issues a correction once per second, cancelling
any old correction that is not yet complete.)

I *think* the non-accumulating behaviour is by intention, because
accumulating the the residual creates a very different feedback
characteristic. That is, it would become a different closed loop
controller, and not necessarily with same stability properties.

Considering the time Dr. Mills spent on those issues I don't think
fiddling around there is a good idea.

Is the 32768Hz oscillator the only possible time source? I would hope
that there are other, much faster oscillators available to implement the
system clock... These would probably result in *much* smaller internal
thresholds, and consequently much smaller residual errors.

Provided the assumption about the internal minimum threshold for
'adjtimex' to kick in can be held upright.

> 
> I'll re-run ntpd on our target arm board under strace, and see it is
> using e.g. some drift file I was unaware of.
> 

Especially the drift file shouldn't be a problem, as after a while your
offset becomes stable -- just not zero, as it should.

> Thanks again for your help and suggestions

de nada!

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

Re: [ntp:questions] reference clock, shm and ntpd

[juergen perlinger]

On 05/25/2016 02:44 AM, Stuart Maclean wrote:
> Hi Pearly, thanks so much for your reply, the first one both seems to
> understand what I am trying to do AND that I can understand your points.
> 
> I am guessing that 'clockTimestamp*' are the fields from the reference
> clock.  Since my ref clock outputs whole seconds only, yes I set
> clockTimestampUsec and clockTimestampNsec to both zero.  I have also
> just asserted that ntpd's shm code never writes to those values, so I am
> safe writing to them just once.
> 
> When my daemon gets system time at time of ref clock PPS, my device
> driver supplies secs and usecs back to it(essentially the data that the
> device driver obtains with a do_gettimeofday right in the ISR attached
> to PPS event).  I am not a fan of how ntp uses the term 'driver', since
> I am using device driver here also, to mean 'code in the Linux kernel'.

(Just nomenclatura. Cups has printer drivers, but the 'real' driver is
obviously an USB or parallel port or even serial line driver. It's a
matter of perspective... but when one is dealing with both levels, it
gets confusing very fast. I have no good solution for that...)

> 
> So anyway, my daemon gets secs + usecs back from the PPS event. and I
> simply set them into the shmTime.receiveTimestampSec and
> shmTime.receiveTimestanpUSec respectively.  I clamp my
> shmTime.receiveTimestampNsec to 0 throughout.
> 
> So in fact I am only setting 3 of the 6 timestamp fields as non-zero:
> the clockTimestampSec, the receiveTimestampSec and the receiveTimestampUSec.
>

Makes perfect sense to me.

> I have precision = -20, leap = 0, samples = 3, though am not sure what
> each is supposedly doing.
> 
> Performance is odd.  I can see ntpd working 'slowly' to align system
> time to the reference, on the order of minutes, and that's fine.  It
> just never gets any closer than ~26ms.  Here's a snippet of my daemon's
> log, each time it grabs refclock time and PPS timestamps.  You can see
> the ~26000 usec offset over time.  By the way, my Linux system tick is
> 10ms, and my Linux clock crystal runs at 32Khz, so my linux system time
> resolution is about 30us as I understand it.

(So basically your precision is -16, not that it matters when we're away
from that by a factor of 10**3...)

> 
> In my log, the 'Data' value is the reference clock.  The PPS values
> (secs + usecs) are Linux system time at time of ref clock PPS,  For this
> run, I had reduced my daemon main loop from 10 secs to 5 secs:
> 
> 20160525004117982   Data: 1464136878, PPS 1464136877 973992
> 20160525004122987   Data: 1464136883, PPS 1464136882 973906
> 20160525004127982   Data: 1464136888, PPS 1464136887 973962
> 20160525004132986   Data: 1464136893, PPS 1464136892 974045
> 20160525004137980   Data: 1464136898, PPS 1464136897 973929
> 20160525004142985   Data: 1464136903, PPS 1464136902 973940
> 20160525004147979   Data: 1464136908, PPS 1464136907 974029
> 
> Of course what i WANT ntpd to do is nudge that 974000 up to towards
> 00, so that when the ref clock's PPS goes off, my system clock reads
> same time as next ref clock data output.
> 
That does look pretty stable to me, and yes, the offset should go away.

Since you have your daemon feeding the SHM segment: What's the output of
NTPQ? (the general 'ntpq -pn' as well one where you can see the clock
and peer variables. That's 'ntpq -c "cv "' and 'ntpq -c "rv "',
where you can get the '' from a 'ntpq -cas' and matching the lines
with the output ofg 'ntpq -crv')

The jitter and offset for your SHM segment provided by 'ntpq -pn' should
match the one you observe from your daemon's debug output. If there's a
discrepancy... I cannot start to suspect where this dead fish is rotting
away, but then it's basically between your acquisition daemon (and/or
it's output / debug output) and ntpq.

If the offset in 'ntpq -crv' is also 26ms, then I assume a different
kind of fish is decaying somewhere inside ntpd. While both aspects are
not exactly wonderful, you may pardon me for hoping it's not NTPD ;)

I'll be AFK and out-of-reach for some time to come, but I think that
trying to correlate the output of NTPQ with the output of your
acquisition daemon will provide further insight. Just don't feel shunted
when I'm unresponsive for some time ;)

Cheers,
Pearly

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

Re: [ntp:questions] reference clock, shm and ntpd

[juergen perlinger]

On 05/24/2016 11:27 PM, Stuart Maclean wrote:
> Back in January of this year, I posted my ntp scenario to this list:
> 
> http://lists.ntp.org/pipermail/questions/2016-January/040609.html
> 
> I never got a reply I could understand.
> 
> I am now revisiting the issue of using ntp to read from a shm segment,
> using driver 28.  I populate that shm segment using a daemon of my own,
> call it D, thus:
> 
> every 10 secs, my daemon D reads 'whole secs since the epoch' from a
> special hardware clock, call it HC.  My daemon also reads PPS events
> from that same clock (imagine it being like a GPS device, it can output
> a PPS and a NMEA-like string containing a timestamp).  I wrote a kernel
> device driver which sees the PPS as an interrupt on a GPIO pin and grabs
> system time and returns that as the read result of the PPS 'device' to
> daemon D.
> 
> So my daemon gets a time value from the hardware clock AND a local Linux
> system time.  I use these two to populate the fields of a single SHM
> struct which I write and NTP then reads.
> 
> My ntp.conf is thus:
> 
> server 127.127.28.2 minpoll 4
> fudge 127.127.28.2 refid HC
> 
> Things are kind-of working. I know without use of ntp, my system clock
> would drift from the HC time value.  It would tick slow, and the drift
> is significant, seconds per hour.
> 
>  ntpd is getting my Linux system clock to stay within 25 ms of the HC
> reference time, but never any nearer.  ntpq -p reports an offset of
> 25-26.  My daemon D also reports the time grabs it gets from HC and
> system time at time of PPS, and it too reports a discrepancy of 25ms.
> 
> I do not understand this 25ms 'barrier'?  Anyone enlighten me?
> 
> I suspect I am not using ntp correctly, with respect to how it expects
> to use a PPS signal.  As I alluded to in my earlier email, our system is
> a legacy Linux 2.6.* kernel pre-dating linuxpps support.
> 

Other clock sources (in my case, the Meinberg service daemon) do *not*
have this issue, so I guess your suspicion is right...

Among the things that can go wrong I would check:

Is the clock time properly set? Assuming you get your PPS pulse at the
start of a new second, both 'clockTimeStampUSec' and
'clockTimeStampNSec' should be zero.

Is 'receiveTimeStampUSec' the truncated result of dividing
'receiveTimeStampNSec' by 1000?

Is the precision field set to something that mirrors the precision of
the PPS signal? If you have 1usec accuracy, 'precision' should be set to
-20.

'leap' should be zero, but I guess you have that, or you would
experience other strange things.

(Note: I have a tendency to mess up the meaning of clock time and
receive time... If in doubt, switch the roles and see if my writing
makes more sense then.)

Oh, another thing that can go wrong: Do you sample the right edge of the
PPS pulse?

I guess you went over your code several times already, so I guess the
time stamps themselves are OK. Which leaves the other things to check.

Thinking about it, the PPS edge that gets evaluated becomes my prime
suspect, but since I don't have details about the hardware I cannot
validate or dismiss that suspicion. (While the trailing edge is not as
stable in timing as the leading edge for most receivers, the PPS pulse
width is stable enough to give you a pretty constant offset...)

And my apologies if you have already checked these issues.



Now, why do some clock sources insist in feeding two clock units, one
for PPS and one for the serial data stream?

Some people consider them being two clocks that are actually unrelated.
I don't want to start a flame war here, so let's just say that's one way
to see it. Other GNS based time sources just use one channel, and IMHO
cause less trouble for NTPD and the programmer. So you should be
perfectly fine with one SHM channel... provided you do the proper error
handling when the sat signal deteriorates, like stopping to feed the SHM
slot with dubious / untrustworthy time stamps.


Cheers,
Pearly

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

Re: [ntp:questions] Align PPS to UTC or GPS?

[juergen perlinger]

On 02/10/2016 07:24 PM, Neil Green wrote:
> I'm configuring a Skytraq Venus GPS module and have the option to align the 
> PPS output to GPS or UTC. Which one is best for use over serial with NTP?

IMHO that's a funny configuration option, as the difference between UTC
and GPS time scale is an integral number of seconds, by definition. So
it should not matter for a true PPS, that is, 1 pulse per second.

This *might* be a difference if the 'PPS' is given every n-th second
(say, every 5 or 10 seconds) and you want one pulse at second zero of
the minute.

Since NTPD syncs to UTC(*), I would suggest the UTC option, and don't be
afraid to have the pulse every second, because it shouldn't make a
difference anyway in that case.

Unless I failed to grasp something?!?

(*) The truth is more complicated, but for all practical purposes it's
easiest to assume NTPD works with UTC.

Cheers,
Pearly

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

Re: [ntp:questions] custom NMEA messages

[juergen perlinger]

On 12/24/2015 09:43 PM, Leon McCalla wrote:
> Hi,
> I have a globalsat BU-353-S4 GPS receiver that I would lie to use as a source 
> for NTPd.  When looking at the messages that it produces, unlike the periodic 
> messages I would expect every second, I get messages in bursts of threes 
> followed by a pause. If the face of an analog clock represented a 3 second 
> window I receive messages at 12,1,4,8.
> 
> One option is to use the UTC messages as an estimate to set the clock 
> initially then NEVER use the gps again but this defeats the purpose of using 
> a GPS for NTPd.  My alternative is to try to find some stability in the 
> madness before subjecting NTPd to these seemingly unstable messages.
> 
> looking at the messages in detail, I can see that a GPGBS message is produced 
> in the middle of the burst and based on wireshark messages, this single 
> message appears every 3.000 seconds. While this is not every second as a 
> traditional PPS message is expected, I would like to see if NTPd can work 
> with something less frequent but highly stable.
> 
> how do I compile a custom driver to read NMEA messages that are not part of 
> the default NMEA driver? The GPGBS message looks like this... 
> http://www.trimble.com/OEM_ReceiverHelp/V4.44/en/NMEA-0183messages_GBS.html
> 
> 
> PS if im going crazy for no reason and NTPd is capable of working with this 
> garbage please let me know.
> 

According to the data sheet at

 http://usglobalsat.com/store/download/688/bu353s4_ds.pdf

the GPS puck can emit GPRMC and GPZDA -- both are supported by the NMEA
driver. (Funny enough, only the data sheet mentions GPZDA... the manuals
don't. But GPRMC is a must have, and it's listed in the manual and in
the data sheet.)

If neither of those can be seen, IMHO the most likely reasons are:

 1. You do not see enough sky for the receiver to make a good fix.
 2. Somehow the device got misconfigured.

In the second case,

  http://usglobalsat.com/store/downloads/NMEA_commands.pdf

might give you basic information for some experiments, including a
possible reset to factory settings.

But unless the receiver emits GPRMC periodically, something is
definitely wrong with the puck, its setup or its location.

My immediate experience with SiRF chipsets is limited, though, and
someone else might have better ideas.

Cheers,
Pearly

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

Re: [ntp:questions] Bug or feature? 4.2.8p3-RC1 - leap_armed not set on dynamic load of leapsecond file

[juergen perlinger]

On 06/07/2015 11:01 AM, Mike Cook wrote:

Hi,
  As part of getting ready for the end of the world as we know it I just 
upgraded  a BBB to 4.2.8p3 and discovered that the leap_armed system status is 
not updated if a leapsecond file is loaded dynamically.

Here’s the trace:

I restarted ntpd after a build and installing a leap second file. The log 
showed that the leapsecond file was not picked up.

Jun  6 22:10:10 bb2 ntpd[1469]: Listen normally on 5 eth0 
[fe80::7aa5:4ff:fecc:d05d%2]:123
Jun  6 22:10:10 bb2 ntpd[1469]: Listening on routing socket on fd #22 for 
interface updates
Jun  6 22:10:10 bb2 ntpd[1469]: leapsecond file ('/etc/ntp/leapdir/leapsecs'): 
stat failed: No such file or directory
Jun  6 22:10:13 bb2 ntpd[1469]: Soliciting pool server 85.21.78.91

I then corrected the error, which was due to a finger check on the directory 
name and waited for ntpd to pick up the now available file, which it did an 
hour later.

Jun  6 23:10:10 bb2 ntpd[1469]: leapsecond file ('/etc/ntp/leapdir/leapsecs'): 
loaded, expire=2015-12-01T00:00Z last=2015-07-01T00:00Z ofs=36

I thought that would be the end of the story, but a routine check this morning 
showed that the leap_armed status was not set.

mike@bb2:~$ ntpq -c rv
associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
version=ntpd 4.2.8p3-RC1@1.3265-o Sat Jun  6 14:56:55 UTC 2015 (1),
processor=armv7l, system=Linux/3.8.13-bone47, leap=00, stratum=2,

I then restarted ntpd to check if that helped.

Jun  7 08:19:21 bb2 ntpd[19014]: ntpd 4.2.8p3-RC1@1.3265-o Sat Jun  6 14:56:55 
UTC 2015 (1): Starting
Jun  7 08:19:21 bb2 ntpd[19014]: Command line: /usr/local/sbin/ntpd -p 
/var/run/ntpd.pid
Jun  7 08:19:21 bb2 ntpd[19009]: Starting NTP server: ntpd.
..
Jun  7 08:19:21 bb2 ntpd[19015]: leapsecond file ('/etc/ntp/leapdir/leapsecs'): 
good hash signature
Jun  7 08:19:21 bb2 ntpd[19015]: leapsecond file ('/etc/ntp/leapdir/leapsecs'): 
loaded, expire=2015-12-01T00:00Z last=2015-07-01T00:00Z ofs=36
..
mike@bb2:~$ ntpq -c rv
associd=0 status=0619 leap_none, sync_ntp, 1 event, leap_armed,
version=ntpd 4.2.8p3-RC1@1.3265-o Sat Jun  6 14:56:55 UTC 2015 (1),

So, it’s fixed by a reboot. Anyone seen this?
Mike, even after restart I see the 'leap_armed' event only for a short 
time -- it gets overwritten with a clock_sync soon. (At least as far as 
the output of ntpq goes.) Could you check the event log of NTPD for a 
'leap_armed' event?


I checked the implementation, and I don't see how the leap_arm event 
should not happen. I'll need some instrumentation in the code to 
validate this,  and testing will take some time. If you find in the 
meantime that the event is written to the log, drop me a notice, please.


Cheers,
Pearly


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

Re: [ntp:questions] Bug or feature? 4.2.8p3-RC1 - leap_armed not set on dynamic load of leapsecond file

[juergen perlinger]

On 06/07/2015 11:01 AM, Mike Cook wrote:

Hi,
  As part of getting ready for the end of the world as we know it I just 
upgraded  a BBB to 4.2.8p3 and discovered that the leap_armed system status is 
not updated if a leapsecond file is loaded dynamically.

Here’s the trace:

I restarted ntpd after a build and installing a leap second file. The log 
showed that the leapsecond file was not picked up.

Jun  6 22:10:10 bb2 ntpd[1469]: Listen normally on 5 eth0 
[fe80::7aa5:4ff:fecc:d05d%2]:123
Jun  6 22:10:10 bb2 ntpd[1469]: Listening on routing socket on fd #22 for 
interface updates
Jun  6 22:10:10 bb2 ntpd[1469]: leapsecond file ('/etc/ntp/leapdir/leapsecs'): 
stat failed: No such file or directory
Jun  6 22:10:13 bb2 ntpd[1469]: Soliciting pool server 85.21.78.91

I then corrected the error, which was due to a finger check on the directory 
name and waited for ntpd to pick up the now available file, which it did an 
hour later.

Jun  6 23:10:10 bb2 ntpd[1469]: leapsecond file ('/etc/ntp/leapdir/leapsecs'): 
loaded, expire=2015-12-01T00:00Z last=2015-07-01T00:00Z ofs=36

I thought that would be the end of the story, but a routine check this morning 
showed that the leap_armed status was not set.

mike@bb2:~$ ntpq -c rv
associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
version=ntpd 4.2.8p3-RC1@1.3265-o Sat Jun  6 14:56:55 UTC 2015 (1),
processor=armv7l, system=Linux/3.8.13-bone47, leap=00, stratum=2,

I then restarted ntpd to check if that helped.

Jun  7 08:19:21 bb2 ntpd[19014]: ntpd 4.2.8p3-RC1@1.3265-o Sat Jun  6 14:56:55 
UTC 2015 (1): Starting
Jun  7 08:19:21 bb2 ntpd[19014]: Command line: /usr/local/sbin/ntpd -p 
/var/run/ntpd.pid
Jun  7 08:19:21 bb2 ntpd[19009]: Starting NTP server: ntpd.
..
Jun  7 08:19:21 bb2 ntpd[19015]: leapsecond file ('/etc/ntp/leapdir/leapsecs'): 
good hash signature
Jun  7 08:19:21 bb2 ntpd[19015]: leapsecond file ('/etc/ntp/leapdir/leapsecs'): 
loaded, expire=2015-12-01T00:00Z last=2015-07-01T00:00Z ofs=36
..
mike@bb2:~$ ntpq -c rv
associd=0 status=0619 leap_none, sync_ntp, 1 event, leap_armed,
version=ntpd 4.2.8p3-RC1@1.3265-o Sat Jun  6 14:56:55 UTC 2015 (1),

So, it’s fixed by a reboot. Anyone seen this?
I'll have a look into it. I think I know what the problem is, and it 
should be easy to fix... Hopefully this weekend.


Cheers,
 Pearly

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

Re: [ntp:questions] [ATOM (PPS) Refclock] Capture assert AND clear

[juergen perlinger]

On 04/21/2015 09:41 AM, f.hiesinger wrote:

Hi Folks,
I'm sourcing a pps-signal via GPIO on a raspberry Pi(debian whezzy). 
The pps0 is configured to capture Assert AND Clear (mode = 
0x11f3). The internal echo-mechanism is used, so reception of BOTH 
edges is required. Up to here everything works fine.
When ntp (incl. ATOM Driver 22) is starting, it instantly 
reconfigures* the pps0-behavior to maintain either Assert OR Clear 
Edges. fudge - flag2 1 inverts the behavior. Any suggestions, how to 
prevent ntpd from reconfiguring the pps-source?


BR,Fran


* in detail, this pps-modebits are removed at the start of ntpd:
 PPS_CAPTURECLEAR 0x02 (depends on flag2)
 PPS_OFFSETASSERT 0x10
 PPS_OFFSETCLEAR 0x20
 PPS_ECHOASSERT 0x40
 PPS_ECHOCLEAR 0x80


That behaviour is pretty much hardwired into ntpd. I think this is done 
to reduce the work needed in kernel space, but that's a wild guess.


Anyway, I checked the sources, and I don't see a way to avoid this 
behaviour without changes in the code, some of them in places that are 
considered mission critical.


Cheers,
Pearly

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

Re: [ntp:questions] Optimising NTP build for Raspberry Pi 2

[juergen perlinger]

On 03/07/2015 01:41 PM, Neil Green wrote:

In an attempt to squeeze all I can out of a NTP and GPS/PPS setup on the 
Raspberry Pi 2 I’m starting to experiment with compile flags using GCC 4.8. 
Currently I have:

CC=gcc-4.8 CFLAGS=-mcpu=cortex-a7 -mfpu=neon-vfpv4 ./configure 
--enable-NMEA --enable-ATOM --enable-linuxcaps --disable-all-clocks --disable-parse-clocks 
--disable-ipv6

Will attempting to optimise the build like this have any positive impact on NTP 
in terms of precision, stability etc, or am I focussing on an area that will 
have no benefit?
Tweaking here can save you code size by omitting features you do not 
use, and it might save you execution cycles if the compiler can tailor 
the machine code as tight to the target as possible. But NTPD is not 
exactly a number crunching application or high volume data server, so 
you might end up with a diminishing return of invest.


IMHO the code size reduction is the most prominent potential benefit you 
can get. ('Potential' because I do not now how tight your RAM is 
crammed.) As others have mentioned, the affect on the operation itself 
is probably nonexistent -- the critical execution paths should mostly be 
in the kernel.


Oh, and your build time should go down. But I guess that's not what was 
foremost in your mind...


Cheers,
Pearly

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

Re: [ntp:questions] NTP, GPSD PPS

[juergen perlinger]

On 12/09/2014 03:29 PM, Sander Smeenk wrote:
 Hi,

 I run a stratum 1 server which has a Garmin LVC 18x connected to its ttyS0.
 The GPS provides a PPS signal via serial and i use gpsd to provide the
 NMEA sentences and pulse data in shared memory to NTP.

 This partly works. NTP syncs against the PPS signal but the NMEA signal
 is always marked as falseticker even though i managed to bring down the
 offset to -1.5ųsec average by fudging the time a bit. The NMEA signal
 offset fluctuates a lot. From ~ -65ųsec to ~ +75ųsec.
This is a known weakness of the GPS18x series. The puck tries to center
the serial output between the PPS pulses, and that's a pain in the back,
pardon my French. But to be fair, some SIRF based modules do it even worse.
 The GPS provides 9600bps serial comms. Would it help to speed this up to
 19200bps? I've already disabled all NMEA sentence output for sentences that
 aren't useful for timekeeping but at this moment i have to use external
 clocks to sync against.
Changing the baud rate does not really help with that device. I have one
of my own, and I tried several speeds. Even reducing to a single
sentence (GPRMC, or PGRMF) does not provide stable timing. A stable
relation between PPS and serial data was obviously no design goal...

 Few questions:

 1) Can i get a 'true PPS sync' with this setup?
 Eliminating gpsd so 'ntpq -p' shows 'oSHM(1)' instead of '*SHM(1)' ?

 2) What could i possibly do to get NTP to sync/accept the NMEA data,
 other than set it as a truechimer in the configuration?
Since you run ntp4.2.6 under Linux, I know only one solution from my own
experience:

Use the NMEA driver with its builtin PPS support instead of GPSD and the
two SHM clocks. Splitting the data into a PPS track and a NMEA track
does not work well: The two clock drivers do not know how to correlate
their data. Neither does the core of NTPD... If the full handling is
done by the NMEA driver, the serial data jitter can be ignored and you
get a good precision.

You need the PPS line discipline attached to your serial device (see
'ldattach PPS /dev/ttyS0'), and you need a symbolic link from
/dev/gpsppsX to /dev/gpsX.

(Note: with ntp4.2.7(!) and GPSD running, you could start GPSD on
/dev/gps0 and use the GPSD-NG (json) protocol driver (type 46). With a
recent version of GPSD you can let GPSD deal with the raw PPS and serial
data; NTPD uses the cooked results with nanosec resolution. Then the
driver can correlate serial and PPS data to compensate for the phase
jitter of the GPS18x.)

pearly

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

Re: [ntp:questions] GPS NG type 46 refclock tests

[juergen perlinger]

On 12/06/2014 09:50 PM, Paul wrote:
 [I just don't understand why NTP people like GPSD]
Well, they have a decent code base for dealing with a number of GPS
devices, and they have hardware PPS support. And using GPSD as a time
source makes more sense than using NTPD as source for position
information...

There has been the idea to support the chrony pipe model as an
alternative to the shared memory clocks to couple GPSD and NTPD, but
that would probably have required work on both sides. I found the idea
of using the JSON GPSD client protocol  more appealing and wrote a
simple driver as  a proof of concept.

 On Sat, Dec 6, 2014 at 4:29 AM, David Taylor 
 david-tay...@blueyonder.co.uk.invalid wrote:

   ln -s /dev/ttyAMA0 /dev/gps0
 Sure that can work.  I haven't looked at Refclock 46 in any detail though.
That's indeed the way it is intended to work. The GPSD-JSON driver uses
the same naming scheme as the NMEA driver -- It makes switching between
NMEA and GPSD a bit more easy while experimenting.

NOTE:  You must also start GPSD on the same link (like 'gpsd -n
/dev/gps0') or the driver will not find its device.

If there is need for it, I'm willing to do the necessary stuff to let
the driver do the link evaluation. Then the native device name would be
used by the driver. This would still require the link for NTPDs sake,
but GPSD could use ttySxy or whatever.

Feel free to file a bug (well, a feature requirement) against the driver
if you feel hampered by the current setup!
 Secondly, in the documentation TVP is mentioned.  It would be helpful if
 it were defined, but is not.  I guess time-velocity-position?  As I have
 those in cgps -s I appear to be covered, but what about the other objects?
 WATCH, PPS and version are listed.  How you I know whether I have these?
 It's TPV not TVP and yes it's time-position-velocity.  This is all
 explained here: http://www.catb.org/gpsd/gpsd_json.html
 WATCH and VERSION are commands sent by the client to the server.  TPV and
 PPS are responses sent by the server to the client.  I'm sure they're fully
 supported in your instance.
I'd call it 'briefly described' -- an explanation would go far beyond
that, IMHO. But I've seen worse also.


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

Re: [ntp:questions] GPS NG type 46 refclock tests

[juergen perlinger]

On 12/07/2014 12:26 PM, David Taylor wrote:
 On 07/12/2014 09:44, juergen perlinger wrote:
 []
 david-tay...@blueyonder.co.uk.invalid wrote:

ln -s /dev/ttyAMA0 /dev/gps0
 Sure that can work.  I haven't looked at Refclock 46 in any detail
 though.
 That's indeed the way it is intended to work. The GPSD-JSON driver uses
 the same naming scheme as the NMEA driver -- It makes switching between
 NMEA and GPSD a bit more easy while experimenting.

 NOTE:  You must also start GPSD on the same link (like 'gpsd -n
 /dev/gps0') or the driver will not find its device.

 If there is need for it, I'm willing to do the necessary stuff to let
 the driver do the link evaluation. Then the native device name would be
 used by the driver. This would still require the link for NTPDs sake,
 but GPSD could use ttySxy or whatever.

 Feel free to file a bug (well, a feature requirement) against the driver
 if you feel hampered by the current setup!

 Thanks for the TVP/TPV correction.  You used to hear a lot about TVP
 but it seems to have gone out of fashion today!

 I could not get this to work to start with, gpsd complaining that it
 could not find a device, but reconfiguring it as you suggested to look
 for /dev/gps0 rather than /dev/ttyAMA0 fixed that.  So it's working,
 but there is a significant problem...

 The timing variation on the serial data from the Adafruit/MTK3339 GPS
 is quite large, and NTP won't sync to it alone, at least when there
 are other LAN or Internet sources available.  As NTP won't accept it
 (marked as - in the tally code), the PPS which it should offer is
 never accepted, so I have had to go back to using the type 22 ATOM
 refclock as well as the type 46 and LAN-based servers as well.  I
 might just as well use type 28 (shared memory gpsd) in addition to the
 ATOM driver as use type 46.  Perhaps it should at least pass PPS when
 it is available, or perhaps NTP should use its PPS irrespective of
 whether it is a avlid time or not, but that's completely against what
 appears to be good practice.
I have a GPS18xLVC running with GPSD, and that puck is also known for
its suboptimal (ahem) serial timing. There might be an issue with GPSD
and the PPS signal, because GPSD needs still to be root when attaching
the PPS line discipline. If the device is coupled via USB, there might
be more issues -- AFAIK, Harlan is fiddling with an UBlox module that
gives him troubles in that area.

Another thing that can go wrong: Once an ldattach daemon is running on
the port, GPSD is not able to attach the PPS line discipline internally,
resulting in the PPS data not being available to GPSD. I removed the
'ldattach' stancas from my UDEV/boot config that I had put there long ago.


 So it appears that type 46 does nothing for me.  Perhaps I'm missing
 something, though.  I had been thinking that type 46 could replace
 /both/ type 28 and type 22 drivers.
That was the original idea...

 I've learnt a little more about Linux, though.

 Thanks for your help, and there's no need to do anything further on my
 behalf.  It might help others were your note about reconfiguring gpsd
 after creating the symlink were on the type 46 Web page.

I think it's written there, but I have to check. It's nearly a year I
wrote that up.


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

Re: [ntp:questions] PPS as a falseticker!!!

[juergen perlinger]

On 08/27/2014 08:46 PM, David Lord wrote:
 Mike S wrote:
 On 8/27/2014 5:48 AM, valizade...@gmail.com wrote:
 I not sure, how should I write the ntp.conf file to achieve the
 maximum accuracy using pps.
 i don't know  if the ntpd use the pps or not in my case!
 Sometimes it is recognized as a falseticker (x) and sometimes it
 is OK(o) !!!

 Try adding tos mindist 0.02 to your config.

 NMEA tends to wander around - the default mindist of 0.001 can result
 in what you see. You might try setting it even higher, and work your
 way down to a reliable minimum.

 Hi

 For several years I've used:
 tos minsane 3
 tos orphan 10
 tos mindist 0.4

 currently with PPS, NMEA, 2 x local pcs, 4 x local pool.ntp.org
 servers and one remote source.

 ntp-dev-4.2.7p444 on NetBSD-6/i386


 David

The basic problem is that using a PPS clock and a GPS(NMEA) clock
separates what belongs together: the time message and the PPS pulse.
Using the PPS-support flag at the NMEA driver and *not* using a separate
PPS clock avoids the problem.

As already mentioned, some receivers (e.g. my Garmin GPS18xLVC) have a
serial timing that leaves something to be desired... I decided to use
the NMEA-internal PPS support and had no problems whith that since years.

Pearly

  From the docs:
 mindist mindistance
 Specify the minimum distance used by the selection and anticlockhop
 algorithm. Larger values increase the tolerance for outliers; smaller
 values increase the selectivity. The default is .001 s. In some
 cases, such as reference clocks with high jitter and a PPS signal, it
 is useful to increase the value to insure the intersection interval
 is always nonempty.


 I tested different ntp.conf and here are some results (ntp.conf and
 ntpq-p):

 #TEST:1

   - ntp.conf---
 server 127.127.22.1 minpoll 4 #PPS
 server 127.127.20.1  prefer minpoll 4 mode 16 #GPS
 fudge 127.127.20.1 flag1 1 flag3 1
 -
 GPS on COM port (PPS connected to DCD pin)
 remote   refid  st t when poll reach   delay   offset 
 jitter
 ==

 xPPS(1)  .PPS.0 l3   16  3770.000  
 30.681  29.011
 oGPS_NMEA(1) .GPS.0 l2   16  3770.000  
 29.964  29.404

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


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

Re: [ntp:questions] serialPPS+gpsd+ntpd large offset jitter

[juergen perlinger]

On 01/12/2011 12:07 PM, Hal Murray wrote:
 Even if you have a perfect source of UTC, it's going to be hard to
 keep a typical Linux server within 5 microseconds of that clock.
 
 I think you need to reconsider the whole system.  Where
 did that 5 microseconds come from?  What happens if/when
 the clocks are off?
  []
 One of the major sources of clock inaccuracy on typical PCs
 and servers is the minor change in frequency of the system
 clock because the temperature of the crystal changed.
  [...]

IMHO, there are at least two other sources for jitter:

Modern boards use spread spectrum technology to reduce the emitted
electromagnetic radiation. They modulate the frequencies of the cores
and other 'non-critical' equipment (as timing goes) to smear the
emission spectrum, so the energy is emitted in bands instead of sharp
single spikes. So a lot of frequencies are a bit wobbly. I don't know
how much that contributes to time measurement noise, but it might be
noticeable. Some frequencies might be more affected than others -- My
personal AMD64 box seems to run smoother with HPET as clock source
instead of TSC. (And no, no proof -- it's a feeling.)

There's always interrupt latency, which is still in the order of a few
microseconds. (*micro*, not nano or pico!)  The speed of interrupt
processing in most combinations of interrupt controllers / CPU
combinations did not increase that much over the years, at least in
typical PCs. That's why some (many?) 10GB and 1GB network chip sets have
the ability to coalesce several interrupt requests into one: The
interrupt processing is too slow.

Then there's interrupt priority, which affects the latency: The serial
line IRQ is probably not the highest (should by the system ticker
anyway), and interrupt chaining compounds the problem by increasing the
jitter in the interrupt latency.

Considering the fact that typical PC's are not build for precision time
keeping, nor for hard realtime conditions, I always thought that keeping
mine in +/-5usec to the PPS pulse of my GPS receiver was quite an
achievement... Maybe I should set up a FreeBSD on the same machine, so I
could try what happens with an OS known for its good interaction with ntpd.

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

Re: [ntp:questions] NTP with GPS + PPS falsetick

[juergen perlinger]

On 06/15/2010 04:46 PM, Marc Leclerc wrote:
 Hi,

 So it seem that after a while NTP reject my GPS and PPS input for time
 keeping. The only source for time sync is the GPS, I cannot use other
 devices and/or remote servers.


Hi Marc,

I have/had similar problems with a Garmin GPS18x and the NMEA / ATOM
driver pair.

As far as I see it (and others are welcome to correct me) it is the fact
that ntpd sees this as two independent clocks, which they are not;
things get worse worse over time if they keep a a difference, which they
do if you cannot 'fudge' the 'real' clock close enough to the PPS clock.

remotest t when poll reach   delay  offset  jitter
 

 xGPS_PALISADE(1)  0 l8   32  3770.000   -1.193  0.409
 xPPS(0)   0 l8   64  1770.000  -104.82  6.030

In your case there seems to be shift of 103.6ms between the PPS and the
palisade clock, and since there are no other sources, both are marked
falsetickers after a while. (They are not from beginning, because they
are close enough for inital sync and ntpd likes to get enough sampled
data to trust it's own measurements and make a decision. This is
probably a bit over-simplified...)

And two is a terrible number of clocks to make a decision on -- or, as
Murphy's Law states: A man with a wrist watch always knows the time; a
man with two can never be sure.

I would suggest to make the PPS a 'noselect' peer and have the palisade
clock to a fudge time of 0, with a maxpoll of 6. Start ntpd and keep it
running for an hour or so, longer if can. Monitor the offset difference
between PPS and palisade; this is what you need to fudge away finally on
your palisade clock.

Then adjust the fudge time on the palisade driver, enable the PPS clock
again and restart ntpd. If you can get both clocks close enough to
survive the internal selection algorithm as a pair, you should be fine.

And check the comments on 'tos minsane' and/or 'tos minclock' in the
description of the ATOM driver in case you haven't yet.

This nearly worked for me with NMEA/ATOM; but because the GPS18x has a
terrible jitter of up to 20msec (serial line vs. PPS), I needed to
modify the NMEA driver finally. Since your jitter numbers seem to be a
lot better, there is hope.


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

Re: [ntp:questions] ntp pll loop on microcontroller?

[Juergen Perlinger]

francesco.messi...@gmail.com wrote:

 Hello all,
 
 did anyone ever attempted (or succeeded too) in porting the ntpd pll
 loop to obtain a synchronized time on a microcontroller  with pps and
 serial input (nmea or other it doesn't really matter)?  Is anyone
 aware of similar projects?
 Thanks
 
 Frank

Well, we did something similar on a Motorola 68360 some 15 years ago. I
don't have sources for that, but the idea was quite close to the windoze
port of NTP. We used a periodic interrupt timer (PIT) which was actually
controlled by a bi-phase counter register. The system had a master PPS
signal and the clock deviation was used to adjust the counter/divider
ratios. So effectively we had a simple PLL for the clock on an embedded
controller; not NTP controlled, alas, but a working PLL nevertheless.

I think the windoze port gives some good ideas how to deal with the problem,
because it uses an API call to adjust the clock speed of the windoze system
clock.(Have a look at 'ports/winnt/ntpd/nt_clockstuff.c') *How* to modify
the clock speed on your embedded controller is something entirely
different.

I don't have any idea if this a useful hint for you, but IMHO the details
will greatly depend on your hardware, while the general problem (using a
PLL without an PLL-API enhanced kernel) was already solved, at least for
windoze.

(I'm aware that using NTPD on windoze is quite similar to trying to adjust a
wrist watch with a two-pound hammer. Or, as it is the case, quite round the
other way.)
-- 
juergen 'pearly' perlinger
It's hard to make new errors!

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

Re: [ntp:questions] how to write a reference clock driver

[Juergen Perlinger]

Harlan Stenn wrote:

 In article 4944eab4$0$12693$9b622...@news.freenet.de, Juergen Kosel
 juergen.ko...@freenet.de writes:
 
 Juergen Hello, Greg Dowd schrieb:
 I'm not quite sure what you mean.  A reference clock doesn't compute an
 offset, it acquires, formats and returns a time value from an external
 source.  NTP takes care of the rest.
 
 Juergen ntpd reads the time of a reference clock with a reference clock
 Juergen driver.  My problem was, that I didn't know from the manual what
 Juergen need to be done with the time from the reference clock.
 Especially Juergen when it is in a differnet format than of the other
 reference Juergen clocks.
 
 Juergen But finally I succeeded by calculating the difference between
 Juergen refence clock time - system clock time and using the SAMPLE()
 macro Juergen to insert this value into the the right data structure
 entry of Juergen ntpd.
 
 
 Juergen,
 
 Most refclock drives do not do it the way you describe.
 
 They take the time from the reflock along with the system timestamp (with
 the intent to get the system timestamp as close as possible to the moment
 the refclock timestamp is obtained), build the contents of the struct
 refclockproc, and call refclock_process().
 

Hi Harlan, Hi Juergen,

The difference is bit more subtle. 'refclock_process()' *will*
call 'refclock_process_offset()', but *only* if the clock conversion
in 'clocktime()' was successful. That means that the difference between
local time and clock time is less than 4 hours! That's why initial
synchronization with clocks only can/will fail if the system has no
battery-backup clock. (That's probably true for most, not all clock
drivers.)

Calling refclock_process_offset()' directly will save that hassle, and it
might provide initial synchronization even if the system clock is way off
from the real time, for a given value of real 8-)
-- 
juergen 'pearly' perlinger
It's hard to make new errors!

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

Re: [ntp:questions] Hopelessly broken clock?

[Juergen Perlinger]

Chris Richmond wrote:

 I'm trying to set up ntp on a new Core2 Duo box running Fredora Core9.
 It appears that it's local clock runs several seconds an hour fast.  I'm
 basing this on running ntpdate against the existing box I have running
 ntp with pps.  It reports skewing the clock by seconds even after just
 a few minutes.
 
 Also, ntpq data shows the jitter as always 0.997, and the offset goes
 nuts right away.  The poll and reach look like they are working, but
 the time just gets away really fast.
 
 I have another box with the same O/S install and ntp config, and it locks
 up right away just fine, so I suspect it's a hardware issue, not a
 config problem.
 
 I've tried to read through the offical docs on the NTP web site on
 diagnosing problems, but can't make sense of what some of the
 instructions mean. What's missing are examples of what actually
 needs to happen.
 
 In any case, if the actual box's clock is that far off, is it a lost
 cause as a time keeper?
 
 Can I make ntptime correct the kernel's clock enough to get this
 to work?  If so, how, and can this be done in the bootup scripts?
 
 Thx, Chris

I have a deja vu... again.

See the support twiki for some hints about linux, but I had similar trouble.
Try to configure your kernel with a 'clocksource=acpi_pm'
or 'clocksource=hpet' and see what happens. A lot of systems try to use the
TSC as clocksource, and the TSC frequency is not constant but varies due to
power management actions.

Have a look at the twiki
at 'https://support.ntp.org/bin/view/Support/KnownOsIssues#Section_9.2.4.2.8.'
-- 
juergen 'pearly' perlinger
It's hard to make new errors!

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