Re: [questions] Specify IP for outgoing sync

[William Unruh]

In comp.protocols.time.ntp, you wrote:
> Hi there,
>
> I read the documentation a few times but can not find if it's possible
> to specify IP address for outgoing connections?
>
> I have server with multiple IP addresses and I need to specify the
> concrete one to be used to sync with servers/peers. For now, ntpd
> selects one of the listening interfaces (still the same one, but I can
> not determine why this one).

Does not route -n
tell you which one? Remember it always used the most the specific
interface.
Ie, if you have say 0.0.0.0/0 and 128.0.0.0/8 on different interfaces,and your 
address of your
ntp server is 128.113.27.6 then it will use the second. If you have
128.113.27.0/24 on a third interface, it will use that third one. If
there are two of equal depth covering the interface, then it will use
the last on I believe.

Ie, with a specific set of routes, it should always pick the same
interface. The server uses the same address it received the query on, so
it will depend on the incoming routing of the response.
>
>
> Thanks,
> Blažej
> -- 
> This is questions@lists.ntp.org
> Subscribe: questions+subscr...@lists.ntp.org
> Unsubscribe: questions+unsubscr...@lists.ntp.org
>
>
>
-- 
This is questions@lists.ntp.org
Subscribe: questions+subscr...@lists.ntp.org
Unsubscribe: questions+unsubscr...@lists.ntp.org

Re: [ntp:questions] ntp pool servers disappear - more data

[William Unruh]

On 2021-06-25, Jim Pennino  wrote:
> chris  wrote:
>> On 06/25/21 17:28, Jim Pennino wrote:
>
...
>  
> Actually what I plan to do is to put a $14 USB GPS on the machine that
> already has a PPS GPS attached and do away with ALL external machines.
>
> If there are two GPS receivers attached to the machine I have a backup
> if one receiver fails.

Two is in general bad, because your machine has no idea which the better
one is and is likely to pick the GPS ratehr than the PPS. 

>
> As GPS receivers are highly unlikely to fail in some wonky mode, e.g. time
> being off by some large amount, but to fail completely, there is no need
> for any other reference source while I replace the failed receiver.

Since both are attached to the same machine, the probability of common
mode errors become high. The cleaner unpluggin the line which feeds both
receivers, etc. 
>
> Now if there is a  Carrington-class coronal mass ejection or WWIII
> breaks out, I will lose all time references but I will have lots of
> other things to worry about that are much more important than the
> computer clock and it is likely that all internet access will also be
> down.

That of course is a very very general common mode error, and is
extremely hard to counteract. More likely are those in your office, on
your floor, or in your building. 

>
> Then on two other machines I attach two $14 USB GPS receivers and no
> external references.

Remember pps is a factor of about 1 more accurate than than NMEA
GPS. 
>
> These three machines then provide time for all other machines on my
> network. The three machines will provide the redundancy needed for when
> one of those machines gets rebooted for updates/upgrades.

Again, make sure they are all on separate electrical circuits,
prefereably also in separate buildings. 

>
> Done.
>
> The only foreseeable change to that I might ever make is if and when USB
> 3.0 GPS receivers with PPS become cheap and available, I might swap out
> the USB receivers with one of those just to see how well they work.

The usb level is irrelevant. It is the PPS that is important. And pps
receivers are also coming down. In fact that UBLOCK probably has a PPS
output, which the manufacturer never bothered to hook upon the puck. 
It is hard to feed ppd over usb with any accuracy. However a separate
pps line which you can attach to some irq line on the computer is
probably possible even for that cheap puck. 

>
> Yes, this scheme only gets my machines to within 10s of milliseconds to
> the actual time, but that is good enough for me.
>
> If I needed better, I would buy one of the $685 GPS GNSS Disciplined
> Rubidium clocks off ebay and get time to the nanosecond.

There is still a wide gap between namosecond and 10s of milliseconds. 
"If walking is too slow, I can always buy a X15 to get there." Actually
the difference there is far less than the difference between ns and msec. 

>
>

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

Re: [ntp:questions] ntp pool servers disappear - more data

[William Unruh]

On 2021-06-25, Jim Pennino  wrote:
> William Unruh  wrote:
>> On 2021-06-25, Jim Pennino  wrote:
>>> chris  wrote:
>>>> On 06/25/21 04:08, Jim Pennino wrote:
>>>>> William Unruh  wrote:
>>>>>
>>>>> 
>>>>>
>>>>>> I suspect it is the number of times that ntpd tries to contact the
>>>>>> server and fails rather than the time that is important. You could try
>>>>>> putting the server offline and then online again (I use chrony so do not
>>>>>> remember if ntpd has that option).
>>>>>
>>>>> No, it doesn't.
>>>>>
>>>> 
>>>> You could use a one line cron script to restart every day, week,
>>>> whenever...
>>>
>>> Or for $14/machine I could use a USB GPS, my machine with PPS GPS, and a
>>> public server that does not request use of DNS.
>> 
>> You could try specifying the server by IP rather than by name, so DNS is
>> not needed. Of course this rule out using pool, unless you put them in
>> by IP. DNS is just used to translate names to IP, so if you use IP, then
>> DNS is not needed.  
>
>
> Or for $14/machine I could use a USB GPS, my machine with PPS GPS, and A
> public server that does NOT request use of DNS which yields 3 sources of
> time without using a pool or DNS lookups.

Not at all sure what you are suggesting. DNS is a way of translating
names to IP addresses, which your machine MUST use to talk to a remote
machine not on your network. The remote machine has nothing to do with
this. Now some remote machines will as for the name associated with the
IP address of machines sending the remote machine a query, to try to see
if someone is spoofing the IP address, but as far as I know ntpd does
not do that. Takes too much time and would make the time responses
really bad. 

>
> Or for $28/machine I could use 2 USB GPS receivers and my machine with
> PPS GPS, which also provides 3 sources of time without any network
>e access at all.

Sure. The problem of course is that that $28 onlybuys you a pretty bad
time source (pretty bad meaning milliseconds rather than microseconds or
nanoseconds), which for most of man's history on this earth is
absolutely astonishingly, and inconceivably good.

Note that hanging all three off of one machine can lead to conflict
between them as to interrupt processing, leading to degraded time
performance. But again that is at the microsecond level, not milli or
second level.
Of course if you machine is at the bottom of a mineshaft in mountains,
gps receivers are pretty useless. Or in the basement of a highrise
without windows. 


>
>

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

Re: [ntp:questions] ntp pool servers disappear - more data

[William Unruh]

On 2021-06-25, Jim Pennino  wrote:
> chris  wrote:
>> On 06/25/21 04:08, Jim Pennino wrote:
>>> William Unruh  wrote:
>>>
>>> 
>>>
>>>> I suspect it is the number of times that ntpd tries to contact the
>>>> server and fails rather than the time that is important. You could try
>>>> putting the server offline and then online again (I use chrony so do not
>>>> remember if ntpd has that option).
>>>
>>> No, it doesn't.
>>>
>> 
>> You could use a one line cron script to restart every day, week,
>> whenever...
>
> Or for $14/machine I could use a USB GPS, my machine with PPS GPS, and a
> public server that does not request use of DNS.

You could try specifying the server by IP rather than by name, so DNS is
not needed. Of course this rule out using pool, unless you put them in
by IP. DNS is just used to translate names to IP, so if you use IP, then
DNS is not needed.  
>
>

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

Re: [ntp:questions] ntp pool servers disappear - more data

[William Unruh]

On 2021-06-24, Jim Pennino  wrote:
> Jim Pennino  wrote:
>> I was checking the stability of a new USB GPS refclock on a server which
>> is configured to use the GPS, servers from the ntp pool, and another server
>> of mine that has a PPS GPS receiver.
>> 
>> I noticed that almost all the pool servers had disappeared.
>> 
>> I then checked other machines that use my "good" server and the ntp
>> pool; most all of the pool servers had also disappeared on those
>> machines.
>> 
>> This is a mix of PC linux, rasberry pi linux, rasberry pi buster, and
>> Windows 10 machines with Meinberg, all with the latest ntp from their 
>> distros.
>> 
>> Long story short: I realized I had had a network outage and tested the
>> theory that was the cause. It was.
>> 
>> It seems that any server in ntp.conf that is specified as a name, as
>> the pool servers are, will after a sufficiently long DNS outage just
>> disappear and not come back after the outage without restarting ntp.
>> 
>> It would seem to me that ntp should only need to do a DNS lookup on
>> startup and from then on continue to use the address found.
>> 
>> But that is not how ntp works.
>> 
>> Anyway, the bottom line is that if the pool is your only source of time
>> and if there is a DNS failure for a sufficiently long time, you will
>> lilely not have any source of time afterwards.
>> 
>> As for the USB GPS I was testing, it is called a VK-162 G-Mouse
>> available from Amazon for $14, uses the Windows 10 native driver so it
>> works with Meinberg ntp, and keeps the time within single digit
>> milliseconds without any other servers.
>  
> Further testing shows the following:
>
> I took a machine and ran watch -p -n 10 ntpq -pn to monitor ntp status.
>
> I then pulled the network connection from the machine.
>
> After about 7 minutes the pool servers started to disappear.
>
> If the machine was reconnected to the network within about 15 minutes,
> the pool servers would reappear.
>
> If the machine was off the network for more than about 15 minutes, the
> pool servers do NOT reappear until ntp is restarted.
>

I suspect it is the number of times that ntpd tries to contact the
server and fails rather than the time that is important. You could try
putting the server offline and then online again (I use chrony so do not
remember if ntpd has that option).
>

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

Re: [ntp:questions] ntp pool servers disappear

[William Unruh]

On 2021-06-23, Jim Pennino  wrote:
> William Unruh  wrote:
>> On 2021-06-23, Jim Pennino  wrote:
>>> William Unruh  wrote:
>>>> On 2021-06-23, Jim Pennino  wrote:
>>>> ...
>>>>>
>>>>> As for the USB GPS I was testing, it is called a VK-162 G-Mouse
>>>>> available from Amazon for $14, uses the Windows 10 native driver so it
>>>>> works with Meinberg ntp, and keeps the time within single digit
>>>>> milliseconds without any other servers.
>>>> 
>>>> Looks like a nice cheap receiver-- no PPS I assume so that accuracy,
>>>> after correction for the NMEA delay is probably in the 10s of ms, not
>>>> their claimed microsecond. But certainly for most people ms is more than
>>>> enough accuracy.
>>>> 
>>>
>>> Correct, no PPS.
>>>
>>> From short term (day or so) testing looking at peerstats data:
>>>
>>> Samples: 3914
>>> Avg offset: -0.00190137
>>> Std dev:0.00921412
>> 
>> The problem is that that does not test the accuracy, just jitter. Ie,
>> the time could be off by a century, but it is repeatable, so ntp says
>> that the offset and standard deviation is small. 
>> You need to compare with another time source that is known to be more
>> accurate than yours. Typically nmea signals are delivered late and the
>> length of the signal is long delaying things still more, expecially if
>> you choose an nmea sentence which reports lots of information, not just
>> the time. 
>
> I didn't bother with the full story as I wanted to be brief unless
> someone had specific questions.
>
> A bit more detail:
>
> For testing purposes, ntp was configured to use my machine that has a
> real PPS GPS and about a half dozen public servers, most of them stratum 1.

OK, sounds good.

>
> I also enabled all the statistics files.
>
> Initial, i.e. an hour or so, testing was with standard linux utilities,
> i.e. ntpq, ntpstat, ntptime, for a sanity check and a tweek of the fudge
> value, which came out to 0.027.

That is fast. Hardly enough time to send the nmea sentence. But it must
be working faster than 9600Bd (serial port speeds). 

>
> After several days I ran a pile of sed/awk scripts to look at the
> statistics files and came to the conclusion that the absolute time error
> was always less than about 5 ms and typically around 1 ms, which for $14 I
> condider good enough.
>
> FYI I have tested a several other generic USB GPS pucks and found the
> jitter to be over an order of magnitude greater than this device with
> fudge times in the order of 0.500 and time errors in the several 10s
> of ms.

Yes, that is what I would expect. 
>
>>>
>>> ntpq typically shows offset and jitter at about 1 and the satellites in
>>> view are usually 14 or more with the puck in a window sill.
>> 
>> And that means that the processor in the gps receiver has to work harder
>> and delays the report of the NMEA even longer. Now of course you may not
>> care -- 100ms may be perfectly acceptable (It is far more accurate than
>> a wrist watch for example) and then my comments are entirely irrelevant.
>> If you want higher accuracy however, then they start to become relevant. 
>> Hook it up to the network and use some of the low stratum sources to get
>> the time. That should be accurate probably to better than a ms. That
>> will allow you to calibrate your gps delay and tell ntp to subtract the
>> persistant offset from the gps signal, and improve your accuracy. 
>> 
>> Again that is only important if you have some reason to care. Again, if
>> accuracy to the nearest second is good enough, ignore this.
>
> See above.
>
> I am assuming that the fudge time of 0.027 versus the typical generic GPS
> puck time of 0.500 means this thing is processing things much faster.
>
> FYI all this is done on a USB 2.0 interface.

Certainly if it used the usb channel at its full speed, that should be
fine. I always thought that gps ran at serial port speeds, but clearly
that is not true. 
>
>>>
>>> That is from a linux PC where there are more tools for testing things.
>>>
>>> The reason I bought it is that it is advertised to work with the Windows
>>> native USB driver, which produces a virtual com port, which makes it
>>> usable with Meinberg ntp without any other drivers or software.
>>>
>>> I have yet to do any Windows testing other than to verify it does work,
>>> but I see no reason why Windows would be much different.
>> 
>> Probably not. But again, testing it aga

Re: [ntp:questions] ntp pool servers disappear

[William Unruh]

On 2021-06-23, Jim Pennino  wrote:
> William Unruh  wrote:
>> On 2021-06-23, Jim Pennino  wrote:
>> ...
>>>
>>> As for the USB GPS I was testing, it is called a VK-162 G-Mouse
>>> available from Amazon for $14, uses the Windows 10 native driver so it
>>> works with Meinberg ntp, and keeps the time within single digit
>>> milliseconds without any other servers.
>> 
>> Looks like a nice cheap receiver-- no PPS I assume so that accuracy,
>> after correction for the NMEA delay is probably in the 10s of ms, not
>> their claimed microsecond. But certainly for most people ms is more than
>> enough accuracy.
>> 
>
> Correct, no PPS.
>
> From short term (day or so) testing looking at peerstats data:
>
> Samples: 3914
> Avg offset: -0.00190137
> Std dev:0.00921412

The problem is that that does not test the accuracy, just jitter. Ie,
the time could be off by a century, but it is repeatable, so ntp says
that the offset and standard deviation is small. 
You need to compare with another time source that is known to be more
accurate than yours. Typically nmea signals are delivered late and the
length of the signal is long delaying things still more, expecially if
you choose an nmea sentence which reports lots of information, not just
the time. 
>
> ntpq typically shows offset and jitter at about 1 and the satellites in
> view are usually 14 or more with the puck in a window sill.

And that means that the processor in the gps receiver has to work harder
and delays the report of the NMEA even longer. Now of course you may not
care -- 100ms may be perfectly acceptable (It is far more accurate than
a wrist watch for example) and then my comments are entirely irrelevant.
If you want higher accuracy however, then they start to become relevant. 
Hook it up to the network and use some of the low stratum sources to get
the time. That should be accurate probably to better than a ms. That
will allow you to calibrate your gps delay and tell ntp to subtract the
persistant offset from the gps signal, and improve your accuracy. 

Again that is only important if you have some reason to care. Again, if
accuracy to the nearest second is good enough, ignore this.

>
> That is from a linux PC where there are more tools for testing things.
>
> The reason I bought it is that it is advertised to work with the Windows
> native USB driver, which produces a virtual com port, which makes it
> usable with Meinberg ntp without any other drivers or software.
>
> I have yet to do any Windows testing other than to verify it does work,
> but I see no reason why Windows would be much different.

Probably not. But again, testing it against some good network ntp
sources should give you an idea of how well it is doing, if that is
important. 
Of course we all like our stuff to be better than others. My system,
using pps from a gps is probably goot to a few microseconds. Do I need a
few microsecond accuracy. No. Even ms accuracy would be way more than  I
need. But I like seeing how far I can push stuff. My only defence is
"its a hobby".

>
>

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

Re: [ntp:questions] ntp pool servers disappear

[William Unruh]

On 2021-06-23, Jim Pennino  wrote:
...
>
> As for the USB GPS I was testing, it is called a VK-162 G-Mouse
> available from Amazon for $14, uses the Windows 10 native driver so it
> works with Meinberg ntp, and keeps the time within single digit
> milliseconds without any other servers.

Looks like a nice cheap receiver-- no PPS I assume so that accuracy,
after correction for the NMEA delay is probably in the 10s of ms, not
their claimed microsecond. But certainly for most people ms is more than
enough accuracy.

>
>

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

Re: [ntp:questions] Score is low and not raising

[William Unruh]

On 2021-06-10, chris  wrote:
>
> Not familar with chrony, but why not go back to basics, run a stock
> ntpd, which works out of the box. Why make life difficult, when ntpd has 
> more than adequate precision for the task ?. Experiment with other
> solutions once the basics are known working and experience gained.

chrony IS the basics, just as ntpd is. I believe he is piling on
options, when he should just try things straightforardly. At present, he
is telling chrony to offset the GPS and the SHM ( which is another pps,
which interferes with the kernel pps) by 1/2 sec, and discovers that
things are out by 1/2 sec. 

>
>>
>>> file, as that can skew everything if misconfigured. Finally, check
>>> the polarity of the pps signal, as the ~500mS offset for several
>>> sources, (0.5 x 1sec), suggest pps input needs an inversion, but the
>>> ntp.conf file has a line to define that...
>>
>> It may be that he has chosen the wrong polarity, but I suspect he has
>> simply chosen the wrong options (the delay and offset options).
>>
>
> If the 1pps signal has a 50% m/s ratio, then the ~0.5second offset on
> the external sources is a glaring indicator of wrong polarity...

Yes, except most pps signals do not have a 50% ratio. More like a 10%
ratio. I do not know the UBlock gps unit so it could be weird, or maybe
he set up the UBLOCk to have a 50% ratio. Or maybe his "offset" commands
are confusing everything. 
>
>

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

Re: [ntp:questions] Score is low and not raising

[William Unruh]

On 2021-06-09, chris  wrote:
> On 06/09/21 22:00, ProGeek wrote:
>> On Wednesday, June 9, 2021 at 6:56:04 PM UTC+3, chris wrote:
>>> On 06/08/21 20:42, Andreas Mattheiss wrote:
 Hello,

 just as additional source of information: I have a similar setup here
 (ublox PPS into a proper serial port of a PC) and I see a stable offset of
 -3 ms to 3 servers on the net (-3 ms to any of them). I'm using ntpd
 though.

 Regards
 Andreas

>>> This is what I see at the ntp host here:
>>>
>>> chris@ntp-host:~ % ntpq -pn
>>> remote refid st t when poll reach delay offset jitter
>>> ==
>>> o127.127.22.0 .PPS. 0 l 1 8 377 0.000 0.000 0.001
>>> +192.9.200.168 .GPS. 1 u 10 64 377 0.193 0.001 0.054
>>> *192.9.200.169 .GPS. 1 u 7 64 377 0.354 0.008 0.046
>>>
>>> Using mini pc host with two network interfaces, internet and internal
>>> network facing. FreeBSD 12 with ttl pps into the serial port dcd line
>>> via a ttl to rs232 converter...
>>>
>>> Chris
>> this is what i see on sourcestats:
>>
>> 210 Number of sources = 7
>>   .- Number of sample points in measurement set.
>>  /.- Number of residual runs with same sign.
>> |/.- Length of measurement set (time).
>> |   |/  .- Est. clock freq error (ppm).
>> |   |   |  /   .- Est. error in freq.
>> |   |   | |   / .- Est. 
>> offset.
>> |   |   | |  |  |   On the -.
>> |   |   | |  |  |   samples. 
>> \
>> |   |   | |  |  |
>>  |
>> Name/IP AddressNP  NR  Span  Frequency  Freq Skew  Offset  Std 
>> Dev
>> ==
>> GPS0   12   6   176-29.089 42.914  -8857us  
>> 1790us
>> SHM1   12   7   178 +0.000  0.010   -530ms   
>> 435ns
>> PPS0   12   7   178 +0.001  0.011 +3ns   
>> 445ns
>> blackmamba-g0.eff.ro2   077 -0.005   2000.000   +501ms  
>> 4000ms
>> 188.213.49.35   9   6   184 -0.748 21.608   +492ms   
>> 721us
>> time.cloudflare.com 6   481 +1.162  9.574   +500ms
>> 72us
>> time.cloudflare.com14  11   168 +0.502  0.939   +500ms
>> 42us
>>
>> if i get the results from PPS0 the offset is low, but is still reported 
>> high. and also correspond with the external time servers.
>>
>> my settings are like this:
>>
>> # SHM(0), gpsd: NMEA data from shared memory provided by gpsd
>> refclock SHM 0 refid GPS0 poll 4 precision 1e-1 trust noselect offset 0.646
>>
>> # SHM(1), gpsd: PPS0 data from shared memory provided by gpsd
>> refclock SHM 1 refid SHM1 poll 4 precision 1e-3 lock GPS0 trust noselect 
>> offset 0.5300
>>
>> # PPS: /dev/pps0: Kernel-mode PPS ref-clock for the precise seconds
>> refclock PPS /dev/pps0 refid PPS0 poll 4 precision 1e-7 lock GPS0 trust 
>> prefer delay 0.50
>>
>> something is off but i can't pinpoint what
>
> Just using a standard ntpd here, as it's more than adequate for the 
> task, with minimum granularity in microseconds. Does look like there
> is something seriously wrong, as the gps is 8mS out, and should be
> fractions of a mS if working right.

No, it should not be. GPS is the NMEA sentences from the gps device. It
is usually delayed by from .1 to .3 sec. Ie, it keeps terrible time. 
It is the PPS that is spot on to the ns level.
>
> What I would try is to strip out all except the pps and gps sources
> and see what the offset looks like. Also, please post the ntpd.conf

He did post the sentences from the chrony.conf file ( the equivalent to
the ntpd.conf file) and they are weird. 

> file, as that can skew everything if misconfigured. Finally, check
> the polarity of the pps signal, as the ~500mS offset for several 
> sources, (0.5 x 1sec), suggest pps input needs an inversion, but the
> ntp.conf file has a line to define that...

It may be that he has chosen the wrong polarity, but I suspect he has
simply chosen the wrong options (the delay and offset options).


>

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

Re: [ntp:questions] Score is low and not raising

[William Unruh]

On 2021-06-09, ProGeek  wrote:
> On Wednesday, June 9, 2021 at 6:56:04 PM UTC+3, chris wrote:
>> On 06/08/21 20:42, Andreas Mattheiss wrote: 
>> > Hello, 
>> > 
>> > just as additional source of information: I have a similar setup here 
>> > (ublox PPS into a proper serial port of a PC) and I see a stable offset of 
>> > -3 ms to 3 servers on the net (-3 ms to any of them). I'm using ntpd 
>> > though. 
>> > 
>> > Regards 
>> > Andreas 
>> > 
>> This is what I see at the ntp host here: 
>> 
>> chris@ntp-host:~ % ntpq -pn 
>> remote refid st t when poll reach delay offset jitter 
>> == 
>> o127.127.22.0 .PPS. 0 l 1 8 377 0.000 0.000 0.001 
>> +192.9.200.168 .GPS. 1 u 10 64 377 0.193 0.001 0.054 
>> *192.9.200.169 .GPS. 1 u 7 64 377 0.354 0.008 0.046 
>> 
>> Using mini pc host with two network interfaces, internet and internal 
>> network facing. FreeBSD 12 with ttl pps into the serial port dcd line 
>> via a ttl to rs232 converter... 
>> 
>> Chris
> this is what i see on sourcestats:
>
> 210 Number of sources = 7
>  .- Number of sample points in measurement set.
> /.- Number of residual runs with same sign.
>|/.- Length of measurement set (time).
>|   |/  .- Est. clock freq error (ppm).
>|   |   |  /   .- Est. error in freq.
>|   |   | |   / .- Est. offset.
>|   |   | |  |  |   On the -.
>|   |   | |  |  |   samples. \
>|   |   | |  |  | |
> Name/IP AddressNP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
>==
> GPS0   12   6   176-29.089 42.914  -8857us  1790us
> SHM1   12   7   178 +0.000  0.010   -530ms   435ns
> PPS0   12   7   178 +0.001  0.011 +3ns   445ns
> blackmamba-g0.eff.ro2   077 -0.005   2000.000   +501ms  4000ms
> 188.213.49.35   9   6   184 -0.748 21.608   +492ms   721us
> time.cloudflare.com 6   481 +1.162  9.574   +500ms72us
> time.cloudflare.com14  11   168 +0.502  0.939   +500ms42us
>
> if i get the results from PPS0 the offset is low, but is still reported high. 
> and also correspond with the external time servers.

Sorry but that is nuts. 
Your external sources are 500ms ( 1/2 sec) off from the internal ones.
But that is probably because you told your system to screw up the
internal sources.

>
> my settings are like this:
>
> # SHM(0), gpsd: NMEA data from shared memory provided by gpsd
> refclock SHM 0 refid GPS0 poll 4 precision 1e-1 trust noselect offset 0.646

Why that offset? and why precision of 1e-1? 
>
> # SHM(1), gpsd: PPS0 data from shared memory provided by gpsd
> refclock SHM 1 refid SHM1 poll 4 precision 1e-3 lock GPS0 trust noselect 
> offset 0.5300

Why that offset?
Also, why are you having both gpsd and pps0 delivering data? It is the
same pps. And they fight each other-- when one interrupt is processing,
the other one is locked out. This makes the accuracy of pps  less than
it should be (by a factor of about 10)
Tell gpsd not to use the PPS. 

>
> # PPS: /dev/pps0: Kernel-mode PPS ref-clock for the precise seconds
> refclock PPS /dev/pps0 refid PPS0 poll 4 precision 1e-7 lock GPS0 trust 
> prefer delay 0.50

Why that delay?

HOw about getting rid of all of the offset and delay stuff on your
internal sources. 
>
> something is off but i can't pinpoint what

Sure is. 

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

Re: [ntp:questions] Score is low and not raising

[William Unruh]

On 2021-06-08, Roger  wrote:
> On Tue, 8 Jun 2021 08:30:31 -0700 (PDT), ProGeek
> wrote:
>
>>Hope that will make the score higher
>
> Excuse me for my rudeness but forget the bloody scores. You need
> to concentrate on having low offsets for months at a time. Look
> at these two servers which are both using GPS.
>
> https://www.pool.ntp.org/scores/212.159.133.83
> https://www.pool.ntp.org/scores/185.57.191.229
>
> Look at the left hand axes; 16 to -4 ms for the first, 0.2 to
> -0.6 ms for the second. Your graphs range from 2 to -2 seconds.
> Both servers are currently showing an offset of 500 ms. Useless
> to the pool at present. Once your offsets are good the scores
> will automatically be good.

Actually for GPS discipline, the offsets should be much better than 1ms.
It should be more like 1us, ie 1000 times better. Of course much of the
trouble could be due to connection problems between the machine and
Newark NJ which is trying to measure the offset (but even then 1ms seems
like a lot). 

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

Re: [ntp:questions] Score is low and not raising

[William Unruh]

As I said, at a minimum run a test in which you have at least one
network pool source to compare your system with some independent outside
system. Why demand that pool people do it for you? Since you want to be
on the pool you must have network connectivity.

On 2021-06-08, ProGeek  wrote:
> ok,
> fixed.
>
> now stats looks like this:
>
>
> Name/IP AddressNP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
>==
> GPS06   382+16.101190.363-80ms  1527us
> SHM17   494 +0.000  0.020   -740ms   239ns
> PPS07   494 +0.000  0.020 +0ns   239ns
>
> MS Name/IP address Stratum Poll Reach LastRx Last sample
>===
> #? GPS0  0   4   37710-80ms[  -80ms] +/-  
> 100ms
> #- SHM1  0   4   37711   -740ms[ -740ms] +/- 
> 1000us
> #* PPS0  0   4   37711   +264ns[ +922ns] +/-  
> 208ns
>
> Hope that will make the score higher
>
>
> On Tuesday, June 8, 2021 at 11:23:09 AM UTC+3, William Unruh wrote:
>> On 2021-06-08, ProGeek  wrote: 
>> > hello, 
>> > 
>> > I am using Chrony as a server. 
>> > 
>> > i manage to lower the offset to 97ms hope is OK like this...or i will try 
>> > new settings 
>> > 
>> > now chrony stats reports are like this: 
>> > 
>> > MS Name/IP address Stratum Poll Reach LastRx Last sample 
>> >===
>> > 
>> > #* GPS0 0 3 377 5 -1167us[-2018us] +/- 98ms 
>> > #x PPM1 0 3 377 4 -406ms[ -406ms] +/- 2497us 
>> > #? PPS0 0 3 0 - +0ns[ +0ns] +/- 0ns
>> Well, pps is not working at all. I have no idea what PPM1 is, and your 
>> system is using GPS0 as its source, which is not a good idea, since it 
>> will be out by many may ms. If you got pps to work, it should have an 
>> accuracy or a few micro seconds, not many ms. (GPS is the NMEA sentences 
>> which are always delayed by about over 100ms.) 
>> 
>> So, figure out why pps is not working, and fix that. In the meantime 
>> without your system actually set up properly in itself, you should not 
>> be going onto the pool and leading others astray.
>> > 
>> > On Tuesday, June 8, 2021 at 10:49:53 AM UTC+3, William Unruh wrote: 
>> >> You give no details at all so it is hard to figure out what you are 
>> >> doing never mind what is wrong. It seems you have a 500 ms (1/2 second) 
>> >> offset, which really is pretty terrible. Wrong edge on the interrupt? 
>> >> ( and at the end it inexplicably drops to 100ms, which is still pretty 
>> >> terrible but better-- what changed) 
>> >> 
>> >> Hook you Pis up to the network, and compare your PPS yourself to some 
>> >> pool server. That way you can debug yourself instead of others doing it 
>> >> for you. 
>> >> On 2021-06-08, ProGeek  wrote: 
>> >> > Hello, 
>> >> > i have 2 IPv6 servers made publicly some days ago. 
>> >> > Servers are build around Raspberry PI and U-blox GPS modules, using PPS 
>> >> > and GPIO. 
>> >> > The problem is that i try to make the servers available in pool, but i 
>> >> > get constant -20 on rating. 
>> >> > 
>> >> > Any idea how can i improve the score? 
>> >> > 
>> >> > https://www.ntppool.org/scores/2a02:2f04:a0e:9199:99::2 
>> >> > 
>> >> > https://www.ntppool.org/scores/2a02:2f04:a0e:9199:99::2

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

Re: [ntp:questions] Score is low and not raising

[William Unruh]

On 2021-06-08, ProGeek  wrote:
> hello,
>
> I am using Chrony as a server.
>
> i manage to lower the offset to 97ms hope is OK like this...or i will try new 
> settings
>
> now chrony stats reports are like this:
>
> MS Name/IP address Stratum Poll Reach LastRx Last sample
>===
> #* GPS0  0   3   377 5  -1167us[-2018us] +/-   
> 98ms
> #x PPM1  0   3   377 4   -406ms[ -406ms] +/- 
> 2497us
> #? PPS0  0   3 0 - +0ns[   +0ns] +/-
> 0ns

Well, pps is not working at all. I have no idea what PPM1 is, and your
system is using GPS0 as its source, which is not a good idea, since it
will be out by many may ms. If you got pps to work, it should have an
accuracy or a few micro seconds, not many ms. (GPS is the NMEA sentences
which are always delayed by about over 100ms.)

So, figure out why pps is not working, and fix that. In the meantime
without your system actually set up properly in itself, you should not
be going onto the pool and leading others astray. 

>
> On Tuesday, June 8, 2021 at 10:49:53 AM UTC+3, William Unruh wrote:
>> You give no details at all so it is hard to figure out what you are 
>> doing never mind what is wrong. It seems you have a 500 ms (1/2 second) 
>> offset, which really is pretty terrible. Wrong edge on the interrupt? 
>> ( and at the end it inexplicably drops to 100ms, which is still pretty 
>> terrible but better-- what changed) 
>> 
>> Hook you Pis up to the network, and compare your PPS yourself to some 
>> pool server. That way you can debug yourself instead of others doing it 
>> for you.
>> On 2021-06-08, ProGeek  wrote: 
>> > Hello, 
>> > i have 2 IPv6 servers made publicly some days ago. 
>> > Servers are build around Raspberry PI and U-blox GPS modules, using PPS 
>> > and GPIO. 
>> > The problem is that i try to make the servers available in pool, but i get 
>> > constant -20 on rating. 
>> > 
>> > Any idea how can i improve the score? 
>> > 
>> > https://www.ntppool.org/scores/2a02:2f04:a0e:9199:99::2 
>> > 
>> > https://www.ntppool.org/scores/2a02:2f04:a0e:9199:99::2

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

Re: [ntp:questions] Score is low and not raising

[William Unruh]

You give no details at all so it is hard to figure out what you are
doing never mind what is wrong. It seems you have a 500 ms (1/2 second)
offset, which really is pretty terrible. Wrong edge on the interrupt? 
( and at the end it inexplicably drops to 100ms, which is still pretty
terrible but better-- what changed) 

Hook you Pis up to the network, and compare your PPS yourself to some
pool server. That way you can debug yourself instead of others doing it
for you. 


On 2021-06-08, ProGeek  wrote:
> Hello,
> i have 2 IPv6 servers made publicly some days ago.
> Servers are build around Raspberry PI and U-blox GPS modules, using PPS and 
> GPIO.
> The problem is that i try to make the servers available in pool, but i get 
> constant -20 on rating.
>
> Any idea how can i improve the score?
>  
> https://www.ntppool.org/scores/2a02:2f04:a0e:9199:99::2
>
> https://www.ntppool.org/scores/2a02:2f04:a0e:9199:99::2

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

Re: [ntp:questions] Wrong Brazilian time with 2.android.pool.ntp.org (Summertime)

[William Unruh]

This has nothing to do with summer time. ntp delivers UTC. That is it.
It has no idea of what summer time, winter time, time zones are nor does
it care. It delivers UTC time. All of the interpretation of the time
into things like timezones, summer time, etc are done locally by your
computer and your operating system. Many use a set of files called
timezone files (tzdata) to look up what the relation  between time at
your location and UTC is. When politicians decide to change those
relations, (eg by abolishing summer time) new tzdata files are issued
which need to be installed on your system. You do not tell us what your
operating system is etc. Note tht some operating systems leave it up to
you to insititute changes (like your wrist watch which you have to keep
resetting when timezones/summer times/... change)

So your problem has nothing to do with NTP. It is a problem within
the device itself. 


On 2020-11-18, Arthur Jahnke Hoch  wrote:
> Hello!
>
> I have many devices with NTP getting a wrong time to Brazil, in Brazil does 
> not exist summertime anymore to (Brasília - Brazil -2), but NTP server  its 
> returning -2 instead of -3.
>
> NTP servers that I use:
>
> 2.android.pool.ntp.org
> south-america.pool.ntp.org
> north-america.pool.ntp.org
> pool.ntp.org
> ntp.api.bz
> ntp.nict.jp
> ntp.sjtu.edu.cn
> 0.asia.pool.ntp.org
> 0.pool.ntp.org
> 0.us.pool.ntp.org
> 1.cn.pool.ntp.org
> 1.us.pool.ntp.org
> 2.asia.pool.ntp.org
> 2.us.pool.ntp.org
> asia.pool.ntp.org
> cn.pool.ntp.org
> europe.pool.ntp.org
> south-america.pool.ntp.org
> north-america.pool.ntp.org
> s2m.time.edu.cn
> time.izatcloud.net
> time-a.nist.gov
>
> What can I do for solve this issue?
>
>
>
>

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

Re: [ntp:questions] How is the BIG guys (Google. FB etc) DNS and NTP architecture

[William Unruh]

On 2020-10-21, Miroslav Lichvar  wrote:
> On 2020-10-21, William Unruh  wrote:
>> On 2020-10-21, CRasch Net  wrote:
>>> Facebook is now using Chrony, you can read about their implementation:
>>>
>>> Building a more accurate time service at Facebook scale
>>> https://engineering.fb.com/production-engineering/ntp-service/
>>
>> Interesting. While I agree that chrony is more precise, I think that
>> their results for ntpd are worse than they should  be. ntpd can
>> certainly do better than 1ms scatter/accuracy (and chrony can do better
>> than 100us.There is something weird about their network paths.) About 10
>> years I ran a number of tests of chrony vs ntpd. and got about a fctor
>> of 3-10 better, not 100. Interrupt latency/clock reading for chrony gave
>> about 1us fluctuations.
>
> It's not clear how ntpd and chrony were configured in their tests. The
> ntpq/chronyc outputs show a poll of 6, which is too long for a highly
> stable synchronization in a local network. If they were using the
> default minpoll 6 and maxpoll 10, a factor of 100 would not surprise me.
> ntpd doesn't adjusts its polling very well when it has stable
> measurements, so it would be effectively comparing ntpd polling at 10 vs
> chrony polling at 6.
>
>> I find this whole thing about leap second smoothing to be a real farce.
>> Just let the step occur instead of delivering the wrong time for hours.
>> Or if you want, run your clocks on TIA not UTC and make the leapsecond
>> conversion in the interpretation as is done for timezones. Would anyone
>> advise leap day smoothing every 4 years so that we do not have trouble
>> with our calenders?
>
> Well, yes. The trouble is that there are applications that break on
> backward step, they need synchronized clocks, and not all NTP clients
> can be configured to make a consistent slew on the leap second. So, the
> easiest way to fix this is to make a slew on the server and hide the
> leap second from the clients. When you internally do this everywhere and
> you want to provide a public NTP service, it's easier to just serve your
> internal leap-smeared time.

Easier. It is probably even easier to forget about ntp and just free run
your server. "Easy" is not the purpose of serving ntp time. 
>

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

Re: [ntp:questions] How is the BIG guys (Google. FB etc) DNS and NTP architecture

[William Unruh]

On 2020-10-21, CRasch Net  wrote:
> Facebook is now using Chrony, you can read about their implementation:
>
> Building a more accurate time service at Facebook scale
> https://engineering.fb.com/production-engineering/ntp-service/

Interesting. While I agree that chrony is more precise, I think that
their results for ntpd are worse than they should  be. ntpd can
certainly do better than 1ms scatter/accuracy (and chrony can do better
than 100us.There is something weird about their network paths.) About 10
years I ran a number of tests of chrony vs ntpd. and got about a fctor
of 3-10 better, not 100. Interrupt latency/clock reading for chrony gave
about 1us fluctuations.

I find this whole thing about leap second smoothing to be a real farce.
Just let the step occur instead of delivering the wrong time for hours.
Or if you want, run your clocks on TIA not UTC and make the leapsecond
conversion in the interpretation as is done for timezones. Would anyone
advise leap day smoothing every 4 years so that we do not have trouble
with our calenders?

___
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

[William Unruh]

On 2020-10-07, Andreas Mattheiss  wrote:
> Hello,
>
> I wonder what's a realistic ballpark for the jitter I can expect when
> feeding a GPS PPS into ntpd?

around a microsecond or less. 
>
> 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

Not really needed since almost all serial cards will handle TTL level
with not problem. 

> at the same time for daily work, so no designated ntp server. The GPS

You need to set the seconds somehow. Are you doing that via nmea from
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.

It sounds to me like you are running from the wrong edge of the signal.
Is your level shifter also and inverter? 
>
> What do you think, is my 10 micro jitter within experience? While I am
No.  I get using chronyd   (report from chronyc)
sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
#* PPS0  0   4   37724  +2035ns[+2458ns] +/-  776ns

sourcestats
Name/IP AddressNP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
PPS0   24  11   367 +0.000  0.016 +1ns  1972ns

Of course chrony has long been know to give much better control of the
clock than does ntpd


> 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
>
> Pretty much what I get.
>
> Thanks, regards
> Andreas
>
>

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

Re: [ntp:questions] Local Time NTP Server

[William Unruh]

On 2020-09-15, David Taylor  wrote:
> On 14/09/2020 13:45, Rob van der Putten wrote:
>> Hi there
>> 
>> 
>> On 24/08/2020 16:07, William Unruh wrote:
>> 
>> 
>> 
>>> It was renamed because UTC has nothing to do with Greenwich. For
>>> historical reasons, the time at Greenwich is the same as UTC.
>> 
>> They are not perfectly identical. The difference is however less then 
>> one second;
>> GMT is mean solar time.
>> UTC is TAI (atomic time) + leap seconds.
>> 
>> 
>> 
>> 
>> Regards,
>> Rob
>
> Whilst this may be true, in practice people use GMT when they mean UTC.
>
> BTW: GMT is mean solar time /at Greenwich/.
>
> What annoys me is when Raspberry Shake and others refer to "UTC time"!

Why? Repetition? Is PST time also annoying?
Universal Time Coordinate time is not really repetitious anyway, since
the noun is Coordinate. And UTC time means the type of time defined by
UTC-- since there are lots of other types of time one could use--
including decimal time ( 100 sec/min/ 100min/hr, 10hr/day)
>

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

Re: [ntp:questions] Local Time NTP Server

[William Unruh]

On 2020-08-24, Jakob Bohm  wrote:
> On 2020-08-24 16:07, William Unruh wrote:
>> On 2020-08-24, Jakob Bohm  wrote:
>>> On 2020-08-24 12:51, Beth Connell wrote:
>>>> Hi,
>>>> I'm struggling to find any information on where the free NTP servers are 
>>>> geographically based. In particular, I'm wondering where Facebook, Google, 
>>>> Microsoft, etc are based within the UK. Just for curiousity, I'm wondering 
>>>> how this affects any interference to my location.
>>>>
>>>> Thanks
>>>>
>>>
>>> All NTP time is GMT (now named UTC, after HM government dropped the
>>> ball).  The only geographic factor is the "ping time" to the time
>>> server, the servers that are the most distant (longest ping) are the
>>> GPS and Galileo satellites, that are hundreds or thousands of km from
>>> the receiver, and use their own (non-NTP) protocols to correct for the
>>> delay.
>> 
>> It was renamed because UTC has nothing to do with Greenwich. For
>> historical reasons, the time at Greenwich is the same as UTC.
>> (Note that the prime meridian now runs through a garbage can in a park
>> just south of the Thames rive in London and not along the line marked
>> on the ground in Greenwich. No idea why you believe the govt dropped the
>> ball. Because the location of Greenwich moves (plate techtonics) it
>> would introduce inaccuracies into the definition of time if it were tied
>> to Greenwich. Also, you cannot ping the sattelites.
>
> I used "ping time" as the popular name of the round trip time (as 
> actually measured by NTP implementations), and thus as a somewhat
> vague reference to the equivalant satellite-to-ground time delay.
>
> As for the reference to HM Government, there was a rumor, many years 
> ago, that the budgets cuts caused the relevant time management job to 
> revert to the IERS in Paris, thus loosing Britain the honor of having 
> the time standard refer to the British victory at the Meridian
> conference.

Is Britain really so bereft of self confidence and feelings of self
worth that they have to hang onto symbols of their past (over 100 year
old) glories? Time is universal, owned by the world.
>
> If the Greenwich observatory had still been in full operation, the
> scientists running it would probably have applied the necessary
> corrections for the ground shifting under their instruments,

You simply cannot have a standard which drifts around. You need it to be
fixed, eg to the stars. 
> rather than having the hole place demolished in favor of a symbolic
> line on the ground.  They would also probably have become the time
> setting command center for the Galileo satellites that replaced their
> daily dropping of an actual ball to signal exact meridian noon to
> ships setting their navigation chronometers.

Again, that daily dropping went outi (as a useful device)  almost a hundred 
years ago, once
radio was invented. (In Canada CBC still broadcasts "At the beginning of
the long dash, the time is exactly 10 oclock Pacific Daylight time"-- I,
just 37 min ago, heard it. I assume BBC has the equivalent.)
That  was a lot more accurate than the one second at best reaction time
to the ball dropping. And even GPS with the 10m fuzzing was over a
million times more accurate. And its lattitude is probably a million
times more accurate than chronometric lattitude. Is there anyone on a
ship these days that still knows how to use a sextant?

>
>
>
>>>
>>> Another problem is if the NTP server is one of those that deliberately
>>> return slightly wrong time before and after each leap second to "smooth
>>> out" the leap, some of the companies you mention reportedly do that.

I agree that that "solution" is pretty horrible.

>>>
>>>
>>> Enjoy
>>>
>>> Jakob
>
>
> Enjoy
>
> Jakob

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

Re: [ntp:questions] Local Time NTP Server

[William Unruh]

On 2020-08-24, Jakob Bohm  wrote:
> On 2020-08-24 12:51, Beth Connell wrote:
>> Hi,
>> I'm struggling to find any information on where the free NTP servers are 
>> geographically based. In particular, I'm wondering where Facebook, Google, 
>> Microsoft, etc are based within the UK. Just for curiousity, I'm wondering 
>> how this affects any interference to my location.
>> 
>> Thanks
>> 
>
> All NTP time is GMT (now named UTC, after HM government dropped the
> ball).  The only geographic factor is the "ping time" to the time
> server, the servers that are the most distant (longest ping) are the
> GPS and Galileo satellites, that are hundreds or thousands of km from
> the receiver, and use their own (non-NTP) protocols to correct for the
> delay.

It was renamed because UTC has nothing to do with Greenwich. For
historical reasons, the time at Greenwich is the same as UTC. 
(Note that the prime meridian now runs through a garbage can in a park
just south of the Thames rive in London and not along the line marked
on the ground in Greenwich. No idea why you believe the govt dropped the
ball. Because the location of Greenwich moves (plate techtonics) it
would introduce inaccuracies into the definition of time if it were tied
to Greenwich. Also, you cannot ping the sattelites. 
>
> Another problem is if the NTP server is one of those that deliberately
> return slightly wrong time before and after each leap second to "smooth
> out" the leap, some of the companies you mention reportedly do that.
>
>
> Enjoy
>
> Jakob

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

Re: [ntp:questions] Local Time NTP Server

[William Unruh]

On 2020-08-24, Beth Connell  wrote:
> Hi, 
> I'm struggling to find any information on where the free NTP servers are 
> geographically based. In particular, I'm wondering where Facebook, Google, 
> Microsoft, etc are based within the UK. Just for curiousity, I'm wondering 
> how this affects any interference to my location. 
All are based all over the place. 
No idea what "interference" you are talking about, but I cannot think of
any definition of that word which would make your last sentance make
sense especially with respect to ntp.
iPerhaps if you told us what you are seeing as a problem with your ntp
use, and then people could perhaps suggest ways of solving that problem.


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

Re: [ntp:questions] create charts

[William Unruh]

On 2020-08-23, Uwe Klein  wrote:
>
> Anybody else getting "request received" from TheFork
> and a bunch of "undeliverable" from uscc.net
>
> for each posting to comp.protocols.time.ntp ?

Nope, not here.

Not sure what you mean by "getting". emails? error messages? Popups?
I use slrn, and am seeing none of those messages.


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

Re: [ntp:questions] create charts

[William Unruh]

On 2020-08-21, David Woolley  wrote:
> On 21/08/2020 11:39, thimoo...@gmail.com wrote:
>> I have a question. how do you make a graph of your ntp server and is that 
>> possible
>
> What parameter do you want to represent?  Remember that the actual error 
> from true time is never known, because, if it could be known, it could 
> be made to be zero.

He of course has not told us what he wants to graph, or what his problem
is in trying to do so. He cannot "make a graph of your server", since
about the only thing accessible to him is time reported by the server
Without some other time standard (gpstime, his own computer, some other 
server,etc) there is
nothing to plot.

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

Re: [ntp:questions] Performance estimation

[William Unruh]

On 2020-06-16, David Taylor  wrote:
> On 16/06/2020 17:11, William Unruh wrote:
> []
>> 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)
>
> I quick it more a question of variance rather than the absolute time, 
> but I agree with your comment.  Again, with only microsecond reporting 
> and today's processors it's difficult to measure.
>
> To the latter, cable length, well under 5 nanoseconds!

Unless the cables are properly terminated at boththe gps receiver and
the computer, this is probably not true. (the velocity of light may be
under 5ns (ie less than 5 feet between the receiver and the computer)
but the capacitive charging of the cable, etc if not properly terminated
would produce a pulse with a rise time of much longer than that.
Note that it is NOT the antenna that I am refering to, but the cable
connecting the gps pps to the computer and the capacitance in the
receiver in the computer and transmitter in the gps. 
. 

Note that the interrupt latency can be very variable, depending on what
else is happening in the computer. I do not know if on the RPi the
interrupt is processed via interrupt, or via some busy loop to find the
edge of the signal. Since one hardly wants to make the RPI spend all of
its processing reading the input, this will also introduce a grainyness
to the received time. 


>
>  
> https://store.uputronics.com/index.php?route=product/product=64_id=84
>

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

Re: [ntp:questions] Performance estimation

[William Unruh]

On 2020-06-16, David Taylor  wrote:
> On 15/06/2020 19:00, David Woolley wrote:
> []
>> What is the clock resolution?  If you try and measure jitters that 
>> aren't several times the resolution, they are not going to be 
>> particularly valid.
>> 
>> If the hardware clock is almost dead on, and the peak to peak dither is 
>> just less than the resolution, there will be long periods in which it 
>> will read as as zero, even though it is actually close to one resolution 
>> unit.  You could also get cases where dither was very low but read as 
>> one resolution unit for long periods.  In fact, if it was possible to 
>> find tune the actual clock oscillator, during an ideal lock you would 
>> have peak to peak dither, as measured, of one or two resolution units, 
>> even though the actual phase noise was much less.
>> 
>> (Arguably, a jitter that is less than the clock resolution will result 
>> in worse time accuracy than one that a few times it, as the clock 
>> resolution will not be dithered out.
>> 
>> That makes the, normally unrealistic, assumption that the systematic 
>> error is less than the clock resolution.)
>
> 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"!
>
> 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.

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)

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

Re: [ntp:questions] Performance estimation

[William Unruh]

On 2020-06-15, David Woolley  wrote:
> On 15/06/2020 15:38, David Taylor wrote:
>>>
>>> https://www.eecis.udel.edu/~mills/ntp/html/cluster.html
>
> What is the clock resolution?  If you try and measure jitters that 
> aren't several times the resolution, they are not going to be 
> particularly valid.
>
> If the hardware clock is almost dead on, and the peak to peak dither is 
> just less than the resolution, there will be long periods in which it 
> will read as as zero, even though it is actually close to one resolution 
> unit.  You could also get cases where dither was very low but read as 
> one resolution unit for long periods.  In fact, if it was possible to 
> find tune the actual clock oscillator, during an ideal lock you would 
> have peak to peak dither, as measured, of one or two resolution units, 
> even though the actual phase noise was much less.

>From his graphs this sure seems to be what is going on. The changes in
the clock seem to all have 1/2 us resolution, while the clock seems to
have 1us resolution.

>
> (Arguably, a jitter that is less than the clock resolution will result 
> in worse time accuracy than one that a few times it, as the clock 
> resolution will not be dithered out.
>
> That makes the, normally unrealistic, assumption that the systematic 
> error is less than the clock resolution.)

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

Re: [ntp:questions] Performance estimation

[William Unruh]

On 2020-06-15, David Taylor  wrote:
> On 15/06/2020 08:33, Miroslav Lichvar wrote:
>> On 2020-06-14, David Taylor  wrote:
>>> When using the ntpq -crv command, which is the better measure of system
>>> performance - clk_jitter or sys_jitter?  I've look for the definitions
>>> and I'm thinking sys_jitter but perhaps someone could please remind me
>>> of the difference?
>> 
>> clk_jitter seems to be the jitter of the system clock as it is being
>> updated with offsets, and sys_jitter seems to be the jitter of the
>> selected peer, or the combined peers after clustering.
>> 
>> https://www.eecis.udel.edu/~mills/ntp/html/cluster.html
>
>==
>
> [Been trying to send through e-mail to ntp-questions, but anything I 
> send gets rejected!]
>
> Thanks, Miroslav.  Right!  I'm not sure which I should be measuring so I
> plotted both:
>
>https://www.satsignal.eu/mrtg/performance_ntp_jitter.php
>
> Blue is system jitter, green is clock jitter.
>
> The lightly-loaded Raspberry Pi cards are all showing low numbers of 
> jitter, and it would be really useful to get that in more than three 
> decimal places of milliseconds.

Why would it be useful? What are you trying to do. It is always better
to first present the problem rather than trying to get people to improve
your solution to an unknown problem.

>

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

Re: [ntp:questions] List rejection!

[William Unruh]

On 2020-06-15, David Taylor  wrote:
> On 15/06/2020 14:50, William Unruh wrote:
>> On 2020-06-15, David Taylor  wrote:
>>> Once again, I tried to reply on the e-mail link but the message was
>>> rejected,  Could the mailing list admin please set it so that:
>> 
>> No idea what you wanted to do. If you wanted to reply to the poster's
>> email, they may--like you -- have an invalid email. Also your email is
>> not either of the two below-- yours ends in .invalid.
>> 
>>>
>>> david-tay...@blueyonder.co.uk
>>> gm8...@yahoo.co.uk
>>>
>>> are allowed through, please.  This hindrance to communication is most
>>> tirecome!
>> Allowed through where?
>
> Through the e-mail interface, not the NNTP.

And why would you think that posting it to the newsgroup would get the
people in charge of the email list?
Do you mean one of the mailing lists listed on
https://lists.ntp.org/listinfo? Which one?
There it says 
If you are having trouble using the lists, please contact mail...@lists.ntp.org.
Have you tried that? 
>

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

Re: [ntp:questions] List rejection!

[William Unruh]

On 2020-06-15, David Taylor  wrote:
> Once again, I tried to reply on the e-mail link but the message was 
> rejected,  Could the mailing list admin please set it so that:

No idea what you wanted to do. If you wanted to reply to the poster's
email, they may--like you -- have an invalid email. Also your email is
not either of the two below-- yours ends in .invalid.

>
>david-tay...@blueyonder.co.uk
>gm8...@yahoo.co.uk
>
> are allowed through, please.  This hindrance to communication is most 
> tirecome!
Allowed through where?

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

Re: [ntp:questions] ntpd - gpsd communication

[William Unruh]

On 2020-06-05, a...@avtodoria.ru  wrote:
>> This sounds more like bit errors in serial reception.
>> ( i.e errors coming up in all magnitudes.)
>
>> That is reception via NMEA?
>> do you check the NMEA checksum ( Portion after * afair)?
>
> Thank you for response. Yes, that is reception via NMEA. No i didn't check 
> checksum, i think gpsd should check it, am i wrong?
>
> I just write to log data from SHM when it's all OK. And try to use this 
> correct log after some time to make ntpd change the time. If you think i do 
> something not correct please tell me, i'll try to do something else
>

You are tracking the wrong problem. The problem is NOT ntpd. The problem
is the time you are getting from gps/gpsd/shm. That is where you should
be looking, not ntpd. ntd has been used for about 40 years now. It
works. Similarly gpsd. Your boss is telling you to fix something that is
not broken, wasting whatever salary they are paying you. Do they really
have solittle for you to do that is useful?
You have not told us what operating system you are using. Or anything
about your systems, except some are old (3mo?, 3yr? 10 yr? 30 yr?)



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

Re: [ntp:questions] ntpd - gpsd communication

[William Unruh]

On 2020-06-04, 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)

What is the wrong data? Ie, how much of an offset does the wrong data
imply? 
What does wrong data mean? Do you mean that the PPS is wrong? that of
course has no time attached so can be wrong by only up to 1 second.
Or do you mean that the time reported by the NMEA sentences is wrong?
How wrong? 1 sec? 100 days?
 
>
> 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

Note that if it really is your GPS that is misbehaving, why not just buy
another board. They are cheap. The Adafruit gps is only about $50.
Your tearing out your hair is probably worth more than that.

>
> Thank you in advance

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

Re: [ntp:questions] symmetricom tp1100 stratum and leap indicator behavior

[William Unruh]

On 2019-07-31, Andrew Harrison  wrote:
> The backstory...  I've been tasked with deploying a pair of Symmetricom 
> TP1100 Time Providers with GPS antennae as the official time source for the 
> company (replacing an ancient server with a Meinberg card in it).  My company 
> actually purchased the Symmetricoms a few years ago, but they never got 
> around to putting them in production.  No one was able or willing to put in 
> the time to get them going.  I started working at the company recently and 
> they gave the project to me.
>
> I've got them up and running and my test ntp client (my Linux workstation 
> running ntp 4.2.8p12) can pull time from them just fine.
>
> Now for the hard part.  What we want to happen is that if the GPS of the 
> primary Symmetricom goes offline, we want the clients to start getting time 
> from the backup unit.
>
> Ideally what would happen is the GPS goes offline, the Symmetricom would set 
> itself to a higher stratum level and the clients abandon it for the device 
> that has the better stratum, but this is not what happens.

I think that the problem is that if ntpd gets invalid packets, it simply
ignores them (as it should because missing a few packets is standard
behaviour) It simply free runs on the last good packets to come in,
since it has nothing else to go by. Apparently it is not actually using
the second device while the first is working ( and besides, it would
have a hard time deciding which was good and which not).

Have you tried using both of the symmetricons as sources always. Then
there is a change that if one goes offline, the other one will
automatically get picked as the source?

Or perhaps you could query the machines, or the symmetricons, to see if
they have gone nuts (invalid stratum) and then have that program do the
substituting for you (by sending ntpd a change of source)? Ie, you have
a second program being the scount to see whether the data coming in is
OK.
>
> I had to use Wireshark to see that instead, when the GPS goes offline, the 
> Symmetricom stops advertising a stratum level (Wireshark shows "unspecified 
> or invalid") while the leap indicator shows "clock unsynchronized" (3 I think 
> it was).  (When I enable the GPS again, Wireshark shows the stratum level 
> coming through as 1 and leap indicator shows 0 "no warning".)
>
> On my workstation test client, ntp apparently doesn't know what to do when a 
> time source stops indicating its stratum level so it keeps right on showing 
> stratum 1 in ntpq output even though Wireshark clearly shows the packets 
> coming through with stratum level "unspecified or invalid".
>
> So, my question is, can I configure ntp in such a way that it responds to 
> either a lack of advertised stratum or a leap warning indicator greater than 
> 0?
>
>
> Thanks!
>
>

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

Re: [ntp:questions] Time server question

[William Unruh]

On 2019-07-24, Jakob Bohm  wrote:
> On 24/07/2019 08:07, William Unruh wrote:
>> On 2019-07-24, Jakob Bohm  wrote:
...
>>>> A good timing-optimized gps unit, like the original Oncore, have a sw
>>>> mechanism to offset the PPS event away from the actual top of the
>>>> second, as well as a way for the sw protocol that numbers the PPS
>>>> signals to also specify how far away this particular pulse is from the
>>>> actual event.
>>>>
>>>> I.e. with an internal 10 MHz clock, PPS signals will be synced to one of
>>>> those 100 ns-wide periods, so it can/will be at least up to +/-50 ns
>>>> away from the proper moment, but when the driver knows about this, it
>>>> can adjust perfectly for that effect.
>>>>
>>>> Terje
>>>>
>>>
>>> I happen to have a GPS unit (not yet connected) that is documented to do
>>> this too: The PPS pulse occurs at an edge of the internal crystal clock,
>>> but a special NMEA statement states (based on the 4D GPS solution) how
>>> many ns it is off for each pulse.  I have yet to find the point to pass
>>> this offset to ntpd after capturing the PPS arrival time.
>> 
>> The problem is this is largely irrelevant. The time it takes the
>> computer to respond to an interrupt id far far larger (and variable)
>> than that offset of the pulse which is on the at most 10s of nsec scale.
>> The computer responds on the usec scale (que the interrupt, the comp
>> responds to the que and loads or branches to the interrupt service
>> routine. The routine reads the system clock. All that takes time and a
>> variable amount of time. Ie, you need specialised hardware to make use
>> of that information, and, I thought, usually that infomation was
>> delivered by the gps unit a lond time after the pulse itself. Ie, it is
>> useful for rewriting history, not for the immediate time.
>> 
>> 
>
> The hardware under consideration can time the pulse arrivals more
> precisely than the interrupt delivery time, thanks to special hardware.

Does that hardware read the local clock of the computer, or its own
internal clock, which then means you have to also figure out what the
relation is between that hardware clock and the system time. 
It also means that you have to be careful of termination resistances in
the lines from the gps to that hardware and drive power from the clock. 
Remember the "faster than light" neutrinos, which cam down to a bad
fibre optics connection from the gps to the underground detector, making
the underground clock sightly late, making it look like neutrinos got
there faster than than they did.

The application of the corrections  should all get handled in an 
ntp driver for the gps unit, which can
apply the corrections and deliver the corrected readings to ntpd. ntpd
has about 50 different refclock drivers and one might well cover your
case. Otherwise one might need to be written.


>
> Once that has been set up (in the future), the next problem becomes
> applying the higher precision offset to the time source data input to
> the ntp algorithms.
>
> At a higher abstraction level this means telling ntp that "at
> hhmmss.x (local clock), a time stamp of hhmmss.y
> arrived from this hardware time source".

OK, that should work. The main problem is that usually that correction
comes long (seconds) after the actual pulse itself as I understand. 

>
>
>
> Enjoy
>
> Jakob

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

Re: [ntp:questions] Time server question

[William Unruh]

On 2019-07-24, Jakob Bohm  wrote:
> On 21/07/2019 16:02, Terje Mathisen wrote:
>> William Unruh wrote:
>>> On 2019-07-19, Chris  wrote:
>>>> On 07/18/19 11:13, William Unruh wrote:
>>>>
>>>>>
>>>>> Sure, but I do not have faith in the "averaging" If one is always 30us
>>>>> after the other, then the average will always be out by 15us.
>>>>
>>>> One would expect a difference, but how can you tell which one is right
>>>> using just 2 pps ?. With three, you could choose the closest to average
>>>> and discard the outlier, or if it was outside a defined window. Ok,
>>>> it's a bit nitpicking, but would still be interesting to try it.
>>>
>>> No. The mechanism is clear. While one is answering its interrupt the
>>> other gets to wait. So, it is the earliest one that is closest to
>>> "right" Ie, do not try to use more than one interrupt on the same
>>> computer. It does not work
>> 
>> A good timing-optimized gps unit, like the original Oncore, have a sw 
>> mechanism to offset the PPS event away from the actual top of the 
>> second, as well as a way for the sw protocol that numbers the PPS 
>> signals to also specify how far away this particular pulse is from the 
>> actual event.
>> 
>> I.e. with an internal 10 MHz clock, PPS signals will be synced to one of 
>> those 100 ns-wide periods, so it can/will be at least up to +/-50 ns 
>> away from the proper moment, but when the driver knows about this, it 
>> can adjust perfectly for that effect.
>> 
>> Terje
>> 
>
> I happen to have a GPS unit (not yet connected) that is documented to do
> this too: The PPS pulse occurs at an edge of the internal crystal clock,
> but a special NMEA statement states (based on the 4D GPS solution) how
> many ns it is off for each pulse.  I have yet to find the point to pass
> this offset to ntpd after capturing the PPS arrival time.

The problem is this is largely irrelevant. The time it takes the
computer to respond to an interrupt id far far larger (and variable)
than that offset of the pulse which is on the at most 10s of nsec scale.
The computer responds on the usec scale (que the interrupt, the comp
responds to the que and loads or branches to the interrupt service
routine. The routine reads the system clock. All that takes time and a
variable amount of time. Ie, you need specialised hardware to make use
of that information, and, I thought, usually that infomation was
delivered by the gps unit a lond time after the pulse itself. Ie, it is
useful for rewriting history, not for the immediate time.




>
> Enjoy
>
> Jakob

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

Re: [ntp:questions] Time server question

[William Unruh]

On 2019-07-20, Chris  wrote:
> On 07/19/19 21:47, William Unruh wrote:
>
>> No. The mechanism is clear. While one is answering its interrupt the
>> other gets to wait. So, it is the earliest one that is closest to
>> "right" Ie, do not try to use more than one interrupt on the same
>> computer. It does not work
>>
>
> I think we are at cross purposes here. What i'm saying is that if there
> are 2 sources of pps signals, say from 2 time servers, there will be a
> slight offset between the two, so how to determine which is the accurate 
> one ?. With 3 or more pps sources, those with the least offset
> could be chosen for analysis, to find a median value.

Again, IF your system really reacted to the PPS signal instantly,
thenthe question you ask makes sense. But since both PPS signals come in
at the same time (<1us difference) the way the system reacts to them
becomes crucial In that case, the first IRQ the system reacts to blocks
the other for a few usec.

>
> Of course, host processing must introduce uncertainty, but would assume
> that ntp is designed to mitigate that ?.

No, it is not. ntp works by interupts, and the first thing that ntp asks
the interrupt handler to do is to read the system clock. That takes a
while, and also blocks any further interrupts while it is reading the
system clock. Once it has rad that, it releases the itnerrupts for
another to take over if it wants, because it has the only time
seneistive data it needs. 

(or at least that is how a good handler behaves Whether for example 
ldattach behaves properly is unclear to me. It looked to me when I once
looked at it like there is a large amount of processing that goes on in
the interrupt handler).


>
>>>
>

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

Re: [ntp:questions] Time server question

[William Unruh]

On 2019-07-19, Chris  wrote:
> On 07/18/19 11:13, William Unruh wrote:
>
>>
>> Sure, but I do not have faith in the "averaging" If one is always 30us
>> after the other, then the average will always be out by 15us.
>
> One would expect a difference, but how can you tell which one is right
> using just 2 pps ?. With three, you could choose the closest to average
> and discard the outlier, or if it was outside a defined window. Ok,
> it's a bit nitpicking, but would still be interesting to try it.

No. The mechanism is clear. While one is answering its interrupt the
other gets to wait. So, it is the earliest one that is closest to
"right" Ie, do not try to use more than one interrupt on the same
computer. It does not work

>
>>
>> Writing a special interrupt handler (eg for the parallel port) whose
>> first action is to read the system clock, and it can then allow other
>> interrupts to be handled. That will be good to about 1us. (time to have
>> the interrupt hadler to be loaded into memory, and for it to read the
>> system clock).
>
> Don't know enough about FreeBSD, but perhaps there is some way to
> specify interrupt priority for a device to minimise latency. It's

There are harddware priorities (parallel port is higher priority to
serial) and there is how much work the computer has to do to anser the
interrupts. (I get the feeling serial is messier than parallel.)


> certainly possible to do that at hardware level, but there's still
> the data pathway uncertainty between the h/w interrupt and the ntp code.
> Signals, shared memory, process priority etc, all introduce uncertainty.
> None of these os's were designed for real time work, but clearly good
> enough for the task...
>
>>
>> I think the main problem witht he serial port is that it seems to take
>> longer to read that the interrupt has occurred. But I did  my
>> experiments 20 years ago.
>
>
>

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

Re: [ntp:questions] Time server question

[William Unruh]

On 2019-07-17, Chris  wrote:
> On 07/17/19 12:59, William Unruh wrote:
>
> > I had some indication that the parallel port was faster.
>
> That would make sense, since the rs232 devices tend to be slew
> rate limited for noise rejection. Found some DS8921 driver / receiver
> devices, originally designed for hard drive data path use. Delay
> around 10-15 nS or so, which should be more than good enough.
> Single 5 volt rail as well.
>
> > I suspect it will be a bad outcome. The rpoblem is that you get
> > interrupt contention, and the two interrups will put in time delays into
> > the second one processed.
>
> Remember hand optimising 6502 asm interrupt handlers years
> ago to tune timer accuracy, but that was a 1uS cycle  machine,
> with handlers stretching out to 100uS or more.
> Don't have data, but modern cpus are much faster and in
> any case, there are other interrupt sources within the system
> which may contribute to jitter. Don't know enough to say, but
> perhaps ntp will average out the two to give a more accurate
> result ?. Would be interesting to hook it up and see what
> happens anyway...

Sure, but I do not have faith in the "averaging" If one is always 30us
after the other, then the average will always be out by 15us.

Writing a special interrupt handler (eg for the parallel port) whose
first action is to read the system clock, and it can then allow other
interrupts to be handled. That will be good to about 1us. (time to have
the interrupt hadler to be loaded into memory, and for it to read the
system clock).

I think the main problem witht he serial port is that it seems to take
longer to read that the interrupt has occurred. But I did  my
experiments 20 years ago. 


>
> Chris
>
>

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

Re: [ntp:questions] Time server question

[William Unruh]

On 2019-07-17, Chris  wrote:
>
> Next thing to try is the parallel port ack line pps and would be

I had some indication that the parallel port was faster.

> interesting to add a second pps signal to see how that affects the
> result. Interesting project for the summer anyway...

I suspect it will be a bad outcome. The rpoblem is that you get
interrupt contention, and the two interrups will put in time delays into
the second one processed. 
>
> Chris
>

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

Re: [ntp:questions] Shall I use a fudge on PPS?

[William Unruh]

On 2019-07-16, Andreas Mattheiss  wrote:
> Hello,
>
> I have a cheap GPS hooked onto my PC via a MAX232 level converter - the
> PPS goes directly into the DCD pin of a native serial port. 
>
> Everything is fine; after some time ntpd locks onto the PPS signal, and
> any other servers from the net show a small offset in ntpq -p. 
>
> What is the correct way of dealing with this? We are talking about 3 ms
> here. Is it appropriate to use a fudge on the PPS to bring it in line with
> the mean of a handfull of other servers from the net, or is is more
> appropriate to use the PPS's pings face value, not using any fudge?

A couple of possibiliites-- your connection to the net is highly
assymetric, so that it send path is 6 ms longer than the receive
path.That will make the ntp software think that everything outside is later than
it is.
Or, you are triggering pps on the falling rather than the rising edge of
the pulse. 
Oh, a third possibility-- your level converter is really really really
slow. GPS PPS  (even cheap ones) should be good to 1 usec, not 3 ms. 

>
> Thanks, regards
> Andreas
>

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

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

[William Unruh]

On 2019-07-11, Michael Haardt  wrote:
> Hello David,
>
> I trust the clock, because with constant temperature crystals perform
> pretty good.  The clock is disciplined with PPS, but no adjustments
> happened during the measurement, so it runs with a constant frequency
> offset.  It took a few days to reach that state.
>
> My point is that NMEA on this device does not jitter with a gauss
> distribution or similar, but in a way that causes the reasonable jitter
> calculation to give too low values.

Do not use nmea as a time source. It it has a long delay ( hundreds of
ms) which depnds on the speed of connection, on length of the nmea
sentance, etc. EAch character takes from 100 of usec to ms to be
delivered, and the lengthof sentences is variable, and the gps sends out
a sentence only when it is not terribly busy ( which depends on how many
sattelites it is trying to handle, etc) It is good for setting the
seconds (sometimes-- if you ask it to send too many sentences it can be
out by more than a second totally messing up your timing). 
One sentence (RMA) and a high baud rate make it useful for setting the
second. 

Ie, do not use it as a time source if you want accuracy that is better
than a second. Its jitter, because fo the above, is also going to be far
from Gaussian. (eg, the sentense on some dates and times is a few bytes
longer than the previous run and suddenly the time delivered is late by
a ms. more than before. )


>
> The jitter diagram shows why 0.1 as minimum distance suffices.
> The problem is, that this is only a workaround, as it effects the root
> dispersion.  What I need is to bypass the NMEA jitter calculation only,
> or give a minimal value for that, to prevent it becoming a false ticker
> when the actual jitter is larger than the estimated jitter.

Or not use nmea as a time source. 

>
> In the diagrams that happens if the estimated jitter does not cover
> zero, because zero is the PPS/crystal clock with 4 us jitter (both
> estimated and actual).
>
> GPS reception was fine with good average SNR and a reasonable of used
> and visible satellites.  TDOP was fine.
>
> I had this behavior before the upgrade from firmware 4.00 to 4.20,
> which is recommended due to the GPS week rollover.  I did not have it
> when the GPS reception was worse and I had a lower average SNR and
> an overall higher NMEA jitter and worse TDOP.
>
> Michael

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

Re: [ntp:questions] Time server question

[William Unruh]

On 2019-06-25, Chris  wrote:
> On 06/25/19 19:35, William Unruh wrote:
>> On 2019-06-25, Chris  wrote:
>> ...
>>>
>>> Thanks again for the replies. Did a bit of digging this morning and
>>> find that the 1pps sync stuff has been done before. Well, many
>>> years ago in fact and more or less how I had visualised it - ntp
>>> data augmented by the 1 pps signal. Several pointers to the way
>>> forward and it's also supported in the FreeBSD kernel, using either a
>>> pin on a serial or parallel port for the 1 pps. Probably go for
>>> the parallel port, as that avoids the hardware to convert 1 pps
>>> ttl to rs232 levels.
>>
>> Except most serial ports actually used on computers handle ttl levels
>> just fine.
>>
>
> True, but would not rely on that sort of hack for anything serious,
> as it won't have good noise immunity for what is a nS scale timing
> signal.  The 1pps from the gps is at ttl or cmos level on a different
> piece of kit in another box. A diff line driver and receiver might
> be the best way, though that would need a bit more hardware. Devil
> is in the detail as usual, but just need to get it working to start
> with.

Not clear what you mean. Note that a driver would introduce its own
delays, and line termination also has  effect.

>
>
>>
>> Stratum 1 says nothing about accuracy. You could have stratum 1 come off
>> smoke signals and have an accuracy of minutes, and a stratum 7 have an
>> accuracy of usec. All it indicates is how many steps the time server is
>> from a hardware time source. It says nothing about how good that time
>> source is, or how good the connection is between servers.
>
> The docs i've looked at seem to say that stratum 1 is generally
> assumed to be caesium or gps, though the number of links would affect

It is basically any hardware. It could be WWV radio signals. Yes most of
the time it is probably gps, but then you do not know how long the line
from the gps receiver to the computer is,or how rapidly the computer
responds to interrupts, etc. Ie, stratum 1 does not imply accuracy.

> it. Just trying work it out so what appears on the net is as good
> as the standard it refers to...
>
> Chris
>
>

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

Re: [ntp:questions] Time server question

[William Unruh]

On 2019-06-25, Chris  wrote:
...
>
> Thanks again for the replies. Did a bit of digging this morning and
> find that the 1pps sync stuff has been done before. Well, many
> years ago in fact and more or less how I had visualised it - ntp
> data augmented by the 1 pps signal. Several pointers to the way
> forward and it's also supported in the FreeBSD kernel, using either a
> pin on a serial or parallel port for the 1 pps. Probably go for
> the parallel port, as that avoids the hardware to convert 1 pps
> ttl to rs232 levels.

Except most serial ports actually used on computers handle ttl levels
just fine.

>
> Have a Minix mini-itx box with two network ports which only draws
> about 12 watts. It has headers for the parallel and serial ports,
> so looks ideal to experiment with. Already has FreeBSD 11.2, but
> will reinstall 12 at minimum level to get the job done. Not after 
> perfection, but engineers always want the best result at minimum
> cost and timescales :-). A few uS should be more than good enough to
> maintain stratum 1 accuracy afaics, as network variables are

Stratum 1 says nothing about accuracy. You could have stratum 1 come off
smoke signals and have an accurcyof minutes, and a stratum 7 have an
accuracy of usec. All it indicates is how many steps the time server is
from a hardware time source. It says nothing about how good that time
source is, or how good the connection is between servers.

> orders of magnitude greater than that. Fun project anyway and
> will document once it's working...
>
>
> Chris
>

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

Re: [ntp:questions] Time server question

[William Unruh]

On 2019-06-25, Chris  wrote:
> On 06/21/19 15:48, Jakob Bohm wrote:
>> On 21/06/2019 15:14, Thomas Laus wrote:
>>> On 2019-06-21, David Woolley  wrote:
 On 21/06/2019 12:26, Thomas Laus wrote:
> Will either isolation solution have direct access to the computer
> CPU? The GPS clock will need the ability to directly adjust the
> frequency of the CPU to achieve expected results for a Stratum 1
> serve

 I'm not aware of anything in ntpd that directly adjusts the CPU
 frequency and there generally isn't any fine grained way of doing that.
 ntpd normally works by adjusting how many cycles of a fixed frequency
 represent a certain time period, and that is a software operation.

>>> I guess that I should have stated this reply a little differently. I
>>> meant to say that ntpd will need direct access to the hardware that
>>> it runs on. That means a hardware serial port for pulse per second
>>> and the running system clock frequency. The ntpd program does not
>>> perform well when running on a virtual machine nor in a isolated
>>> security environment similar to a freebsd jail. My advice to the
>>> original poster is to get ntpd running as a stratum 1 source and
>>> then connect it to the internet with the fewest number of inter-
>>> mediate hops in between. I doubt that this is possible if the
>>> Stratum 1 time source can be connected through any buffer device
>>> to the internet and still serve Stratum 1 time.
>>>
>>>
>>
>> The deeper problem here is that the NTP protocol doesn't clearly
>> distinguish between a stratum 2 server running dozens of low quality
>> hops from it's time sources and a stratum 2 server that sits a single
>> hop from a solid stratum 1 source.
>>
>> On the other hand, a GPS, WWVB or other radio clock isn't really a
>> stratum 1, as it receives remote time over a non-NTP protocol, so that
>> sort of cancels out the stratum 2 reported due to the stacking.
>>
>> Running the Internet-exposed ntp server in a bastion host separate
>> from the difficult-to-upgrade old hardware makes perfect sense, and
>> an ntpd server without same machine precision time sources only needs
>> the permissions to use port 123 and to adjust the local clock (including
>> it's speed) via the various privileged system calls. Running the
>> computer clocks in such a bastion host from a quality crystal rather
>> than a cheap ceramic oscillator would also help reduce time errors, but
>> this is in the hardware buying phase and not a detail typically provided
>> by computer vendors.
>>
>> I suspect the ntp servers run by national time services and synced to
>> their reference Cs and maser clocks are also receiving the time via
>> some kind of internal network, either ntp with stratum fudge, PTP low
>> latency Ethernet distribution or an amplified low latency coax
>> distribution of the 1Hz or 10MHz reference (the latter would be most
>> precise and offer no data channel for a compromised server to attack the
>> actual clock).
>>
>>
>> Enjoy
>>
>> Jakob
>
> Thanks for all the replies. I guess the next thing to do is to build
> a working system, then evaluate to see how it can be improved. All
> the kit is in the same rack and with dedicated hardware interfaces,
> network latency shouldn't be a problem. This is effectively a real
> time requirement, so any code running needs to be consistent in terms
> of  response time to minimise jitter on the timing. Need to get
> a feel for acceptable delay and response times, so will look to see
> what others have done in the past.
>
> I like the idea of using a 1 pps signal from the gps for fine tuning.
> Rough time and date via the network ntp and the 1pps to fine tune it.
> That could maintain the stratum 1 timing quality, as the 1pps is
> generally within 10's of nS of UTC, but need to look into how ntpd

Well, yes and no. That may be when a certain point inthe transition of
the pps signal occurs (although youwoillo have to be really careful
about the line from the gps to the computer, and the terminations of the
lines. Also that tends to be the corrected time (for the sawtooth
running). Also it is really hard to get your computer to process the
signal  to 0ns. A more resonable estimate is 1microsecond Taking
intoaccunt the computer's interrupt latency, time to read system time,
etc.
To do better is going to take a lot of work.

Note the gps ALSO delivers the seconds information in the gps time
signal. (Ie labelling the seconds).
 
> would handle that and also how to introduce that into the system.
> Already use an ex telco gps for a lab frequency standard, but of
> course, frequency != time of day. A dedicated embedded solution might
> be the best bet, but other options might include a cheap netgear
> router to provide the isolation, as it would only be handling ntp
> packets at low and consistent system and network load.
>
> Nothing is ever as easy as it seems, as usual...

Depends on what you want out of the system, or rather what 

Re: [ntp:questions] Fine tuning ntp.conf

[William Unruh]

On 2019-04-27, David Taylor  wrote:
> On 27/04/2019 17:37, William Unruh wrote:
> []
>> On the subject of gps/pps receivers, since the Sure OEM board seems to
>> have disappeared, what is the current recommendation for a cheap gps/pps
>> board to attach to your computer? (the above is not cheap-- on the
>> order of $500, rather than $50)
>
> Something happened to the previous
>
> As mentioned on my Web page:
>
>https://www.satsignal.eu/ntp/Sure-GPS.htm
>
> you can use a cheap module from eBay, or perhaps an Adafruit one, and 

The Sure module no longer seems to exist even on eBay.
They seem to have gone out of the GPS business.

> you could need a TTL to RS-232 voltage level converter:
>Adafruit one looks interesting. 

>https://www.adafruit.com/product/746
>https://www.amazon.co.uk/gp/product/B00EJ9NAKA
>
> I found that the PPS signal was OK at TTL level.
>
> The Leo Bodnar unit would be ideal as a central server for a small group 
> or bigger, and has the advantage of excellent support.  The cost is 
> appropriate for the quality level of the unit, but it would likely be 
> overkill for a single PC.
>
>  
> http://www.leobodnar.com/shop/index.php?main_page=product_info=120_id=272
>

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

Re: [ntp:questions] Fine tuning ntp.conf

[William Unruh]

On 2019-04-27, David Taylor  wrote:
> On 26/04/2019 21:27, jelisko...@gmail.com wrote:
> []
>> I think that you are mistaken.
>> 
>> " The servers joining should not have pool.ntp.org as their upstream 
>> server(s), but should configure some good servers manually (those servers 
>> may be chosen from the pool. The point is that they are chosen statically 
>> instead of assigned randomly at each server restart " - 
>> https://www.ntppool.org/en/join.html
>
> As I read it, that refers to pool servers themselves.  Their clients, 
> your PC, will choose between the available pool servers for best results 
> over time if you use the pool directive.
>
> My suggestion was to avoid very well-known servers which may well be 
> stratum-1, but which are are so busy that they provide less accuracy 
> than pool servers, and to get the benefit of automatic removal and 
> replacement of dead servers.
>
> If accuracy is /that/ critical, you should consider either adding a PPS 
> feed to your own PC, or using a GPS/PPS device with good holdover to 
> your network, such as:
>
>  
> http://www.leobodnar.com/shop/index.php?main_page=product_info=120_id=272
>
> It all depends on your requirements.

On the subject of gps/pps receivers, since the Sure OEM board seems to
have disappeared, what is the current recommendation for a cheap gps/pps
board to attach to your computer? (the abo ve is not cheap-- on the
order of $500, rather than $50)

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

Re: [ntp:questions] Fine tuning ntp.conf

[William Unruh]

On 2019-04-26, jelisko...@gmail.com  wrote:
> On Friday, 26 April 2019 19:39:25 UTC+2, William Unruh  wrote:
>> On 2019-04-26, David Taylor  wrote:
>> > On 26/04/2019 14:31, jelisko...@gmail.com wrote:
>> >> Hi guys,
>> >> 
>> >> This is my config file for my NTP Stratum 2 server. Any suggestion for 
>> >> fine tuning will be appreciated.
>> > []
>> >> # Use public servers from the pool.ntp.org project.
>> >> # Please consider joining the pool (http://www.pool.ntp.org/join.html).
>> >> #server ntp.svilengrad.eu iburst
>> >> #server ntp.fizyka.umk.pl iburst
>> >> server ntp.bsdbg.net iburst
>> >> server ptbtime1.ptb.de iburst
>> >> server zeit.fu-berlin.de iburst
>> >> server ntp0.fau.de iburst
>> > []
>> > One comment - why not use the pool servers, as suggested?  Replace your 
>> > four lines with:
>> >
>> >pool  de.pool.ntp.org  minpoll 6 maxpoll 7  iburst
>> >
>> > You may find that some of the public servers you list may be overloaded, 
>> > or come and go from time to time - the "pool" directive takes care of 
>> > vanishing and overloaded servers.
>> >
>> One problem with the pool is that the servers have varying accuracy. If
>> you have carefully chosen your servers as having low uncertainty, then
>> your list might be better. But if you simply chose them randomly, then
>> the pool will probably be just as good.
>
> Yes, I tried with nearest to my country

That is one issue (it should tend to make the round trip time, and thus
the chances of assymetry) slightly lower. But I have found that sites
2000km away can be much better than some other sources 50 ft away. It
really depends on all the switches/routers/etc between you and the
source, and also what that source uses for its sources. For example one
might use GPS time with a really good GPS card, while the other might
use WWV. Both are stratum 1 sources, but on it a lot lot lot more
accurate than the other. 

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

Re: [ntp:questions] Fine tuning ntp.conf

[William Unruh]

On 2019-04-26, David Taylor  wrote:
> On 26/04/2019 14:31, jelisko...@gmail.com wrote:
>> Hi guys,
>> 
>> This is my config file for my NTP Stratum 2 server. Any suggestion for fine 
>> tuning will be appreciated.
> []
>> # Use public servers from the pool.ntp.org project.
>> # Please consider joining the pool (http://www.pool.ntp.org/join.html).
>> #server ntp.svilengrad.eu iburst
>> #server ntp.fizyka.umk.pl iburst
>> server ntp.bsdbg.net iburst
>> server ptbtime1.ptb.de iburst
>> server zeit.fu-berlin.de iburst
>> server ntp0.fau.de iburst
> []
> One comment - why not use the pool servers, as suggested?  Replace your 
> four lines with:
>
>pool  de.pool.ntp.org  minpoll 6 maxpoll 7  iburst
>
> You may find that some of the public servers you list may be overloaded, 
> or come and go from time to time - the "pool" directive takes care of 
> vanishing and overloaded servers.
>
One problem with the pool is that the servers have varying accuracy. If
you have carefully chosen your servers as having low uncertainty, then
your list might be better. But if you simply chose them randomly, then
the pool will probably be just as good. 

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

Re: [ntp:questions] Hoes a IoT device discover the NTP era with NTPv4?

[William Unruh]

On 2019-03-11, Nelson Bolyard  wrote:
> I'm working on an IoT device whose clock only runs when it has power.  When 
> it first starts up, and also after every crash, its clock starts at zero.  
> Today this device uses SNTPv3 to set its clock by contacting a nearby NTP 
> server, and always assumes it is in NTP era zero.  
>
> But 2036 is fast approaching.  I want to know how, using NTPv4, a device like 
> mine can figure out that it is no longer in era zero.  Once it figures out 
> the era that it is in, the rest should be easy.  

If (Era 0 year<2019) then you are in era 1, else in era 0) That should get you 
to 2080
or so. If you really believe your device will  survive till that time,
then you may have to think of something else. 

>
> Advice?

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

Re: [ntp:questions] What is the mean of below output?

[William Unruh]

On 2018-08-06, David Woolley  wrote:
> On 06/08/18 08:16, ashishchugh@gmail.com wrote:
>> 3- Is there is any way through i can determine that what is the currently 
>> difference between my local system and ntp server.
>
> No.  If you could, NTP could modify the local time to make the value zero.

That is of course what it tries to do, without jumping the local time (which
would be bad). Of course the whole chain (Your program, your network hardware,
the network, various routers etc along the way, the remote machine hardware,
the remote software and back again) introduces noise, so you do not know that
the remote ntp server's time is. But in the logs it will tell you what the
difference is between the local time and the estimate of the remote time is
obtained from that noisy chain. That is the best you can do. 
Of course you could attach your ssytem to gps, and get the remote gps server's
time to 10s or 100s of nanosecond accuracy. And yo ucould use that to see how
far your system is off the remote server, If you could borrow a gps, you could
test your system. If you bought a gps, then the best idea would be to use it
as your server, and get your machine disciplined to sub microsecond accuracy.
 
 From network servers, you can expect 10s of microseconds (nearby servers--
 like in the same  building) to millisec for distant servers. 
For gps, it depends on how you feed the gps into your system. Here you can get
100s of nanoseconds to a few microseconds using chrony. 

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

Re: [ntp:questions] What is the mean of below output?

[William Unruh]

On 2018-08-06, ashishchugh@gmail.com  wrote:
> Hi 
>
> I am facing time drifting problem in my linux , i install ntp. first of all i 
> am unable to execute ntpstat command as it is saying command not found.
>
> Then i execute ntpq -p and can see below ouuput
>
>  remote   refid  st t when poll reach   delay   offset  jitter
>==
>  time.tritn.com  .INIT.  16 u- 102400.0000.000   0.000
>  ntp1.wiktel.com .INIT.  16 u- 102400.0000.000   0.000
>  clocka.ntpjs.or .INIT.  16 u- 102400.0000.000   0.000
>  ntp.your.org.INIT.  16 u- 102400.0000.000   0.000
>  chilipepper.can .INIT.  16 u- 102400.0000.000   0.000
>
> But i am unable to understand what is the mean of this output.

It means that none of those refclocks has ever been successfully used. You are
not synched at all. 

>
> Is that mean my system time is synced with ntp and at current time there is 
> no time delay in my local linux.
>
> 2- May i execute the ntp every time or it will run at back end automatically.

It depends on how you set things up. You do not say which version of Linux,
how you installed it, what your networking is, etc. 


>
>
>  Local time: Mon 2018-08-06 07:15:02 UTC
>   Universal time: Mon 2018-08-06 07:15:02 UTC
> Timezone: Etc/UTC (UTC, +)
>  NTP enabled: yes
> NTP synchronized: no
As you can see, ntp is not synchronized.


>  RTC in local TZ: no
>   DST active: n/a
>
>
> 3- Is there is any way through i can determine that what is the currently 
> difference between my local system and ntp server.

Once you get it working, sure. Look at the logs.


>
> Please help if someone have idea.
>

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

Re: [ntp:questions] How can i make sure that how much time ntp is adjusting one day

[William Unruh]

On 2018-08-05, aashish.ch...@fonantrix.com  wrote:
> Hi,
>
> I am facing time drifting problem in my production env.
>
> I install ntp on my linux server and configure that.
>
> i enable the ntp, how can end of the day i can get the total time which ntp 
> adjusted.
>
> when i execute ntpstat command i can see following output
>
> synchronised to NTP server (169.254.169.123) at stratum 4
>time correct to within 9 ms
>polling server every 8 s

That poll interval is really short, and if you are getting the time from a
server that you do not control, they could get really really annoyed with you
and cut you off.

That is a link local address, so I do not know what it is you are using as a
server. Could you post your ntp.conf file.

>
>
> is there is anything need to do.

Use a decent server?
>
> Please help.

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

Re: [ntp:questions] shm + pps calibration

[William Unruh]

On 2018-07-01, ggavila...@gmail.com  wrote:
> I am currently using a Ublox M8N either for positioning than for time 
> synchronization (as stratum0 source and stratum1 server to other subsystems). 
> In order to achieve this I have a gpsd listening the device in a local port 
> and publishing timing/positioning in shared memory (to be visible to NTP.). I 
> have also put PPS electrical signal from the GNSS receiver into a gpio 
> handled by a pps-gpio linux driver. That works fine in my system.
>
> PPS has been tested with ppstest tool. also ntpshmmon gives time/position 
> exports to shared memory for every second.
>
> The problem is that up to now I haven't found a way to calibrate accurately 
> the initial calibration time offset estimations given by ntp. I used 
> trial-and-error approach to arrive to a combination of calibration times for 
> [PPS , SHM] that keeps my local clock synchronized for as long as possible. 
> The most I have got with that combination is 300 seconds after ntp service 
> restart.

I do not know what that means.

>
> After the ntp restart, the ntp shows:
>
> root@hostname:~# ntpq -p
>  remote   refid  st t when poll reach   delay   offset  jitter
>==
> *SHM(0)  .UBL.0 l6   16   170.000   -5.601   7.147
> oPPS(1)  .PPS.0 l5   1670.000   -2.434   0.391
> but after a (short) while, ntp marks both sources as false tickers:

Not surprizing. PPS hs no idea what the seconds are, only the decimal part of
the time. It gets the initial seconds from the local clock. Thus PPS shoulnd
not be started until the system time is within about 1/4 sec of UTC.
The shm should give UTC. So, let the system run a while to lock onto shm time,
then start PPS.
Note that if there are two time souces and they disagree, NTP has no way of
knowing which is right,so the beest it can do is say both are wrong.


>
> root@hostname:~# ntpq -p
>  remote   refid  st t when poll reach   delay   offset  jitter
>==
> xSHM(0)  .UBL.0 l4   16  3770.000  -11.125   5.132
> xPPS(1)  .PPS.0 l3   16  3770.000   -2.701   0.200
> Sometimes it comes back to synch, and it goes back and forth. For my 
> purposes, it might be acceptable (since local time clock does not diverge 
> much until the next time ntp resync), but when I apply the same ntp 
> configuration to another system with the exactly the same hardware/software 
> configuration (even the same GNSS antenna in open sky), the synchronization 
> state is not stable (ntps declares false tickers almost always). This makes 
> me think that the ntp configuration I have obtained is not the optimal.
  >
> The NTP configuration I have is this:
>
> driftfile /netlab/log/ntp.drift
> statsdir /netlab/log/ntpstats/
> statistics loopstats peerstats clockstats
> logfile /netlab/log/NTP/ntp.log
> enable calibrate
> filegen clockstats ntp.stats clockstats type day enable
>  
> # SHM driver doc:
> # time1 Specifies the time offset calibration factor, in seconds and 
> fraction, with default 0.0.
> # time2 Maximum allowed difference between remote and local clock, in 
> seconds. Values <1.0 or >86400.0 are ignored, and the default value of 4hrs 
> (14400s) is used instead. See also flag 1.
> # stratum Specifies the driver stratum, in decimal from 0 to 15, with default 
> 0.
> # refid Specifies the driver reference identifier, an ASCII string from one 
> to four characters, with default SHM.
> # flag1 0 | 1 Skip the difference limit check if set. Useful for systems 
> where the RTC backup cannot keep the time over long periods without power and 
> the SHM clock must be able to force long-distance initial jumps. Check the 
> difference limit if cleared (default).
> # flag2 0 | 1 Not used by this driver.
> # flag3 0 | 1 Not used by this driver.
> # flag4 0 | 1 If flag4 is set, clockstats records will be written when the 
> driver is polled.
>  
> server 127.127.28.0 mode 1 minpoll 4 maxpoll 6 prefer
> fudge 127.127.28.0 time1 0.040 time2 1.00 stratum 0 flag1 1 flag4 1 refid UBL
>  
> # driver 22 (ATOM PPS)
> # flag2 Specifies PPS capture on the rising (assert) pulse edge if 0 
> (default) or falling (clear) pulse edge if 1 
> # flag3 Controls the kernel PPS discipline: 0 for disable (default), 1 for 
> enable
> server 127.127.22.1 minpoll 4 maxpoll 4 version 4 prefer  # enable PPS API
> fudge 127.127.22.1 flag2 0 time1 -0.040 stratum 0 flag3 1
>  
> (sorry for the long intro) 
>
> Is there a way to systematically calibrate the offsets so the synchronization 
> is stably maintained (obviously under optimal sky visibility) ?

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

Re: [ntp:questions] shm + pps calibration

[William Unruh]

On 2018-07-07, David Taylor  wrote:
> On 06/07/2018 21:18, Daniel Gearty wrote:
>> In my case, I attribute the PPS delay to the serial to USB 1.1 conversion of 
>> the Prolific PL2303HXD in my NaviSys GR-8013W GPS.  The offset bounces 
>> around within +/- 0.5 msec.
>> It appears the initial PPS offset should be zero if you receive your PPS 
>> signal directly from a proper serial port.
>> 
>> I am using NTP "Generic NMEA GPS Receiver" driver 20 with the Windows 
>> loopback driver.
>> 
>> ggavi is using "PPS Clock Discipline" driver 22 for PPS, but perhaps should 
>> be using "Shared Memory Driver" driver 28 for both NMEA and PPS.
>> http://www.catb.org/gpsd/gpsd-time-service-howto.html#_feeding_ntpd_from_gpsd
>> 
>> Another, newer driver for NTPD to receive time from gpsd is "GPSD NG client 
>> driver" driver 46.
>> http://doc.ntp.org/current-stable/drivers/driver46.html
>> 
>> Although I wonder whether chronyd receiving time from gpsd via a socket has 
>> the best NTP performance.
>> https://chrony.tuxfamily.org/doc/3.3/chrony.conf.html
>
> Using different software (Chrony or gpsd) is unlikely to improve 
> performance which is inherently limited by the serial-USB conversion, 
> unless someone were to write a special driver to average out the USB 
> jitter.  NTP will do that to an extent, of course.
>
> For best NTP performance, if you aren't using a portable PC (so no 
> serial port), check whether your motherboard has a serial port header, 
> or get an add-in PCIe serial port and swap the GPS for one which has a 
> real PPS line.  Likely even the low-cost Chinese ones will be good enough.
>
> On one PC I'm using an add-in PCIe card, a TTL-RS232 converter (tried 
> without but the signal levels were too low) and a Chinese module sitting 

That is really unusual. Most serial cards now will happily use TTL levels. 
The converter may (or may not) introduce delays to the pps signal. If they are
sub usec it probably does not matter. 

> on the bench.  Needed to add one wire from the u-blox module's PPS pin:
>
>https://www.satsignal.eu/ntp/NEO-6M-under-initial-test.jpg
>https://www.satsignal.eu/ntp/RasPi-3-with-u-blox-RX.jpg
>
> but you could avoid that with the Adafruit module:
>
>https://www.adafruit.com/product/746
>
> Here's a link to the PC's performance:
>
>https://www.satsignal.eu/mrtg/lund-ntp-2.html
>
> The variation on that PC is likely due to the CPU temperature as the 
> load varies with receiving new Sentinel-3A satellite data every orbit 
> (101 minutes).
>

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

Re: [ntp:questions] This is project have any SLA and does it meets th PCI and DSS compliance

[William Unruh]

On 2018-05-12, bhuvaneshwara...@powerupcloud.com 
 wrote:
> Hello,
>
> We are going to use these pool servers for our production env, so we need to 
> know that you have any SLA for uptime and does this project meets the PCI and 
> DSS compliance? 
>

No idea what you are asking, but pool.ntp.org is a huge bunch of volunteers
who provice their own ntp servers for the use of others. It meets no
compliance standards, and the uptime of volunteers is random, and certainly
not tracked. Note also that the quality of time served by random members of
pool.ntp.org is highly variable-- from tens of microseconds to hundreds of
milliseconds.

If you want to make sure that you have reliable service, set up your own set
ofservers, fed for example from a GPS-PPS source. If you are an organization
then you should also set up your own pool powerupcloud.pool.ntp.org.
for your clients to use, rather than making use of those volunteers. 

ntp is a time source, not a secure environment. 

So I think that the answer to your question is NO. And also that you are
confused about  what ntp is. 

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

Re: [ntp:questions] does this make sense?

[William Unruh]

On 2018-04-04, Maria Iano  wrote:
> I'm purchasing ntp appliances to put into three datacenters. Does it make 
> sense to purchase two that use GPS and two that use WWVB, and configure them 
> as peers?

Well, WWVB is about a million times less accurate than GPS (even with a cheap
GPS it is well over a thousand times less accurate). So it seems a little bit
strange. The WWVB could be used as a backup, although I suspect is would be
flakier than the GPS time signal. 

> Thanks,
> Maria

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

Re: [ntp:questions] does this make sense?

[William Unruh]

On 2018-04-05, Terje Mathisen  wrote:
> Maria Iano wrote:
>> Thanks for your reply, David. Accuracy to within milliseconds is fine
>> for us. We currently have four old GPS appliances in four data
>> centers that we are replacing, and my thought is that some vendor
>> diversity would be good.
>>
>> We are only staying in two of those data centers, so that was where I
>> was thinking of using GPS as we already have a cable to an antenna to
>> the roof. We have a third data center where we currently don't have
>> any ntp appliance, and that's where I was thinking it would be
>> convenient to put a WWVB device. But we do have access to the roof,
>> and from what you say it sounds like we would be better off putting a
>> GPS using all three services there.
>>
>> We have a network of 12 stratum 2 servers that get time from our
>> appliances, and most of our infrastructure points to those, so maybe
>> a fourth stratum 1 server is overkill. Does this make more sense:
>> three GPS appliances using all three services at the three data
>> centers?
>
> I've designed similar setups a couple of times: Since we're located in 
> Europe my backup was the German radio transmitter since that one uses 
> spread spectrum modulation of the carrier, enabling 10-15 us precision.

That is about 2 miles light travel time. I suspect you are further than that
from the tranmitter. And propagation is all in the atmosphere, and the speed
of radio  varies in the atmosphere, depending on the pressure, the humidity,
clouds, Ie, I am doubting the 10-15us. Maybe 10-15 ms.?

>
> With a modern multi-system GNSS receiver and multiple geographical 
> locations I would probably be happy with a very good local clock (at 
> least TCXO, maybe a second-hand Rb?) to provide holdover and using 
> multiple internet sources as a sanity check.
>
> Terje
>

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

Re: [ntp:questions] How to keep fake time in past/future?

[William Unruh]

On 2017-12-12, romain.cordonn...@gmail.com  wrote:
> Hi
>
> Many thanks for your information.
>
> My project is processing meteorological data.
>
> I will check the fake ntp server python code.
>
> Restarting the ntpd is enough to synchronize with upper source ? even if 
> system is 2018 and upper source is 2030 ?
>

It depends on what you tell ntpd to do. If you tell it to step the clock if it
is too much in disagreement with its source, then it will do so.

> Thks
>
> Romain
>
>

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

Re: [ntp:questions] How to keep fake time in past/future?

[William Unruh]

On 2017-12-05, romain.cordonn...@gmail.com  wrote:
> Hi All,
>
> I have the same need as Cristian.
>
> I am working on a data processing project which is designed to run for 25 
> years.
>
> The customer wants us to run data processing simulation at any time 
> (past/present/future) from 2018 to 2043.
>
> Is to possible to build-up a fake "stratum 0" NTP server ?

Why? Just reset the system clock. Is ntp somehow inextricably embedded in the
project? ntpd should be setting and disciplining the system clock and all
software should get their time from the system clock. What is your project
doing?

Not that ntp trusts what the server reports. If the server reports that it is
stratum 1, the clients will believe it. Stratum 0 is not an ntp server. It is
an outside trusted time source-- atomic clock, gps,  A server who gets
time from such a source is a stratum 1 source as I understand it. But if a
server reports it is stratum 1 it will be believed. 


>
> What are the config options to force the ntp clients to synchronize 
> immediately to the fake source ?

ntpd does not "sync immediately". If it finds the time out by a sufficient
amount for a long enough time, it will step the local clock. Or you can
restart ntpd. 


>
> Steve suggests "Undisciplined Local Clock driver ", any other suggestion ? 
> The time diffusion will be restricted to the project servers (worldwide), it 
> will not be seen by internet.
>
> Thanks in advance !
>
> Romain

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

Re: [ntp:questions] Problems with Sure OEM pps gps

[William Unruh]

On 2017-11-19, David Taylor <david-tay...@blueyonder.co.uk.invalid> wrote:
> On 19/11/2017 06:29, William Unruh wrote:
> []> t but it is annoying to keep seeing 8 or more postings
>> only to have all of them killed. It is bizzare, and wonder if there is some
>> way of getting google to kill that account.
>> 
>>>
>>> Can you check other devices in the same location?  I've seen something
>>> similar happen when a GPS jamming device was (I guess) parked nearby.
>>> You might also check that the serial feed is still OK.
>> 
>> I have no other devices in the area. All I use is the PPS on that gps
>> receiver, not the nmea. But yes, I do believe it is OK. It is hard to see 
>> what
>> could happen in an empty office at 4PM.
>> 
>> I will see if I can find another gps receiver.
>
> I have just two e-mail addresses set to filter and delete.
>
> I was thinking of a mobile phone as the "test" GPS receiver.  If you 
> have an Android phone it will be able to see the individual signal 
> strengths.
>

If it cannot see the sattelites, then I would not expect the pps to suddenly
pick up a 20usec scatter in the pulse timing. The average seems to track the
the time reasonably well (as indicated by the tracking of two external ntp
sources-- I am not getting a drift away from their time of the system).

Unfortunately, the other Ssure GPS board I have is a different one, based on
the Skylark chipset, and the PPS does not seem to be working on it (the pps
light does not blink at all) Perhaps it is not switched on, but the Skylark
GPS manual does not indicate any way of switching on the PPS, or of sending
any NMEA signal to the device-- just proprietary ones which only change the
baud rate or do various temperatures of reboot.


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

Re: [ntp:questions] Problems with Sure OEM pps gps

[William Unruh]

On 2017-11-19, David Taylor <david-tay...@blueyonder.co.uk.invalid> wrote:
> On 18/11/2017 21:55, William Unruh wrote:
>> I am having sudden problems on my system with a Sure GPS with PPS.
>> I am running chrony, using a serial port to bring in the PPS signal.
>> Everything was working well-- the rms timing on the pulse was about 1usec.
>> Suddenly on Nov 18 at very close to 00:00:00UTC the timing went to hell, and 
>> the
>> rpms is now at 20us-- the individual pulses have an offset that fluctuates
>> between about 50us, and -50us.
>> Is there any hint as to what I could do to track down the problem. Could it 
>> be
>> the sattelites (ie the timing has suddenly gone from ns to tens of usec for
>> some reason? But if this were true I would have expected to hear many many
>> loud screams here.) Or the gps receiver? (again, unlikely I would think). Or
>> the serial card? or chrony? Or the computer clock? (the computer was not
>> rebooted anywhere around that date).
>> :
>> By the way, what in the world has happened to this newsgroup? I am getting
>> about 1 valid message to over 100 Case Solutions?
>
> Bill,
>
> You need to add a filter to your news feed to remove the unwanted postings.

t but it is annoying to keep seeing 8 or more postings
only to have all of them killed. It is bizzare, and wonder if there is some
way of getting google to kill that account.

>
> Can you check other devices in the same location?  I've seen something 
> similar happen when a GPS jamming device was (I guess) parked nearby. 
> You might also check that the serial feed is still OK.

I have no other devices in the area. All I use is the PPS on that gps
receiver, not the nmea. But yes, I do believe it is OK. It is hard to see what
could happen in an empty office at 4PM.

I will see if I can find another gps receiver. 

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

[ntp:questions] Problems with Sure OEM pps gps

[William Unruh]

I am having sudden problems on my system with a Sure GPS with PPS.
I am running chrony, using a serial port to bring in the PPS signal.
Everything was working well-- the rms timing on the pulse was about 1usec.
Suddenly on Nov 18 at very close to 00:00:00UTC the timing went to hell, and the
rpms is now at 20us-- the individual pulses have an offset that fluctuates
between about 50us, and -50us. 
Is there any hint as to what I could do to track down the problem. Could it be
the sattelites (ie the timing has suddenly gone from ns to tens of usec for
some reason? But if this were true I would have expected to hear many many
loud screams here.) Or the gps receiver? (again, unlikely I would think). Or
the serial card? or chrony? Or the computer clock? (the computer was not
rebooted anywhere around that date).
:
By the way, what in the world has happened to this newsgroup? I am getting
about 1 valid message to over 100 Case Solutions?

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

Re: [ntp:questions] false ticker after GPS coldreset

[William Unruh]

On 2017-11-05, valizadeh...@gmail.com  wrote:
> On Friday, November 3, 2017 at 1:01:26 AM UTC+3:30, Martin Burnicki wrote:
>> valizade...@gmail.com wrote:
>> > i have a ntp server based on Raspberry Pi3 with PPS (from u-blox6 ). i 
>> > have also added a hardware clock to this system.
>> > 
>> > 
>> > SOME times there is a large offset(3-18 sec) on the SHM (ntp driver 28).
>> > i did some experiments and figured out it is related to "leap seconds". 
>> > when i COLD-RESET the ublox(via USB through u-center) this offset appears 
>> > on the ntp and both PPS and SHM become false-tickers.
>> 
>> GPS internal system time is off UTC by an integral number of seconds
>> corresponding to the number of leap seconds that have been observed
>> since 1980.
>> 
>> As Jakob has already pointed out, the satellites send this information
>> once every ~12 minutes.
>> 
>> The GPS receiver needs this information to convert the raw GPS time
>> received from the satellites to UTC, so it usually store this
>> information in its non-volatile memory to have it available right after
>> power-up.
>> 
>> However, if you force the GPS receiver into cold boot mode then this
>> information gets lost, so the receiver outputs GPS time instead of UTC.
>> I'm not sure if the output contains some status that indicates that the
>> time sent by the receiver is not UTC.
>> 
>> Anyway, gpsd seems to accept the raw GPS time as UTC time, feeds it to
>> ntpd, and ntpd sets the Linux system time off by a number of seconds.
>> 
>> Up to 12 minutes later, after the GPS receiver has seen the UTC
>> correction parameters from the satellites, the GPS receiver starts to
>> convert GPS time to true UTC, and the time output jumps by a number of
>> seconds.
>> 
>> ntpd observes the sudden time step by a number of seconds, but accepts
>> it only after it has persisted by a certain interval, by default ~15
>> minutes. So your system time should be stepped to the correct time, but
>> only after up to 12 + 15 minutes after power-up.
>
> yes, you are almost right but "sometimes"(i dont know why!) ntp is not able 
> to correct the time and as you may see in my first post system time has 2-11 
> seconds offset not only after 15 minutes even after 24 hours. i think ntp 
> does not accept the time from GPS and mark it as false-ticker  because its 
> time has jumped after it has already been recognized a truechimers before 
> leap-second's effect.

2-11 seconds does NOT seem to have anything to do with leapseconds. 

You seem to have gps as your ONLY source, except for LOCAL. That means that it
should not be a false chimer. As has been emphasised time and again, get rid
of your LOCAL time source. It is NOT the hardware clock. It has nothing to do
with the hardware clock. It is the system clock itself. Get rid of it. 
Then gps will be your only source and it can never be a false chimer. 
Then for testing purposes, put in some ntp network sources so you can test
against something. 


>> 
>> I think the best solution would be to provide your GPS receiver with a
>> backup battery, if the device supports this, to make sure the UTC
>> correction parameters don't get lost while the system is powered off.
>> 
> i am thinking of a solution in which ntp update system time after leap second 
> have been observed by the GPS. 
> any ideas?

And you would know when that occurs how? If the gps receiver (I have no idea
what your receiver does) gives a flag saying "I now have UTC time" then you
should not be using the time from GPS before that anyway-- ie the receiver
should not be used as a source until you are sure it is giving proper time. 

>

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

Re: [ntp:questions] false ticker after GPS coldreset

[William Unruh]

On 2017-10-31, valizade...@gmail.com  wrote:
> i have a ntp server based on Raspberry Pi3 with PPS (from u-blox6 ). i have 
> also added a hardware clock to this system.
>
>
> SOME times there is a large offset(3-18 sec) on the SHM (ntp driver 28).

What program is delivering the time to the SHM? gpsd?

> i did some experiments and figured out it is related to "leap seconds". 

No idea how it could be related to leap seconds. Leap seconds are only one
second and that almost never happens. Is your gps broken?

> when i COLD-RESET the ublox(via USB through u-center) this offset appears on 
> the ntp and both PPS and SHM become false-tickers.
>
>
> i wait for over 12.5 minutes so that the UTC time become accurate (Almanac 
> data reception period) some times it works and SHM/PPS become truechimers and 
> some times even after 24 hrs they still are falsetickers with "3 seconds" 
> offset!

It really sounds like a broken gps to me. 

>
> here is what i think: 
> 1- system is tured on 
> 2- utc time is not accurate(leap seconds) but ntp dosent care and do iburst 
> 3- system time become updated
> 4- 12.5 min is passed
> 5- GPS time is changed (3-18 sec)
> 6- ntp is not able to handle this 
>
>
>
> i also used leap-second list file but there was no change
> http://support.ntp.org/bin/view/Support/ConfiguringNTP#Section_6.14.
>
>
> *system power on:***
> Every 1.0s: ntpq -p   PI3: Tue Oct 31 07:18:25 2017
>  remote   refid  st t when poll reach   delay   offset  jitter
>==
> oPPS(0)  .kPPS.   0 l18   170.000   -5.553   2.806
> *SHM(0)  .GPSD.   1 l18   370.0004.468   5.104
>  LOCAL(1).LOCL.   3 l   398   200.0000.000   0.002

a) why do you have LOCAL as one of your clocks. That should basically never be
used.  It is useless except in very particular situations where it is a server
which has to keep serving time even if its time is completely useless, because
all clocks in an organisation have to on the same time, even if that is wrong.
b) Do you have some other source of time? 


>
> *after ~20 min:*
> Every 1.0s: ntpq -p   PI3: Tue Oct 31 07:39:28 2017
>  remote   refid  st t when poll reach   delay   offset  jitter
>==
> oPPS(0)  .kPPS.   0 l-   16  3770.000   -4.023   0.355
> *SHM(0)  .GPSD.   1 l-8  3770.0001.894   1.650
>  LOCAL(1).LOCL.   3 l 1302800.0000.000   0.000
>
> * COLDSTART *
> Every 1.0s: ntpq -pPI3: Tue Oct 31 07:44:09 2017
>  remote   refid  st t when poll reach   delay   offset  jitter
>==
> oPPS(0)  .kPPS.   0 l   178  3740.000   -2.423   0.661
> *SHM(0)  .GPSD.   1 l   178  3740.000   -0.057   0.652
>  LOCAL(1).LOCL.   3 l 1583800.0000.000   0.000
>
> *after COLDSTART *
> Every 1.0s: ntpq -pPI3: Tue Oct 31 07:44:17 2017
>  remote   refid  st t when poll reach   delay   offset  jitter
>==
> +PPS(0)  .kPPS.   0 l   258  3700.000   -2.423   0.661
> *SHM(0)  .GPSD.   1 l18  3710.000  3044.83 3045.01
>  LOCAL(1).LOCL.   3 l 1591800.0000.000   0.000
>  
> *after COLDSTART *
> Every 1.0s: ntpq -p  PI3: Tue Oct 31 
> 07:44:37 2017
>  remote   refid  st t when poll reach   delay   offset  jitter
>==
> xPPS(0)  .kPPS.   0 l   458  3400.000   -2.423   0.590
> xSHM(0)  .GPSD.   1 l58  3470.000  3044.73 2573.41
>  LOCAL(1).LOCL.   3 l3810.0000.000   0.002
>
>
>
>
> ntp.conf:
>
> tos maxdist 16
> tos mindist 0.400
>
>
> server 127.127.22.0 minpoll 3 maxpoll 4
> fudge 127.127.22.0 refid kPPS flag3 1 flag2 0
>
> server 127.127.28.0 minpoll 3 maxpoll 4 iburst prefer
> fudge 127.127.28.0 time1 +0.145 flag1 1 refid GPSD stratum 1
>
> server 127.127.1.1 minpoll 3 maxpoll 4 #hwcloak
> fudge 127.127.1.1 stratum 3

That is not the hardware clock. It is the system clock. It is completely
useless.

At present there is no evidence of anything. You do not have any independent
source of time, so you have no idea what the time 

Re: [ntp:questions] GPS-PPS, standalone server. NTP

[William Unruh]

On 2017-07-06, Fida Hasan  wrote:
>
>> 
>> You mean that the fluctuation in theoffset if 1.6us. YOu have no way of
>> knowing what the actual offset is, or do you have an independent clock?
>> Ie, ntp could be adding 100ms to the time and you would not know it. 
>> (Not that that would be likely but 2 or 3 usec could be likely)
>> 
>
> Thanks William! You are right. NTP adjustment and mitigation loops play a 
> role in this part.
> I made a straightforward experiment with two Rpi that are sync with two 
> individual GPS with an offset of 1.6 micro (that what NTP shows) each. In P2P 
> mode I connected them through ethernet cable and gave one's address in 
> other's ntp.conf as a server while the node was sync with PPS-GPS in either 
> circumstance. Primarily I found their offset shows 20 microseconds!
> It is interesting because theoretically, we know that gps is highly accurate 
> in ns level. Due to some hardware jitters, there might have some additional 
> offsets but they should not be larger like that.
> I observed some experiments have been conducted in hardware level through a 
> direct connection with signal measurement instruments like the oscilloscope. 
> Those result shows the offsets between two gps receivers are around 100 ns! 
> So, the receiver I am using right now, I compared them using oscilloscope and 
> found similar offsets (100 ns). But they are as high as 20 micro in my RPi.


The gps delivers a pps pulse to its output with an delay of something
like 10-100 ns. Then the gps raises the PPS line, which is almost
certainly not terminated properly so the pulse has an indetermnate rise
time. Then the gpio triggers an interrupt at some point on that rise and
it takes a while for the computer to page out what it is now doing and
start he interrupt service routine. It then has to read out the time
from the kernel. All of that takes time, time which is not accounted
for. Basically the system says that the pps pulse occured when the clock
is read out, which is of the order of a microsecond after the gps
delivered the pps pulse to its output. To really get say 100ns
precision, you need to compensate for all of those delays. They all have
jitter as well (jitter which only increases the time delay, not
decreases it-- eg the interrupts happen to be masked when the pulse
actually comes in, the computer is busy in an non-interrruptable
routine, etc.  Ie to get into the ns regime you have to work hard on all
those delays, and you will not get it from a RPi.
Note that timing gps receivers will have a compensation for internal
delays ( which apparently tend to look like staircases) which it can
tell the computer about well after they have occured. So you can
compensate for them after the fact.
(PS it would be nice if youput line breaks ito your posts).
>
> So, along with NTP some other jitters are there. Now, my question, wheather 
> it is possible to command NTP to stop adjustment only say to fix the GPS PPS 
> with the system clock. If it is possible then I can understand how accurately 
> Rpi can produce GPS PPS signal!
>
>
>> 
>> The shm drive is one way. Another is the pps driver
>> 
>> Make sure that you have the 
>> timepps.h header file somewhere. You have to find it somewhere .
>> If you have it, and you make chrony, it woill be built witht eh PPS API
>> driver.
>> Then before starting chrony and assuming you have the pps fed into the
>> the serial port /dev/ttyS0, do
>> modprobe pps-ldisc
>> ldattach 18 /dev/ttyS0
>> 
>> Then in chrony.conf put
>> refclock PPS /dev/pps0
>> 
>> and you should be set up.
>
> I followed your guide and tried with Chrony. Very unfortunately I can not 
> develop Chrony in my system.
> Problems are:
>
> 1 If I install Chrony from repository (apt-get install chrony), I cant 
> interface it with PPS API, and I even don't find 'chronyd' daemon in my 
> system.
>
> 2. While trying to install manually 
> (https://chrony.tuxfamily.org/doc/3.1/installation.html), it gives make error!
>
> Completely stuck! 
>
>

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

Re: [ntp:questions] GPS-PPS, standalone server. NTP

[William Unruh]

On 2017-06-21, Fida Hasan  wrote:
> On Thursday, June 15, 2017 at 2:58:07 AM UTC+10, Hans Mayer wrote:
>> Hi Fida, 
>> 
>> > However, did you ever tried to achieve 1-microsecond accuracy in your used 
>> > refid (in your case with driver 28 which NTP uses)? My primary goal is to 
>> > attain 1-microsecond accuracy bond where I can see 3 milliseconds offset 
>> > with .GPS refid.
>> 
>> Definitely not. 
>> With driver 22  I am in the +- 10 usec range. With driver 28 in millisecond 
>> range. 
>> 
>> See my blog.
>> http://blog.mayer.tv/2017/06/14/ntp-driver-22-versus-28.html
>> 
>> I assume driver 20 is very similar to 28. Both are reading serial data. 
>> 
>> I don't know if 1-microsecond is a easy goal. I am using a very cheap 
>> hardware. It's running on a BananaPI. All together about 150 EUR. With a 
>> good hardware it's maybe possible. 
>> 
>> But why do you need this ? Is it just your ambition. This I could 
>> understand. 
>> 
>> 
>> // Hans
>
> Hi Hans,
>
> I have made a stand-alone server using the only driver 20, means no other 
> servers were associated, no internet connection at all. 
> In user mode, I recorded the maximum offset as 6 microseconds. But in kernel 
> mode, the result is much better. I run the system over three days, and the 
> maximum offset comes 1.60 microseconds. From the statistical recorded data, I 
> found the average is 1.03 microseconds.
>

You mean that the fluctuation in theoffset if 1.6us. YOu have no way of
knowing what the actual offset is, or do you have an independent clock?
Ie, ntp could be adding 100ms to the time and you would not know it. 
(Not that that would be likely but 2 or 3 usec could be likely)


> Regards,
> Fida
>

> N.B. I am trying to use chrony as I found some references in favor of it. But 
> still unable to feed the GPS in it.

The shm drive is one way. Another is the pps driver

Make sure that you have the 
timepps.h header file somewhere. You have to find it somewhere .
If you have it, and you make chrony, it woill be built witht eh PPS API
driver.
Then before starting chrony and assuming you have the pps fed into the
the serial port /dev/ttyS0, do
modprobe pps-ldisc
ldattach 18 /dev/ttyS0

Then in chrony.conf put
refclock PPS /dev/pps0

and you should be set up. 


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

Re: [ntp:questions] NTP under AIX?

[William Unruh]

On 2017-05-18, Terje Mathisen  wrote:
> David Taylor wrote:
>> On 16/05/2017 19:53, Greg Moeller wrote:
>>> Is there a way to test?  It seems like I'm heading into the
>>> unknown here.  :)
>>
>> You could get a dedicated NTP box such as:
>>
>>
>> http://www.leobodnar.com/shop/index.php?main_page=product_info_id=272
>>
>> and scatter a few or a dozen around your enterprise.  Brand new
>> hardware!
>>
> That's an very good price point for a nice box. :-)

The price appears to be 300GPB. It is GPS driven, so the OP would have
to install this outside of his datacenter, where he claims there is no
possibility of getting a GPS signal. Whether he is allowed to have one
of the machines, the ntp server, live outside the datacenter is unclear,
even though it is very limited in its ability to affect any of the
machines inside (security concerns I suppose).

>
> Terje
>

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

Re: [ntp:questions] NTP under AIX?

[William Unruh]

On 2017-05-16, David Woolley  wrote:
> On 16/05/17 16:37, Greg Moeller wrote:
>> Has anyone come across the advisability of running an enterprise-wide NTP 
>> server under an AIX LPAR?
>> We're currently running NTP on old Intel hardware and the company policy is 
>> to refresh hardware on a regular basis.
>> It seems a waste to buy several new servers if we could just put the NTP 
>> service on an AIX LPAR.
>>
>
> If you are talking virtual machines, ntpd should always be run on the 
> host.  Any use on a guest should only be as a leaf node.

Remember also that you could put the ntp server onto some old or small
hardware (eg a Raspberry Pi connected to a GPS with a PPS output). These
is not necessity to run it on large fast expensive hardware. Also you
want to run it on something whose workload does not fluctuate since work
requires energy which produces heat, and the biggest enemy of accurate
clocks is fluctuating temperature of the clock crystal. The actual value of the 
temperature
does not really matter, but the fluctuations do.

But as David says, you should never try to run an ntp server on a
virtual machine. Far too much bad interaction between the virtual OS and
the actual hardware, which is what ntp is trying to control.

Of course it depends on the accuracy you want. If +-1sec is good enough
then almost anything you do will work. If you want +- 1 microseconds,
you will have to work at it and virtual machines will be a disaster. 
If you want 1ns, then you will need special hardware.


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

Re: [ntp:questions] NTP under AIX?

[William Unruh]

On 2017-05-16, Greg Moeller  wrote:
> On Tuesday, May 16, 2017 at 10:37:55 AM UTC-5, Greg Moeller wrote:
>> Has anyone come across the advisability of running an enterprise-wide NTP 
>> server under an AIX LPAR?
>> We're currently running NTP on old Intel hardware and the company policy is 
>> to refresh hardware on a regular basis.
>> It seems a waste to buy several new servers if we could just put the NTP 
>> service on an AIX LPAR.
>
> I'm at a large company, serving NTP to over >1000 systems.

> Policy is that we can't have old hardware, so they will spend several 
> thousand $$ on servers to run a single process.  (we're an IBM/Lenovo based 
> shop)

Raspberry Pi is not old hardware. 

>
> Technically, yes, this is a virtual machine, but this is on 250K$+ hardware, 
> not something like ESXi or Xen.

Unfortunately ntp does not look at the price tag on the machine. It is
still a very bad idea to run ntp as a server on a virtual OS. 


> (and CPU/RAM/hardware can be dedicated to the LPAR if needed)


> These boxes are meant for heavy lifting, the same type of frames power AIX, 
> iSeries, IBM mainframe, and Watson.

My semi costs $100 and does very heavy hauling. What do you mean I
cannot enter it into the Indie 500?


>
> Is there a way to test?  It seems like I'm heading into the unknown here.  :)

No. It is not unkown. It is well known. It is a bad idea.


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

Re: [ntp:questions] NTP under AIX?

[William Unruh]

On 2017-05-16, Greg Moeller  wrote:
>> My semi costs $100 and does very heavy hauling. What do you mean I
>> cannot enter it into the Indie 500?
They would not allow me to do so.

> Of course you can.  Will it do very well in the race?  Possibly not.  But it 
> wouldn't have to pit so maybe it could be a tortoise/hare thing.  :)
> You can also haul a load of merchandise to a warehouse with a panel truck or 
> a pickup truck.  Is it very good at it?  Probably not. 
> Is the IBM P series hardware very good at multitasking?  Yes, yes it is.  
> (that's what it's main/only job is)
>> 

Precisely. It would not be very good at it. 

>> 
>> >
>> > Is there a way to test?  It seems like I'm heading into the unknown here.  
>> > :)
>> 
>> No. It is not unkown. It is well known. It is a bad idea.
> Technically, running NTP on unix isn't a very good idea as all unix systems 
> are multitasking and can get busy/lose time.  I suppose the question is how 
> sloppy any given system might be.

The cpu has a cycle counter in it. That counter does not care that the

system is multitasking. Ie the time counting is not a software clock.  

Can one put a ntp onto a virtual machine. Yes. Does it give great time?
No.


> A nice oven-controlled-crystal dedicated system running a dedicated OS just 
> for time keeping would serve the best time.

Yes. But again it depends on its time source. Using a gps receiver with
a PPS output will give time to a few microseconds of UTC. If you are
serious about time for your systems, get a gps. You can run a coax out
to a window somewhere where you put the gps antenna. A hundred feet of
coax should get you out to window-- preferably facing south with a
realtively clear viewof the sky.  If needed you can
compensate for the time delay along that cable ( about 1.5ns per foot if
you require that accuracy-- you still have not told us what accuracy
you want. ).

Re your people-- don't call it a computer. Call it an ntp time source.
Make a nice box for it if nessary and still come in well under the spare
change limit in your organization.

But yes, a nice oven controlled crystal dedicated system would serve
time best. You can buy them. Of course the time that the computers in
your organization got from it would be much less accurate, and probably
no worse than if youuse an RPi with a Sure GPS receiver (about $80-- 100
with box).





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

Re: [ntp:questions] NTP under AIX?

[William Unruh]

On 2017-05-16, Greg Moeller <skyw...@gmail.com> wrote:
> On Tuesday, May 16, 2017 at 3:36:07 PM UTC-5, William Unruh wrote:
>> Yes. But again it depends on its time source. Using a gps receiver with
>> a PPS output will give time to a few microseconds of UTC. If you are
>> serious about time for your systems, get a gps. You can run a coax out
>> to a window somewhere where you put the gps antenna. A hundred feet of
>> coax should get you out to window-- preferably facing south with a
>> realtively clear viewof the sky.  If needed you can
>> compensate for the time delay along that cable ( about 1.5ns per foot if
>> you require that accuracy-- you still have not told us what accuracy
>> you want. ).
> That would imply there are windows.  This is one of those places with 
> trapping passages in case intruders try to storm the datacenter, windows 
> would be a fatal weakness.  :)

There are no windows anywhere in the building? Then mount it outside on
the wall:-) Ie, I did not assume there were windows inside the
datacenter but somewhere on the same floor as the datacenter that you
could run a line to. 


>> 
>> Re your people-- don't call it a computer. Call it an ntp time source.
>> Make a nice box for it if nessary and still come in well under the spare
>> change limit in your organization.
>> 
>> But yes, a nice oven controlled crystal dedicated system would serve
>> time best. You can buy them. Of course the time that the computers in
>> your organization got from it would be much less accurate, and probably
>> no worse than if youuse an RPi with a Sure GPS receiver (about $80-- 100
>> with box).
>
> I'm looking at simple stable time.  Time used to come from AD servers keeping 
> their own time.  Standing there with a pocket watch would be an improvement 
> over that.

Simple stable time does not really mean much. What accuracy do you want?
Seconds, msec, usec, nsec? All have different solutions.



> Currently, we have 3 DMZ servers getting time from the internet (stratum 2 
> and 1), then 2 NTP servers inside the DMZ getting time from those 3 servers.  
> The inner environment then gets time from those two. (AD also gets it's time 
> from the 3 DMZ servers, putting them on equal footing, stratum-wise)

So the DMZ has a tunnel under it-- the connection of the inside to the
outside ntp.
An since the outside ones all serve all the inside ones, that hole is
really wide open. Exactly what is the purpose of this DMZ?
One or two cables o gps receivers outside, which are pretty hrd to
subvert, would seem to be safer than this.

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

Re: [ntp:questions] NTP under AIX?

[William Unruh]

On 2017-05-16, Greg Moeller  wrote:
> On Tuesday, May 16, 2017 at 2:07:01 PM UTC-5, Terje Mathisen wrote:
>> Greg Moeller wrote:
>> > On Tuesday, May 16, 2017 at 10:37:55 AM UTC-5, Greg Moeller wrote:
>> >> Has anyone come across the advisability of running an enterprise-wide NTP 
>> >> server under an AIX LPAR?
>> >> We're currently running NTP on old Intel hardware and the company policy 
>> >> is to refresh hardware on a regular basis.
>> >> It seems a waste to buy several new servers if we could just put the NTP 
>> >> service on an AIX LPAR.
>> >
>> > I'm at a large company, serving NTP to over >1000 systems.
>> > Policy is that we can't have old hardware, so they will spend several 
>> > thousand $$ on servers to run a single process.  (we're an IBM/Lenovo 
>> > based shop)
>> >
>> > Technically, yes, this is a virtual machine, but this is on 250K$+ 
>> > hardware, not something like ESXi or Xen.
>> > (and CPU/RAM/hardware can be dedicated to the LPAR if needed)
>> > These boxes are meant for heavy lifting, the same type of frames power 
>> > AIX, iSeries, IBM mainframe, and Watson.
>> >
>> > Is there a way to test?  It seems like I'm heading into the unknown here.  
>> > :)
>> >
>> There is indeed a way to test: "Just do it!"
>> 
>> I worked for many years in a similar enviroment (large multi-national 
>> corporation with factories/offices in 100+ countries), our LPAR based 
>> AIX machines were very stable.
>> 
>> Terje
>> 
>> PS. I did use to run our ultimate NTP reference clock on a hand-soldered 
>> GPS board hanging on the side of a FreeBSD (v 4.x probably, i.e. a long 
>> time ago) box under my desk.
>> 
>> A number of years later I finally got the money to do a proper job, 
>> that's when I setup 3-4 geo-distributed GPS-based Stratum 1 clocks (from 
>> 3 different vendors), with a second layer of 6+ Stratum 2 machines.
>> 
>> The S2 machines used all of the S1 servers plus a set of vetted external 
>> S1 and S2 reference servers. All other internal machines used all the S2 
>> servers as their configured sources.
>> 
>> -- 
>> - 
>> "almost all programming can be viewed as an exercise in caching"
>
> Ok, I'm good with 'just do it'!  :)
> So, as a test.  If I setup 2 servers(Physical x86 and AIX LPAR) with the same 
> external sources, how can I test them against one another?  I've dabbled in 
> NTP for years but never delved far into the deeper numbers.
>
The best way is to attach a GPS/PPS to each of the computers, do not
take time from them, but look at the time on the PPS pulse. Th
fluctuation of that wil give you a feeling for the accuracy of the two
methods.

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

Re: [ntp:questions] Registering a new reference clock driver to NTP4

[William Unruh]

On 2017-02-21, Erdem Ersagun  wrote:
> 28 Kasım 2016 Pazartesi 16:19:51 UTC+3 tarihinde Terje Mathisen yazdı:
>> Erdem Ersagun wrote:
>> > Hello,
>> >
>> > I couldn't find any documents clarifying the process to apply for a
>> > new reference clock driver.
>> >
>> > Here in our projects, we use a custom time card (reference clock) for
>> > time synchronization among multiple network peers. We developed a
>> > software which reads the time from the device and adjusts the
>> > operating system time. Now we want to replace our software with NTP4
>> > and want to register this time card to NTP world and contribute any
>> > header/source files so that we can use standard NTP distributions.
>> >
>> > How can we reserve a reference clock ID defined in .include/ntp.h
>> > file? When I downloaded the NTP source code it says "If you want to
>> > add a new refclock let us know and we'll assign you a number." in the
>> > README.refclocks file. But no contact is given.
>> 
>> By far the easiest method to interface with a new clock is to write a 
>> SHM (Shared Memory) driver for it!
>> 
>> There are multiple examples of people who have already done this, a 
>> little bit of googling should find them for you.
>> 
>> Good Luck!
>> 
>> Terje
>> 
>> -- 
>> - 
>> "almost all programming can be viewed as an exercise in caching"
>
> Thank you for your reply. I should clarify my question:
>
> We have already prepared our reference clock driver which uses the address 
> "127.127.47.0". 
> 47 is not used in ntp-4.2.8p8. Now we want to commit our reference clock 
> driver to ntp community so that ntp will provide built-in support to our 
> reference clock just like Bancomm or any other reference clock listed in 
> ntp.h header file.

If this is some special hardware clock that is unique to you and your
place, why do it. If you want to sell it, and expect others to adopt it,
then it should be possible. But this would mean ntpd committing to
supporting that driver, when you go ahead and make major changes in it.
and they might wonder if this is just you trying to offload your support
to others. Many of the reference clocks that ntpd now supports are
obsolete, and it is not clear that a better way is not to supply a
entrance into ntpd (like the shm driver), separatig ntpd out from the
details of those drivers. 
>
Ie, why is is it better to have a special driver rather than making use
of the generic entry ports? What is so special about your clock that
that is not a better solution?
> Is it possible?

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

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

[William Unruh]

On 2017-02-03, sean <s...@sean.eternal-september.org> wrote:
> On 2017-02-02, William Unruh <un...@invalid.ca> wrote:
>>>>
>>>> Another low-cost device is the Sure evaluation board:
>>>>
>>>>http://www.satsignal.eu/ntp/Sure-GPS.htm
>>>>
>>>>  
>>>> http://www.ebay.com/itm/SKG16A-Bluetooth-RS232-USB-UART-GPS-Module-Demo-Board-/230844194302
>>>>
>>>
>>> Thanks for the link! That's about half the price of the garmin and would
>>> likely get me better precision than just syncing to the NTP pool.
>>
>> Yes.
>>>
>
> Just curious, any experience with those?

Sure:-) Loads of it. I have used a couple for the past 4 years. Work
well. Needs a little bit of work to get out the PPS signal (soldering a
wire between a couple of points on the board). The GPS18 (both samples I
had) I found would
die after a few years. No idea why. Have not had that problem with the
Sure boards, except one antenna was flakey and then died after a few
months. No support from Sure-Electronics for that, so it seems it is a
WYSIWYG. (Mind you a new antenna was just a copule of bucks, and a
month wait. The free shipping is paid for in shipping time).


>
>>>> Windows uses NTP but not with the reference implementation, so of 
>>>> unknown quality, and not manageable in the same way.  It used to be 
>>>> lousy, and I've not tested since then.
>>>>
>>>
>>> I think I'll install the ntp client on my windows machine and see what
>>> kind of time I can get.
>>
>> You would probably be better off syncing a linux machine to the gps
>> board and then syncing the windows machine to that over the local Lan.
>>
>>
>
> Yes, but if the windows machine isn't at home, it won't sync. Allowing
> remote access will come later. :)

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

Re: [ntp:questions] How common is LI=3 (clocks not synchronized)?

[William Unruh]

On 2017-02-03, Miroslav Lichvar  wrote:
> On 2017-02-03, Jakob Bohm  wrote:
>> On 03/02/2017 04:15, Robert Scott wrote:
>>> When the two LI bits come back as 11 (clocks not synchronized) I have
>>> been treating that as a fatal error for that server.  I ignore that
>>> packet and do not attempt to retry my query for that server.  However
>>> I have found that LI=11 is not all that uncommon for servers from the
>>> pool.  Is my response to LI=11 the correct one?  Should I discard the
>>> response and should I write off that server for retries?  So far, the
>>> only reason I might retry a server is if my recvfrom() socket call
>>> times out.
>>>
>>
>> I suspect this is the expected response from a time server which has
>> recently booted and has not yet synchronized itself, probably combined
>> with stratum=15 or more.  But I haven't double checked this against
>> code or RFCs.
>
> Another reason for the "unsynchronized" leap bits might be a recent step
> of the system clock. If the clock is unstable, ntpd may need to step the
> clock often (after reaching the threshold of 128ms). I think I've
> seen some servers in the pool that behaved like that.

Those pool sources you probably would want to blackball.
>

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

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

[William Unruh]

On 2017-02-02, sean  wrote:
> On 2017-02-01, David Taylor  wrote:
>>
>> Sean,
>>
>> Thanks for your comments - much of the Web site is comprised of my own 
>> notes to remind me what to do next time!  Still waiting for one minor 
>> operation, and then to see if (or should it be when?) the Crohn's returns.
>>
>
> Well your self made notes for yourself have proven to have a rich amount
> of helpful information. :) Keep the faith with your healing.
>
>> Unfortunately I can't be part of the pool as my ISP doesn't offer static 
>> addresses.
>>
>
> I posted a followup whether a hostname could be used in lieu leui of an
> IP address. I understand it can't change every few hours/days. Does your
> changed that frequently?
>
>> I don't know whether FreeBSD is better than Linux any more, others will 
>> need to answer that.  My FreeBSD box refused to update from FreeBSD 7 to 
>> FreeBSD 8, so I stuck Linux on it in desperation!
>
> Wow, those versions are well before my time with FreeBSD. I'm not sure
> if I'll be that concerned about the OS, and rather focus on the GPS
> equipment you linked to below.
>
>>
>> Another low-cost device is the Sure evaluation board:
>>
>>http://www.satsignal.eu/ntp/Sure-GPS.htm
>>
>>  
>> http://www.ebay.com/itm/SKG16A-Bluetooth-RS232-USB-UART-GPS-Module-Demo-Board-/230844194302
>>
>
> Thanks for the link! That's about half the price of the garmin and would
> likely get me better precision than just syncing to the NTP pool.

Yes.
>
>> Windows uses NTP but not with the reference implementation, so of 
>> unknown quality, and not manageable in the same way.  It used to be 
>> lousy, and I've not tested since then.
>>
>
> I think I'll install the ntp client on my windows machine and see what
> kind of time I can get.

You would probably be better off syncing a linux machine to the gps
board and then syncing the windows machine to that over the local Lan.


>
>> What will be good enough depends on your needs.  The lowest cost might 
>> be the Sure board attached to an existing FreeBSD box, running 24 x 7 
>> and in as stable a thermal environment as necessary.  Both the Raspberry 
>> Pi and BeagleBone Black are low-power devices and therefore low-cost to 
>> run 24 x 7, with the BBB having a slightly better Ethernet 
>> implementation if you need to get down to the tens of microseconds 
>> level, but with the Raspberry Pi have a much wider support even though 
>> it might offer (approx) fifties of microseconds.  Judge for yourself here:
>>
>>http://www.satsignal.eu/ntp/BBB-vs-RPi.html
>>
>> If you already have an RPi doing something, adding a NTP server to its 
>> tasks will make little extra load for an environment with a thousand or 
>> more clients
>>
>
> Incidentally I do have a BBB and a few raspberry pis. The BBB goes back
> and forth to/from work so I won't be able to use that as the NTP host.
>
> As an aside, have you done anything with SDR? You may be interested in
> this:
> https://github.com/flightaware/piaware
>

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

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

[William Unruh]

On 2017-01-30, sean  wrote:
> Hi All,
>
> I'm real interested in NTP and accurate time, hence why I'm on this
> newsgroup. I would like to look into getting a time sensor and I hear
> the Garmin GPS 18X is what some folks run unless they need much more
> precision. Is this still a pretty well regarding GPS unit for pretty
> accurate (I know that's highly subjective) time keeping? This would be
> a hobbyist thing and I'm not running an important business, if you were
> going to ask.
>
> Next question...Do most folks here use the NTPD client, or it is a
> mixture of Chrony and openNTPD? Maybe some folks just go with what ships
> with their OS?

You do not say which OS you use. Windows (which version?), Mac, linux,
BSD?

chrony does not work on windows. ntpd is what what tends to ship with
linux distros. chrony gives better time discipline but has a smaller
user group. 

> The comparison chart is pretty nice and lays each option out nicely:
> https://chrony.tuxfamily.org/comparison.html
>
> I think that's all for now. Feel free to provide any URLs to any
> resources I should check out about time sycing, NTP, etc. 

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

Re: [ntp:questions] Writing the drift file

[William Unruh]

On 2015-03-07, Magnus Danielson mag...@rubidium.dyndns.org wrote:
 Harlan,

 On 03/07/2015 12:12 PM, Harlan Stenn wrote:
 OK, a fair amount of good stuff is being discussed.

 Do we mostly all agree that the purpose of the drift file is to give
 ntpd a hint as to the frequency drift at startup?

 If so...

 The current mechanism is designed to handle the case where ntpd is
 restarted fairly quickly, so there's a good chance the same drift value
 will work.

 Remember that for embedded devices, the operational conditions may be 
 such that it's not a quick restart at all times. You cannot assume and 
 know when it will go up the next time after being powered off. It can be 
 minutes, hours, weeks, years.

 Just like the leap-second file, the time of the drift-file is relevant, 
 and if it is too old, it is one (of several) reasons to disqualify it.

 Relying on the time-stamp of the file can be trouble-some, as it may not 
 be respected by file-management. Writing it into the file is more robust.

I suppose one could have ntpd calculate several drifts-- averaged over
now, 1 hr, one day, one week and record them into the drift file, and
have ntpd pick which one to use based on the current best estimate of
the time elapsed since the drift file was written ( which could be
stored in the file as well.) The question is whether or not the
additional complexity in the file and the added code to ntpd would be
worth it. Most programs grow by this kind of gradual accretion.
Wouldn't it be nice if the program did this and it is implimented (it
is not that hard to stick it in) even if this is only used by one
person in a million. And gradually the program becomes an unsupportable mess,
with bugs hiding all over the place.


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

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

[William Unruh]

On 2015-03-07, Neil Green nc...@hotmail.co.uk 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?

I vote for No benefit.

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

Re: [ntp:questions] Writing the drift file

[William Unruh]

On 2015-03-06, Terje Mathisen terje.mathi...@tmsw.no wrote:
 Jochen wrote such a nice synopsis that I can only add my vote for a 
 single write of the average drift over a long time period, i.e. somthing 
 like this:

 a) Collect and average the values that would have been written every 
 hour, then write this out to the file system after 24 or 48 hours, i.e. 
 long enough to average out any day/night or AC changes.

 b) Write a new value every week, but only if the average has changed sp 
 much that the control loop can overshoot after a full restart.

Often the drift file is used, not on computers that are shut down for
days at a time, but briefly. (eg a crash, or maintainance shutdown).
Then you would want the current drift when you start up again. Ie, the
useage profile varies.


 The latter value can probably be calculated:

nptd does not like to remember stuff. This would demand that it remember
the drift over long time periods (of course on could do the averaging by
adding in some tiny fraction
avdrift= (1-e)*avdrift +e*currentdrift.
and this would effectively average over 1/e periods. 
And e could be user selectable via a fudge factor, between 0 and 1. )


 We know that a modern ntpd will handle a missing drift file much better 
 than a badly wrong one, so lets start with a drift file which is 100 ppm 
 in error:

 This results in an offset of 26 ms in 4 polling period of 64 seconds 
 each, so even with a default minpoll 6 value we will not go outside the 
 128 ms limit before active steering fixes the bad drift value.

Well, no that forgets the clock filter algorithm. With poll 6 the
measurements are 64 sec apaprt, but the selected ones are more like 8
min apart (smallest delay of the past 8) . That would certainly send the clock 
out of bounds. 


 Terje

 Jochen Bern wrote:
 On 03/06/2015 10:35 AM, Harlan Stenn wrote:
 A while ago we got a request from the embedded folks asking for a way to
 limit the writing of the drift file unless there was a big enough
 change in the value to warrant this.
 [...]
 I'm wondering if we should just let folks specify a drift/wander
 threshold, and if the current value is more than that amount we write
 the file, and if the current value is less than that amount we don't
 bother updating the file.  If folks are on a filesystem where the number
 of writes doesn't matter, no value would be set (or we could use 0.0)
 and it's not an issue.

 Thoughts?

 *Thoughts* I have, but no clear conclusion, I'm afraid ...

 0. There's limiting the write ops, and then there's being all out to
 avoid them. Saying that the value should *never* be written unless the
 difference exceeds the threshold suggests the latter, is that actually
 the request? From a sanity POV, *some* timeout (say, a month) and/or
 writing triggered on orderly shutdowns sound like something we'ld want
 to do.

 1. What about *appending* to the file (up to some length limit) instead
 of overwriting the exact same bytes within it? Is that something that
 flash RAM and its specialized fs'es can handle better?

 2. What's actually the worst-case scenario here? Let's assume a unit
 whose drift is correlated with the 24h temperature cycle, -6 ppm at
 daybreak, +6 ppm in the early afternoon, and the limit is a delta of 10
 ppm. Now, if the drift file gets initially written with an intermediate
 value of abs(x)4, it'll *never* get rewritten - but otherwise, there
 will be two writes per day for all eternity, as the mechanism doesn't
 allow the stored value to ever gravitate to the middle ground. Is that
 something that should be taken care of?

 3. What's the purpose of that stored value? IIUC ntpd only ever reads it
 on startup, and the inherent assumption is that it is a fairly *RECENT*
 drift value that ntpd can assume to be a proper approximation of the
 *current* drift, and compensate for it. With the new mechanism, the
 actual current drift is somewhere within +/-limit of the stored value.
 Is that still useful, as in minimizing the offset that the starting ntpd
 will pick up until it has obtained a drift estimate of its own? Or would
 it be better to have it start with some sort of *average* value of the
 drift, rather than a current value that actually isn't ... ?

 Regards,
  J. Bern




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

Re: [ntp:questions] ntpq authentication problem

[William Unruh]

On 2015-03-01, catherine.wei1...@gmail.com catherine.wei1...@gmail.com wrote:
 On Saturday, February 28, 2015 at 4:25:02 PM UTC+8, Jan Ceuleers wrote:
 On 28/02/15 08:48, catherine.wei1...@gmail.com wrote:
  I still have a doubt: the key file is generated on my PC (as the first ntp 
  server) , when I copied it to the box(client), and I changed the box's ntp 
  server to a second server 3.cn.pool.ntp.org or some other ntp servers. 
  The authentication still passes. Why is that?
 
 ntpq talks directly to the ntpd process over the network. If you run
 ntpq without specifying where the server is located it talks to ntpd on
 localhost. Which time sources ntpd uses is immaterial.


 Hi, Jan
 I specified the ntp server 3.cn.pool.ntp.org in the /etc/ntp.conf file. In 
 this case, I run ntpq :config ...   , does it still talk to ntpd on localhost 
 ? and time sources is still 3.cn.pool.ntp.org ?

3.cn.pool.npt.org is not an ntp time source. It is a dummy name, which
is filled in by pool.ntp.org. For example every time you ping that a
different address comes up

ping -c 1 3.cn.pool.ntp.org
PING 3.cn.pool.ntp.org (202.112.10.36) 56(84) bytes of data.
ping -c 1 3.cn.pool.ntp.org
PING 3.cn.pool.ntp.org (202.112.31.197) 56(84) bytes of data.
ping -c 1 3.cn.pool.ntp.org
PING 3.cn.pool.ntp.org (202.118.1.81) 56(84) bytes of data.

Thus there is no time source 3.cn.pool.ntp.org ( or to be exact, there
are many)

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

Re: [ntp:questions] Could some one help in pointing out the error here

[William Unruh]

On 2015-02-28, catherine.wei1...@gmail.com catherine.wei1...@gmail.com wrote:
 On Saturday, April 21, 2007 at 9:50:48 PM UTC+8, Steve Kostecke wrote:
 On 2007-04-21, Remo madhu_me...@yahoo.co.uk wrote:
 
  I was not able to set a remote server's leap. It looks like the NTP
  packets from the query is not generated at all. Though the  sendpkt
  procedure is being called sendrequest, I am not able to see the
  packet reaching the other side. I guess that I am missing something as
  there is a error reported with authentication.
 
 I believe that the real issue is that you can't use writevar to set the
 leap.
 
  ntpq asso
  ind assID status  conf reach auth condition  last_event cnt
 ===
1 17284  f614   yes   yes   ok   sys.peer   reachable  1
2 17285  c000   yes   yes   badreject
  ntpq writevar 17284 leap=1
  Keyid: 64
  MD5 Password:
  ***Server disallowed request (authentication?)
 
 I have flock of systems that are set up to allow remote modification
 and have a working symmetric key set. When I tried to set the leap on
 another ntpd I see the same message:
 
 steve@stasis:~$ ntpq
 ntpq as
 ...
   2 20879  7014no   yes   ok reject   reachable  1
 ...
 ntpq writevar 20879 leap=1
 Keyid: 1
 MD5 Password: 
 ***Server disallowed request (authentication?)
 
 I've also tried setting the local ntpd leap and that fails, too:
 
 ntpq rv 0 leap
 assID=0 status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg,
 leap=00
 ntpq writevar 0 leap=1
 ***Server returned an unspecified error
 ntpq rv 0 leap
 assID=0 status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg,
 leap=00
 
  trustedkey 1234
  requestkey 61
  controlkey 64
 
 All of the keys must be listed on the 'trustedkey' line. This tells ntpd
 to trust those keys; the default is to trust these keys to authenticate
 time service. Subsets of the trusted keys may also be specified on the
 'trustedkey' and 'requestkey' lines if you wish to allow the use of
 certain keys by ntpdc and ntpq.
 
 This is discussed in the distribution documentation at
 http://www.cis.udel.edu/~mills/ntp/html/authopt.html#symm (the emphasis
 is mine):
 
 When ntpd is first started, it reads the key file specified in the keys
 configuration command and installs the keys in the key cache. HOWEVER,
 INDIVIDUAL KEYS MUST BE ACTIVATED WITH THE TRUSTEDKEY COMMAND BEFORE
 USE. This allows, for instance, the installation of possibly several
 batches of keys and then activating or deactivating each batch remotely
 using ntpdc. This also provides a revocation capability that can be used
 if a key becomes compromised. THE REQUESTKEY COMMAND SELECTS THE KEY
 USED AS THE PASSWORD FOR THE NTPDC UTILITY, WHILE THE CONTROLKEY COMMAND
 SELECTS THE KEY USED AS THE PASSWORD FOR THE NTPQ UTILITY.
 
 This is also documented in section 6.1.3.3 at
 http://www.eecis.udel.edu/~ntp/ntpfaq/NTP-s-config.htm
 
  Is this possible to work without authentication. Please help.
 
 You could disable authentication when ntpd is started, but this will
 leave your ntpd open to being remotely modified by anyone who can
 connect to it.

Or could you not use restrict to restrict who is able to change things
on your machine. That does not necessarily stop people from getting time
from it (not sure what you meant by anyone who can connect to it)

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

Re: [ntp:questions] chrony as a server

[William Unruh]

On 2015-02-24, Paul tik-...@bodosom.net wrote:
 On Tue, Feb 24, 2015 at 1:14 PM, Charles Swiger cswi...@mac.com wrote:

 On Feb 23, 2015, at 11:57 PM, David Woolley david@ex.djwhome.demon.invalid
 wrote:
  On 23/02/15 21:23, William Unruh wrote:
  manual corrections are probably good to 1 sec.
 
  It's a long time since I did this, but 200ms is more like it

 However, if you time things with a rhythm you can get to ~50 ms or better


 While these performance anecdotes are interesting they (starting with
 unruh@invalid) are all anecdotes.  I didn't mention research and real
 numbers by accident.

 The underlying assertion is that the chrony method offers some value and is
 superior to NTPd.  So I'd like something more than hand-waving regarding

It is superior in that you can do it easily. Whether that is of any
importance to you is of course up to you. Myself I have never used it.

 the performance and if it's better than just setting the clock once and a
 while I'll write something to create a drift file based on the operator
 listening to USNO ticks (or Emerald Time if you have it) and pressing
 return at the right time.

Fine. It has already been written for chrony. For those that want it,
this is an advantage for chrony. I could argue that ntpd is
no better than nothing because I could write a program to do what ntpd
does. While (possibly) true, it is a silly argument.





 Someone else can do a version that uses a microphone to listen to the ticks
 -- a stone-age ACTS driver.

 With regard to return on investment and underlying arguments about
 advantages.  I don't buy the Well someone may want to do this so it's
 worthwhile argument.  Doing something foolish or stupid doesn't make
 Chrony better than NTPd.

It is not either foolish or stupid. It was written because Curnoe had a
bunch of computers that spent  a lot of time disconnected from the net.
He had a need. Others may or may not. But if you do, then chrony's
having it is an advantage. If you have no need it is not an advantage to
you, but there are lots of things in most programs that I never have a
need for, but their being there is still an advantage of those programs
(assuming the presense does not mess other things up).


 Or to put it another way -- NTPd is about precise time transfer and it
 protects you from falsetickers like your wristwatch.

Your wristwatch may well be a much better ticker than the localclock is
(seconds per year rather than hours per year.)
 And listening to the time signal on the radio (At the beginning of the
 long dash it is exactly 12:00 for those that live, or lived in
 Canada) is much better than seconds per year. 


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

Re: [ntp:questions] chrony as a server

[William Unruh]

On 2015-02-25, Paul tik-...@bodosom.net wrote:
 On Tue, Feb 24, 2015 at 3:22 PM, Charles Swiger cswi...@mac.com wrote:


 Data is available.  Feel free to review the papers referenced from:


 I was unclear.  I mean specific research regarding disciplining a clock via
 manual correction not human coordination or fine motor control.

 As I said, an unbiased assessment of long term corrections using manual
 correction.  Not well theory says speculation either on the part of
 chrony and/or human performance.

I am still unclear as to what you would want. To use an analogy, it sounds like 
you saying
you want original research on disciplining the clock using say
tick.microsoft.com, not theory as to how ntpd works, or
tick.microsoft.com works. and evidence as to how ntpd works with any
other server is irrelevant, you want research on that particular server. 
What are you looking for, or is this just an
excercise in futility.
A human clock source is just like any other source, with an offset
accuracy somewhere between .2 and 1 seconds. Both chrony and ntpd have
been tested ad nausium with clock sources of many different kinds. We
understant them, both theoretically and experimentally. What is there
about this particular clock source that  you would want to investigate.


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

Re: [ntp:questions] chrony as a server

[William Unruh]

On 2015-02-25, Paul tik-...@bodosom.net wrote:
 On Tue, Feb 24, 2015 at 4:17 PM, William Unruh un...@invalid.ca wrote:

 It is superior in that you can do it easily. Whether that is of any
 importance to you is of course up to you. Myself I have never used it.


 As is often the case you completely miss the point.

As is often the case, you have no point to make.


 Fine. It has already been written for chrony. For those that want it,
 this is an advantage for chrony. I could argue that ntpd is
 no better than nothing because I could write a program to do what ntpd
 does. While (possibly) true, it is a silly argument.


 If there's an real use case for the feature then writing a few lines of
 some scripting language to implement an equivalent solution for NTPd is not
 a significant effort.


Again, you cannot read. The claim was this feature was the same as
orphan or local mode. You seem to now agree that it is not. That was my
point. 


 If such an add-on was available for NTPd would you stop or would you
 continue asserting that Chrony has some unproven advantage.  And until
 someone shows the level of correction you can expect then it remains
 unproven speculation.


As I have said, I do not use it. It is a difference from ntpd. If ntpd
had it then I would agree it is not a difference or an advantage for
chrony. But until it is written it is. 

So go ahead and write it, When you do and get it incorporated into ntpd, 
I will advocate removal of that sentence
from the description of the advantages of chrony in the docs. 
 I do not expect to have to do so anytime soon.



 (assuming the presense does not mess other things up).


 Yeah there's always that.


 Your wristwatch may well be a much better ticker than the localclock


 Well mine isn't but that wasn't the point.  Come back when you have real
 measurements of an end-to-end system.  I don't care about the time source.
 You assert that there's an advantage to disciplining a clock by hand versus
 free-running.  So come back in a year and tell me how it went.

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

Re: [ntp:questions] chrony as a server

[William Unruh]

On 2015-02-23, Paul tik-...@bodosom.net wrote:
 On Mon, Feb 23, 2015 at 12:53 PM, William Unruh un...@invalid.ca wrote:

 As Lichvar says with chrony
 you periodically read your watch, or listen to radio, and set the time
 and chrony figures out that you have a drift rate of about 30PPM and
 corrects. Now you may not value that possibility, which is perfectly all
 right, but some people might.


 Seems like someone should do some unbiased research and determine just how
 long it takes to find  clock drift, say to 2 ppm, using chrony with manual
 corrections.  Finding a nice (efficient) method would be useful too.

manual corrections are probably good to 1 sec. to get 1 sec at 2ppm is
about 5 days per measurement or 10 days altogether. 


 With NTPd I might set the clock, wait a month check the time and create a
 drift file.

Yes, But as Lichvar said, having the program do the work for you is
easier. You could also measure offsets by hand and use adjtimex to
adjust the clock yourself and not use either chrony or ntpd. 



 Sometimes you have to examine a use case and conclude that it's poor return
 on investment.  I think trying to discpline an uncharaterized oscillator
 with a wristwatch is certainly marginal.

Up to you. The option is there for chrony. 

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

Re: [ntp:questions] chrony as a server

[William Unruh]

On 2015-02-23, Harlan Stenn st...@ntp.org wrote:
 Miroslav Lichvar writes:
 On Sat, Feb 21, 2015 at 07:02:28PM +, David Taylor wrote:
  On 21/02/2015 17:52, William Unruh wrote:
  []
  It will do that too. The crucial item there is the only method of time
  correction is manual entry which is different from ntpd and orphan
  mode. I have no idea why this conversation is continuing. The two are
  different. The two methods are trying to solve the same problem
  (timekeeping of isolated systems) but doing so in a different manner. If
  you like one better than the other, that is fine. But they are not the
  same.
  
  Bill, please enlighten me why I cannot, using NTP's orphan mode, set the
  time on one PC manually and have another PC sync to it?
 
 Well, you can, but it's not as easy. You need to find the orphan
 parent first (i.e. the system with the smallest refid), somehow
 figure out its phase and frequency error to the real time, and correct
 them behind ntpd's back (possibly with the date and ntptime -f
 commands).
 
 With chrony you just run chronyc -a settime xx:xx:xx once in a while
 on the server and it will do the rest for you.

 I'm not buying it.

 It's trivially easy to set up a proper orphan mesh.

 A proper network configuration will have multiple time servers on it,
 because sometimes things break.  If you want to set up something where a
 flock of machines follow a single server, that's your choice and there
 are consequences to that choice when things break.

 If you implement the recommended setup then the old local refclock
 scheme will usually pretty much just work, and an an orphan scheme will
 just work.

Of course it will work but the clocks will go wandering off, with no
way of hauling them back into time. Lets start with a single machine
with a drift rate of 30PPM. By the end of the month it will be a minute
out. So if that is working, then it works. As Lichvar says with chrony
you periodically read your watch, or listen to radio, and set the time
and chrony figures out that you have a drift rate of about 30PPM and
corrects. Now you may not value that possibility, which is perfectly all
right, but some people might. 

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

Re: [ntp:questions] chrony as a server

[William Unruh]

On 2015-02-23, Harlan Stenn st...@ntp.org wrote:
 William Unruh writes:
 On 2015-02-23, Harlan Stenn st...@ntp.org wrote:
  Miroslav Lichvar writes:
  On Sat, Feb 21, 2015 at 07:02:28PM +, David Taylor wrote:
   On 21/02/2015 17:52, William Unruh wrote:
   []
   It will do that too. The crucial item there is the only method of time
   correction is manual entry which is different from ntpd and orphan
   mode. I have no idea why this conversation is continuing. The two are
   different. The two methods are trying to solve the same problem
   (timekeeping of isolated systems) but doing so in a different manner. I
 f
   you like one better than the other, that is fine. But they are not the
   same.
   
   Bill, please enlighten me why I cannot, using NTP's orphan mode, set the
   time on one PC manually and have another PC sync to it?
  
  Well, you can, but it's not as easy. You need to find the orphan
  parent first (i.e. the system with the smallest refid), somehow
  figure out its phase and frequency error to the real time, and correct
  them behind ntpd's back (possibly with the date and ntptime -f
  commands).
  
  With chrony you just run chronyc -a settime xx:xx:xx once in a while
  on the server and it will do the rest for you.
 
  I'm not buying it.
 
  It's trivially easy to set up a proper orphan mesh.
 
  A proper network configuration will have multiple time servers on it,
  because sometimes things break.  If you want to set up something where a
  flock of machines follow a single server, that's your choice and there
  are consequences to that choice when things break.
 
  If you implement the recommended setup then the old local refclock
  scheme will usually pretty much just work, and an an orphan scheme will
  just work.
 
 Of course it will work but the clocks will go wandering off, with no
 way of hauling them back into time.

 Bullshit.  As soon as a proper time source is found the servers will use
 it.

??? That is true in both cases. The assumption was that you have a clock
which has no connectivity for months. Ie, no proper time source will be
found. The question is about disciplining the clock in that case. If
time sources are available, then yes, please use them. 


 Lets start with a single machine
 with a drift rate of 30PPM. By the end of the month it will be a minute
 out. So if that is working, then it works. As Lichvar says with chrony
 you periodically read your watch, or listen to radio, and set the time
 and chrony figures out that you have a drift rate of about 30PPM and
 corrects. Now you may not value that possibility, which is perfectly all
 right, but some people might. 

 So you are assuming that an orphan mesh kicks in at a time when there is
 an uncorrected drift of 30ppm, and this is at a site where time synch is
 important and they're OK with no proper time source for a month?

Sure. The computer starts up with no time sources availble. The drift
could well be 30PPm. 


 What would happen if chrony happened to lose its time source while there
 was an uncorrected drift of 30ppm?  Anything different?

Yes, you would feed it time manually, and it would use that as its time
source. That is what we are discussing. 


 With ntpd and chrony it's possible to adjust the frequency in this case.

It is possible sure. It is just that chrony does it differently. The
question that was raised was whether or not chrony's handling of a time
island is identical with ntpd's. It is not. Now you may not care, or may
not believe anone could be interested in the difference. But they are
different. 


 It's posts like these from you that cause me to wonder if you are just a
 troll.  It's why I tend to not respond to you, but sometimes I do
 respond to at least some of your more egregious posts.

??? Clearly you have not been following the discussion. The claim was
that chrony's ability to use manual time input as a time source was
identical with ntpd's orphan or local clock modes. All I have said is
that it is not.  No idea why you call that trolling. 



 H

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

Re: [ntp:questions] NTP with 2 servers

[William Unruh]

On 2015-02-23, Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
 On 2015-02-23 10:58, William Unruh wrote:
 On 2015-02-23, Nuno Pereira nuno.pere...@g9telecom.pt wrote:

 On 2015-02-20, Nuno Pereira wrote:
 By the answers that I've received meanwhile, we need 2 more.

 You need one more, at a minimum. Ie, with three sources one can alway
 have two outvote the one. four sources are often recommended so that
 even if one dies, or is taken offline you still have three left. Of
 course that reasoning could be extended to say that you need 10
 sources, just in case 7 went offline.
 But with 2, the system is left to hop between them if they diverge. If
 one goes offline of course there is no problem since one always wins in
 a vote with itself the only voter.

 This is why to need to roll patching across your internal time servers
 - so that no more than one is offline at one time - and your normal
 clients do not lose all their sources at once.

Two sources will do that for you as well. 
There are two failure modes. One is that a time source goes down. The
other is that a time source goes crazy (eg does not impliment leap
seconds). Two will protect you against the first, three against the
second. Four will protect against both happening at once, etc. For
rolling adjustments, three would be fine, as long as you check that all
three are behaving properly ( are not false tickers) when you take one
of them out briefly. 


 Your restricted internal clients' time will start to drift away from UTC
 as soon as NTP on their single source goes down for patching.

 If you can get multiple internal sources running with different, independent
 external or pool sources, you can peer them in an NTP subnet, and set up a DNS
 round robin list name e.g. ntp_pool, to return all internal sources, and 
 change all
 yourinternal clients to use pool instead of server e.g pool ntp_pool iburst 
 preempt.

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

Re: [ntp:questions] chrony as a server

[William Unruh]

On 2015-02-21, David Taylor david-tay...@blueyonder.co.uk.invalid wrote:
 On 21/02/2015 07:04, William Unruh wrote:
 []
 orphan mode is about a group of computers. Orphan Mode allows a group
 of ntpd processes to automonously select a leader in the event that all
 real time sources become unreachable (i.e. are inaccessible).

 chrony's is that you can enter the time by hand (Ie, by typing a current
 time and hitting enter) on a single machine.  You are the remote clock. 
 Now, how useful that
 is now adays is open to question, but in the past with telephone modems
 and flaky connections it was worth something. And if you are setting up
 something on the Hebrides or on a buoy in the Atlantic where no
 connection of anykind is possible, it could be useful.
 Ie, it IS different from orphan mode.

 Things chronyd can do that ntpd can?t:  chronyd provides support for 
 isolated networks whether the only method of time correction is manual 
 entry (e.g. by the administrator looking at a clock).

 The claim is for networks, not single machines.

It will do that too. The crucial item there is the only method of time
correction is manual entry which is different from ntpd and orphan
mode. I have no idea why this conversation is continuing. The two are
different. The two methods are trying to solve the same problem
(timekeeping of isolated systems) but doing so in a different manner. If
you like one better than the other, that is fine. But they are not the
same. 



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

Re: [ntp:questions] chrony as a server

[William Unruh]

On 2015-02-21, Rob nom...@example.com wrote:
 William Unruh un...@invalid.ca wrote:
 On 2015-02-19, Rob nom...@example.com wrote:
 Miroslav Lichvar mlich...@redhat.com wrote:
 On Thu, Feb 19, 2015 at 10:05:45AM +, Rob wrote:
 We have systems in places that are not temperature controlled and then
 chrony is much better.  I am looking for the best way to find the
 values to use in the tempcomp configuration directive.

 What resolution does the sensor have? Don't expect good results
 with 1C or 0.5C resolution that sensors on mainboards typically have.

 I am still finding out what sensor is best to use, we do have a room
 temperature sensor that has .1C resolution and is readable via snmp,
 and there are the usual sensors for board- and inlet air temperature.
 (and of course CPU temperature)

 It does not matter if it is only a course indication, the room temperature
 varies over a -10 .. 50C range (don't ask...) and a 1C resolution is not
 bad relative to that.

 It is of course the temperature of the crystal itself that is important.
 Ie, the room temp could be constant and the computer varies in its
 workload and thus its internal temperature. Unfortunately temp sensors
 on the crystal are rare in commodity computers. 

 I am not looking for a precise crystal temperature but for a ballpark
 value that will compensate for the quick temperature swings that occur
 when this system (which is in an unheated glasshouse) quickly warms up
 when the sun rises, and cools down when the sun sets.

It is the crystal temperature that determines the rate change. That
crystal temp will be affected by the room temperature (with a lag since
it it takes a while for the heat in the air to diffuse into the
crystal--I have no idea how long that is, but is probably minutes rather
than hours) how hard the machine is working (again the cpu heats up
which eventually heats up the crystal) etc. One could probably use any
of the temperature measurements that most motherboards have as proxies
for the crystal temperature and get improved performance. 

Remember that the cpu temperature can vary by 20C which is probably more
than the room does, and the motherboard forms a heat pipe from the cpu
to the crystal. 


If you really want to study this, get a gps with a PPS and track the
offset from the gps and one of those temperature measurements. You could
switch off all clock discipline so that it cannot affect your
measurements of rate as a function of temperature. Plot offset vs
temperature. Look at the averaged slope of the curve to get a measure of
how that temperature correlates with the rate. You could fit a curve
(probably a quadratic in temperature would be fine.) Or run chrony or
ntpd and plot the drift as a function of temperature with a low poll
interval. chrony would probably be better in that it  responds more
quickly to changes in drift. (chrony has some tools for helping with
this). Once you have measured this, you could use it in either the forks
of ntpd which have temperature compensation, or with chrony.


 In ntpd these events result in offset swings that are the derivative
 of the temperature.   In chrony the swings are smaller, but it may be
 deceptive because I have not yet found a completely satisfactory way
 of gathering an average offset that is similar to the offset value
 in ntpq -c rv.

chrony's offset IS an average offset. It is fit to the past N
measurements, where N varies depending on how good the linear fit is. 


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

Re: [ntp:questions] chrony as a server

[William Unruh]

On 2015-02-21, Rob nom...@example.com wrote:
 William Unruh un...@invalid.ca wrote:
 On 2015-02-19, Rob nom...@example.com wrote:
 Miroslav Lichvar mlich...@redhat.com wrote:
 On Thu, Feb 19, 2015 at 12:48:46PM +, Rob wrote:
 I am still finding out what sensor is best to use, we do have a room
 temperature sensor that has .1C resolution and is readable via snmp,
 and there are the usual sensors for board- and inlet air temperature.
 (and of course CPU temperature)
 
 It does not matter if it is only a course indication, the room temperature
 varies over a -10 .. 50C range (don't ask...) and a 1C resolution is not
 bad relative to that.

 In my tests using a sensor with 1C resolution it was barely useful
 with NTP sources and 1024s polling interval. If the sensitivity is
 around 0.1 ppm per degree, 1C resolution means the compensation
 jumping the frequency in 0.1ppm steps. That's a lot, especially if you
 compare it to the tracking skew with a refclock.

 Ok but of course we are using PPS and a 16 second polling interval.
 (or maybe the PPS refclock polls even faster although it displays 4 as
 the poll interval indicator)

 The shm refclock will get one pulse per second, and then average the
 offsets over a 16 sec period after getting rid of the outliers.

 I am not using the SHM refclock in those systems.

What are you using? Are you on ntpd or chrony? As I recall ntpd in its
pps refclock also collect say 16 outputs of PPS, finds the median, thros
away the 40% greatest outliers and reports the resultant median to ntpd
as the current offset. That is the same kind of filter chrony uses in
its shm driver.

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

Re: [ntp:questions] chrony as a server

[William Unruh]

On 2015-02-19, David Taylor david-tay...@blueyonder.co.uk.invalid wrote:
 On 19/02/2015 01:24, Paul wrote:
 []
 Chrony (in general) pros and cons: 
 http://chrony.tuxfamily.org/manual.html#Other-time-synchronisation-packages
 []

 ... whwre it says: Things chronyd can do that ntpd can?t:  chronyd 
 provides support for isolated networks whether the only method of time 
 correction is manual entry (e.g. by the administrator looking at a clock).

 Does not NTP's orphan mode and local clock driver provide this?


No. The local clock simply trusts the time (Ie all offsets are defined
to be zero) chrony takes the time as entered by hand by the operator and
uses that to determine the offset. Of course that will not be terribly
accurate ( a second is probably good), but if you are disconnected for a
month, a second is probably pretty good accuracy.


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

Re: [ntp:questions] chrony as a server

[William Unruh]

On 2015-02-19, Rob nom...@example.com wrote:
 Miroslav Lichvar mlich...@redhat.com wrote:
 On Thu, Feb 19, 2015 at 10:05:45AM +, Rob wrote:
 We have systems in places that are not temperature controlled and then
 chrony is much better.  I am looking for the best way to find the
 values to use in the tempcomp configuration directive.

 What resolution does the sensor have? Don't expect good results
 with 1C or 0.5C resolution that sensors on mainboards typically have.

 I am still finding out what sensor is best to use, we do have a room
 temperature sensor that has .1C resolution and is readable via snmp,
 and there are the usual sensors for board- and inlet air temperature.
 (and of course CPU temperature)

 It does not matter if it is only a course indication, the room temperature
 varies over a -10 .. 50C range (don't ask...) and a 1C resolution is not
 bad relative to that.

It is of course the temperature of the crystal itself that is important.
Ie, the room temp could be constant and the computer varies in its
workload and thus its internal temperature. Unfortunately temp sensors
on the crystal are rare in commodity computers. 

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

Re: [ntp:questions] chrony as a server

[William Unruh]

On 2015-02-19, Rob nom...@example.com wrote:
 Miroslav Lichvar mlich...@redhat.com wrote:
 On Thu, Feb 19, 2015 at 12:48:46PM +, Rob wrote:
 I am still finding out what sensor is best to use, we do have a room
 temperature sensor that has .1C resolution and is readable via snmp,
 and there are the usual sensors for board- and inlet air temperature.
 (and of course CPU temperature)
 
 It does not matter if it is only a course indication, the room temperature
 varies over a -10 .. 50C range (don't ask...) and a 1C resolution is not
 bad relative to that.

 In my tests using a sensor with 1C resolution it was barely useful
 with NTP sources and 1024s polling interval. If the sensitivity is
 around 0.1 ppm per degree, 1C resolution means the compensation
 jumping the frequency in 0.1ppm steps. That's a lot, especially if you
 compare it to the tracking skew with a refclock.

 Ok but of course we are using PPS and a 16 second polling interval.
 (or maybe the PPS refclock polls even faster although it displays 4 as
 the poll interval indicator)

The shm refclock will get one pulse per second, and then average the
offsets over a 16 sec period after getting rid of the outliers.

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

Re: [ntp:questions] chrony as a server

[William Unruh]

On 2015-02-19, Rob nom...@example.com wrote:
 Miroslav Lichvar mlich...@redhat.com wrote:
 My update to that after the years would be that 3x is not really the
 minimum difference. If the clock is stable enough, they can perform
 similarly.

 Indeed when a system is in a reasonably constant temperature and the
 clock happens to be good, ntpd performs similar to chrony.

As I said, I believe that one of the reasons chrony is better is because
it reacts to changes, like temp change, much faster. If there are no
changes, I suspect, but cannot prove, that they are very similar. But
most people do not have temperature controlled crystals on their
computer, and most people have variable work that their computer does,
so the internal temperature fluctuates. 


 We have systems in places that are not temperature controlled and then
 chrony is much better.  I am looking for the best way to find the
 values to use in the tempcomp configuration directive.

 Ideally there would be a program that analyzes a log of momentary
 temperature and frequency values to find the coefficients, but how
 is such a logfile even generated?

 Should I enter a tempcomp line with zero coefficients and then use
 the tempcomp logging?


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

Re: [ntp:questions] NTP with 2 servers

[William Unruh]

On 2015-02-20, Nuno Pereira nuno.pere...@g9telecom.pt wrote:

  

 In our infrastructure we had some ntp clients that don't have access to the
 world and so they are configured to use only 2 servers (by the way, the other
 have 2 more options). In reality both servers are the same, but with different
 IPs.

So you only have one server. Why have two that are the same?


  

 From time to time some clients configured in this way lose their reference for
 some short period.

  

 I know how NTP works
 (http://www.ntp.org/ntpfaq/NTP-s-algo-real.htm#Q-NTP-ALGO), and so this seems
 to be caused by both 2 servers or just 1 of them not have survived.

 But both the clients and the servers are physically in the same place, and
 even if they aren't in the same IP network, they are in the same LAN with just
 a switch or two between them (delay is between 1 and 2 ms).

What is the switch? Smoke signals? Any switch should be a lot lot faster
than 1ms.


  

 And the question is why this does happen in the local network?

 Aren't they close enough in order to avoid a split?

  

  

 Given that, I have changed the configuration, and now they only use 1 server,
 but that is not a good solution.

But that is what you have!


 Any alternative for the configuration? More servers, most likely virtual
 servers?

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

Re: [ntp:questions] chrony as a server

[William Unruh]

On 2015-02-19, Paul tik-...@bodosom.net wrote:
 On Thu, Feb 19, 2015 at 5:34 AM, David Taylor 
 david-tay...@blueyonder.co.uk.invalid wrote:

 Does not NTP's orphan mode and local clock driver provide this?


 Refclock 1 (LOCAL/LOCL) is deprecated and I believe as of a recent release
 it's useless* but Orphan mode is intended to replace the local clock
 driver. It provides a single simulated UTC source   Note that I
 provided a link not any commentary on the correctness of the claims at that
 link.  It would be nice if the Chrony docs told the truth but likewise the
 NTP docs.

??? how do assume that the chrony docs do not tell the truth? 


 *Previously LOCL+PPS was a useful configuration, now you need (or should)
 use kernel PPS.

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

Re: [ntp:questions] chrony as a server

[William Unruh]

On 2015-02-21, Paul tik-...@bodosom.net wrote:
 On Fri, Feb 20, 2015 at 3:23 PM, William Unruh un...@invalid.ca wrote:

 ??? how do assume that the chrony docs do not tell the truth?
 ^ you



 I don't understand that sentence.

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