Re: [ntp:questions] How to get a list of > 500 ntp clients

[Mike Cook]

Are you using a standard dist?
 ntpq -c mru
gives you the client list.

The list length and size can be tailored:
ex:

# mru [maxdepth count | maxmem kilobytes | mindepth count | maxage seconds | 
initalloc count | initmem kilobytes | incalloc count |
incmem kilobytes]
  mru mindepth 5 maxdepth 100 initmem 1 incmem 1 maxage 86400


> Le 13 août 2019 à 00:34, Chris Trevino  a écrit :
> 
> 
> I’m running NTP servers on centos 7.6. I know that I can get a list of ntp 
> clients doing “ntpq -p” but I seem to remember reading somewhere that it was 
> limited to 500 clients.
> 
> Is there another method in which I can quickly get / monitor the number of 
> clients that are “attached” to my server if I plan on having a few thousand 
> clients?
> 
> Thanks
> 
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions


«  What’s the point? »
J.C.








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

Re: [ntp:questions] Garmin 18x LVC - degraded precision ?

[Mike Cook]

Hi, 
  It’s possibly on the way out. I don’t have an 18x but can get badformat 
showing if I pull the antenna on a NMEA source. Another possibility, it could 
be that you have a GPS jammer in the vicinity.  If you run your cv command in a 
loopover a day you may see some pattern in the badformat counts. 
Mike



> Le 7 août 2019 à 02:37, Brandon Applegate  a écrit :
> 
> Hello all,
> 
> First of all - I know my question technically isn’t about ntp software per 
> se.  But I figured this is probably the best audience that might know what’s 
> going on.
> 
> I have a Garmin 18x LVC connected via serial to a Linux box.  It has been 
> rock solid for years (I think I got it in 2012 ?).  I have all the usual 
> tweaks for low_latency, recommended ntp.conf fudge values, flags, etc.  I’ve 
> also used the SNSRCFG Windows software to update the firmware as well as make 
> tweaks (i.e. minimum GPS sentence output).  It has been very accurate for 
> years (i.e. in the single digit microseconds, typically close to 0).
> 
> In the past couple of weeks (maybe, regretfully I don’t have my graphing 
> running at the moment…) it seems to have crept up into the 20s.
> 
>remote   refid  st t when poll reach   delay   offset  jitter
> ==
> o127.127.20.0.GPS.0 l3   16  3770.000   -0.025   0.005
> 
> One thing I notice is that the badformat counter for clockvar is also 
> increasing, whereas I don’t think it really ever increased before:
> 
> vom@ice:~$ ntpq -c cv | grep badformat
> poll=1508, noreply=1, badformat=865, baddata=0, fudgetime2=600.000,
> 
> I haven’t made any software or config changes.  The GPS puck hasn’t been 
> moved.  I’ve rebooted the server as well as power cycled the puck.  I’m not 
> quite sure what else I can look at.
> 
> Could it be my 18x is “dying a slow death” ?  Has anyone ever seen this 
> behavior or have any advice ?
> 
> Thanks in advance.
> 
> --
> Brandon Applegate - CCIE 10273
> PGP Key fingerprint:
> 0641 D285 A36F 533A 73E5  2541 4920 533C C616 703A
> "For thousands of years men dreamed of pacts with demons.
> Only now are such things possible."
> 
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions

"Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une 
petite et provisoire sécurité, ne méritent ni liberté ni sécurité."
Benjimin Franklin

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

Re: [ntp:questions] Time server question

[Mike Cook]

> Le 24 juil. 2019 à 11:19, William Unruh  a écrit :
>> 
>> The hardware under consideration can time the pulse arrivals more
>> precisely than the interrupt delivery time, thanks to special hardware.

That tickled a grey cell. There was/is a timing product family bc635/637 time 
and frequency processors sold by Microsemi which can timestamp a PPS input 
event  to 100ns resolution.  Various OS drivers are available, but no ntp 
refclock driver AFAIK. 

> 
> 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


«  What’s the point? »
J.C.








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

Re: [ntp:questions] ntp-client does not sync with server

[Mike Cook]

That doesn’t look unreasonable. I get similar sequences at startup on the 
client.

What is your client ntp version? 

Don’t know if it is relevant, but if you want to open a bug you will have to 
upgrade to latest and try to reproduce there. 
 
> Le 21 mars 2019 à 15:52, Stefan K  a écrit :
> 
> Hello,
> 
> today I've to spend a little bit time for this, here are the tcpdump results, 
> it looks good to me:
> #client ask:
> Network Time Protocol (NTP Version 4, client)
>Flags: 0xe3, Leap Indicator: unknown (clock unsynchronized), Version 
> number: NTP Version 4, Mode: client
>Peer Clock Stratum: unspecified or invalid (0)
>Peer Polling Interval: 6 (64 sec)
>Peer Clock Precision: 0.00 sec
>Root Delay: 0 seconds
>Root Dispersion: 0 seconds
>Reference ID: (Initialization)
>Reference Timestamp: Jan  1, 1970 00:00:00.0 UTC
>Origin Timestamp: Jan  1, 1970 00:00:00.0 UTC
>Receive Timestamp: Jan  1, 1970 00:00:00.0 UTC
>Transmit Timestamp: Mar 21, 2019 14:23:59.184649604 UTC
> 
> #server answer:
> Network Time Protocol (NTP Version 4, server)
>Flags: 0x24, Leap Indicator: no warning, Version number: NTP Version 4, 
> Mode: server
>Peer Clock Stratum: secondary reference (3)
>Peer Polling Interval: 6 (64 sec)
>Peer Clock Precision: 0.00 sec
>Root Delay: 0.00921630859375 seconds
>Root Dispersion: 0.020660400390625 seconds
>Reference ID: 129.70.132.35
>Reference Timestamp: Mar 21, 2019 14:23:51.562362183 UTC
>Origin Timestamp: Mar 21, 2019 14:23:59.184649604 UTC
>Receive Timestamp: Mar 21, 2019 14:23:59.170848067 UTC
>Transmit Timestamp: Mar 21, 2019 14:23:59.170907972 UTC
> 
> At the moment I tried it with debian stretch as server, but the problem is 
> the same :(
> 
> 
> On Monday, March 18, 2019 5:18:32 PM CET Mike Cook wrote:
>> I don’t have these versions but I would suspect some DNS/routing issue. Have 
>> you tried tcpdump or other packet tracing to see if you are getting any ntp 
>> packets back. 
>> Your nmap response has an ip resolution for  timeserv.domain.ag as 
>> 194.94.xxx.xxx but this net dress is not used in the working config. 
>> 
>> 
>> 
>>> Le 11 mars 2019 à 12:38, Stefan K  a écrit :
>>> 
>>> nobody an idea?
>>> 
>>> 
>>> 
>>> On Tuesday, March 5, 2019 9:11:54 AM CET Stefan K wrote:
>>>> Hallo,
>>>> 
>>>> we have our own ntp-server which is running Ubuntu 14.04.LTS.
>>>> This Server works fine:
>>>> ntpq -pn
>>>>remote   refid  st t when poll reach   delay   offset  
>>>> jitter
>>>> ==
>>>> *178.63.9.110129.69.1.153 2 u   56  128  377   22.6580.249   
>>>> 0.053
>>>> -85.214.38.116   192.53.103.108   2 u   54  128  3772.101   -5.105   
>>>> 0.051
>>>> +37.58.57.238192.53.103.103   2 u   50  128  377   20.9710.839   
>>>> 0.114
>>>> +94.130.76.108   192.53.103.108   2 u   56  128  377   24.007   -1.009   
>>>> 0.163
>>>> 
>>>> 
>>>> But on our Debian Strech server they all got Stratum16 and doesn't sync:
>>>> ntpq -p
>>>>remote   refid  st t when poll reach   delay   offset  
>>>> jitter
>>>> ==
>>>> timeserv.domain.ag .INIT.  16 u- 102400.0000.000   
>>>> 0.000
>>>> 
>>>> 
>>>> In Debian Jessie (and the same configuration/network) it works fine and 
>>>> get a Stratum3, also an 'ntpdate timeserv.domain.ag' works on Debian 
>>>> Stretch.
>>>> 
>>>> The firewall is not a problem, because with nmap and ntp-script it works 
>>>> fine:
>>>> nmap -sU -p 123 --script ntp-info timeserv.domain.ag
>>>> 
>>>> Starting Nmap 7.40 ( https://nmap.org ) at 2019-02-26 09:25 CET
>>>> Nmap scan report for timeserv.domain.ag (194.94.xxx.xxx)
>>>> Host is up (0.00017s latency).
>>>> PORTSTATE SERVICE
>>>> 123/udp open  ntp
>>>> | ntp-info: 
>>>> |   receive time stamp: 2019-02-26T08:26:05
>>>> |   version: ntpd 4.2.6p5@1.2349-o Fri Jul  6 20:19:54 UTC 2018 (1)
>>>> |   processor: x86_64
>>>> |   system: Linux/3.13.0-161-generic
>>>> |   leap: 0
>>>> |   stratum: 3
&g

Re: [ntp:questions] ntp-client does not sync with server

[Mike Cook]

I don’t have these versions but I would suspect some DNS/routing issue. Have 
you tried tcpdump or other packet tracing to see if you are getting any ntp 
packets back. 
Your nmap response has an ip resolution for  timeserv.domain.ag as 
194.94.xxx.xxx but this net dress is not used in the working config. 



> Le 11 mars 2019 à 12:38, Stefan K  a écrit :
> 
> nobody an idea?
> 
> 
> 
> On Tuesday, March 5, 2019 9:11:54 AM CET Stefan K wrote:
>> Hallo,
>> 
>> we have our own ntp-server which is running Ubuntu 14.04.LTS.
>> This Server works fine:
>> ntpq -pn
>> remote   refid  st t when poll reach   delay   offset  jitter
>> ==
>> *178.63.9.110129.69.1.153 2 u   56  128  377   22.6580.249   
>> 0.053
>> -85.214.38.116   192.53.103.108   2 u   54  128  3772.101   -5.105   
>> 0.051
>> +37.58.57.238192.53.103.103   2 u   50  128  377   20.9710.839   
>> 0.114
>> +94.130.76.108   192.53.103.108   2 u   56  128  377   24.007   -1.009   
>> 0.163
>> 
>> 
>> But on our Debian Strech server they all got Stratum16 and doesn't sync:
>> ntpq -p
>> remote   refid  st t when poll reach   delay   offset  jitter
>> ==
>> timeserv.domain.ag .INIT.  16 u- 102400.0000.000   
>> 0.000
>> 
>> 
>> In Debian Jessie (and the same configuration/network) it works fine and get 
>> a Stratum3, also an 'ntpdate timeserv.domain.ag' works on Debian Stretch.
>> 
>> The firewall is not a problem, because with nmap and ntp-script it works 
>> fine:
>> nmap -sU -p 123 --script ntp-info timeserv.domain.ag
>> 
>> Starting Nmap 7.40 ( https://nmap.org ) at 2019-02-26 09:25 CET
>> Nmap scan report for timeserv.domain.ag (194.94.xxx.xxx)
>> Host is up (0.00017s latency).
>> PORTSTATE SERVICE
>> 123/udp open  ntp
>> | ntp-info: 
>> |   receive time stamp: 2019-02-26T08:26:05
>> |   version: ntpd 4.2.6p5@1.2349-o Fri Jul  6 20:19:54 UTC 2018 (1)
>> |   processor: x86_64
>> |   system: Linux/3.13.0-161-generic
>> |   leap: 0
>> |   stratum: 3
>> |   precision: -20
>> |   rootdelay: 31.589
>> |   rootdisp: 42.723
>> |   refid: 178.63.9.110
>> |   reftime: 0xe01f73ce.3608c5f7
>> |   clock: 0xe01f768f.e9bd2105
>> |   peer: 57654
>> |   tc: 10
>> |   mintc: 3
>> |   offset: 0.008
>> |   frequency: 27.593
>> |   sys_jitter: 1.020
>> |   clk_jitter: 0.180
>> |_  clk_wander: 0.014\x0D
>> Service Info: OS: Linux/3.13.0-161-generic
>> 
>> Nmap done: 1 IP address (1 host up) scanned in 13.75 seconds
>> 
>> and it also looks like that the client try to query the tnp-server because I 
>> can find the IP-Address of the Server under the section 'private clients':
>> nmap -sU -pU:123 -Pn -n --script=ntp-monlist timeserv.domain.ag
>> 
>> Can somebody help me with this issue?
>> 
>> Thanks in advance!
>> 
>> best regards 
>> Stefan
>> 
>> 
>> ___
>> questions mailing list
>> questions@lists.ntp.org
>> http://lists.ntp.org/listinfo/questions
>> 
> 
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions

"Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une 
petite et provisoire sécurité, ne méritent ni liberté ni sécurité."
Benjimin Franklin

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

Re: [ntp:questions] Judged falsetickers under NTPD version 4.2.0.

[Mike Cook]

> Le 9 janv. 2019 à 22:52, chorowit...@scarsdaleschools.org a écrit :
> 
> On Wednesday, March 3, 2004 at 11:38:29 PM UTC-5, Yoshinobu Onozuka wrote:
>> Hello,
>> 
>> 
>> 
>> I was using NTPD referring to two timeservers like the following setting.
>> 
>> The contents of ntp.conf
>> 
>> Server 172.16.0.1 minpoll 4 maxpoll 4
>> 
>> Server 172.16.125.92 minpoll 4 maxpoll 4
>> 
>> 
>> (minpoll , maxpoll=4 for test)
>> 
>> 

Have you never heard of the ancient truth that

«  A man with two clocks cannot know what the time is » .

So NTP can not decide which server is good , so they both get flagged.

You need to add some more servers. Have at least 5.


>> 
>> NTPD version 4.1.x was used so far and it was working normally but
>> 
>> when NTPD was updated to version 4.2.0, two timeservers became
>> 
>> judged to be falsetickers.
>> 
>> 
>> 
>> The output of ntpq - p
>> 
>> remote   refid  st t when poll reach   delay   offset
>> jitter
>> 
>> 
>> ==
>> 
>> x172.16.0.1  .TJJY.   1 u   12   16  3770.4700.082
>> 0.069
>> 
>> x172.16.125.92   .TJJY.   1 u   15   16  3770.4887.433
>> 0.226
>> 
>> 
>> 
>> The timeservers correct their time from the telephone JJY service(JST) via
>> the telephone line.
>> 
>> The time correction precision of the timeserver is 20 ms of +- / a day.
>> 
>> Generally, once a day, they call at a different timing and they correct.
>> 
>> 
>> 
>> Doesn't NTPD4.2.0 permit a time error among these two timeservers?
>> 
>> I hope that the option which can set the latitude of the falseticker
>> judgment is
>> 
>> implemented to NTPD.
>> 
>> 
>> 
>> Thank you.
> 
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions

I am not a a vegetarian because I love animals. I’m a vegetarian because I hate 
plants.

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

Re: [ntp:questions] Initial sync on starting ntpd with 20-21 minute time difference

[Mike Cook]

Karen,
> 
> Before restarting ntpd you could use ntpdate to set the clock using the -B 
> option to slew, rather than step, the clock to the correct time before 
> restarting ntpd, but your offset is so large (1260 secs), that this may take 
> a long time to complete.
> 
> On an Arm/Linux system I have I did a test with your offset and my clock is 
> slewing at a little over 0,025 secs per minute, so the correction will need 
> around 14 hours to complete.
> 

My sums were wrong…   at 0,025sec per minute, 1260 seconds correction takes 
(1260/0,025)/60/24 = 35 days

maybe too long for you.

Only other option , as Monty P suggests, is start again. 
Boot it in single user mode to prevent ntpd starting. Reset the clock. Remove 
the ntp drift file . reboot.
That will probably fix it though I have known some cases where a power cycle is 
required as active frequency corrections were not reset by hardware on a normal 
boot cycle. 


> Mike
> 

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

Re: [ntp:questions] Initial sync on starting ntpd with 20-21 minute time difference

[Mike Cook]

Karen,

> Le 24 sept. 2018 à 12:19, Karen Austin  a écrit :
> 
> Hi,
> 
> We have a RH 6.8 server with ntpd installed, but not currently running.
> 
> The time on this server is showing around 20-21 minutes ahead.
> 
> The server has been restarted and the messages log shows a successful ntpd 
> start, but it is no longer running.

This is normal as ntpd will bail out if the initial difference between the 
reference server and local clock is greater than 1000 seconds, or 16mins 40secs.
So if you restart the daemon it will just exit as before. 


> 
> I would like to attempt to manually start the daemon but am concerned that 
> the local time will then 'jump' to the correct time, which may affect 
> applications on the server.
> 

You could override this protection mechanism by using startup option -g , but 
the local clock will step to the correct time, with possible application 
issues. There is an option -x to prevent steps on time differences greater than 
128ms, but the max time difference accounted for is 600s, which is too small 
for your issue.

Before restarting ntpd you could use ntpdate to set the clock using the -B 
option to slew, rather than step, the clock to the correct time before 
restarting ntpd, but your offset is so large (1260 secs), that this may take a 
long time to complete.

On an Arm/Linux system I have I did a test with your offset and my clock is 
slewing at a little over 0,025 secs per minute, so the correction will need 
around 14 hours to complete.

Mike


> Can anyone confirm that the time will sync gradually?
> 
> Many thanks
> 
> 
> 
> 
> 
> 
> This email has been scanned for all viruses.
> 
> Please consider the environment before printing this email.
> 
> The content of this email and any attachment is private and may be 
> privileged. If you are not the intended recipient, any use, disclosure, 
> copying or forwarding of this email and/or its attachments is unauthorised. 
> If you have received this email in error please notify the sender by email 
> and delete this message and any attachments immediately. Nothing in this 
> email shall bind the Company or any of its subsidiaries or businesses in any 
> contract or obligation, unless we have specifically agreed to be bound.
> 
> KCOM Group PLC is a public limited company incorporated in England and Wales, 
> company number 02150618 and whose registered office is at 37 Carr Lane, Hull, 
> HU1 3RE.
> 
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions

People have only as much liberty as they have the intelligence to want and the 
courage to take.

Emma Goldman

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

Re: [ntp:questions] Regular spike_detect on syslog

[Mike Cook]

> Le 16 sept. 2018 à 16:34, Jan Ceuleers  a écrit :
> 
> On 16/09/18 14:15, Sean Austin Critica wrote:
>>  
>> 
>> Can I directly observe these sources and see which ones are stable
>> (maybe by dumping them periodically, remotely from a machine with a
>> known stable clock)? The OS in this case is RedHat EL 7.
>> 
>>  
>> 

you might check out 
https://www.pantz.org/software/cpufreq/usingcpufreqonlinux.html

I don’t have Redhat but I expect similar commands are available for showing 
scaling info.
The webpage mentions a Redhead package cpuspeed.
You should be able to get speed change stats from that. Works for Debian with 
their cpufrequtils commands.

It would be useful to check that you do not have any processes other than ntpd 
running or scheduled by cron, that set the clock.
Also check the clock drift rate without ntpd running. Best to do this after 
cold boot in case previous frequency mods are active.

> 
> "Directly observe": no. But you can look at the kernel log to see which
> clock source the OS has selected:
> 
> # dmesg | grep clocksource
> [0.00] clocksource: refined-jiffies: mask: 0x
> max_cycles: 0x, max_idle_ns: 7645519600211568 ns
> [0.00] clocksource: hpet: mask: 0x max_cycles:
> 0x, max_idle_ns: 79635855245 ns
> [0.053021] clocksource: jiffies: mask: 0x max_cycles:
> 0x, max_idle_ns: 764504178510 ns
> [0.181027] clocksource: Switched to clocksource hpet
> [0.198695] clocksource: acpi_pm: mask: 0xff max_cycles:
> 0xff, max_idle_ns: 2085701024 ns
> [0.906180] clocksource: tsc: mask: 0x max_cycles:
> 0x2879c5f06f2, max_idle_ns: 440795220049 ns
> [1.931401] clocksource: Switched to clocksource tsc
> 
> You can then look in your CPU's manual to determine whether the selected
> clocksource is influenced by SpeedStep (or whatever dynamic CPU speed
> changes are called these days).
> 
> HTH, Jan
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions

People have only as much liberty as they have the intelligence to want and the 
courage to take.

Emma Goldman

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

Re: [ntp:questions] Regular spike_detect on syslog

[Mike Cook]

> Le 16 sept. 2018 à 16:34, Jan Ceuleers  a écrit :
> 
> "

People have only as much liberty as they have the intelligence to want and the 
courage to take.

Emma Goldman

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

Re: [ntp:questions] Regular spike_detect on syslog

[Mike Cook]

> Le 14 sept. 2018 à 10:50, Sean Austin Critica  a 
> écrit :
> 
> Hello,
> 
> 
> I'm new to configuring NTP, and am having a bit of trouble figuring out why
> there are regular spike_detect messages on my syslog.
> 
> I already checked the connection to the NTP server and it is stable with no
> packet drops.
> Additionally, that same NTP server is used by another machine on the same
> network and it is synchronizing fine. So it seems isolated to this
> particular machine.
> 
> 
> I find one particular sequence curious. From 17:30 to 18:53, there was a
> positive spike, followed by a negative spike, followed by a positive spike
> interleaved with clock_sync.
> Can you give me some hints regarding what may be causing this?

>  kernel 0.059 PPM
> Jun  5 14:50:21 info localhost ntpd[13659]:  0.0.0.0 c615 05 clock_sync
> Jun  5 15:03:36 info localhost ntpd[13659]:  0.0.0.0 0618 08 no_sys_peer

I think that it is probably your servers clock. NTP is unable to decide if a 
potential peer is stable enough. 

> Jun  5 15:07:55 info localhost ntpd[13659]:  0.0.0.0 0613 03 spike_detect
> +0.269228 s
> Jun  5 15:16:37 info localhost ntpd[13659]:  0.0.0.0 061c 0c clock_step
> +0.303049 s

  +64 PPM if my sums are OK

> Jun  5 15:16:37 info localhost ntpd[13659]:  0.0.0.0 0614 04 freq_mode
> Jun  5 15:16:38 info localhost ntpd[13659]:  0.0.0.0 c618 08 no_sys_peer
> Jun  5 15:31:55 info localhost ntpd[13659]:  0.0.0.0 c612 02 freq_set
> kernel -186.040 PPM

Now -ve

This is anomalous . Not yet outside NTPs limit of 500ppm but modern hardware is 
usually much better.
Maybe your server is frequency shifting . Check your BIOS settings . 
Are you using VMWARE or something like it. If it is not configured correctly 
virtual systems can get duff clock states. 

< snip rest >

> 
> 
> Regards,
> Sean Critica
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions

People have only as much liberty as they have the intelligence to want and the 
courage to take.

Emma Goldman

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

Re: [ntp:questions] restrict: ignoring line %u, address/host '%s' unusable.

[Mike Cook]

Maybe you could show us the config lines that are causing your issue.
IP4 and IP6 network and IP specific restrict config lines are not causing these 
messages on my deb+p10 config.
It is deb7 however so maybe you should be talking to a Debian maintainer. 
Has your issue appeared with a Debian upgrade and was it OK before?

 
> Le 14 sept. 2018 à 08:39, Jakob Bohm  a écrit :
> 
> On 13/09/2018 07:35, David Taylor wrote:
>> On 12/09/2018 08:06, Jakob Bohm wrote:
>>> NTP 4.2.8p10+dfsg-3+deb9u2 (Debian packaged with backported security
>>> fixes), on a dual stack (IPv4+IPv6) machine logs the following error
>>> messages for each netmask specific restrict line, and does seem to
>>> ignore the lines or otherwise enforce incorrect limits:
>>> 
>>> ntpd[]: restrict: ignoring line %u, address/host '%s' unusable.
>>> 
>>> Looking at github, this seems to happen when a line doesn't match the
>>> address family (IPv4 or IPv6) of a loop iteration in the config code.
>>> 
>>> Is this a general NTP bug or did the Debian maintainer get a patch
>>> wrong.
>>> 
>>> Enjoy
>>> 
>>> Jakob
>> Isn't NTP 4.2.8p12 the current version?
>> 4.2.8p10 was March last year, sigh!
>> Hope you find the issue.
> 
> As I said at the top, this is the Debian packaged version where the
> Debian maintainer has backported later changes over multiple "patch"
> releases of the package.  Backporting fixes rather than pushing
> bleeding edge versions to users is standard Debian policy.
> 
> The latest update to the package was on Thu, 15 Feb 2018 12:45:57 +0100
> 
> Searching online for the string found a github repository of ntp with
> weird loop constructs around the message.
> 
> 
> Enjoy
> 
> Jakob
> -- 
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
> 
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions

People have only as much liberty as they have the intelligence to want and the 
courage to take.

Emma Goldman

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

Re: [ntp:questions] NTPd in embedded application slow to serve/sync time.

[Mike Cook]

> 
> 
> Anything else I can do to speed up the server to being happy about giving out 
> time?

 The usual method is to give it a good starting time at boot. You can too that 
by adding a battery (or cap) backed RTC chip and setting the system clock to 
that time before NTP starts. That will speed up convergence. If your embedded 
system is linux, the command , hwclock, is your friend.

> 
> Thanks,
> 
>  -Ben
> 
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions

Don’t worry about how powerful the machines are. Worry about who the machines 
are giving  power to.

___
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

[Mike Cook]

> Le 6 août 2018 à 03:06, William Unruh  a écrit :
> 
> On 2018-08-05, aashish.ch...@fonantrix.com  
> wrote:
>> Hi,
>> 
>> I am facing time drifting problem in my production env.

When face with this or any problem you should measure it BEFORE applying 
corrections. I have seen many admins just add NTP, only to find that the clock 
drift was too great to be corrected by NTP.
NTP will bail out if it finds a drift of over 500ppm. 
Check the value measured before correcting and see if it is within the server 
manufactures clock spec. You may have a bad board or need a firmware update.
It may also depend on the hardware context. Is your prod running in a stand 
alone server or is it in a virtual environment (container). There are tight 
constraints for running time critical stuff in containers.
Maybe your server is modifying its cpu clock frequencies depending on load. You 
will need to check and stop that.

>> 
>> 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.  

As said by others , NTP alters the clock frequency rather than setting the 
clock (unless way out).  
If you run « ntpq -c rv » you will see a variable labeled « frequency » which 
gives the clock drift that NTP is correcting for at any one time. 
The best way to evaluate this over long periods this is to enable stats logging 
and graph the loopstats drift frequency data. 
 

>> 
>> 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

Don’t worry about how powerful the machines are. Worry about who the machines 
are giving  power to.

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

Re: [ntp:questions] long time to report sync per leap indicator, when initial system time is set far into the future

[Mike Cook]

> Le 13 déc. 2017 à 08:57, Mike Cook <michael.c...@sfr.fr> a écrit :
> 
> 

> ntpq: read: Connection refused
> Wed Dec 13 06:50:30 UTC 2017
> associd=0 status=c016 leap_alarm, sync_unspec, 1 event, restart,
> version="ntpd 4.2.8p10@1.3728-o Tue Dec 12 08:45:23 UTC 2017 (1)",
> processor="armv7l", system="Linux/3.8.13-bone47", leap=11, stratum=16,
> precision=-19, rootdelay=0.000, rootdisp=0.030, refid=INIT,
> reftime=.  Thu, Feb  7 2036  6:28:16.000,
> clock=dddb4c36.78d0e3a5  Wed, Dec 13 2017  6:50:30.471, peer=0, tc=3,
> <=
> mintc=3, offset=0.00, frequency=-31.917, sys_jitter=0.00,
> clk_jitter=0.002, clk_wander=0.000, leapsec=20170101,
> expire=20170628
> Wed Dec 13 06:36:12 UTC 2017
> associd=0 status=c615 leap_alarm, sync_ntp, 1 event, clock_sync,
> version="ntpd 4.2.8p10@1.3728-o Tue Dec 12 08:45:23 UTC 2017 (1)",
> processor="armv7l", system="Linux/3.8.13-bone47", leap=11, stratum=16,   
> precision=-19, rootdelay=0.000, rootdisp=0.000, refid=STEP,
> reftime=.  Thu, Feb  7 2036  6:28:16.000,
> clock=dddb48dc.1ed39583  Wed, Dec 13 2017  6:36:12.120, peer=9799, tc=4,  
> <**
> mintc=3, offset=0.00, frequency=-31.917, sys_jitter=0.001907,
> clk_jitter=0.002, clk_wander=0.000, leapsec=20170101,
> expire=20170628

I forgot to mention:

The fact that the system clock has been updated via -g even though the server 
config cannot be validated ( leap=11) may explain why when the  OP stopped NTP 
and was able to restart it immediately after without the issue as the servers 
clock was now very close to the correct time. An argument for executing ntpdate 
before starting ntpd?

"The power of accurate observation is commonly called cynicism by those who 
have not got it. »
George Bernard Shaw

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

Re: [ntp:questions] long time to report sync per leap indicator, when initial system time is set far into the future

[Mike Cook]

> Le 12 déc. 2017 à 23:17, Mike Cook <michael.c...@sfr.fr> a écrit :
> 
>> 
>> (servers #4 ff. are assigned from pool.ntp.org)
>> 
>> But, even then, from "eyeballing" the system clock it appears correct within 
>> at least 1 s,
> 
> Odd as well. Is it possible that there is another process updating the clock. 
> I’ll try to see when I get the first clock update. 

I checked and see the clock change after four poll results returned.

Wed Dec 13 06:50:23 UTC 2017
ntpq: read: Connection refused
Wed Dec 13 06:50:28 UTC 2017
 remote   refid  st t when poll reach   delay   offset  jitter
==
 127.127.22.0.M12+.   0 l-   1600.0000.000   0.000
 192.168.1.23.INIT.  16 u-   1600.0000.000   0.002
 192.168.1.4 .G10.1 u1   1610.948  -863504   0.002
 192.168.1.17.INIT.  16 u-   1600.0000.000   0.002
 192.168.1.18.M8T.1 u1   1610.978  -863504   0.002
Wed Dec 13 06:50:34 UTC 2017
 remote   refid  st t when poll reach   delay   offset  jitter
==
 127.127.22.0.M12+.   0 l-   1600.0000.000   0.000
 192.168.1.23.GPS.1 u1   1610.279  -863504   0.062
 192.168.1.4 .G10.1 u2   1610.626  -863504   0.165
 192.168.1.17.M8N.1 u1   1610.521  -863504   0.133
 192.168.1.18.M8T.1 u2   1610.563  -863504   0.195
Wed Dec 13 06:36:16 UTC 2017
 remote   refid  st t when poll reach   delay   offset  jitter
==
 127.127.22.0.M12+.   0 l-   1600.0000.000   0.000
 192.168.1.23.GPS.1 u-   1610.3070.003   0.072
 192.168.1.4 .G10.1 u1   1610.564   -0.026   0.004
 192.168.1.17.M8N.1 u-   1610.6690.087   0.065
 192.168.1.18.M8T.1 u1   1610.5360.038   0.028
Wed Dec 13 06:36:21 UTC 2017
 remote   refid  st t when poll reach   delay   offset  jitter
==
 127.127.22.0.M12+.   0 l-   1600.0000.000   0.000
*192.168.1.23.GPS.1 u1   1610.2790.020   0.044
 192.168.1.4 .G10.1 u-   1610.5630.017   0.058
 192.168.1.17.M8N.1 u1   1610.5400.022   0.043
 192.168.1.18.M8T.1 u-   1610.505   -0.011   0.044

ntpq: read: Connection refused
Wed Dec 13 06:50:28 UTC 2017
processor="armv7l", system="Linux/3.8.13-bone47", leap=11, stratum=16,
Wed Dec 13 06:50:34 UTC 2017
processor="armv7l", system="Linux/3.8.13-bone47", leap=11, stratum=16,
Wed Dec 13 06:36:15 UTC 2017
processor="armv7l", system="Linux/3.8.13-bone47", leap=11, stratum=16,
Wed Dec 13 06:36:21 UTC 2017
processor="armv7l", system="Linux/3.8.13-bone47", leap=00, stratum=2,


ntpq: read: Connection refused
Wed Dec 13 06:50:30 UTC 2017
associd=0 status=c016 leap_alarm, sync_unspec, 1 event, restart,
version="ntpd 4.2.8p10@1.3728-o Tue Dec 12 08:45:23 UTC 2017 (1)",
processor="armv7l", system="Linux/3.8.13-bone47", leap=11, stratum=16,
precision=-19, rootdelay=0.000, rootdisp=0.030, refid=INIT,
reftime=.  Thu, Feb  7 2036  6:28:16.000,
clock=dddb4c36.78d0e3a5  Wed, Dec 13 2017  6:50:30.471, peer=0, tc=3,
<=
mintc=3, offset=0.00, frequency=-31.917, sys_jitter=0.00,
clk_jitter=0.002, clk_wander=0.000, leapsec=20170101,
expire=20170628
Wed Dec 13 06:36:12 UTC 2017
associd=0 status=c615 leap_alarm, sync_ntp, 1 event, clock_sync,
version="ntpd 4.2.8p10@1.3728-o Tue Dec 12 08:45:23 UTC 2017 (1)",
processor="armv7l", system="Linux/3.8.13-bone47", leap=11, stratum=16,
precision=-19, rootdelay=0.000, rootdisp=0.000, refid=STEP,
reftime=.  Thu, Feb  7 2036  6:28:16.000,
clock=dddb48dc.1ed39583  Wed, Dec 13 2017  6:36:12.120, peer=9799, tc=4,  
<**
mintc=3, offset=0.00, frequency=-31.917, sys_jitter=0.001907,
clk_jitter=0.002, clk_wander=0.000, leapsec=20170101,
expire=20170628

In this case where 3 or more servers are responding.
For one configured server, even though it was responding, I did not see the 
clock updated and the unsync'd status remained. However
I did not wait for more than a minute. 
For 2 configured servers, provided that both were responding I saw the same 
result as above

Re: [ntp:questions] long time to report sync per leap indicator, when initial system time is set far into the future

[Mike Cook]

> Le 12 déc. 2017 à 17:31, Stephan E.  a écrit :
> 
> 



> During that waiting period, I get a status of e.g.
> 
># ./ntpq -c peers
> remote   refid  st t when poll reach   delay   offset  
> jitter
>
> ==
> ptbtime1.ptb.de .STEP.  16 u-   6400.0000.000   
> 0.000
> ptbtime2.ptb.de .STEP.  16 u   20   6400.0000.000   
> 0.000
> ptbtime3.ptb.de .STEP.  16 u   25   6400.0000.000   
> 0.000
> ntp2.m-online.n .STEP.  16 u  770   6400.0000.000   
> 0.000
> 1c.ncomputers.o .STEP.  16 u  385   6400.0000.000   
> 0.000
> ntp1.wtnet.de   .STEP.  16 u  850   6400.0000.000   
> 0.000
> backup.heikoric .STEP.  16 u 1864   6400.0000.000   
> 0.000
> 
># ./ntpq -c rl
>associd=0 status=c018 leap_alarm, sync_unspec, 1 event, no_sys_peer,
>version="ntpd 4.2.8p10@1.3728-o Tue Dec 12 11:03:31 UTC 2017 (1)",
>processor="ppc", system="Linux/3.10.104", leap=11,
>stratum=16, precision=-18, rootdelay=0.000, rootdisp=1.620, refid=STEP,
>reftime=.  Thu, Feb  7 2036  6:28:16.000,
>clock=ddda50cf.3c52fb54  Tue, Dec 12 2017 12:57:51.235, peer=0, tc=6,
>mintc=3, offset=0.00, frequency=0.000, sys_jitter=0.003815,
>clk_jitter=0.004, clk_wander=0.000

   This confirms what I found. The reason that you are not getting any 
responses from the servers is not clear. Once I had defined 3 or 4 servers I 
had no issues. 

> 
> (servers #4 ff. are assigned from pool.ntp.org)
> 
> But, even then, from "eyeballing" the system clock it appears correct within 
> at least 1 s,

Odd as well. Is it possible that there is another process updating the clock. 
I’ll try to see when I get the first clock update. 

Have you checked your daemon log for clues. You could run ntpd in debug mode as 
well.

Have you tried running ntpdate  prior to starting ntpd. I do this when starting 
ntpd from the init script as my server has no hardware clock.

> and if I now stop and restart ntpd, I almost immediately get
> 
># ./ntpq -c peers
> remote   refid  st t when poll reach   delay   offset  
> jitter
>
> ==
> ptbtime1.ptb.de .INIT.  16 u-   6400.0000.000   
> 0.000
>+ptbtime2.ptb.de .PTB.1 u1   641   57.113   -1.902   
> 2.851
>*ptbtime3.ptb.de .PTB.1 u2   641   57.678   -1.829   
> 7.572
>+ntp2.m-online.n 212.18.1.106 2 u3   641   60.2881.178   
> 4.073
>+1c.ncomputers.o 222.217.153.82 u1   641   73.751   -0.535   
> 4.885
>+ntp1.wtnet.de   10.129.40.2112 u1   641   57.8111.985   
> 3.249
>+backup.heikoric 124.216.164.14   2 u3   641   61.142   -0.668   
> 5.216
> 
># ./ntpq -c rl
>associd=0 status=0614 leap_none, sync_ntp, 1 event, freq_mode,
>version="ntpd 4.2.8p10@1.3728-o Tue Dec 12 11:03:31 UTC 2017 (1)",
>processor="ppc", system="Linux/3.10.104", leap=00,
>stratum=2, precision=-18, rootdelay=57.678, rootdisp=192.086,
>refid=192.53.103.103,
>reftime=ddda5126.d1f40191  Tue, Dec 12 2017 12:59:18.820,
>clock=ddda512b.edb0de7d  Tue, Dec 12 2017 12:59:23.928, peer=46425, tc=6,
>mintc=3, offset=0.209764, frequency=0.000, sys_jitter=2.308874,
>clk_jitter=0.720, clk_wander=0.000

"The power of accurate observation is commonly called cynicism by those who 
have not got it. »
George Bernard Shaw

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

Re: [ntp:questions] long time to report sync per leap indicator, when initial system time is set far into the future

[Mike Cook]

> Le 11 déc. 2017 à 12:49, Stephan E.  a écrit :
> 
> I want ntpd 4.2.8p10 to sync to public servers, then serve time to a local 
> network. It is running with '-g' because initial system time on the host can 
> be far off. I observe that, when initial system time of the host was set > 5 
> minutes into the future, the time it will take ntpd to report a synced leap 
> second to its clients approaches the time of that initial offset. E.g., when 
> the initial time was erroneously set 24 hours into the future, ntpd will take 
> approximately 24 hours to report a synced time in the LI field to its 
> clients, and they will reject to sync to my host during that period.
> 
> Is this behavior to be expected, or is it likely that am I doing something 
> wrong? I would agree that it is a weird scenario, but it can not be ruled out 
> in my application.
> 

I am pretty sure that this is expected behavior and a configuration error.

I have tried and failed to reproduce this in either 4.2.8p10 or 4.2.8p9 UNLESS 
there are NOT ENOUGH sufficiently stable servers available at start up.

That is to say, that if their reach values does not tend to 377. 

for example if I have only 2 servers configured and only one is stable such as 
here:

Tue Dec 12 08:19:11 UTC 2017
 remote   refid  st t when poll reach   delay   offset  jitter
==
 time-c-g.nist.g .NIST.   1 u5   16  275   95.193  -398059   0.047
 india.colorado. .NIST.   1 u   14   16  377  130.526  -398062   0.050

The leap indicator  will remain 11, i.e. unsynchronized

Tue Dec 12 08:19:03 UTC 2017
processor="armv7l", system="Linux/3.8.13-bone47", leap=11, stratum=16,
Tue Dec 12 08:19:08 UTC 2017
processor="armv7l", system="Linux/3.8.13-bone47", leap=11, stratum=16,
Tue Dec 12 08:19:13 UTC 2017
processor="armv7l", system="Linux/3.8.13-bone47", leap=11, stratum=16,
Tue Dec 12 08:19:18 UTC 2017

So you should make sure that you select servers that have good connectivity ( 
closer is better ) and use a minimum of 5.

So to debug this,  change your date , restart ntpd with just -g and then 
monitor the server status.  If the servers are showing poor connectivity, 
change/add .

Hope this helps

> A workaround appears to be running with '-g -q' first, in which case ntpd 
> will sync and exit under 1 minute; then run without either option, in which 
> case the LI field will report a sync within approx. 300s.
> 
> Do you think the workaround is suitable, or am I inviting e.g. errors in leap 
> second handling?
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions

"The power of accurate observation is commonly called cynicism by those who 
have not got it. »
George Bernard Shaw

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

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

[Mike Cook]

> Le 5 déc. 2017 à 18:04, William Unruh  a écrit :
> 
> 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.
>> 

 If legal time is any essential parameter in the project, there are three major 
aspects that you will have take into account.
   a) Leap seconds. They are not predictable.
   b) The second NTP epoch will occur in 2036.
   c)The  32bit time_t will roll in 2038.

 The later two will get fixed nearer the dates , but you may not get updated 
OS/libraries when you need them.

>> 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

"The power of accurate observation is commonly called cynicism by those who 
have not got it. »
George Bernard Shaw

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

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

[Mike Cook]

> Le 18 nov. 2017 à 22:55, William Unruh  a écrit :
> 
> 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. 

I can just report that I didn’t see any issues with my Sure board at that time. 
I am getting 1-5us offset reported by NTP pretty much stable all day. 

> 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).

Have you checked the antenna. I had one of mine fall off the window ledge which 
didn’t help.
Have you power cycled the receiver? That may kill it, but at least you will 
know. 
If you have another computer, connect it to that to see if the problem follows. 
You could configure it as « noselect » (if possible in chrony) and see if the 
clock drift is erratic. 
Borrow an oscilloscope and check the raw PPS signal.
If you have a second PPS source, check your config with that in place of the 
Sure board.

> :
> By the way, what in the world has happened to this newsgroup? I am getting
> about 1 valid message to over 100 Case Solutions?

Its very low traffic . Maybe we are considered dummies.

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

"The power of accurate observation is commonly called cynicism by those who 
have not got it. »
George Bernard Shaw

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

Re: [ntp:questions] source code kernel driver (linux or freebsd) for symmetricom bc635PCI ?

[Mike Cook]

> Le 28 sept. 2017 à 16:58, Fiorenzo Cattaneo  a écrit :
> 
> BC635PCI

There is a C/C++ linux kit .
see 

Seems to include device driver and API.

maybe that has what you want.







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

Re: [ntp:questions] NTPv1 queries

[Mike Cook]

> Le 23 août 2017 à 17:56, Nikolay Stoyanov  a écrit :
> 
> Hello ,
> 
> i receive  many requests  "NTPv1, unspecified, length 48".
> 
> What is reason some devices to use tool old protocol version or they maybe 
> use buggy software ?

 This has been seen of old. See
< 
https://www.lightbluetouchpaper.org/2006/04/07/when-firmware-attacks-ddos-by-d-link/
 >
It might be a DDOS or just someone using an old router.  Block it with your 
firewall.
regards.

> 
> Any ideas ?
> 
> Regards,
> 
> Niky
> 
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions

"The power of accurate observation is commonly called cynicism by those who 
have not got it. »
George Bernard Shaw

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

Re: [ntp:questions] ***SPAM*** How to sync my system clock when there is high offset

[Mike Cook]

> Le 13 juin 2017 à 12:20, Miroslav Lichvar <mlich...@redhat.com> a écrit :
> 
> On Fri, Jun 09, 2017 at 04:28:07PM +0200, Mike Cook wrote:
>>> Le 9 juin 2017 à 12:52, Ashish Kurian <ashish...@gmail.com> a écrit :
>>> In my ntpq -p output, I see that the offset is around 70 milli second. How
>>> can I force my system clock to sync with the NTP server time. If I wait for
>>> a day, I know that the value will come down, but how can i get it synced
>>> without such long wait?
>> 
>> Again, and I would say «  as usual » , not enough info in the question to 
>> make a reasonable guess. A bit like answering the question «  how long is a 
>> piece of sting? ».
>> That said, if you detected that just after starting ntpd, it probably means 
>> the you need the « -g » option on startup.
> 
> You mean the -G option which was added in recent ntp versions? The -g
> option just temporarily disables the panic threshold and should't make
> a difference (unless the initial offset is larger than 1000 seconds).

Yes, indeed. Thx

> 
> With older ntp versions it's recommended to run ntpdate -b before
> starting ntpd in order to speed up the initial synchronization.
> 
> -- 
> Miroslav Lichvar

"The power of accurate observation is commonly called cynicism by those who 
have not got it. »
George Bernard Shaw

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

Re: [ntp:questions] ***SPAM*** How to sync my system clock when there is high offset

[Mike Cook]

> Le 9 juin 2017 à 12:52, Ashish Kurian  a écrit :
> 
> Hi Folks,
> 
> In my ntpq -p output, I see that the offset is around 70 milli second. How
> can I force my system clock to sync with the NTP server time. If I wait for
> a day, I know that the value will come down, but how can i get it synced
> without such long wait?

Again, and I would say «  as usual » , not enough info in the question to make 
a reasonable guess. A bit like answering the question «  how long is a piece of 
sting? ».
That said, if you detected that just after starting ntpd, it probably means the 
you need the « -g » option on startup.
If you were monitoring and the offset suddenly jumped to 70ms, check the delay 
field to see if it jumped. Maybe your routing changed. If that value stayed 
constant, check your system load. Maybe ntpd is starving. If that has not 
changed, go look see what the server was doing.

> 
> Best Regards,
> Ashish Kurian
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions

"The power of accurate observation is commonly called cynicism by those who 
have not got it. »
George Bernard Shaw

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

Re: [ntp:questions] ipsntp_query_time failing with IPCOM_ERR_FAILED

[Mike Cook]

> Le 9 juin 2017 à 12:02, sneha b  a écrit :
> 
> Basically I want to reduce this 4.5 to something less.
> And also want to know why do we get *IPCOM_ERR_FAILED.*
> 

From what I can see this is a proprietary vxworks error status message. Google 
threw up :

"wr_sntp_for_vx7_programmers_guide_1.0_图文_百度文库 

... else printf("System time updated!\n"); break; case IPCOM_ERR_FAILED: 
printf("Invalid (S)NTP message received!\n"); break; case 
IPCOM_ERR_INVALID_ARG: printf("Invalid arguments!\n"); break; case 
IPCOM_ERR_TIMEOUT: printf("Timeout. No responses received!\n"); break; default: 
… 

So from that code snippet interpretation, it looks like you are getting bad 
format data returned from the server. 
I should check your system call man page and header files . 
Of course, if you have a Wind River support contract, give them a call.


> Thanks,
> Sneha
> 
> On Fri, Jun 9, 2017 at 3:27 PM, sneha b  wrote:
> 
>> Hi,
>> 
>> We are using vxworks as ntp client and windows7 as ntp server, and are
>> using ipsntp_query_time, to get the time.
>> 
>> This query will happen every 45 second, but for first 6 packets, i.e
>> almost 4.5 minutes we are getting,  "*IPCOM_ERR_FAILED*" error.
>> 
>> I searched in net, but was unable to get any information on this.
>> 
>> Can some one please help me in this, I am blocked here.
>> 
>> Thanks in advance,
>> Sneha
>> 
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions

"The power of accurate observation is commonly called cynicism by those who 
have not got it. »
George Bernard Shaw

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

Re: [ntp:questions] ntp client does not sync with server after nic down and up

[Mike Cook]

> Le 5 juin 2017 à 11:06, 稻草人/nl <1227870...@qq.com> a écrit :
> 
> hi,guys
> 
> 
> i have a ntp server and client on suse with v 4.2.8p10.  both server and 
> client have two ip in the same subnet, and client use this 2 ip sync with 
> server，after long time test(8hours for ifconfig down and then up 2 nics), i 
> found client cannot sync with server(saw a large value of "when" by ntqp 
> command), and restart ntp will solve this, some time i found it will recover 
> automatically in few hours.
> 
> 
> i found i can ping each other but no packet on port123 between and server 
> when problem occures.
> flash code is 1200 for two assid
> 
> 
> any ideas?
> 

First thing to do is check the existing logs, system messages, ntp log, daemon 
logs if available ; there should be a clue there. 
As this is a test, the problem should be reproducible. So before repeating it 
make sure that ntp logging is enabled, that ntp reconfig ad system nic reconfig 
messages are capture , and maybe run ntpd in debug mode , i.e. not demonized.  
Just standard debugging methodology really.



> 
> by the way, is there a document explaining how client connect to server when 
> starting ntp and when and how client will reconnect to server after interface 
> changed?
> 
> 
> BR
> kenn
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions

"The power of accurate observation is commonly called cynicism by those who 
have not got it. »
George Bernard Shaw

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

Re: [ntp:questions] Looking for a NTP stratum 2 appliance

[Mike Cook]

> Le 26 mai 2017 à 11:35, Matthew Huff  a écrit :
> 
> The OXCO oscillator requirement is for hold-over, but we are looking for less 
> jitter in the system. We could strip down the OS machines and run only NTP 
> and make other system adjustments that would accomplish much of the same, but 
> to dedicated a server just for NTP when an appliance is available seems a 
> waste.
> 
> FINRA has made new timing requirements that are pushing this. Switching to 
> PTP is ultimately the solution, but the switches in our core data center 
> don't support it, and would be very costly to migrate to.
> 
  You could check out the Spectracom NetClock Model 9489, which although is 
primarily a GPS stratum one device, also has Ethernet input for stratum 2 
operation. It has a TCXO as LO, but with  S1 servers upstream should easily 
keep to the FIRNA constraints that I have been able to dig up. Any unloaded 
(other than NTP) micro server will get there as well. Mixing NTP with 
production loads never works. 

> 
> 
> Matthew Huff | 1 Manhattanville Rd
> Director of Operations   | Purchase, NY 10577
> OTA Management LLC   | Phone: 914-460-4039
> aim: matthewbhuff| Fax:   914-694-5669
> 
> 
>> -Original Message-
>> From: Miroslav Lichvar [mailto:mlich...@redhat.com]
>> Sent: Friday, May 26, 2017 5:29 AM
>> To: Matthew Huff 
>> Cc: NTP Questions 
>> Subject: Re: [ntp:questions] Looking for a NTP stratum 2 appliance
>> 
>> On Thu, May 25, 2017 at 11:31:27AM +, Matthew Huff wrote:
>>> For the last 20 years I've run our stratum 2 ntp servers under
>> Solaris then Linux. I'm looking to replace them with an appliance for a
>> number of reasons. One of the main one is clock stability. We have 2
>> microsemi GPS synced stratum 1 servers with rubidium oscillators. I am
>> not looking for a linux/bsd/unix box running NTP, but a dedicated non-
>> os appliance.
>> 
>> I don't know if such an appliance exists (all I saw that had a real
>> NTP client ran a regular OS), but I'm curious what problems is the
>> (in)stability of an ordinary computer oscillator causing. Are the
>> servers supposed to be able to hold over long periods of time in case
>> the stratum-1 servers fail?
>> 
>> --
>> Miroslav Lichvar
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions

"The power of accurate observation is commonly called cynicism by those who 
have not got it. »
George Bernard Shaw

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

Re: [ntp:questions] Monitoring Number of Clients

[Mike Cook]

> Le 17 mai 2017 à 10:42, Johannes Weber  a écrit :
> 
> Hi list, 
> 
> some months ago I asked about NTP monitoring. Thanks for your answers! 
> 
> I tried Brians' version which sets some mru parameters. But it's not
> working as I expected. Does anyone see my mistake? 
> 
> I set the following parameter: "mru mindepth 30 maxage 1200" in order to
> delete all addresses that are older than 1200 seconds in case the list
> is longer than 30. 
> 
> However, this is not the case. I hit my NTP server with 50 probes (via
> RIPE Atlas) yesterday, but they are still stored as you can see the "78"
> addresses: 
> 
> pi@ntp2:~ $ ntpq -c mon
> enabled:  0x1
> addresses:78
> peak addresses:   78
> maximum addresses:14563
> reclaim above count:  30
> reclaim older than:   1200

Mine works ok.  I don’t think there is an issue. The entries aren’t deleted 
when the limit is reached,  unless there a request for a new client which 
arrives after it. 
Maybe you had no new requests coming in?

Here I have limited the entry count to 5 and age to 30

mike@bb3:~$ ntpq -c mrulist
Ctrl-C will stop MRU retrieval and display partial results.
Retrieved 6 unique MRU entries and 0 updates.
lstint avgint rstr r m v  count rport remote address
==
 3 15  1c0 . 4 4 69   123 bb2.home
 5 15  1c0 . 4 4 69   123 bb1.home
 5 15  1c0 . 4 4 69   123 muon.stratum1.ddns.net
   114  10 . 3 4  4 49741 raspb3.stratum1.ddns.net
   313  10 . 3 4  4 46493 raspb2.stratum1.ddns.net
   328  40 . 3 4  8 59803 electron.home

here I did an ntpdate -d from client raspb4

mike@bb3:~$ ntpq -c mrulist
Ctrl-C will stop MRU retrieval and display partial results.
Retrieved 6 unique MRU entries and 0 updates.
lstint avgint rstr r m v  count rport remote address
==
 2  10 . 3 4  4 36616 raspb4.stratum1.ddns.net
12 15  1c0 . 4 4 72   123 bb2.home
14 15  1c0 . 4 4 72   123 muon.stratum1.ddns.net
14 15  1c0 . 4 4 72   123 bb1.home
   171  10 . 3 4  4 49741 raspb3.stratum1.ddns.net
   371  10 . 3 4  4 46493 raspb2.stratum1.ddns.net

you can see that the entry or electron has been removed.

Mike


> kilobytes:5
> maximum kilobytes:1024 
> 
> They are all still in the list: 
> 
> pi@ntp2:~ $ ntpq -c mru
> Ctrl-C will stop MRU retrieval and display partial results.
> Retrieved 78 unique MRU entries and 0 updates.
> lstint avgint rstr r m v  count rport remote address
> ==
> 
> 
> [...] 
> 
> 69885  0  1d0 . 3 4  3 55430 2001:67c:10ec:3548:8000::1337
> 69885  0  1d0 . 3 4  3 38038 2a02:a40:300::12
> 69885  0  1d0 . 3 4  3 36528 2a01:360:1:18:c24a:ff:fecc:59ac
> 69885  0  1d0 . 3 4  3 45882
> 2a02:29b0:1004:0:c66e:1fff:fe5b:cc64
> 69885  0  1d0 . 3 4  3 39951
> 2a00:ca60:11:6000:f6f2:6dff:fe5d:971a
> 69885  0  1d0 . 3 4  3 48751 2a02:f48:1:200:16cc:20ff:fe48:d0e2
> 69885  0  1d0 . 3 4  3 43509 2a06:eac0:3000::4
> 69885  0  1d0 . 3 4  3 37525 2a03:1ae0:0:270:185:65:96:253
> 69885  0  1d0 . 3 4  3 40210 2a06:6bc0:0:2:ea94:f6ff:fee3:6d5a
> 69885  0  1d0 . 3 4  3 58714 2001:638:80a:2::b3ff:feb0:e194
> 69885  0  1d0 . 3 4  3 42365
> 2a00:4ae0:4000:0::b3ff:feb0:d85c
> 69885  0  1d0 . 3 4  3 43873 2a0b:2f00:29:0:fa1a:67ff:fe4d:847f
> 
> 
> Any ideas? 
> 
> Thanks again, 
> 
> Johannes
> 
> ---
> Johannes Weber
>  Webernetz.net - Network Security Consulting
>  mail:johan...@webernetz.net
>  mobile:  +49 174 1880211
> 
>  blog:https://blog.webernetz.net
>  twitter: @webernetz [1] 
> 
> Am 14.02.2017 23:31, schrieb Brian Inglis:
> 
>> On 2017-02-06 13:10, Johannes Weber wrote: 
>> 
>>> I have one question concerning the monstats and mrulist commands. I am
>>> monitoring my NTP servers and I want to graph the current clients. I am
>>> using the "addresses" line from the monstats output.
>>> However, it seems that every client that is gone many days ago (!) is
>>> still listed within the "addresses" section and not only in the "peak
>>> addresses". Same is true within the mrulist output which lists addresses
>>> that have a lstint many days ago.
>>> 
>>> So my question is: How can I get a number of the "most recent" clients,
>>> i.e., clients that have a lstint < 2000 or the like. (One bad approach
>>> might be to use the mrulist output and to grep all lines that have an
>>> lstint < 2000. But I am searching for a better way to do it.)
>> 
>> You can tweak the monitor stats collection with the mru conf statement:
>> 
>> mru [maxdepth count | maxmem kilobytes | mindepth count | maxage seconds 
>> | initalloc count | initmem kilobytes | 

Re: [ntp:questions] Can I stop authenticated peers from mobilizing symmetric associations

[Mike Cook]

> 
> 
> Now assume that one of the remote NTP clients turns bad, deliberately 
> configures forged time, and enters "peer " in its 
> ntp.conf. This (correct me if I'm wrong) creates a dynamic mobilization with 
> my local NTP server, and my local NTP server will eventually believe in the 
> client's (now it's a peering server) time.
> 
  I think that this could only happen if the local NTP server has a peer 
command for that client. So you only need to restrict that client’s 
modification access.

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

"The power of accurate observation is commonly called cynicism by those who 
have not got it. »
George Bernard Shaw

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

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

[Mike Cook]

AFAIK no new ref clock integrations are being accepted at this time. Check with 
Harlen Stenn ( st...@nwtime.org ) who will know.

What is needed is an Interface Description Language to enable one driver to 
handle all clocks.
Then it would only need a « refclock.conf » 

> Le 21 févr. 2017 à 13:31, Erdem Ersagun  a écrit :
> 
> 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.
> 
> Is it possible?
> 
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions

"The power of accurate observation is commonly called cynicism by those who 
have not got it. »
George Bernard Shaw

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

Re: [ntp:questions] Monitoring Number of Clients

[Mike Cook]

> Le 6 févr. 2017 à 21:10, Johannes Weber  a écrit :
> 
> Hello NTP list,
> 
> I have one question concerning the monstats and mrulist commands. I am
> monitoring my NTP servers and I want to graph the current clients. I am
> using the "addresses" line from the monstats output.
> However, it seems that every client that is gone many days ago (!) is
> still listed within the "addresses" section and not only in the "peak
> addresses". Same is true within the mrulist output which lists addresses
> that have a lstint many days ago.
> 
> So my question is: How can I get a number of the "most recent" clients,
> i.e., clients that have a lstint < 2000 or the like. (One bad approach
> might be to use the mrulist output and to grep all lines that have an
> lstint < 2000. But I am searching for a better way to do it.)
> 

grep is great.

> Thanks in advance!

but try:
ntpq -c "mrulist mincount=2000"

There are a number of newish knobs to twiddle in ntp.conf as well with which to 
tailor the data collection strategy. 

> 
> Johannes
> 
> -- 
> Johannes Weber
> Webernetz.net - Network Security Consulting
> mail:johan...@webernetz.net
> mobile:  +49 174 1880211
> 
> blog:https://blog.webernetz.net
> twitter: @webernetz [1] 
> 
> Links:
> --
> [1] https://twitter.com/webernetz
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions

"The power of accurate observation is commonly called cynicism by those who 
have not got it. »
George Bernard Shaw

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

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

[Mike Cook]

Harlen’s idea may be right. If your GPS is seeing a lot of SVs then the NMEA 
stream can overrun the second. The time used is that of the end of the the 
first recognized NMEA sentence containing the time field in the cycle.
If you are able to send the commands necessary, you can limit the data stream 
length by selecting just $GPRMC which is often the first sent.
The NMEA command to do that depends on the receiver. What make/model do you 
have?

To check on what your device is sending, cat your NMEA device.

$ sudo cat /dev/gps0  #  that will get the whole stream 

You can check the UTC date from one sentence against another source to see if 
the seconds field is right. It could be that the receiver isn’t counting in 
leap seconds correctly. I had that with one receiver. 

Does your GPS have PPS output? If you have a scope you can check if the data is 
running into the following second. 

Have fun

> Le 23 janv. 2017 à 13:03, Harlan Stenn  a écrit :
> 
> Lloyd Dizon writes:
>> Hi.
>> I've installed a GPS module on a Raspberry Pi and I'm getting 1000ms
>> offsets between the GPS readings and network NTPs.
>> 
>> lloyd@jadzia:~ $ ntpq -p
>> remote   refid  st t when poll reach   delay   offset
>> jitter
>> =
>> =
>> LOCAL(0).LOCL.  10 l  447   64  1000.0000.000
>> 0.001
> 
> Why are you using the LOCAL refclock?
> 
>> xGPS_NMEA(0) .GPS.0 l-   16  3770.0006.229
>> 142.320
> 
> Is your NMEA source identifying the wrong second?
> 
>> *ntp0.as34288.ne 85.158.25.74 2 u   24   6439.810  1004.83
>> 1.687
>> +246.11.25.212.f 162.23.41.10 2 u   19   643   10.636  1004.22
>> 1.376
>> +ch-ntp01.10g.ch 81.94.123.17 3 u   21   643   10.493  1001.79
>> 3.299
>> -khyber.madduck. 192.33.96.1022 u   20   6438.703  1001.72
>> 4.474
> 
> Your NMEA source is sending ntpd samples every 16 seconds.  It's filling
> the sample buffer, and the the other sources (are you using iburst on
> these?  You should be...) are taking a while to provide enough samples
> to detect that your NMEA source is "off" by a second.
> 
>> Sometimes it will be the GPS which will have 1000ms offset and the NTP
>> serveurs will have 4-6ms instead.
>> 
>> Anybody has a clue what is going on?
> 
> I think your NMEA signal is identifying the wrong second.
> -- 
> Harlan Stenn 
> http://networktimefoundation.org - be a member!
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions

"The power of accurate observation is commonly called cynicism by those who 
have not got it. »
George Bernard Shaw

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

Re: [ntp:questions] Sync system time with pixhawk autopilot

[Mike Cook]

> Le 4 nov. 2016 à 02:33, Jason Beach  a écrit :
> 
> I am working on a multicopter that is flown by a pixhawk autopilot and also
> a Jetson TK1 running Ubuntu (both onboard the vehicle). I am trying to
> figure out how best to synchronize the time between the two boards. The
> pixhawk has a GPS that it uses for navigation and also to set the autopilot
> system time (the pixhawk runs an RTOS called nuttx).  Communication between
> the pixhawk and Jetson is via a serial port using a protocol called
> mavlink.  It's fairly straightforward to determine the time offset between
> the two boards using a ptp-ish type algorithm--i.e. the Jetson timestamps a
> mavlink timesync packet, sends it to the autopilot which timestamps it and
> sends it back.  The Jetson records the time the timesync packet is received
> and using the three timestamps, calculates the offset (this all occurs on a
> custom interface written in C++).

Assuming that you are doing your maths right, you are doing what NTP does in a 
client/server dialogue and so can directly correct the system clock using 
adjtime(2) system call. The time correction is slow so that the two platform 
times need to be close before going into the loop. You probably need to jam 
sync the Jetson system time from an initial time sync exchange if that is not 
already done. 

> 
> The problem is how do I feed that offset to ntp so that it can correct the
> Jetson time or use it to adjust the Jetson system time outright? I know
> enough about ntp to get it to sync to computers together using fudge and
> that's about it.  Any advice is appreciated.
> 
> Thanks,
> Jason
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions

"The power of accurate observation is commonly called cynicism by those who 
have not got it. »
George Bernard Shaw

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

Re: [ntp:questions] ***SPAM*** ntpd reporting as stratum 16 despite fudge stratum 10

[Mike Cook]

> Le 10 mai 2016 à 09:29, Nicolas Bock  a écrit :
> 
> Hi,
> 
> I have configured ntpd to serve as the time source for the local network:
> 
> server 127.127.1.0 minpoll 3 burst
> fudge 127.127.1.0 stratum 10
> 
> Despite the fudge stratum, upon a repoot ntpd reports itself as stratum
> 16 to the subnet for while before raising its stratum to 10. This can
> take a few minutes. Why is that? Can the time it takes before ntpd
> settles be changed?

I couldn’t replicate this exactly with 4.2.8p4. 
If all your servers clients are without external ntp access, you could try 
orphan mode. In which case there is an orphan wait option of the dos command to 
configure delay time.

regards
> 
> Thanks,
> 
> Nick
> 
> 
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions

"The power of accurate observation is commonly called cynicism by those who 
have not got it. »
George Bernard Shaw

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

Re: [ntp:questions] ntpd sensitivity to ordering of servers in ntp.conf?

[Mike Cook]

> Le 25 févr. 2016 à 14:13, Miroslav Lichvar  a écrit :
> 
> On Thu, Feb 25, 2016 at 02:49:48AM -0800, Weber wrote:
>> ntp.conf is specifies both servers with minpoll 4/maxpoll 4. Peer and loop
>> statistics are enabled.
> 
>> By just changing the order of servers in ntp.conf the delay and offset
>> values in peerstats are swapped. Now it is A with 60us delay and B has 85us.
>> Similarly, A's offset is not -5us and B is showing +5us.
>> 
>> It appears there is something in ntpd where measurements on server A in
>> ntp.conf come out slightly different depending its ordering in ntp.conf.
> 
> When A is specified as first in the config, the interval between
> polling of A and B will be 1 second and the interval between B and A
> will be 15 seconds. When you swap the servers, the intervals will be
> swapped too. I think there could be a lot of things than would happen
> in 15 seconds, but not in 1 second. Maybe some power saving feature is
> activated or maybe some cache entry expires.
> 
> You could try adding B manually via ntpq -c config:, timing the
> command so that the polling is exactly between two polls of B, and
> see what happens with the delays. Or you could run ping against the
> servers to keep the link "up".
> 
> The direction in which the offset changed suggests it's the processing
> of the server packet that has the extra delay.

Hi,
  I have also run some tests with identically configured (hardware (ARM uc)/LAN 
segment/OS( linux Debian variant )/NTP version 4.2.8p4) servers/client and 
replicate Weber’s findings. However loading the network as suggested by 
Miroslav does not improve the situation. Neither does saturating the cpu with 
other work. Agreed that this is just usecs and would be washed out over the 
WAN, but it is an order of magnitude. Curious.
So what’s up?


> -- 
> Miroslav Lichvar
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions

"The main function of a modern police force is filling in forms."
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] custom NMEA messages

[Mike Cook]

If you look at the doc 
<> you will 
see that your message is not supported, so you would have to modify the driver.
However I suspect that you also have some standard sentences as well as these 
beast are supposed to work with GPSD under linux. I haven’t looked in detail 
but I found a link to 
<>
 which may help.
It is possible that your device was configured for a particular application and 
you will need to reset it to its defaults to get the common NMEA sentences. 

Hope the helps.
Mike



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

"The main function of a modern police force is filling in forms."
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ***SPAM*** NTP throwing error 'kod_init_kod_db(): Cannot open KoD db file /var/db/ntp-kod: No such file or directory'

[Mike Cook]

my guess is that you don’t have /var/db .

> Le 1 déc. 2015 à 08:31, Keshav B  a écrit :
> 
> Hi Team,
> 
> The base kernel that was shipped with SLES 11 SP4 is 3.0.101-63-default.
> I'm trying to use sntp command from the machine and got the following error
> as below
> --
> [kbyri@pavm43-6 ~]$ sudo /usr/sbin/sntp -s 10.65.67.11
> sntp 4.2.8p2@1.3265-o Fri May 29 15:17:59 UTC 2015 (1)
> kod_init_kod_db(): Cannot open KoD db file /var/db/ntp-kod: No such file or
> directory
> 2015-12-01 02:20:23.315697 (+0500) +0.000131 +/- 0.153687 10.65.67.11 s3
> no-leap
> --
> 
> To debug this, I've freshly configured ntp client in SLES 11 SP4 step by
> step and then
> restarted the service again but to no avail.
> 
> The version of sntp is Ver. 4.2.8p2
> 
> Could anybody have any idea/knowledge how to resolve this? Any help would
> be greatly appreciated. Thanks in advance
> 
> Regards,
> Keshav
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions

"The main function of a modern police force is filling in forms."
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP throwing error 'kod_init_kod_db(): Cannot open KoD db file /var/db/ntp-kod: No such file or directory'

[Mike Cook]

My guess is that you don’t have /var/db.


> Le 1 déc. 2015 à 08:31, Keshav B  a écrit :
> 
> Hi Team,
> 
> The base kernel that was shipped with SLES 11 SP4 is 3.0.101-63-default.
> I'm trying to use sntp command from the machine and got the following error
> as below
> --
> [kbyri@pavm43-6 ~]$ sudo /usr/sbin/sntp -s 10.65.67.11
> sntp 4.2.8p2@1.3265-o Fri May 29 15:17:59 UTC 2015 (1)
> kod_init_kod_db(): Cannot open KoD db file /var/db/ntp-kod: No such file or
> directory
> 2015-12-01 02:20:23.315697 (+0500) +0.000131 +/- 0.153687 10.65.67.11 s3
> no-leap
> --
> 
> To debug this, I've freshly configured ntp client in SLES 11 SP4 step by
> step and then
> restarted the service again but to no avail.
> 
> The version of sntp is Ver. 4.2.8p2
> 
> Could anybody have any idea/knowledge how to resolve this? Any help would
> be greatly appreciated. Thanks in advance
> 
> Regards,
> Keshav
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions

"The main function of a modern police force is filling in forms."
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP not syncing immediately

[Mike Cook]

Can’t remember who the OP was…

The original ntp.conf, if that was all the entries reference just the local 
clock so why start ntp at all. There will be no disciplining anyway.

That aside I have just run some tests on a non windows machine and don’t see 
the issue, unless you are saying that you do not see the ‘*’ next to  the local 
clock. 
That I do not see on startup with your config.
It can be corrected by the following:

server 127.127.1.0 prefer  
fudge 127.127.1.0 stratum 0
restrict 127.127.1.0

Then on start up:

Sat Sep 19 08:56:43 UTC 2015
[ ok ] Starting ntpd (via systemctl): ntpd.service.

Sat Sep 19 08:56:44 UTC 2015
 remote   refid  st t when poll reach   delay   offset  jitter
==
*127.127.1.0 .LOCL.   0 l-   6410.0000.000   0.002

there is sync with one second difference, but as I was polling with ntpq at 2 
sec intervals it my be less than one second. Probably immediate.

Hope that helps.

Mike

> Le 18 sept. 2015 à 18:24, Kiss Gábor  a écrit :
> 
>> I want to sync immediately, my project requires to sync immediately as the
>> client is real time systems.
> 
> I'm afraid "real time system" means something else. :-)
> It is not related to wallclock time.
> https://en.wikipedia.org/wiki/Real-time_computing
> 
> Gabor
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions

"The main function of a modern police force is filling in forms."
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] what's the matter with my ntp

[Mike Cook]

> Le 6 sept. 2015 à 08:48, ※踏梦狼※ <121156...@qq.com> a écrit :
> 
> How long the difference of time of ntp client  time and ntp server time ,the 
> ntp client exit ?
> 

This is determined by the value of the panic threshold. By default it is 1000s 
but this can be configured or disabled in ntp.conf. See the man page tinker 
option.

> 
> -- 原始邮件 --
> 发件人: "Mike Cook";<michael.c...@sfr.fr>;
> 发送时间: 2015年8月29日(星期六) 下午4:41
> 收件人: "Mike Cook"<michael.c...@sfr.fr>;
> 抄送: "※踏梦狼※"<121156...@qq.com>; "questions"<questions@lists.ntp.org>;
> 主题: Re: [ntp:questions] what's the matter with my ntp
> 
> > 
> > For me this would not be considered acceptable. I would NEVER have ntp 
> > servers in virtual machines. Especially if they are LAN primary servers. 
> > The figures for delay and 
> 
>Oops… I meant offset. delay is not an issue unless it is highly variable, 
> indicating asymmetric path length and induces jitter.
> 
> > jitter are abnormally high.  
> 
> 
> "The bugs are notably apparent when the PC is disconnected from the mains".
> PC Shop director

"The main function of a modern police force is filling in forms."
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] what's the matter with my ntp

[Mike Cook]

> Le 31 août 2015 à 07:05, ※踏梦狼※ <121156...@qq.com> a écrit :
> 
> hello,
> could you have related the ntp log article in your ntp website ? i want 
> to understand the meaning of the below log.
> 
> 31 Aug 02:55:46 ntpd[10817]: 0.0.0.0 061c 0c clock_step -0.193855 s   * 
> system clock > 128ms fast so step it back. pb seen more than once.
> 31 Aug 02:55:46 ntpd[10817]: 0.0.0.0 0615 05 clock_sync  
> * report we are sync’d 
> 31 Aug 02:55:47 ntpd[10817]: 0.0.0.0 c618 08 no_sys_peer   
> * no server is considered healthy enough for  selection
> 31 Aug 05:33:44 ntpd[10817]: 0.0.0.0 0628 08 no_sys_peer   
> * thing are better for a while, then it happens again
> 31 Aug 05:49:05 ntpd[10817]: 0.0.0.0 0613 03 spike_detect +0.203705 s  * 
> single clock offset greater than 128ms , report and forget it
> 31 Aug 06:06:35 ntpd[10817]: 0.0.0.0 061c 0c clock_step +0.193691 s * 
> step threshold passed repeatedly so step again. 

drift of 194ms in 11489s which is less than the free clock drift if the later 
drift file value is to be believed. (would be about 384ms). Curious.. it is 
almost exactly half?? I don’t know how to interpret that.

> 31 Aug 06:06:35 ntpd[10817]: 0.0.0.0 0615 05 clock_sync
> 31 Aug 06:06:36 ntpd[10817]: 0.0.0.0 c618 08 no_sys_peer
> 31 Aug 07:56:00 ntpd[10817]: 0.0.0.0 0613 03 spike_detect +0.130901 s  
> 31 Aug 08:22:16 ntpd[10817]: 0.0.0.0 061c 0c clock_step +0.129834 s

drift of 130ms in 8141s which is less than the free clock drift if the later 
drift file value is to be believed. (would be about 298ms). About half again?   
What’s wrong with my sums?

> 31 Aug 11:07:31 ntpd[10817]: 0.0.0.0 0613 03 spike_detect -0.131656 s
> 31 Aug 11:16:12 ntpd[10817]: ntpd exiting on signal 15
>   * ntpd is  restarted 
> 31 Aug 11:16:12 ntpd[44046]: 0.0.0.0 c016 06 restart
> 31 Aug 11:16:12 ntpd[44046]: 0.0.0.0 c012 02 freq_set kernel -36.649 PPM  
>  loads drift file sets initial frequency, to adjust for a fast local 
> oscillator
> 31 Aug 11:19:30 ntpd[44046]: 0.0.0.0 c615 05 clock_sync

 I’m up a stump. It looks like the system clock is being corrected for just 
half its frequency drift. So there is some time when the clock is being sync’d 
to the servers. I still would look at your config first and try and find out 
what clients are seeing issues and which are not and list the differences 
between them. Something will pop out of that to point to a probably cause.

> 
> thanks 
> 
> -- 原始邮件 --
> 发件人: "Mike Cook";<michael.c...@sfr.fr>;
> 发送时间: 2015年8月29日(星期六) 下午4:41
> 收件人: "Mike Cook"<michael.c...@sfr.fr>;
> 抄送: "※踏梦狼※"<121156...@qq.com>; "questions"<questions@lists.ntp.org>;
> 主题: Re: [ntp:questions] what's the matter with my ntp
> 
> > 
> > For me this would not be considered acceptable. I would NEVER have ntp 
> > servers in virtual machines. Especially if they are LAN primary servers. 
> > The figures for delay and 
> 
>Oops… I meant offset. delay is not an issue unless it is highly variable, 
> indicating asymmetric path length and induces jitter.
> 
> > jitter are abnormally high.  
> 
> 
> "The bugs are notably apparent when the PC is disconnected from the mains".
> PC Shop director

"The main function of a modern police force is filling in forms."
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] what's the matter with my ntp

[Mike Cook]

 Le 30 août 2015 à 05:26, Brian Inglis brian.ing...@systematicsw.ab.ca a 
 écrit :
 
 On 2015-08-29 15:23, Mike Cook wrote:
 Le 29 août 2015 à 17:41, Charles Swiger cswi...@mac.com a écrit :
 On Aug 29, 2015, at 1:03 AM, Mike Cook michael.c...@sfr.fr wrote:
 For me this would not be considered acceptable. I would NEVER have ntp 
 servers in virtual machines.
 +1 to this point.
 Your maxpoll default of 10(1024s) for the pool servers is too high. Try 
 dropping it to 6 (64s) or 7(128s).
 -1 to this.
   experience tells me otherwise.
 Here’s a test:
 2 clients, same hardware, same LAN segment, same version NTP, same ntp 
 config, with exception of their own GPS PPS ref clock.
 The 2 clients reference 4 identical servers with the same versions of ntpd, 
 all 4 have GPS PPS ref clocks in addition to their PPS refs and preferred 
 GPS sync’d server.
 All servers are on the same LAN segment as the clients. These servers are 
 configured with maxpoll 10 on bb2, and 6 on bb3.
 ntpq -pn data
 bb2
 Sat Aug 29 20:59:19 UTC 2015
  remote   refid  st t when poll reach   delay   offset  
 jitter
 ==
 o127.127.22.0.Neo6.   0 l   13   16  3770.0000.002   
 0.002
 *192.168.1.4 .PPS1.   1 u9   16  3770.7120.119   
 0.015
 -192.168.1.15.PA6H.   1 u  583 1024  3771.1630.358   
 0.056
 -192.168.1.16.MAX7.   1 u  597 1024  3771.2600.369 
 189.435
 +192.168.1.17.ResT.   1 u  493 1024  3771.2610.312   
 0.040
 +192.168.1.18.Neo8.   1 u  600 1024  3771.1360.250   
 0.088
 bb3
 Sat Aug 29 20:57:18 UTC 2015
  remote   refid  st t when poll reach   delay   offset  
 jitter
 ==
 o127.127.22.0.NS-T.   0 l   12   16  3770.0000.003   
 0.002
 *192.168.1.4 .PPS1.   1 u   10   16  3770.5910.064   
 0.029
 +192.168.1.15.PA6H.   1 u   10   16  3770.4370.021   
 0.037
 -192.168.1.16.MAX7.   1 u9   16  3770.5830.074   
 0.029
 +192.168.1.17.ResT.   1 u   10   16  3770.4480.017   
 0.030
 +192.168.1.18.Neo8.   1 u   10   16  3770.5930.055   
 0.022
 
 You can see that the maxpoll 10 servers seen from bb2 have delays at 2 
 times that of the same servers seen from bb3.
 Reported offset on bb3 is up to 5 times that seen from bb3.
 Reported jitter (ntpd’s error bars) is in 3 cases of the same order, though 
 greater, but in one is completely anomalous on bb2 .
 
  I have not made a complete analysis of this and give the following as a 
 probable cause.
 Long intervals between client server exchanges allow arp caches to be 
 cleared in both clients, servers, routers causing arp resolution (who has 
 IP, I have IP, here’s my MAC).
 This extra path delay will possibly be asynchronous and offset and jitter 
 will be increased .
 Here are the clients arp caches to show what I mean:
 bb2
 mike@bb2:~$ arp -a
 livebox-router (192.168.1.1) at 3c:81:d8:db:4e:b4 [ether] on eth0
 muon.stratum1.d2g.com (192.168.1.4) at 00:00:24:c6:20:60 [ether] on eth0
 electron.home (192.168.1.13) at 34:15:9e:01:e5:9c [ether] on eth0
 cubieez.stratum1.d2g.com (192.168.1.124) at 02:cd:07:c1:82:5f [ether] on eth0
 mike@bb2:~$ exit
 bb3
 mike@bb3:~$ arp -a
 cubieez.stratum1.d2g.com (192.168.1.124) at 02:cd:07:c1:82:5f [ether] on eth0
 livebox-router (192.168.1.1) at 3c:81:d8:db:4e:b4 [ether] on eth0
 raspb3.stratum1.d2g.com (192.168.1.17) at b8:27:eb:71:05:50 [ether] on eth0
 raspb2.stratum1.d2g.com (192.168.1.16) at b8:27:eb:2b:ab:90 [ether] on eth0
 raspb4.stratum1.d2g.com (192.168.1.18) at b8:27:eb:fe:15:fa [ether] on eth0
 electron.home (192.168.1.13) at 34:15:9e:01:e5:9c [ether] on eth0
 muon.stratum1.d2g.com (192.168.1.4) at 00:00:24:c6:20:60 [ether] on eth0
 raspb1.stratum1.d2g.com (192.168.1.15) at b8:27:eb:7e:0b:f2 [ether] on eth0
 So in certain application environments using long poll intervals IS 
 detrimental.
 I am going to run the same configs overnight with the net loaded to see what 
 difference that makes.
 
 Unless your hardware is broken, it shouldn't need to ask what the time is 
 every minute just to manage decent timekeeping accuracy.  Admittedly, 
 running on a VM often resembles running on real hardware with a broken 
 clock, but to me that in turn means one should be running ntpd in the 
 hypervisor so that it is managing a real HW clock and let the VMs inherit 
 time from the hypervisor / Dom0 / etc.
 
 Reports indicate min/maxpoll 4 improve results on LAN segments,
 minpoll 6 improves remote network server offsets, maxpoll 10
 improves system clock frequency and offset estimation using only
 remote network servers.
 I have seen the latter pull Windows systems within 10-100us of UTC,
 much better than the few to tens of ms

Re: [ntp:questions] what's the matter with my ntp

[Mike Cook]

 snip
 For me this would not be considered acceptable. I would NEVER have ntp 
 servers in virtual machines. Especially if they are LAN primary servers. The 
 figures for delay and 

   Oops… I meant offset. delay is not an issue unless it is highly variable, 
indicating asymmetric path length and induces jitter.

 jitter are abnormally high.  


The bugs are notably apparent when the PC is disconnected from the mains.
PC Shop director
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] what's the matter with my ntp

[Mike Cook]

 
scheduling bugs… 

I would recommend that you look at getting your primary NTP servers off a VM 
infrastructure. If this is a large business environment, recommend the 
installation of dedicated primary time servers using reference clocks,  GPS for 
example.



  
  
 
 -- 原始邮件 --
 发件人: Mike Cook;michael.c...@sfr.fr;
 发送时间: 2015年8月28日(星期五) 晚上7:36
 收件人: ※踏梦狼※121156...@qq.com;
 抄送: questionsquestions@lists.ntp.org;
 主题: Re: [ntp:questions] what's the matter with my ntp
 
 
  Le 28 août 2015 à 12:36, ※踏梦狼※ 121156...@qq.com a écrit :
  
  hello,
   you say  128ms max offset ,is it refer to the time difference of the 
  client ntp system time and ntp peer time? if the time difference bigger 
  128ms, ntp don't sync clock ?
  
 No, the system clock will be synced, but may be « stepped » rather than « 
 slewed ».
 
  thanks
  
  
  -- 原始邮件 --
  发件人: Mike Cook;michael.c...@sfr.fr;
  发送时间: 2015年8月28日(星期五) 下午5:59
  收件人: ※踏梦狼※121156...@qq.com;
  抄送: questionsquestions@lists.ntp.org;
  主题: Re: [ntp:questions] what's the matter with my ntp
  
  
   Le 28 août 2015 à 11:43, ※踏梦狼※ 121156...@qq.com a écrit :
   
   The ntp client have  stand alone and virtual machines, Those machines run 
   serveral days，the time differ 30 seconds compare the normal time。 you 
   look the below log:
   
20 Aug 20:05:15 ntpd[14554]: 0.0.0.0 0615 05 clock_sync
20 Aug 20:05:16 ntpd[14554]: 0.0.0.0 c618 08 no_sys_peer
20 Aug 20:42:53 ntpd[14554]: 0.0.0.0 c613 03 spike_detect +0.949681 s
20 Aug 21:00:09 ntpd[14554]: 0.0.0.0 c618 08 no_sys_peer
21 Aug 14:24:50 ntpd[14554]: ntpd exiting on signal 15
   
   could you  tell me what's the meaning of  no_sys_peer、spike_detect and 
   clock_step ? Are those normal ?
  
 What’s normal? The messages are in response to what the client ntpd 
  detects when comparing the local clock with the set of configured servers 
  (peers).
  IIRC:
  no_sys_peer Indicates that there is no server that satisfies ntpd’s 
  stability criteria.
  spike_detect This is informational in that a difference between the local 
  clock and the valid servers was temporarily greater than the 128ms max 
  offset.
  clock_step Normally modifies the local system clock frequency to adjust for 
  differences between it and the valid servers. If the offset is greater than 
  128ms, then unless 
  configured otherwise, will step the system clock.
  Mike
  
   
   my clock seeting like this:
   [root@S10-2-1-3 ~]# cat /etc/sysconfig/clock 
   ZONE=Asia/Shanghai
   
   How i solved this problem ? 
   
   
   -- 原始邮件 --
   发件人: Mike Cook;michael.c...@sfr.fr;
   发送时间: 2015年8月28日(星期五) 下午5:25
   收件人: ※踏梦狼※121156...@qq.com;
   抄送: questionsquestions@lists.ntp.org;
   主题: Re: [ntp:questions] what's the matter with my ntp
   
   
Le 28 août 2015 à 04:52, ※踏梦狼※ 121156...@qq.com a écrit :

20 Aug 12:42:52 ntpd[14554]: 0.0.0.0 c618 08 no_sys_peer
20 Aug 12:58:17 ntpd[14554]: 0.0.0.0 c612 02 freq_set kernel -586.374 
PPM   *
20 Aug 12:58:17 ntpd[14554]: 0.0.0.0 c61c 0c clock_step -0.522594 s
20 Aug 12:58:17 ntpd[14554]: 0.0.0.0 c615 05 clock_sync
20 Aug 12:58:18 ntpd[14554]: 0.0.0.0 c618 08 no_sys_peer
20 Aug 13:11:51 ntpd[14554]: 0.0.0.0 0613 03 spike_detect +0.247108 s
20 Aug 13:28:12 ntpd[14554]: 0.0.0.0 061c 0c clock_step +0.174737 s
20 Aug 13:28:12 ntpd[14554]: 0.0.0.0 0614 04 freq_mode
20 Aug 13:28:13 ntpd[14554]: 0.0.0.0 c618 08 no_sys_peer
20 Aug 13:43:52 ntpd[14554]: 0.0.0.0 c612 02 freq_set kernel -461.842 
PPM
20 Aug 13:43:52 ntpd[14554]: 0.0.0.0 c615 05 clock_sync
20 Aug 19:48:08 ntpd[14554]: 0.0.0.0 0613 03 spike_detect +1.010504 s   
 *
20 Aug 20:05:14 ntpd[14554]: 0.0.0.0 061c 0c clock_step +1.491656 s
20 Aug 20:05:15 ntpd[14554]: 0.0.0.0 0615 05 clock_sync
20 Aug 20:05:16 ntpd[14554]: 0.0.0.0 c618 08 no_sys_peer
20 Aug 20:42:53 ntpd[14554]: 0.0.0.0 c613 03 spike_detect +0.949681 s
20 Aug 21:00:09 ntpd[14554]: 0.0.0.0 c618 08 no_sys_peer
21 Aug 14:24:50 ntpd[14554]: ntpd exiting on signal 15
28 Aug 10:25:48 ntpd[5937]: 0.0.0.0 c016 06 restart
28 Aug 10:25:48 ntpd[5937]: 0.0.0.0 c012 02 freq_set kernel -471.344 PPM
28 Aug 10:29:04 ntpd[5937]: 0.0.0.0 c61c 0c clock_step +0.233855 s
28 Aug 10:29:04 ntpd[5937]: 0.0.0.0 c614 04 freq_mode
28 Aug 10:29:05 ntpd[5937]: 0.0.0.0 c618 08 no_sys_peer
28 Aug 10:44:43 ntpd[5937]: 0.0.0.0 c612 02 freq_set kernel -25.526 PPM
28 Aug 10:44:43 ntpd[5937]: 0.0.0.0 c61c 0c clock_step +0.418623 s
28 Aug 10:44:44 ntpd[5937]: 0.0.0.0 c618 08 no_sys_peer

   
   The above indicates that this clients local clock (cpu) is running too 
   slow, exceeding the ntpd’s max drift factor of 500ppm and also the max 
   offset factor of 128ms.
   So if this is the only system affected it looks like the clock is sick.  
   Monitor it’s drift outside NTP

Re: [ntp:questions] what's the matter with my ntp

[Mike Cook]

 Le 29 août 2015 à 17:41, Charles Swiger cswi...@mac.com a écrit :
 
 On Aug 29, 2015, at 1:03 AM, Mike Cook michael.c...@sfr.fr wrote:
 For me this would not be considered acceptable. I would NEVER have ntp 
 servers in virtual machines.
 
 +1 to this point.
 
 Your maxpoll default of 10(1024s) for the pool servers is too high. Try 
 dropping it to 6 (64s) or 7(128s). 
 
 -1 to this.
 
  experience tells me otherwise. 
Here’s a test:
2 clients, same hardware, same LAN segment, same version NTP, same ntp config, 
with exception of their own GPS PPS ref clock.


The 2 clients reference 4 identical servers with the same versions of ntpd, all 
4 have GPS PPS ref clocks in addition to their PPS refs and preferred GPS 
sync’d server.
All servers are on the same LAN segment as the clients. These servers are 
configured with maxpoll 10 on bb2, and 6 on bb3.

ntpq -pn data

bb2
Sat Aug 29 20:59:19 UTC 2015
 remote   refid  st t when poll reach   delay   offset  jitter
==
o127.127.22.0.Neo6.   0 l   13   16  3770.0000.002   0.002
*192.168.1.4 .PPS1.   1 u9   16  3770.7120.119   0.015
-192.168.1.15.PA6H.   1 u  583 1024  3771.1630.358   0.056
-192.168.1.16.MAX7.   1 u  597 1024  3771.2600.369 189.435
+192.168.1.17.ResT.   1 u  493 1024  3771.2610.312   0.040
+192.168.1.18.Neo8.   1 u  600 1024  3771.1360.250   0.088

bb3
Sat Aug 29 20:57:18 UTC 2015
 remote   refid  st t when poll reach   delay   offset  jitter
==
o127.127.22.0.NS-T.   0 l   12   16  3770.0000.003   0.002
*192.168.1.4 .PPS1.   1 u   10   16  3770.5910.064   0.029
+192.168.1.15.PA6H.   1 u   10   16  3770.4370.021   0.037
-192.168.1.16.MAX7.   1 u9   16  3770.5830.074   0.029
+192.168.1.17.ResT.   1 u   10   16  3770.4480.017   0.030
+192.168.1.18.Neo8.   1 u   10   16  3770.5930.055   0.022

You can see that the maxpoll 10 servers seen from bb2 have delays at 2 times 
that of the same servers seen from bb3.
Reported offset on bb3 is up to 5 times that seen from bb3.
Reported jitter (ntpd’s error bars) is in 3 cases of the same order, though 
greater, but in one is completely anomalous on bb2 . 

 I have not made a complete analysis of this and give the following as a 
probable cause.
Long intervals between client server exchanges allow arp caches to be cleared 
in both clients, servers, routers causing arp resolution (who has IP, I have 
IP, here’s my MAC).
This extra path delay will possibly be asynchronous and offset and jitter will 
be increased .
Here are the clients arp caches to show what I mean:
bb2
mike@bb2:~$ arp -a
livebox-router (192.168.1.1) at 3c:81:d8:db:4e:b4 [ether] on eth0
muon.stratum1.d2g.com (192.168.1.4) at 00:00:24:c6:20:60 [ether] on eth0
electron.home (192.168.1.13) at 34:15:9e:01:e5:9c [ether] on eth0
cubieez.stratum1.d2g.com (192.168.1.124) at 02:cd:07:c1:82:5f [ether] on eth0
mike@bb2:~$ exit
bb3
mike@bb3:~$ arp -a
cubieez.stratum1.d2g.com (192.168.1.124) at 02:cd:07:c1:82:5f [ether] on eth0
livebox-router (192.168.1.1) at 3c:81:d8:db:4e:b4 [ether] on eth0
raspb3.stratum1.d2g.com (192.168.1.17) at b8:27:eb:71:05:50 [ether] on eth0
raspb2.stratum1.d2g.com (192.168.1.16) at b8:27:eb:2b:ab:90 [ether] on eth0
raspb4.stratum1.d2g.com (192.168.1.18) at b8:27:eb:fe:15:fa [ether] on eth0
electron.home (192.168.1.13) at 34:15:9e:01:e5:9c [ether] on eth0
muon.stratum1.d2g.com (192.168.1.4) at 00:00:24:c6:20:60 [ether] on eth0
raspb1.stratum1.d2g.com (192.168.1.15) at b8:27:eb:7e:0b:f2 [ether] on eth0

So in certain application environments using long poll intervals IS detrimental.

I am going to run the same configs overnight with the net loaded to see what 
difference that makes.


Mike


 Unless your hardware is broken, it shouldn't need to ask what the time is 
 every minute just to manage decent timekeeping accuracy.  Admittedly, running 
 on a VM often resembles running on real hardware with a broken clock, but to 
 me that in turn means one should be running ntpd in the hypervisor so that it 
 is managing a real HW clock and let the VMs inherit time from the hypervisor 
 / Dom0 / etc.
 
 Regards,
 -- 
 -Chuck

Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une 
petite et provisoire sécurité, ne méritent ni liberté ni sécurité.
Benjimin Franklin
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] what's the matter with my ntp

[Mike Cook]

errata:
 
 The 2 clients reference 4 identical servers with the same versions of ntpd, 
 all 4 have GPS PPS ref clocks in addition to their PPS refs and preferred GPS 
 sync’d server.
 All servers are on the same LAN segment as the clients. These servers are 
 configured with maxpoll 10 on bb2, and 6 on bb3.
 

  read as  

 The two client reference 4 identical servers with the same version of NTP, all 
4 having GPS PPS ref clocks. 

Hope that make more sense.

Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une 
petite et provisoire sécurité, ne méritent ni liberté ni sécurité.
Benjimin Franklin
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] what's the matter with my ntp

[Mike Cook]

 Le 28 août 2015 à 04:52, ※踏梦狼※ 121156...@qq.com a écrit :
 
 20 Aug 12:42:52 ntpd[14554]: 0.0.0.0 c618 08 no_sys_peer
 20 Aug 12:58:17 ntpd[14554]: 0.0.0.0 c612 02 freq_set kernel -586.374 PPM   
 *
 20 Aug 12:58:17 ntpd[14554]: 0.0.0.0 c61c 0c clock_step -0.522594 s
 20 Aug 12:58:17 ntpd[14554]: 0.0.0.0 c615 05 clock_sync
 20 Aug 12:58:18 ntpd[14554]: 0.0.0.0 c618 08 no_sys_peer
 20 Aug 13:11:51 ntpd[14554]: 0.0.0.0 0613 03 spike_detect +0.247108 s
 20 Aug 13:28:12 ntpd[14554]: 0.0.0.0 061c 0c clock_step +0.174737 s
 20 Aug 13:28:12 ntpd[14554]: 0.0.0.0 0614 04 freq_mode
 20 Aug 13:28:13 ntpd[14554]: 0.0.0.0 c618 08 no_sys_peer
 20 Aug 13:43:52 ntpd[14554]: 0.0.0.0 c612 02 freq_set kernel -461.842 PPM
 20 Aug 13:43:52 ntpd[14554]: 0.0.0.0 c615 05 clock_sync
 20 Aug 19:48:08 ntpd[14554]: 0.0.0.0 0613 03 spike_detect +1.010504 s
 *
 20 Aug 20:05:14 ntpd[14554]: 0.0.0.0 061c 0c clock_step +1.491656 s
 20 Aug 20:05:15 ntpd[14554]: 0.0.0.0 0615 05 clock_sync
 20 Aug 20:05:16 ntpd[14554]: 0.0.0.0 c618 08 no_sys_peer
 20 Aug 20:42:53 ntpd[14554]: 0.0.0.0 c613 03 spike_detect +0.949681 s
 20 Aug 21:00:09 ntpd[14554]: 0.0.0.0 c618 08 no_sys_peer
 21 Aug 14:24:50 ntpd[14554]: ntpd exiting on signal 15
 28 Aug 10:25:48 ntpd[5937]: 0.0.0.0 c016 06 restart
 28 Aug 10:25:48 ntpd[5937]: 0.0.0.0 c012 02 freq_set kernel -471.344 PPM
 28 Aug 10:29:04 ntpd[5937]: 0.0.0.0 c61c 0c clock_step +0.233855 s
 28 Aug 10:29:04 ntpd[5937]: 0.0.0.0 c614 04 freq_mode
 28 Aug 10:29:05 ntpd[5937]: 0.0.0.0 c618 08 no_sys_peer
 28 Aug 10:44:43 ntpd[5937]: 0.0.0.0 c612 02 freq_set kernel -25.526 PPM
 28 Aug 10:44:43 ntpd[5937]: 0.0.0.0 c61c 0c clock_step +0.418623 s
 28 Aug 10:44:44 ntpd[5937]: 0.0.0.0 c618 08 no_sys_peer
 

The above indicates that this clients local clock (cpu) is running too slow, 
exceeding the ntpd’s max drift factor of 500ppm and also the max offset factor 
of 128ms.
So if this is the only system affected it looks like the clock is sick.  
Monitor it’s drift outside NTP .
Is this the only client seeing the issue, or are others? Are the clients stand 
alone or virtual machines? If virtual, maybe you are missing a system config 
parameter.

Hope that helps.

Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une 
petite et provisoire sécurité, ne méritent ni liberté ni sécurité.
Benjimin Franklin
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] what's the matter with my ntp

[Mike Cook]

 Le 28 août 2015 à 12:36, ※踏梦狼※ 121156...@qq.com a écrit :
 
 hello,
  you say  128ms max offset ,is it refer to the time difference of the 
 client ntp system time and ntp peer time? if the time difference bigger 
 128ms, ntp don't sync clock ?
 
No, the system clock will be synced, but may be « stepped » rather than « 
slewed ».

 thanks
 
 
 -- 原始邮件 --
 发件人: Mike Cook;michael.c...@sfr.fr;
 发送时间: 2015年8月28日(星期五) 下午5:59
 收件人: ※踏梦狼※121156...@qq.com;
 抄送: questionsquestions@lists.ntp.org;
 主题: Re: [ntp:questions] what's the matter with my ntp
 
 
  Le 28 août 2015 à 11:43, ※踏梦狼※ 121156...@qq.com a écrit :
  
  The ntp client have  stand alone and virtual machines, Those machines run 
  serveral days，the time differ 30 seconds compare the normal time。 you look 
  the below log:
  
   20 Aug 20:05:15 ntpd[14554]: 0.0.0.0 0615 05 clock_sync
   20 Aug 20:05:16 ntpd[14554]: 0.0.0.0 c618 08 no_sys_peer
   20 Aug 20:42:53 ntpd[14554]: 0.0.0.0 c613 03 spike_detect +0.949681 s
   20 Aug 21:00:09 ntpd[14554]: 0.0.0.0 c618 08 no_sys_peer
   21 Aug 14:24:50 ntpd[14554]: ntpd exiting on signal 15
  
  could you  tell me what's the meaning of  no_sys_peer、spike_detect and 
  clock_step ? Are those normal ?
 
What’s normal? The messages are in response to what the client ntpd 
 detects when comparing the local clock with the set of configured servers 
 (peers).
 IIRC:
 no_sys_peer   Indicates that there is no server that satisfies ntpd’s 
 stability criteria.
 spike_detect  This is informational in that a difference between the local 
 clock and the valid servers was temporarily greater than the 128ms max offset.
 clock_stepNormally modifies the local system clock frequency to adjust 
 for differences between it and the valid servers. If the offset is greater 
 than 128ms, then unless 
 configured otherwise, will step the system clock.
 Mike
 
  
  my clock seeting like this:
  [root@S10-2-1-3 ~]# cat /etc/sysconfig/clock 
  ZONE=Asia/Shanghai
  
  How i solved this problem ? 
  
  
  -- 原始邮件 --
  发件人: Mike Cook;michael.c...@sfr.fr;
  发送时间: 2015年8月28日(星期五) 下午5:25
  收件人: ※踏梦狼※121156...@qq.com;
  抄送: questionsquestions@lists.ntp.org;
  主题: Re: [ntp:questions] what's the matter with my ntp
  
  
   Le 28 août 2015 à 04:52, ※踏梦狼※ 121156...@qq.com a écrit :
   
   20 Aug 12:42:52 ntpd[14554]: 0.0.0.0 c618 08 no_sys_peer
   20 Aug 12:58:17 ntpd[14554]: 0.0.0.0 c612 02 freq_set kernel -586.374 PPM 
 *
   20 Aug 12:58:17 ntpd[14554]: 0.0.0.0 c61c 0c clock_step -0.522594 s
   20 Aug 12:58:17 ntpd[14554]: 0.0.0.0 c615 05 clock_sync
   20 Aug 12:58:18 ntpd[14554]: 0.0.0.0 c618 08 no_sys_peer
   20 Aug 13:11:51 ntpd[14554]: 0.0.0.0 0613 03 spike_detect +0.247108 s
   20 Aug 13:28:12 ntpd[14554]: 0.0.0.0 061c 0c clock_step +0.174737 s
   20 Aug 13:28:12 ntpd[14554]: 0.0.0.0 0614 04 freq_mode
   20 Aug 13:28:13 ntpd[14554]: 0.0.0.0 c618 08 no_sys_peer
   20 Aug 13:43:52 ntpd[14554]: 0.0.0.0 c612 02 freq_set kernel -461.842 PPM
   20 Aug 13:43:52 ntpd[14554]: 0.0.0.0 c615 05 clock_sync
   20 Aug 19:48:08 ntpd[14554]: 0.0.0.0 0613 03 spike_detect +1.010504 s
   *
   20 Aug 20:05:14 ntpd[14554]: 0.0.0.0 061c 0c clock_step +1.491656 s
   20 Aug 20:05:15 ntpd[14554]: 0.0.0.0 0615 05 clock_sync
   20 Aug 20:05:16 ntpd[14554]: 0.0.0.0 c618 08 no_sys_peer
   20 Aug 20:42:53 ntpd[14554]: 0.0.0.0 c613 03 spike_detect +0.949681 s
   20 Aug 21:00:09 ntpd[14554]: 0.0.0.0 c618 08 no_sys_peer
   21 Aug 14:24:50 ntpd[14554]: ntpd exiting on signal 15
   28 Aug 10:25:48 ntpd[5937]: 0.0.0.0 c016 06 restart
   28 Aug 10:25:48 ntpd[5937]: 0.0.0.0 c012 02 freq_set kernel -471.344 PPM
   28 Aug 10:29:04 ntpd[5937]: 0.0.0.0 c61c 0c clock_step +0.233855 s
   28 Aug 10:29:04 ntpd[5937]: 0.0.0.0 c614 04 freq_mode
   28 Aug 10:29:05 ntpd[5937]: 0.0.0.0 c618 08 no_sys_peer
   28 Aug 10:44:43 ntpd[5937]: 0.0.0.0 c612 02 freq_set kernel -25.526 PPM
   28 Aug 10:44:43 ntpd[5937]: 0.0.0.0 c61c 0c clock_step +0.418623 s
   28 Aug 10:44:44 ntpd[5937]: 0.0.0.0 c618 08 no_sys_peer
   
  
  The above indicates that this clients local clock (cpu) is running too 
  slow, exceeding the ntpd’s max drift factor of 500ppm and also the max 
  offset factor of 128ms.
  So if this is the only system affected it looks like the clock is sick.  
  Monitor it’s drift outside NTP .
  Is this the only client seeing the issue, or are others? Are the clients 
  stand alone or virtual machines? If virtual, maybe you are missing a system 
  config parameter.
  
  Hope that helps.
  
  Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une 
  petite et provisoire sécurité, ne méritent ni liberté ni sécurité.
  Benjimin Franklin
 
 Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une 
 petite et provisoire sécurité, ne méritent ni liberté ni sécurité.
 Benjimin Franklin

Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une

Re: [ntp:questions] what's the matter with my ntp

[Mike Cook]

 Le 28 août 2015 à 12:12, ※踏梦狼※ 121156...@qq.com a écrit :In 
 /var/log/messages have like no_sys_peer information，but the time is correct!
  

no_sys_peer - means that the configured servers are not considered usable. 
Maybe they could not be accessed. See ntpq -pn stats for clues. Is « reach » 
not equal to 377, has « when » value exceeded the  poll interval?  It could 
be that it is a connection issue (routing?). Are your ntp servers used 
exclusively for ntpd or do they get high application use as well?

 Aug 24 18:31:40 service ntpd[1596]: peers refreshed
 Aug 24 18:32:49 service ntpd[1596]: 0.0.0.0 0613 03 spike_detect +0.155167 s
 Aug 24 19:26:24 service ntpd[1596]: 0.0.0.0 061c 0c clock_step +0.158865 s

When you say the time is correct, it is difficult to say by eyeballing a wall 
clock. Try ntpdate -d « server name » to see what the offset is.

 Aug 24 19:26:24 service ntpd[1596]: 0.0.0.0 0615 05 clock_sync
 Aug 24 19:26:25 service ntpd[1596]: 0.0.0.0 c618 08 no_sys_peer
 Aug 25 15:46:54 service ntpd[1596]: Deleting interface #53 br_wan, 
 192.168.122.208#123, interface stats: received=180, sent=287, dropped=0, 
 active_time=101542 secs
 Aug 25 15:46:54 service ntpd[1596]: 202.120.2.101 interface 192.168.122.208 
 - (none)
 Aug 25 15:46:54 service ntpd[1596]: 202.112.31.197 interface 192.168.122.208 
 - (none)
 Aug 25 15:46:54 service ntpd[1596]: 202.112.10.36 interface 192.168.122.208 
 - (none)
 Aug 25 15:46:54 service ntpd[1596]: peers refreshed
 Aug 25 15:46:56 service ntpd[1596]: Listen normally on 55 br_wan 
 192.168.123.208 UDP 123
 Aug 25 15:46:56 service ntpd[1596]: peers refreshed
 Aug 25 15:46:57 service ntpd[1596]: 0.0.0.0 0628 08 no_sys_peer
 service:/root# date
 Fri Aug 28 18:07:49 CST 2015
 
 Is it related ntp version result time is not normal ?  my ntp version like 
 below:
 
 [root@S10-2-4-2 ~]# rpm -qa|grep ntp
 ntpdate-4.2.6p5-1.el6.centos.x86_64
 ntp-4.2.6p5-1.el6.centos.x86_64

   I don’t know about CentOS, but although 4.2.6p5 is not recommended, I have 
it running without your issues.
 
 
 thanks
 -- 原始邮件 --
 发件人: Mike Cook;michael.c...@sfr.fr;
 发送时间: 2015年8月28日(星期五) 下午5:59
 收件人: ※踏梦狼※121156...@qq.com;
 抄送: questionsquestions@lists.ntp.org;
 主题: Re: [ntp:questions] what's the matter with my ntp
 
 
  Le 28 août 2015 à 11:43, ※踏梦狼※ 121156...@qq.com a écrit :
  
  The ntp client have  stand alone and virtual machines, Those machines run 
  serveral days，the time differ 30 seconds compare the normal time。 you look 
  the below log:
  
   20 Aug 20:05:15 ntpd[14554]: 0.0.0.0 0615 05 clock_sync
   20 Aug 20:05:16 ntpd[14554]: 0.0.0.0 c618 08 no_sys_peer
   20 Aug 20:42:53 ntpd[14554]: 0.0.0.0 c613 03 spike_detect +0.949681 s
   20 Aug 21:00:09 ntpd[14554]: 0.0.0.0 c618 08 no_sys_peer
   21 Aug 14:24:50 ntpd[14554]: ntpd exiting on signal 15
  
  could you  tell me what's the meaning of  no_sys_peer、spike_detect and 
  clock_step ? Are those normal ?
 
What’s normal? The messages are in response to what the client ntpd 
 detects when comparing the local clock with the set of configured servers 
 (peers).
 IIRC:
 no_sys_peer   Indicates that there is no server that satisfies ntpd’s 
 stability criteria.
 spike_detect  This is informational in that a difference between the local 
 clock and the valid servers was temporarily greater than the 128ms max offset.
 clock_stepNormally modifies the local system clock frequency to adjust 
 for differences between it and the valid servers. If the offset is greater 
 than 128ms, then unless 
 configured otherwise, will step the system clock.
 Mike
 
  
  my clock seeting like this:
  [root@S10-2-1-3 ~]# cat /etc/sysconfig/clock 
  ZONE=Asia/Shanghai
  
  How i solved this problem ? 
  
  
  -- 原始邮件 --
  发件人: Mike Cook;michael.c...@sfr.fr;
  发送时间: 2015年8月28日(星期五) 下午5:25
  收件人: ※踏梦狼※121156...@qq.com;
  抄送: questionsquestions@lists.ntp.org;
  主题: Re: [ntp:questions] what's the matter with my ntp
  
  
   Le 28 août 2015 à 04:52, ※踏梦狼※ 121156...@qq.com a écrit :
   
   20 Aug 12:42:52 ntpd[14554]: 0.0.0.0 c618 08 no_sys_peer
   20 Aug 12:58:17 ntpd[14554]: 0.0.0.0 c612 02 freq_set kernel -586.374 PPM 
 *
   20 Aug 12:58:17 ntpd[14554]: 0.0.0.0 c61c 0c clock_step -0.522594 s
   20 Aug 12:58:17 ntpd[14554]: 0.0.0.0 c615 05 clock_sync
   20 Aug 12:58:18 ntpd[14554]: 0.0.0.0 c618 08 no_sys_peer
   20 Aug 13:11:51 ntpd[14554]: 0.0.0.0 0613 03 spike_detect +0.247108 s
   20 Aug 13:28:12 ntpd[14554]: 0.0.0.0 061c 0c clock_step +0.174737 s
   20 Aug 13:28:12 ntpd[14554]: 0.0.0.0 0614 04 freq_mode
   20 Aug 13:28:13 ntpd[14554]: 0.0.0.0 c618 08 no_sys_peer
   20 Aug 13:43:52 ntpd[14554]: 0.0.0.0 c612 02 freq_set kernel -461.842 PPM
   20 Aug 13:43:52 ntpd[14554]: 0.0.0.0 c615 05 clock_sync
   20 Aug 19:48:08 ntpd[14554]: 0.0.0.0 0613 03 spike_detect +1.010504 s
   *
   20 Aug 20:05:14 ntpd[14554]: 0.0.0.0 061c 0c clock_step +1.491656 s
   20 Aug 20:05:15 ntpd

Re: [ntp:questions] what's the matter with my ntp

[Mike Cook]

 

I should have also signaled, that if this is the only sick instance:
 then it might be that the drift file has a bad value to start with. That can 
throw ntpd. 
Try stopping ntpd, removing the drift file, and then restarting ntpd.
Bad drift files can have the clock so badly off nominal frequency that you will 
need to power cycle the client. Rebooting may not be sufficient.


 
 I wait for your answer my question , thanks!
 ___
 questions mailing list
 questions@lists.ntp.org
 http://lists.ntp.org/listinfo/questions

Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une 
petite et provisoire sécurité, ne méritent ni liberté ni sécurité.
Benjimin Franklin
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NIST server anomaly

[Mike Cook]

 Le 26 août 2015 à 00:37, Nathan Stratton Treadway 
 nathanst+ntp-questi...@ontko.com a écrit :
 
 snipped
 
 Did you ever figure out what was going on here?  
 
 I noticed that the output you quoted from your second server looks
 simarly to what I get from my server... but the output you show from bb1
 is wierd in that both commands show 129.6.15.30 as being stratum 2.  It
 seems like somehow some other system is replying in place of the actual
 time-c.nist.gov, or something
 
   Nathan
 

I didn’t get a root cause. In order to get the UT1 NTP service, you have to 
register a static IP with NIST. My ISP doesn’t allocate static IP’s so I rented 
a couple.
The address I allocated to the server bb1, which was giving these strange 
results, (served from the eastern US IIRC) turned out to be unreliable. I 
subsequently switched, first to a Bolder Co. served address and then to a UK 
served address where the problem is not seen. So as you say, it looks as though 
on the bad link, the packets were being routed elsewhere. 

Regards
Mike


 
 Nathan Stratton Treadway  -  natha...@ontko.com  -  Mid-Atlantic region
 Ray Ontko  Co.  -  Software consulting services  -   http://www.ontko.com/
 GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239
 Key fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239

Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une 
petite et provisoire sécurité, ne méritent ni liberté ni sécurité.
Benjimin Franklin
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] iburst and NIST servers AND NIST server anomaly

[Mike Cook]

FYI the issues reported are related to the VPN link I am using to access the US 
NIST servers.
If I deactivate openvpn then the issues are corrected .
Re-activating it recreates the issues. I was intrigued why ntpdate was seeing 
the servers and it looks like it may be due to its use of a non root source 
port. There is possibly some firewall in the vpn link  blocking root traffic. 
Anyway ntp is working as designed.

Regards,
Mike



 Le 2 août 2015 à 16:58, Charles Elliott elliott...@comcast.net a écrit :
 
 In your NIST server anomaly email, you are using an older version of ntpdate; 
 my output from ntpdate is much different from yours.
 
 As far as the refid for time-c.nist.gov goes, in your output it is different 
 in two places, neither of which is correct:
 
 refid [129.6.15.30], delay 0.11169, dispersion 0.00015
 
 ntpq -pn on this system showed
 129.6.15.30 43.77.130.2542 u   13   16  377   86.5011.132   0.582
 
 All that being said, it is a good catch; there is obviously something wrong.  
 However, with older versions of ntdpdate and possibly ntpd, there have been 
 so many changes it is hard to tell what is wrong, whether it is a programming 
 error or an NIST error.  However, it appears that 43.77.130.254 is registered 
 to a university in Tokyo, Japan.  Is some enterprising young Japanese lad 
 performing experiments, or is NTPD performing inverse IP address lookups 
 incorrectly again?
 
 I have achieved much better results from ntpd (currently offset=0.030818 
 milliseconds and sys_jitter=0.014405 milliseconds) by selecting up to 9 NTP 
 servers that are physically close to me and are not heavily loaded.  And I 
 avoid using the pool servers, period.  Pool servers in the United States 
 apparently use computers not even the Salvation Army will give away to the 
 poor.  In addition, in my experience, they are not well maintained.
 
 NTPD error is proportional to the distance between the client and server 
 machines.  You have very little hope of accessing accurate time by using 
 servers that are thousands of miles away from you, and thousands of miles 
 from each other.  Time-c.nist.gov is located in the American state of 
 Maryland, which on the east coast; access time for me is about 18 
 milliseconds.  India.colorado.edu is located slightly west of the middle of 
 the United States, and access time for me is 53 milliseconds.  Right this 
 minute, they are both showing about the same time, about 1.7 milliseconds 
 apart, but ordinarily I would expect the difference to be greater than that.  
 In any case, my ntpd client almost never selects time-c.nist.gov because I 
 can access physically closer servers with less jitter.
 
 
 Charles Elliott
 
 
 -Original Message-
 From: questions [mailto:questions-
 bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of Mike Cook
 Sent: Sunday, August 2, 2015 5:32 AM
 To: Questions List
 Subject: [ntp:questions] iburst and NIST servers
 
 Hi,
  Can anyone confirm that this is an issue?
 
 I habitually put an burst directive in my ntp.conf server statements.
 ex:
 
  server 129.6.15.30 noselect iburst minpoll 4 maxpoll 6
  server 128.138.140.44 noselect iburst minpoll 4 maxpoll 6
  server 98.175.203.200 noselect iburst minpoll 4 maxpoll 6
 
 But in the case of these NIST servers, sometimes they never get out of
 INIT state.
 
 #  pool 0.europe.pool.ntp.org iburst
 mike@bb1:~$ ntpq -pn
 remote   refid  st t when poll reach   delay   offset
 jitter
 ===
 ===
 o127.127.22.0.M12+.   0 l4   16  3770.0000.003
 0.002
 +192.168.1.23.GPS.1 u1   16  3770.473   -0.031
 0.011
 129.6.15.30 43.77.130.2542 u   16   16  376   86.0820.805
 0.312
 128.138.140.44  .INIT.  16 u-   6400.0000.000
 0.000
 98.175.203.200  .INIT.  16 u-   6400.0000.000
 0.000
 *192.168.1.4 .PPS1.   1 u-   16  3770.5800.049
 0.018
 +192.168.1.18.Neo8.   1 u2   16  3770.4370.019
 0.035
 
 I see in http://tf.nist.gov/tf-cgi/servers.cgi the following gotcha
 
 All users should ensure that their software NEVER queries a server more
 frequently than once every 4 seconds. Systems that exceed this rate
 will be refused service. In extreme cases, systems that exceed this
 limit may be considered as attempting a denial-of-service attack.
 
 The refusal appears random as sometimes a server never leaves INIT,
 however if I restart ntpd it may be accepted.
 
 Could there be another explanation?
 
 Regards,
 Mike
 
 Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir
 une petite et provisoire sécurité, ne méritent ni liberté ni sécurité.
 Benjimin Franklin
 ___
 questions mailing list
 questions@lists.ntp.org
 http://lists.ntp.org/listinfo/questions

Ceux qui sont prêts à abandonner

[ntp:questions] NIST server anomaly

[Mike Cook]

While modifying a couple of servers ntp configs to test their UT1 service I 
noticed the following that seem odd. If anyone has seen the same I would like 
to know and if there are plausible explanations I would also be interested.

The issue pertains to server time-c.nist.gov (129.6.15.30) which 
http://tf.nist.gov/tf-cgi/servers.cgi show has all services available.

I have just executed ntpdate -d  129.6.15.30 on two different systems. The 
results are as follows, with uninteresting lines removed.

mike@bb1:~$ ntpdate -d 129.6.15.30
 2 Aug 08:51:00 ntpdate[26533]: ntpdate 4.2.8p3@1.3265-o Tue Jun 30 16:13:49 
UTC 2015 (1)
Looking for host 129.6.15.30 and service ntp
129.6.15.30 reversed to time-c.nist.gov
host found : time-c.nist.gov
transmit(129.6.15.30)
….
receive(129.6.15.30)
server 129.6.15.30, port 123
stratum 2, precision -22, leap 00, trust 000
refid [129.6.15.30], delay 0.11169, dispersion 0.00015
transmitted 4, in filter 4
reference time:d9685702.8297381a  Sun, Aug  2 2015  8:44:50.510
…..
offset 0.000847

ntpq -pn on this system showed
 129.6.15.30 43.77.130.2542 u   13   16  377   86.5011.132   0.582


mike@cubieez2:~/src/python$ sudo ntpdate -d 129.6.15.30
 2 Aug 10:50:59 ntpdate[21672]: ntpdate 4.2.8p3-RC1@1.3265-o Sun Jun  7 
13:29:09 UTC 2015 (1)
Looking for host 129.6.15.30 and service ntp
129.6.15.30 reversed to time-c.nist.gov
host found : time-c.nist.gov
transmit(129.6.15.30)
…..
receive(129.6.15.30)
server 129.6.15.30, port 123
stratum 1, precision -29, leap 00, trust 000
refid [ACTS], delay 0.17868, dispersion 0.00026
transmitted 4, in filter 4
reference time:d968583c.1e7f0dab  Sun, Aug  2 2015 10:50:04.119
….
offset -0.008539

(forget the 2hr diff in reported  times as the shell for the first command is 
running with a UTC TZ and the second has a TZ of CEST)

ntpq -pn on this system shows
 129.6.15.30 .ACTS.   1 u   15   64  377  151.910   -8.515   0.081


What intrigues me is that the refid is not the same. Any idea why?  Isn’t 
having inconsistent data from the same configurations an issue?

Regards
Mike



Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une 
petite et provisoire sécurité, ne méritent ni liberté ni sécurité.
Benjimin Franklin
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] iburst and NIST servers

[Mike Cook]

Just checked that the iburst rate is one packet every 2 secs for a responding 
client , total 6 . 

16:45:00.115534 IP 209.200.39.7.123  129.6.15.30.123: NTPv4, Client, length 48
16:45:00.206980 IP 129.6.15.30.123  209.200.39.7.123: NTPv4, Server, length 48
16:45:02.122616 IP 209.200.39.7.123  129.6.15.30.123: NTPv4, Client, length 48
16:45:02.295478 IP 129.6.15.30.123  209.200.39.7.123: NTPv4, Server, length 48
16:45:04.115161 IP 209.200.39.7.123  129.6.15.30.123: NTPv4, Client, length 48
16:45:04.202371 IP 129.6.15.30.123  209.200.39.7.123: NTPv4, Server, length 48
16:45:06.115260 IP 209.200.39.7.123  129.6.15.30.123: NTPv4, Client, length 48
16:45:06.202423 IP 129.6.15.30.123  209.200.39.7.123: NTPv4, Server, length 48
16:45:08.115264 IP 209.200.39.7.123  129.6.15.30.123: NTPv4, Client, length 48
16:45:08.201688 IP 129.6.15.30.123  209.200.39.7.123: NTPv4, Server, length 48
16:45:10.115066 IP 209.200.39.7.123  129.6.15.30.123: NTPv4, Client, length 48
16:45:10.238195 IP 129.6.15.30.123  209.200.39.7.123: NTPv4, Server, length 48

So NIST servers should not refuse access , and this one clearly doesn’t.

For a client that is stays in INIT.
Requests are sent at minpoll , which in my case is 16 secs.

16:23:21.428877 IP 209.200.39.7.123  128.138.140.44.123: NTPv4, Client, length 
48
16:23:37.428912 IP 209.200.39.7.123  128.138.140.44.123: NTPv4, Client, length 
48
16:23:53.428827 IP 209.200.39.7.123  128.138.140.44.123: NTPv4, Client, length 
48
16:24:09.428838 IP 209.200.39.7.123  128.138.140.44.123: NTPv4, Client, length 
48
16:24:25.428832 IP 209.200.39.7.123  128.138.140.44.123: NTPv4, Client, length 
48
16:24:41.428875 IP 209.200.39.7.123  128.138.140.44.123: NTPv4, Client, length 
48
16:24:57.428801 IP 209.200.39.7.123  128.138.140.44.123: NTPv4, Client, length 
48
16:25:13.428818 IP 209.200.39.7.123  128.138.140.44.123: NTPv4, Client, length 
48

 So my issue is not with iburst as I do not get ANY packets in response from 
this server but ntpdate does get a response


 Le 2 août 2015 à 16:33, Charles Swiger cswi...@mac.com a écrit :
 
 On Aug 2, 2015, at 2:31 AM, Mike Cook michael.c...@sfr.fr wrote:
 Can anyone confirm that this is an issue?
 
 I habitually put an burst directive in my ntp.conf server statements. ex:
 
 server 129.6.15.30 noselect iburst minpoll 4 maxpoll 6  
 server 128.138.140.44 noselect iburst minpoll 4 maxpoll 6  
 server 98.175.203.200 noselect iburst minpoll 4 maxpoll 6  
 
 But in the case of these NIST servers, sometimes they never get out of INIT 
 state.
 
 iburst isn't usually a problem, but minpoll 4 / maxpoll 6 would be
 considered abusive without prior arrangements.  minpoll 6 is the fastest
 rate you should query other NTP servers without explicit permission.
 
 To be more specific, folks who implement per-client firewall rate rules
 tend to block clients who exceed ~100 packets per hour.
 
 
 The main point of iburst is to quickly get a downed NTP server back up
 and serving valid time.  That matters most for isolated stratum-2+
 servers; if you've already got S1 timesources available and multiple
 redundant NTP servers locally, using iburst is superfluous.
 
 Sure, use iburst on one remote server entry if you want and/or against
 all of the other NTP peers on your local subnet, but it's not obviously
 helpful to use iburst everywhere.
 
 Regards,
 -- 
 -Chuck

Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une 
petite et provisoire sécurité, ne méritent ni liberté ni sécurité.
Benjimin Franklin
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

[ntp:questions] iburst and NIST servers

[Mike Cook]

Hi,
  Can anyone confirm that this is an issue?

I habitually put an burst directive in my ntp.conf server statements. ex:

  server 129.6.15.30 noselect iburst minpoll 4 maxpoll 6  
  server 128.138.140.44 noselect iburst minpoll 4 maxpoll 6  
  server 98.175.203.200 noselect iburst minpoll 4 maxpoll 6  

But in the case of these NIST servers, sometimes they never get out of INIT 
state.

#  pool 0.europe.pool.ntp.org iburst
mike@bb1:~$ ntpq -pn
 remote   refid  st t when poll reach   delay   offset  jitter
==
o127.127.22.0.M12+.   0 l4   16  3770.0000.003   0.002
+192.168.1.23.GPS.1 u1   16  3770.473   -0.031   0.011
 129.6.15.30 43.77.130.2542 u   16   16  376   86.0820.805   0.312
 128.138.140.44  .INIT.  16 u-   6400.0000.000   0.000
 98.175.203.200  .INIT.  16 u-   6400.0000.000   0.000
*192.168.1.4 .PPS1.   1 u-   16  3770.5800.049   0.018
+192.168.1.18.Neo8.   1 u2   16  3770.4370.019   0.035

I see in http://tf.nist.gov/tf-cgi/servers.cgi the following gotcha

All users should ensure that their software NEVER queries a server more 
frequently than once every 4 seconds. Systems that exceed this rate will be 
refused service. In extreme cases, systems that exceed this limit may be 
considered as attempting a denial-of-service attack.

The refusal appears random as sometimes a server never leaves INIT, however if 
I restart ntpd it may be accepted. 

Could there be another explanation? 

Regards,
Mike

Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une 
petite et provisoire sécurité, ne méritent ni liberté ni sécurité.
Benjimin Franklin
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

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

[Mike Cook]

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

Here’s the trace:

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

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

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

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

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

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

I then restarted ntpd to check if that helped.

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

So, it’s fixed by a reboot. Anyone seen this? 

Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une 
petite et provisoire sécurité, ne méritent ni liberté ni sécurité.
Benjimin Franklin
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP setup in time sensitive environment

[Mike Cook]

 

I can’t remember the previous thread but I expect you got good advice and 
ignored it. 

 ---
 We are trying to setup NTP in our subsystem in a LAN environment for
 time-sensitive systems.

If time « sensitivity » is a prime objective, then a sufficient and robust time 
distribution network has to be designed. This is obviously not the case with 
what your setup is describing. In the previous thread, I can not imagine the 
many knowledgable contributors here would have not pointed it out. That is why 
I suspect that you have ignored good advice. If this requirement is for 
business applications it is up to the IT directors to budget for this mission 
critical requirement. It cannot be skimped.

SO.  As the Monty Python sketches often pointed out «  Start Again » . See 
ntp.org for good architecture hints here. 

That said. My 2cents (payable through paypal).

 But, we are facing some challenging issues in terms of minimizing the time
 offset from the NTP time server.
 
 *Setup:*
 PC_V syncs to an external NTP time server PC_NTP which could be within the
 same network or could be an external time server listed on NTP.org
 PC_A and PC_B sync to PC_V which are in the same isolated subnet since PC_A
 and PC_B are not exposed to external network.
 PC_A, PC_B, PC_V could restart atleast once a day and might even be
 restarted few times a day.
 All PCs have Windows 7 x64 bit installed, have gigabit network with no
 network congestion and we are using ntp 4.2.8p1.
 
 *NTP Commands used:*
 *Sync: *ntpd.exe -g -N -q -c Sync Config file
 *Drift:* ntpd.exe -g -N -c Drift Config file
 
 *NTP Configuration:*
 *Sync Config file includes:*
 server  iburst burst
 *Drift Config file includes:*
 server  burst minpoll 3 maxpoll 6 prefer true
 tinker step 0
 tinker panic 0
 ---
 
 *Requirements: *Requirement is to setup NTP on these PCs in such a way that:
 1) Time Sync between PCs as accurate as possible,  lets say within +/-5ms.

  This is not strictly the same as saying as you do above, as minimizing the 
offset with the NTP server.  If as you admit, your only NTP server PC_V is 
down, any client which only has this as a source ( another NoNo )will be 
drifting away according to the quality of its local clock. If you are seriously 
accepting that there is the probability that clients will be without a server , 
BUT must remain sync’d with each other, then you should be « peer »ing them, as 
well as configuring the server PC_V.

 2) Time Offset between PCs shall remain as low as possible for as long as
 possible, lets say within +/- 5ms offset for 24 hours.

 As indicated above, if you do not peer, and there is a weak server tree, then 
you have no chance. 

 3) PC_V might be able to talk to only one NTP time server within network,
 lets say at stratum level 5.

 This is a NoNo . 

 But, it is important to keep the time offset as low as possible, lets say
 within +/- 5ms offset.

 As indicated, this is a requirement incompatible with the resources at hand.

 
 *Actuals:*
 1) Time offset between PCs after Time sync could be within +/- 100ms.

  You need to more data to get any useful response here. Take ntpq -pn data at 
say 30 second intervals from server and client over a « sync » cycle.

 2) The clocks could have an offset of +/- 60ms within few mins after sync.

 You don’t give hard figures for analysis (see above), but this seems excessive 
for modern hardware and may indicate either bad hardware, unlikely, or that the 
system is chasing its tail with a bad drift file value, or that the clock is 
being steered by something else than NTP. Is your Windows Time Service disabled 
on all systems running NTP.

 Even on overnight runs using loopstats and peerstats, we see that the
 offset of system time from NTP time could be +/-50ms.

see above

 3) As per the following link, we should be using atleast 4 time servers for
 maintaining accuracy:
 http://support.ntp.org/bin/view/Support/StartingNTP4
 But how do we assure that the time offset is minimal.
 
 *Questions:*
 1) How can we assure that the sync will consistently result in +/- 5ms
 offset?
 2) This seems to defeat the whole purpose of synching if the offset cannot
 be maintained!
 Is there a way to force the system offset to remain within +/-5ms?

NTP does it’s best to get offsets as low as possible. With Windows 7 I have 
offsets sub millisecond with no problem, but then I have a correctly configured 
network.

 3) Can we live with just 1 time server PC_NTP and PC_V, PC_A and PC_B will
 closely following that time no matter?

 Dream on.  

 

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

[Mike Cook]

 Le 10 mars 2015 à 19:13, Neil Green nc...@hotmail.co.uk a écrit :
 
 
 Thanks to everyone who gave answers to my question. David, as the GPS I use 
 sits directly over the Pi I’ve just started a cron job to collect the CPU 
 temperature every 10 minutes, which I’ll run for 24 hours or so, but was 
 wondering if you (or anyone) could offer suggestions with regards to keeping 
 temperature constant in a normal home environment (room heated but only as 
 needed and not overnight, computer and GPS placed near a window through 
 necessity (GPS antenna is placed on the window sill)). Any advice much 
 appreciated.

Quick and cheap test to see if you get the results you need. Put the 
combination in a closed cardboard box to protect it from air currents and if 
you can find something suitable, surround the r-pi and receiver in the box with 
some thermal mass, or even foam to lessen temperature gradients. You may have 
to poke a few holes in the top if the cpu temp gets too high.  If you find you 
need better, prettier, you can use the pi itself to control a fan to regulate 
box temp. Plenty of sources on the web.  I myself am just using an insulated 
cardboard box without fan for one. It is fine for NTP. 

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

Re: [ntp:questions] rasperry pi, pps, false ticker

[Mike Cook]

You don’t give your config, but as using the shared memory driver works, do you 
have a prefer peer active when you are using the atom driver? If there isn’t 
one, that will cause the ref clock to be falseticker’d?. Your atom jitter isn’t 
the issue.


Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une 
petite et provisoire sécurité, ne méritent ni liberté ni sécurité.
Benjimin Franklin

 Le 9 mars 2015 à 10:52, folkert folk...@vanheusden.com a écrit :
 
 Hi,
 
 I have a raspberry pi with a gps connected to it.
 It runs linux kernel 3.18.5+ and ntp version 1:4.2.6.p5+dfsg-2.
 When I use my own rpi_gpio_ntp which is a userspace program, I get
 something like:
 
 remote   refid  st t when poll reach   delay   offset jitter
 ==
 *127.127.28.1.PPS.0 l8   16  3770.000   -0.010 0.008
 
 *127.127.28.1.PPS.0 l   11   16  3770.0000.005 0.012
 
 *127.127.28.1.PPS.0 l   12   16  3770.0000.005 0.012
 
 *127.127.28.1.PPS.0 l1   16  3770.0000.001 0.011
 
 (I omitted the peers)
 So the jitter is around 8us. Not bad for userspace.
 
 Linux has this PPS interface for a while so now that it is easy
 configurable in config.txt on the rpi, I thought I give that a try. The
 strange thing now is that using that I get very bad jitter. So bad that
 ntp discards it as a false ticker!
 
 remote   refid  st t when poll reach   delay   offset jitter
 ==
 x127.127.22.1.PPS.0 l2   16  3770.0000.161 0.001
 
 x127.127.22.1.PPS.0 l7   16  3770.0000.148 0.006
 
 x127.127.22.1.PPS.0 l   13   16  3770.0000.147 0.007
 
 x127.127.22.1.PPS.0 l2   16  3770.0000.146 0.006
 
 This is odd: the pps interface should work way better due to lower
 latency etc.
 
 What could be going wrong here?
 
 The one at the top (28.1) uses GPS and the one at the bottom uses a
 combined Glonass/GPS receiver. Note that I also swapped tried using pps
 with 28.1 and rpi_gpio_ntp on 22.1 and then 28.1 fails and 22.1 is fine.
 
 
 Folkert van Heusden
 
 -- 
 Curious about the inner workings of your car? Then check O2OO: it'll
 tell you all that there is to know about your car's engine!
 http://www.vanheusden.com/O2OO/
 --
 Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
 ___
 questions mailing list
 questions@lists.ntp.org
 http://lists.ntp.org/listinfo/questions
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Writing the drift file

[Mike Cook]

 Le 6 mars 2015 à 17:39, Terje Mathisen terje.mathi...@tmsw.no a écrit :
 
 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.
 
 The latter value can probably be calculated:
 
 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.
 
 Terje

I suspect that this is a non-issue as someone else indicated.

Current practice appears to be to open and write each new value to a temporary 
file then unlink the old and rename the temporary file.
This means that a whole new file structure including new blocks is created each 
time and the old one freed up. So even in the worst case where the same blocks 
are allocated on alternated file updates, the effective life of the device is 
doubled. 

If the object is to just not write the file, then KIS. Add a command option of 
a fixed start up drift value determined by the integrator.
As an extra, to minimize writes add a « learn once only» option which could be 
an averaging exercise though I am a bit skeptical of that. This would be ok 
where a device is to be used in a reasonable stable environment as although the 
median drift of devices of the same architecture can vary quite a bit ( My 
R-PIs are 35-55ppm, Soekris  8-15ppm, BBBs 32-34ppm), the bounds during 
operation do not vary by more than a couple of ppm over the day. So having a 
ball park figure would be sufficient. 
For sheer luxury, allow a device for the drift file, which would determine the 
current drift before starting ntpd.  
Otherwise for devices being started in varying environmental conditions, better 
to have nothing. 


 
 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
 
 
 
 -- 
 - Terje.Mathisen at tmsw.no
 almost all programming can be viewed as an exercise in caching
 
 

Re: [ntp:questions] moving from ntpdc to ntpq

[Mike Cook]

Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une 
petite et provisoire sécurité, ne méritent ni liberté ni sécurité.
Benjimin Franklin

 Le 27 févr. 2015 à 08:22, catherine.wei1...@gmail.com a écrit :
 
 On Saturday, February 7, 2015 at 11:25:02 AM UTC+8, Harlan Stenn wrote:
 Pretty much the same thing, except with :config addpeer ... and
 :config unconfig 
 
 I think...
 
 Please feel free to add examples to:
 
 http://support.ntp.org/Support/MonitoringAndControllingNTP
 http://support.ntp.org/Dev/DeprecatingNtpdate
 
 H
 Richard writes:
 What is ntpq's equivelant of -c addpeer ntp host   and  -c unconfig
 ntp host  ?
 
 
 I just upgraded from ntp 4.2.6 to 4.2.8 and ntpdc isn't connecting to my
 local ntpd. According to the ntpdc man page:
 
 ntpdc is deprecated. Please use ntpq(1) instead - it can do everything
 ntpdc used to do,
 
 
 In ntpq how do I do the equivalent of ntpdc's -c addpeer   or -c
 unconfig commands?
 
 
 Here is part of what previously did with ntpdc:
 
 /usr/sbin/ntpc -4 -c keyid 5 -c passwd  mypassword \
 -c addpeer  ntp server   localhost
 
 
 ___
 questions mailing list
 questions@lists.ntp.org
 http://lists.ntp.org/listinfo/questions
 
 
 Hi, if I add :config in front of addpeer, it seems that an authentication is 
 required. When I specify the keyid to 0, it said invalid key identifier ».

The MD5 keys file used for passwords does not contain a 0 key. Starts at 1.
ex:
apache2  ntpkey_md5_cubieez  ntpkey_MD5key_cubieez.3634012029
root@cubieez:/usr/local/etc# cat ntpkey_MD5key_cubieez.3634012029
# ntpkey_MD5key_cubieez.3634012029
# Fri Feb 27 08:47:09 2015

 1 MD5 w$It8qF.yq)G[bhV:  # MD5 key
 2 MD5 1,fLb0.0uu;!4sI4%os  # MD5 key
 3 MD5 GSz/.']5D_l6DMjpL2D  # MD5 key
 4 MD5 TAM=C][4j=a,`X$sm=2e  # MD5 key
 5 MD5 PW.s^OS_kE+X~qKUm\:.  # MD5 key
 6 MD5 D;4!c.swl:~cUvM!J^3  # MD5 key
 7 MD5 wq[?.c}S{lV79HX{`tle  # MD5 key
 8 MD5 SJxajDfU*2`A+i}%R{M  # MD5 key
 9 MD5 AGBp[Z]iEH@z1:?T3!OA  # MD5 key
10 MD5 Al'jlgWLE?:IH;mCegNJ  # MD5 key


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

Re: [ntp:questions] Type 28 driver (gpsd, SHM) - understanding flag1

[Mike Cook]

 Le 21 févr. 2015 à 08:37, David Taylor 
 david-tay...@blueyonder.co.uk.invalid a écrit :
 
 Folks,
 
 I'm looking at:
 
  http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver28.html
 
 and wanting to be sure that I understand flag1 correctly.  The situation is 
 starting a computer which has no real-time clock, and has been down for a 
 day.  This computer is in the middle of nowhere, and has a GPS and PPS as 
 reference clocks, using the type 22 and type 28 drivers.  By observation, the 
 type 22 (PPS) driver won't kick in until the type 28 (SHM/gpsd) driver is 
 valid, but also by observation with no flags set it seems that the type 28 
 driver never syncs at all, even though valid GPS data is present.
 
 My reading of that page is:
 
 - the default, flag1 = 0 or absent, and no time2 set, NTP will not kick in 
 unless the local clock is within 4 hours of the GPS time.  It seems that even 
 with -g as an ntpd parameter, which /should/ allow a large initial offset NTP 
 won't kick in.  In the computer in question, the difference is likely to be 
 in excess of 24 hours, so NTP will not attempt to correct the clock.  This is 
 not the desired behaviour!
 
 Is my understanding correct?  Would the correct thing to do in such 
 circumstances be to set flag1 = 1 so that the difference limit is ignored?
 
   My aged understanding concurs with yours. Set flag 1. Maybe not your desired 
behavior, but possibly that of the designer.

 I ask what may be an obvious question as I appear to have difficulty in 
 reading the page.  Perhaps old age, I hope nothing more!  I suppose I had 
 expect the -g to override other sanity checks.
 
 -- 
 Thanks,
 David
 Web: http://www.satsignal.eu
 
 ___
 questions mailing list
 questions@lists.ntp.org
 http://lists.ntp.org/listinfo/questions
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Pool server gone wild

[Mike Cook]

 Le 21 févr. 2015 à 10:00, Roger invalid@invalid.invalid a écrit :
 
 On Fri, 20 Feb 2015 19:19:43 +, Roger
 invalid@invalid.invalid wrote:
 
 Terje made the suggestion about too few servers. DNS returns 4
 IP addresses at a time. By having four lines ntpd could have 12
 different IP addresses returned if it used all four lines.
 
 Roger, repeat after me: 4 times 4 equals 16 ! How come nobody
 corrected that for me?

My secondary school maths teacher used to make 'errors' like that to see if we 
were still awake. Mostly we weren’t either.

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

Re: [ntp:questions] Pool server gone wild

[Mike Cook]

 snipped
 
 The server was still in the peerstats at 18:25 the following day
 when I did a reboot. So, after approximately 27 hours, ntpd
 hadn't dropped it. Obviously, my system isn't performing as you
 say it should. Can you, or anyone else, provide a clue as to how
 I might determine if my system is a fault or if there is a bug
 in the ntpd code?
 
 I.e. as long as you use the pool properly there is no need to worry 
 about servers coming and going, or even individual servers that become 
 falsetickers.

Hmmm. Sometime back I had noticed on my servers using the pool, that a couple 
of the selected servers had stopped responding. I did not know at the time that 
that situation was supposed to be dynamically corrected so I dropped the pool 
as  being unreliable. Maybe there is some issue. I just re-configured 4 servers 
back to using the pool and will monitor for black sheep.

 
 When I first tried 4.2.8 I noticed the soliciting lines and
 that occasionally a server didn't get used.

 I have that too.

Feb 20 13:49:42 raspB2 ntpd[27451]: Soliciting pool server 195.154.41.195
Feb 20 13:50:48 raspB2 ntpd[27451]: Soliciting pool server 195.154.216.35
Feb 20 13:51:55 raspB2 ntpd[27451]: Soliciting pool server 5.39.78.25
Feb 20 13:51:56 raspB2 ntpd[27451]: Soliciting pool server 91.121.157.10
Feb 20 13:53:05 raspB2 ntpd[27451]: Soliciting pool server 195.154.78.115
Feb 20 13:54:12 raspB2 ntpd[27451]: Soliciting pool server 212.83.131.33
^Cmike@raspB2 ~ ntpq -pn
 remote   refid  st t when poll reach   delay   offset  jitter
==
*127.127.28.1.GPS2.   0 l4   16  3770.0000.008   0.006
+192.168.1.4 .PPS1.   1 u3   16  3770.9260.039   0.032
+192.168.1.23.GPS.1 u2   16  3770.5830.049   0.218
 0.pool.ntp.org  .POOL.  16 p-   6400.0000.000   0.004
+5.39.78.25  140.7.62.122 2 u   14   64   175.8832.928   0.047
+188.165.255.179 193.110.137.171  2 u2   6416.0790.342   0.057

It also seems to be soliciting every minute and 7 secs. rather than hourly.

Feb 20 13:49:42 raspB2 ntpd[27451]: Soliciting pool server 195.154.41.195
Feb 20 13:50:48 raspB2 ntpd[27451]: Soliciting pool server 195.154.216.35
Feb 20 13:51:55 raspB2 ntpd[27451]: Soliciting pool server 5.39.78.25
Feb 20 13:51:56 raspB2 ntpd[27451]: Soliciting pool server 91.121.157.10
Feb 20 13:53:05 raspB2 ntpd[27451]: Soliciting pool server 195.154.78.115
Feb 20 13:54:12 raspB2 ntpd[27451]: Soliciting pool server 212.83.131.33
Feb 20 13:55:18 raspB2 ntpd[27451]: Soliciting pool server 188.165.255.179
Feb 20 13:55:19 raspB2 ntpd[27451]: Soliciting pool server 91.121.167.51
Feb 20 13:56:28 raspB2 ntpd[27451]: Soliciting pool server 178.32.54.53
Feb 20 13:57:35 raspB2 ntpd[27451]: Soliciting pool server 91.121.165.146
Feb 20 13:58:42 raspB2 ntpd[27451]: Soliciting pool server 91.121.169.20
Feb 20 13:59:50 raspB2 ntpd[27451]: Soliciting pool server 37.187.107.140
Feb 20 14:00:58 raspB2 ntpd[27451]: Soliciting pool server 195.154.108.164
Feb 20 14:02:05 raspB2 ntpd[27451]: Soliciting pool server 178.32.54.53
Feb 20 14:03:13 raspB2 ntpd[27451]: Soliciting pool server 129.250.35.250
Feb 20 14:04:22 raspB2 ntpd[27451]: Soliciting pool server 5.39.71.117
Feb 20 14:05:31 raspB2 ntpd[27451]: Soliciting pool server 129.250.35.251
Feb 20 14:06:38 raspB2 ntpd[27451]: Soliciting pool server 37.187.2.84
Feb 20 14:07:45 raspB2 ntpd[27451]: Soliciting pool server 87.98.188.218


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

Re: [ntp:questions] chrony as a server

[Mike Cook]

I admit that I have not looked at the chrony code/doc and do not use it as it 
when I did take a look, it had no ref clock support so I don’t know what the 
objective is here. That said, from the current discussion I have a feeling that 
integrating temperature data into the clock control loop is not the right use 
for that info. Where frequency stability is paramount as in quartz/rubidium 
frequency standards which have stability 2 or more orders of magnitudes better 
than any cpu system clock,  none of those use temperature data in their control 
loops and for good reason. The only instance where it could possibly be useful, 
but where there are no commercial implementation AFAIK would be where a 1PPS 
ref was lost. Use temperature date by all means, but use it to control the 
environment and not the loop, for what you are measuring with the clock offset 
is the result of the total perturbations on the system, temperature being the 
most important in the short term. With a modern cpu, chip temperature, for 
which you can get data has extremely erratic and rapid swings according to 
load. Trying to follow those is unlikely be productive as you have recognized . 


Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une 
petite et provisoire sécurité, ne méritent ni liberté ni sécurité.
Benjimin Franklin

 Le 19 févr. 2015 à 15:18, Miroslav Lichvar mlich...@redhat.com a écrit :
 
 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.
 
 I'd probably try a shorter polling interval first and maybe get a PPS
 with higher rate if possible to minimize the swings due to temperature
 changes.
 
 -- 
 Miroslav Lichvar
 ___
 questions mailing list
 questions@lists.ntp.org
 http://lists.ntp.org/listinfo/questions
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] leapseconds.list updates and ntpd

[Mike Cook]

The doc http://support.ntp.org/bin/view/Support/ConfiguringNTP#Section_6.14. 
says you have to, but it is describing a particular case where the config file 
is updated. 
If the file path directive is already there, would be a no brainer to add a 
check on the file now and again to see if it had changed. It seems an 
unnecessary constraint to have to restart ntpd in that case. I had a look at 
the source but see no indication that it can be dynamically updated.

 Le 10 févr. 2015 à 16:48, walter.preunin...@gmail.com a écrit :
 
 Either I have missed it, or it is not there. My question is 'does ntpd have 
 to be restarted after a new leapseconds.list file has been downloaded?'
 
 Thanks,
 
 Walter
 
 ___
 questions mailing list
 questions@lists.ntp.org
 http://lists.ntp.org/listinfo/questions
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntpd -x and leap seconds

[Mike Cook]

As the man page for ntpd does not specifically exclude leap second ‘stepping’ 
from the -x behavior, I think that it could well be that the behavior that you 
describe is a bug. That said, it would be nice to have a  -x [ policy ] option 
for it, with the type of slewing for the leaping day ;-) . Could be [ linear | 
google | step | custom ].


 Le 9 févr. 2015 à 11:49, Miroslav Lichvar mlich...@redhat.com a écrit :
 
 I was wondering what others think about handling leap seconds when
 ntpd is running in the slew only mode (-x option).
 
 The -x option disables the kernel discipline, so the kernel is not
 told about pending leap seconds and its up to ntpd to do whatever is
 needed. Older ntpd versions (before 4.2.6) didn't handle leap second
 in the daemon loop and -x could be used to avoid the backward step in
 the Unix time scale and possibly upset the applications running on the
 system.
 
 In 4.2.6 was added support for leap seconds in the daemon loop and
 ntpd now steps the clock by calling settimeofday() or clock_settime(),
 even if the step threshold (set by -x or tinker step) is larger than
 one second.
 
 Should be leap seconds threated as a normal offset and not corrected
 by step when the threshold is larger than 1.0? Should there be a
 separate option for them?
 
 http://bugs.ntp.org/show_bug.cgi?id=2745
 
 -- 
 Miroslav Lichvar
 ___
 questions mailing list
 questions@lists.ntp.org
 http://lists.ntp.org/listinfo/questions
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Shared PPS source/Multiple PPS sources

[Mike Cook]

 Le 7 févr. 2015 à 13:20, Jan Ceuleers jan.ceule...@computer.org a écrit :
 
 On 07/02/15 10:29, Rob wrote:
 I presume you meant this followup to the multi PPS sources to a single
 system and then it is not true either, of course our systems have
 at least 4 cores and they can service multiple interrupts at the same
 time.
 
 On a single-core system I'd invert one of the PPS signals and then
 appropriately fudge the offset so that the two interrupts do not compete
 with each other.

  Another possibility in a single cored system would be to configure 1PPS pulse 
delays. Ublox 6,7,8 and other receivers such at Motorola VP,UT+,M12+T, Trimble 
Resolution, Res.SMT etc, have this possibility. Then fudge that offset in NTP. 

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

Re: [ntp:questions] UK pool server denying access

[Mike Cook]

This guy needs bouncing


 Le 30 déc. 2014 à 07:56, shalu.sysc...@gmail.com a écrit :
 
 Swimming pool Our company designs and installs deluxe indoor and outdoor 
 swimming pools in Central and Greater London areas.
 More at : http://www.swimmingpoolquotes.co.uk/pool-liners/
 
 ___
 questions mailing list
 questions@lists.ntp.org
 http://lists.ntp.org/listinfo/questions

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

Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers

[Mike Cook]

 snip
 Three are fine, as long as only one dies or goes nuts.
 
 Again, define goes nuts. You don't seem to like the term 
 falseticker, so how do you define goes nuts? If one goes nuts or 
 even goes offline, if the remaining two do not agree then it is like 
 having no server at all.
 
 No, it is like having two, with one being out. 
 falseticker is a term with a very specific internal definition. Thus a
 server whose time is right on UTC could be a falseticker, because the
 other two servers were both exactly 3 days out, with tiny jitter estimates. 
 I would say then that you had two servers going nuts, and one good, even
 though ntpd would say there were two good and one false ticker. 

In fact this does not happen. I just tested the hypothesis.
What happens depends on how the two wayward get there exaggerated offset:
a) someone,something resets the date:
result: ntp on both those servers crashes due to the panic_stop limit.

  So in this case  the client has only one reference and continues using that. 
It is not flagged as a falsticker.
  That is normal.
   
b) someone restarts ntp on the servers with the wrong date. Here the servers 
ntpd has no way of knowing that it has bad time and so continues serving 
normally. 
On the client. The running ntp sees immediately a huge offset and huge 
jitter.

Tue Dec  9 13:15:04 CET 2014
 remote   refid  st t when poll reach   delay   offset  jitter
==
*192.168.1.15.GPS1.   1 u  320   64  3600.5490.040   0.037
+192.168.1.16.GPS2.   1 u   37   64  3770.6060.006   0.028
+192.168.1.17.GPS1.   1 u  309   64  3600.5760.027   0.025
Tue Dec  9 13:16:08 CET 2014
 remote   refid  st t when poll reach   delay   offset  jitter
==
 192.168.1.15.GPS1.   1 u   55   64  3410.5650.042 9660780
*192.168.1.16.GPS2.   1 u   37   64  3770.6060.006   0.024
 192.168.1.17.GPS1.   1 u   42   64  3410.5790.041 9660773

After 5 mins the client is unable to resolve this and declares all clock 
falsetickers and then panics. I did not have ntpd in debug mode here, but it is 
reasonable to assume that it panics due to the selected clock being too far out 
and hitting the panic limit.

Tue Dec  9 13:23:37 CET 2014
 remote   refid  st t when poll reach   delay   offset  jitter
==
 192.168.1.15.GPS1.   1 u   45   64  3770.596  -255600 155.539
*192.168.1.16.GPS2.   1 u   25   64  3770.6140.024   0.008
 192.168.1.17.GPS1.   1 u   30   64  3770.583  -255600  52.806
Tue Dec  9 13:24:41 CET 2014
 remote   refid  st t when poll reach   delay   offset  jitter
==
x192.168.1.15.GPS1.   1 u   43   64  3770.596  -255600 179.609
x192.168.1.16.GPS2.   1 u   23   64  3770.6140.024   0.008
x192.168.1.17.GPS1.   1 u   27   64  3770.618  -255599   6.009
/usr/local/bin/ntpq: read: Connection refused
Tue Dec  9 13:25:45 CET 2014
/usr/local/bin/ntpq: read: Connection refused

This is exactly what happens if the client is restarted.

clock_filter: n 1 off -255599.997967 del 0.000662 dsp 7.937502 jit 0.02
select: endpoint -1 -255600.000806
select: endpoint  1 -255599.995128
select: survivor 192.168.1.17 0.002839
select: combine offset -255599.997967134 jitter 0.0
event at 1 192.168.1.17 903a 8a sys_peer
clock_update: at 1 sample 1 associd 18641
event at 1 0.0.0.0 c617 07 panic_stop -255600 s; set clock manually within 1000 
s.
event at 1 0.0.0.0 c61d 0d kern kernel time sync disabled

So ntp does NOT continue in your test case. Your case may be better if the time 
difference is less than the panic limit. Say if the two servers do not insert a 
leap second, but the  « correct » one does. I’ll try that for my own 
satisfaction if I can figure how to do it.

Like

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

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

Re: [ntp:questions] flash=0 , sel_reject

[Mike Cook]

 Le 3 déc. 2014 à 02:37, ganeshsubramon...@gmail.com a écrit :
 
 Is there any scenario where the flash code show 00,ok, but the condition will 
 show server rejected ?
 more details on 
 http://lists.ntp.org/pipermail/questions/2014-December/039065.html
 
 Hope I am not posting in the wrong forum.

It’s the right forum.

I did trawl bugzilla for the symptom but did not find a match. There are issues 
decoding flash when ntpq version and ntpd version are not matched and there are 
differences in bit interpretation introduced over time but a zero report 
doesn’t appear to fit those. 
If you are able to reproduce the problem with the latest dev code, I would open 
a bug at http://bugs.ntp.org.

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

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

Re: [ntp:questions] Leap second to be introduced in June

[Mike Cook]

Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une 
petite et provisoire sécurité, ne méritent ni liberté ni sécurité.
Benjimin Franklin



 Le 16 janv. 2015 à 08:42, Harlan Stenn st...@ntp.org a écrit :
 
 Terje Mathisen writes:
 cmad...@cmadams.net (Chris Adams) wrote:
 Also, you can't properly represent future timestamps (necessary for some
 things) as seconds since an epoch, and that's pretty widely used.  By
 that I mean that the number of seconds between 2015-06-30 23:59:00 and
 2015-07-01 00:00:00 has changed since last month.
 
 The General Timestamp API handles this case, as those timestamps track
 the version number of the timescale.  If you specify noon at (some
 future date), an absolute timestamp, and between now and then some leap
 seconds are added, they'll be added here, too.

 How can we take into account an unknown number of leaps? I will listen 
attentively to your presentation in Bruxelles.
 I can see how it might be feasible…. But I will have to check with 
Schrodinger's cat first.

 
 And this is _exactly_ why it is always a bad idea to use (UTC) seconds 
 for those future timestamps:
 
 If you actually mean that something has to happen N seconds from now, 
 that future timestamp has to be in TAI, since using UTC would obviously 
 blow up across any leap second, right?
 
 If one used a relative/difference timestamp for this, then we're in the
 same boat and we might need some sort of trigger or signal to indicate
 that a leap event has happened.
 
 We're often in a similar boat though, if the clock steps during the
 interval this relative/difference timestamp covers.  This should
 arguably be an option for cron jobs and timer events.

cron is a notoriously bad scheduler. It only wakes up every minute to check the 
schedule tasks, so you can’t be sure of getting accurate execution times. 
It am not sure it is relevant either, as events are scheduled in terms of 
absolute times so will be correct whether or not a leap second is scheduled. 
Task execution on a callback, interval timer event is different. One scheduled 
for execution in 5 seconds, 3 seconds prior to a positive leap second will  get 
dispatched 4 TAI seconds later, but from a legal point of view will be dead on. 
 However if that is not already fixed, it could be.


 
 H
 --
 If you instead meant a calendar event, then you need a different 
 timescale which is either Julian Day Number (JDN) or YMD, followed by 
 either HMS or an offset into the day, followed by the applicable time zone.
 
 Terje
 
 -- 
 - Terje.Mathisen at tmsw.no
 almost all programming can be viewed as an exercise in caching
 
 ___
 questions mailing list
 questions@lists.ntp.org
 http://lists.ntp.org/listinfo/questions
 
 ___
 questions mailing list
 questions@lists.ntp.org
 http://lists.ntp.org/listinfo/questions

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

Re: [ntp:questions] Leap second to be introduced in June

[Mike Cook]

strange response!

 Le 11 janv. 2015 à 21:18, Paul tik-...@bodosom.net a écrit :
 
 Why do folks mention leap seconds on this list?

  part of the NTP protocol deals with the scheduling insertion/deletion of leap 
seconds.

 Why do people point to leap-seconds.NTPtimestamp instead of just
 leap-seconds.list?

  leap-seconds.list is not the file itself, but a symbolic link, which in 
itself contains no relevant information other than the pathname, in this case 
relative, to the actual file.
  The symbolic link leap-seconds.list does not exist on some repositories of 
the information, for example on the navy server tyco.
  Using the full timestamped name is also the only way of unambiguously 
identifying this data. The time stamp differs on different sources. 

 
 My five line leap second file with comments and one extra line for
 (completely unnecessary) context.
 
 #$  3629404800
 #@  3660249600
 3550089600  35  # 1 Jul 2012
 3644697600  36  # 1 Jul 2015
 #h  6eb5f274 cb8c4f5d 6ac15b69 6b095017 f219e7c
 ___
 questions mailing list
 questions@lists.ntp.org
 http://lists.ntp.org/listinfo/questions

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

Re: [ntp:questions] problem with pool directive?

[Mike Cook]

Sorry if this is a dup. My first went through in a non text format. Just 
upgraded to Yosemite.

 Le 12 nov. 2014 à 00:15, Brian Utterback brian.utterb...@oracle.com a écrit 
 :
 
 I believe that the number of pool servers used is determined by the minclock 
 and maxclock parameters.
 


Hmmm. Good idea, but looks like there may be work required. Results of a quick 
test on a cubietruck with :

mike@cubieez:~$ ntpq --version
ntpq 4.2.7p452@1.2483 Fri Jul 18 15:35:11 UTC 2014 (2)

mike@cubieez:~$ ntpq -pn
 remote   refid  st t when poll reach   delay   offset  jitter
==
+192.168.1.23.GPS.1 u   33   64  3770.429   -0.031   0.005
 0.europe.pool.n .POOL.  16 p-   6400.0000.000   0.002
*192.168.1.4 .PPS1.   1 u   64   64  3770.6480.027   0.024
+192.168.1.15.GPS1.   1 u   24   64  3770.5950.068   0.031
-149.210.163.34  80.94.65.10  2 u1  128  377   22.0701.290   0.013
-212.51.144.44   .PPS.1 u  105  128  377   32.5210.185   0.024
-212.70.148.17   109.160.0.1543 u   78  128  377   51.914   -1.027   0.077
-46.4.205.42 192.53.103.108   2 u  104  128  377   33.453   -2.408   0.031
-91.240.0.5  212.82.32.15 2 u   36  128  377   25.9435.495   0.106

  add our limiter and restart ntpd

mike@cubieez:~$ sudo vi /etc/ntp.conf
[sudo] password for mike: 
mike@cubieez:~$ sudo /etc/init.d/ntp restart
[sudo] password for mike: 
[ ok ] Stopping NTP server: ntpd.
[ ok ] Starting NTP server: ntpd.
mike@cubieez:~$ ntpq -pn
 remote   refid  st t when poll reach   delay   offset  jitter
==
+192.168.1.23.GPS.1 u6   16   370.193   -0.017   0.038
 0.europe.pool.n .POOL.  16 p-   6400.0000.000   0.002
*192.168.1.4 .PPS1.   1 u7   16   370.498   -0.055   0.062
+192.168.1.15.GPS1.   1 u5   16   370.5780.065   0.036
-62.75.236.38192.53.103.108   2 u2   643   26.994   -1.179   0.091
-193.225.118.163 121.131.112.137  2 u   56   641   43.189   -0.369   0.441
mike@cubieez:~$ 

  so tos maxclock 5 limits those allocated as Brian suggests, but removing 
access to a local clock leads to instability from which the pool allocations do 
not recover. 

mike@cubieez:~$ # pull a local clock
mike@cubieez:~$ 
mike@cubieez:~$ bin/ntpchk
NOTICE: using /usr/local/bin/ntpq to query ntpd.

ntp is up and running - checking peer status
Wed Nov 12 08:50:27 CET 2014
 remote   refid  st t when poll reach   delay   offset  jitter
==
+192.168.1.23.GPS.1 u   19   32  3770.4500.008   0.022
 0.europe.pool.n .POOL.  16 p-   6400.0000.000   0.002
*192.168.1.4 .PPS1.   1 u4   32  3770.6290.022   0.053
+192.168.1.15.GPS1.   1 u2   32  3770.6180.055   0.034
-62.75.236.38192.53.103.108   2 u   23   64  177   27.043   -1.064   0.065
-193.225.118.163 165.94.197.402 u   24   64  177   43.191   -0.371   0.543
Wed Nov 12 08:51:32 CET 2014
 remote   refid  st t when poll reach   delay   offset  jitter
==
+192.168.1.23.GPS.1 u   51   32  3760.450   -0.044   0.045
 0.europe.pool.n .POOL.  16 p-   6400.0000.000   0.002
*192.168.1.4 .PPS1.   1 u4   32  3770.6290.022   0.045
+192.168.1.15.GPS1.   1 u2   32  3770.6180.055   0.043
-62.75.236.38192.53.103.108   2 u   20   64  377   27.030   -1.169   0.081
-193.225.118.163 165.94.197.402 u   22   64  377   43.173   -0.369   0.483

  So 192.168.1.23 is down and unreachable.


Wed Nov 12 08:59:01 CET 2014
 remote   refid  st t when poll reach   delay   offset  jitter
==
 192.168.1.23.GPS.1 u  500   6400.450   -0.044   0.000
 0.europe.pool.n .POOL.  16 p-   6400.0000.000   0.002
*192.168.1.4 .PPS1.   1 u3   32  3770.6260.007   0.008
+192.168.1.15.GPS1.   1 u   30   32  3770.6130.003   0.015
+139.112.153.37  146.213.3.1812 u   17   647   45.515   -3.319   0.214
-147.231.100.5   147.231.100.11   2 u   18   647   51.684  -10.521   0.300
^C
mike@cubieez:~$ #   this appears stable

 An extra pool server is not allocated to fill the hole. This may be as 
designed as the association has not disappeared but ideally one would like the 
hole filled with something that works.
But worse is to come.

Nov 12 09:06:33 cubieez ntpd[16279]: 147.231.100.5 local addr 

Re: [ntp:questions] problem with pool directive?

[Mike Cook]

 Le 12 nov. 2014 à 00:15, Brian Utterback brian.utterb...@oracle.com a écrit 
 :
 
 I believe that the number of pool servers used is determined by the minclock 
 and maxclock parameters.
 

Hmmm. Good idea, but looks like there may be work required. Results of a quick 
test on a cubietruck with :

mike@cubieez:~$ ntpq --version
ntpq 4.2.7p452@1.2483 Fri Jul 18 15:35:11 UTC 2014 (2)

mike@cubieez:~$ ntpq -pn
 remote   refid  st t when poll reach   delay   offset  jitter
==
+192.168.1.23.GPS.1 u   33   64  3770.429   -0.031   0.005
 0.europe.pool.n .POOL.  16 p-   6400.0000.000   0.002
*192.168.1.4 .PPS1.   1 u   64   64  3770.6480.027   0.024
+192.168.1.15.GPS1.   1 u   24   64  3770.5950.068   0.031
-149.210.163.34  80.94.65.10  2 u1  128  377   22.0701.290   0.013
-212.51.144.44   .PPS.1 u  105  128  377   32.5210.185   0.024
-212.70.148.17   109.160.0.1543 u   78  128  377   51.914   -1.027   0.077
-46.4.205.42 192.53.103.108   2 u  104  128  377   33.453   -2.408   0.031
-91.240.0.5  212.82.32.15 2 u   36  128  377   25.9435.495   0.106

  add our limiter and restart ntpd

mike@cubieez:~$ sudo vi /etc/ntp.conf
[sudo] password for mike: 
mike@cubieez:~$ sudo /etc/init.d/ntp restart
[sudo] password for mike: 
[ ok ] Stopping NTP server: ntpd.
[ ok ] Starting NTP server: ntpd.
mike@cubieez:~$ ntpq -pn
 remote   refid  st t when poll reach   delay   offset  jitter
==
+192.168.1.23.GPS.1 u6   16   370.193   -0.017   0.038
 0.europe.pool.n .POOL.  16 p-   6400.0000.000   0.002
*192.168.1.4 .PPS1.   1 u7   16   370.498   -0.055   0.062
+192.168.1.15.GPS1.   1 u5   16   370.5780.065   0.036
-62.75.236.38192.53.103.108   2 u2   643   26.994   -1.179   0.091
-193.225.118.163 121.131.112.137  2 u   56   641   43.189   -0.369   0.441
mike@cubieez:~$ 

  so tos maxclock 5 limits those allocated as Brian suggests, but removing 
access to a local clock leads to instability from which the pool allocations do 
not recover. 

mike@cubieez:~$ # pull a local clock
mike@cubieez:~$ 
mike@cubieez:~$ bin/ntpchk
NOTICE: using /usr/local/bin/ntpq to query ntpd.

ntp is up and running - checking peer status
Wed Nov 12 08:50:27 CET 2014
 remote   refid  st t when poll reach   delay   offset  jitter
==
+192.168.1.23.GPS.1 u   19   32  3770.4500.008   0.022
 0.europe.pool.n .POOL.  16 p-   6400.0000.000   0.002
*192.168.1.4 .PPS1.   1 u4   32  3770.6290.022   0.053
+192.168.1.15.GPS1.   1 u2   32  3770.6180.055   0.034
-62.75.236.38192.53.103.108   2 u   23   64  177   27.043   -1.064   0.065
-193.225.118.163 165.94.197.402 u   24   64  177   43.191   -0.371   0.543
Wed Nov 12 08:51:32 CET 2014
 remote   refid  st t when poll reach   delay   offset  jitter
==
+192.168.1.23.GPS.1 u   51   32  3760.450   -0.044   0.045
 0.europe.pool.n .POOL.  16 p-   6400.0000.000   0.002
*192.168.1.4 .PPS1.   1 u4   32  3770.6290.022   0.045
+192.168.1.15.GPS1.   1 u2   32  3770.6180.055   0.043
-62.75.236.38192.53.103.108   2 u   20   64  377   27.030   -1.169   0.081
-193.225.118.163 165.94.197.402 u   22   64  377   43.173   -0.369   0.483

  So 192.168.1.23 is down and unreachable.


Wed Nov 12 08:59:01 CET 2014
 remote   refid  st t when poll reach   delay   offset  jitter
==
 192.168.1.23.GPS.1 u  500   6400.450   -0.044   0.000
 0.europe.pool.n .POOL.  16 p-   6400.0000.000   0.002
*192.168.1.4 .PPS1.   1 u3   32  3770.6260.007   0.008
+192.168.1.15.GPS1.   1 u   30   32  3770.6130.003   0.015
+139.112.153.37  146.213.3.1812 u   17   647   45.515   -3.319   0.214
-147.231.100.5   147.231.100.11   2 u   18   647   51.684  -10.521   0.300
^C
mike@cubieez:~$ #   this appears stable

 An extra pool server is not allocated to fill the hole. This may be as 
designed as the association has not disappeared but ideally one would like the 
hole filled with something that works.
But worse is to come.

Nov 12 09:06:33 cubieez ntpd[16279]: 147.231.100.5 local addr 192.168.1.124 - 
null
Nov 12 09:12:19 cubieez ntpd[16279]: 139.112.153.37 local addr 192.168.1.124 - 

Re: [ntp:questions] Timekeeping on Windows 2008r2 VM on Linux QEMU/KVM

[Mike Cook]

Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une 
petite et provisoire sécurité, ne méritent ni liberté ni sécurité.
Benjimin Franklin

 Le 21 janv. 2015 à 23:40, Harlan Stenn st...@ntp.org a écrit :
 
 Rob writes:
 Sander Smeenk ssme...@freshdot.net wrote:
 What is actually wrong with running ntpdate to initially sync a
 clock?  Why is the ntpdate.exe binary provided when 'we' shouldnt use
 it?  Keep in mind that i 'just want to get to seconds accuracy'
 before i start ntpd.
 
 The problem is that you give the clock an initial kick that ntpd does
 not know about, and it tends to have problems correcting that.
 This sometimes results in the problems you are seeing.
 
 This sounds like total BS to me.
 
 ntpd has no way of knowing what went on before it was started, and I'm
 not aware of anything on either Windows or Unix that would cause any
 applied immediate adjustment to have *any* residual affect on ntp.
 
 But perhaps you know something I don't - please say more.

 I don’t have a free client to test this on, but I believe that by default 
ntpdate will SLEW the clock if the offset is less than 128ms and that operation 
could still be in progress even though the command has terminated, and when 
ntpd is started during that period, it gets a false sense of the system clock 
stability as it is comparing against a moving target. I have seen this before I 
think, in xntpd. If it is the case, then we should see the same in unix, so I 
will try and test it.


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

Re: [ntp:questions] Leap second to be introduced in June

[Mike Cook]

 Le 21 janv. 2015 à 07:18, Terje Mathisen terje.mathi...@tmsw.no a écrit :
 
 Mike S wrote:
 The real problem is systems (POSIX, particularly), which incorrectly
 handle time, despite having over 40 years to get it right. They try to
 please everyone, while pleasing no one. POSIX tracks and does
 calculations on determinate intervals (seconds since 1/1/1970, and every
 minute has 60 seconds), and also tries to handle civil time, which has
 indeterminate intervals (unpredictable 61 second minutes). So it fails
 by trying to do two mutually exclusive things.
 
 Right, POSIX is neither UTC nor TAI: It is mostly a calendar device!
 
 POSIX is really measuring day numbers, but using a counter which is scaled by 
 86400. This means that on any day with a leap second, it is not really using 
 SI seconds as the time base.
 
 It's not a particularly difficult problem to solve (timezone info is
 regularly updated because of civil changes, historical leap seconds
 could be, too), but requires thought about whether specific future
 events should be considered as intervals or absolute time values.
 
 Since there is no way to know about leap seconds several years into the 
 future, forward POSIX timestamps must always be considered as absolute 
 references. They should never be used for time intervals, even if that is the 
 (by far) most common use today. :-(

  And one of the reasons why a significant portion of the computing community 
wants to get rid of leap seconds. A coverup for bad engineering practices.

 
 Terje
 
 -- 
 - Terje.Mathisen at tmsw.no
 almost all programming can be viewed as an exercise in caching
 
 ___
 questions mailing list
 questions@lists.ntp.org
 http://lists.ntp.org/listinfo/questions
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Leap second to be introduced in June

[Mike Cook]

 
 Not true. That would violate POSIX. There is no properly implements,
 or right thing.
 
 Perhaps you're unaware that POSIX isn't the One True Operating System 
 specification.
 
 Properly implements means it follows the well defined, 40 year old 
 normative specification for handling leap seconds, which requires supporting 
 minutes with 59 or 61 seconds. That's something POSIX doesn't properly 
 implement.

Agreed. It is often overlooked that leap seconds were implemented from 1972 and 
POSIX only  saw the light of day in 1988. So POSIX is just plain wrong here 
IMHO.

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

Re: [ntp:questions] UK pool server denying access

[Mike Cook]

This guy needs bouncing


 Le 30 déc. 2014 à 07:56, shalu.sysc...@gmail.com a écrit :
 
 Swimming pool Our company designs and installs deluxe indoor and outdoor 
 swimming pools in Central and Greater London areas.
 More at : http://www.swimmingpoolquotes.co.uk/pool-liners/
 
 ___
 questions mailing list
 questions@lists.ntp.org
 http://lists.ntp.org/listinfo/questions
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Firewall requirements for NTP as both client and server

[Mike Cook]

 Le 28 déc. 2014 à 17:11, David Taylor david-tay...@blueyonder.co.uk.invalid 
 a écrit :
 
 I'm trying to understand the firewall requirements for NTP.  Using the 
 FreeBSD ipfw I have the following, which appears to allow NTPns to operate as 
 a client, i.e. it can get times from other servers on my LAN, and even from 
 the WAN.
 
  add 100 allow udp from any to any 123
  add 200 allow udp from any 123 to any
 
 Check  with ipfw -S show that you are getting the result you want:

 However, other servers on the same LAN appear not to be able to see this 
 NTPns server, always being in an INIT state.  I wonder whether this might be 
 a firewall issue, or whether the settings above should suffice both for NTPns 
 as a client, and as a server.  My reading is that they should, but I'm very 
 unfamiliar with ipfw (and that's what I have to use).
 
  
I use the following for my 4801 on 192.168.1.3 (show result), allowing all NTP 
requests IN
00960 55601149140 set 8 allow udp from any to 192.168.1.3 dst-port 123 
via sis0 keep-state
and letting any server initiated request out. I don’t restrict outgoing packets 
as I am the only user.
05100  9721814 1149904224 set 0 allow ip from 192.168.1.3 to any keep-state

when I get odd things like this happening I select logging and see what is / is 
not getting through.
ex.
00705   717773  274869433 set 2 allow log ip from not 192.168.0.0/16 to 
192.168.1.3 dst-port 80 via sis0 keep-state
to log all incoming http from the internet.

It could be that your other servers have firewalls restricting some address 
traffic . 

you can use tcpdump to see what is on your LAN

$ sudo tcpdump -p udp port 123
Password:
Hold it up to the light --- not a brain in sight!
Password:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on sis0, link-type EN10MB (Ethernet), capture size 96 bytes
18:06:01.575375 IP gluon.stratum1.d2g.com.ntp  ntp-p1.obspm.fr.ntp: NTPv4, 
Client, length 48
18:06:02.575056 IP gluon.stratum1.d2g.com.ntp  ns1.nexellent.net.ntp: NTPv4, 
Client, length 48
18:06:02.597744 IP ns1.nexellent.net.ntp  gluon.stratum1.d2g.com.ntp: NTPv4, 
Server, length 48
18:06:03.575860 IP gluon.stratum1.d2g.com.ntp  
ch-ntp01.swiss-networks.net.ntp: NTPv4, Client, length 48
18:06:03.601883 IP ch-ntp01.swiss-networks.net.ntp  
gluon.stratum1.d2g.com.ntp: NTPv4, Server, length 48
18:06:05.575561 IP gluon.stratum1.d2g.com.ntp  
laurelineA.stratum1.d2g.com.ntp: NTPv4, Client, length 48
18:06:05.575815 IP laurelineA.stratum1.d2g.com.ntp  
gluon.stratum1.d2g.com.ntp: NTPv4, Server, length 48
18:06:14.575661 IP gluon.stratum1.d2g.com.ntp  muon.stratum1.d2g.com.ntp: 
NTPv4, Client, length 48
18:06:14.576758 IP muon.stratum1.d2g.com.ntp  gluon.stratum1.d2g.com.ntp: 
NTPv4, Server, length 48
18:06:15.575563 IP gluon.stratum1.d2g.com.ntp  raspb1.home.ntp: NTPv4, Client, 
length 48
18:06:15.576416 IP raspb1.home.ntp  gluon.stratum1.d2g.com.ntp: NTPv4, Server, 
length 48

have fun

 Thanks!
 
 -- 
 Cheers,
 David
 Web: http://www.satsignal.eu
 
 ___
 questions mailing list
 questions@lists.ntp.org
 http://lists.ntp.org/listinfo/questions
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Firewall requirements for NTP as both client and server

[Mike Cook]

 Le 28 déc. 2014 à 19:14, David Taylor david-tay...@blueyonder.co.uk.invalid 
 a écrit :
 
 17:46:20.823583 IP 192.168.0.1.ntp  net4501.ntp: NTPv4, Client, length 48
 17:46:52.838966 IP 192.168.0.1.ntp  net4501.ntp: NTPv4, Client, length 48
 
 They are 32 seconds approximately apart which is what I would expect. SO does 
 that mean that the firewall has blocked them, or that the NTPns server never 
 responded?  There is no firewall block on 192.168.0.1 making requests and 
 getting responses from servers on or off the LAN.
 
  This looks like your firewall, 

  add 200 allow udp from any 123 to any

  Is saying allow port 123 SOURCE packets in from any  source, BUT client 
packets don’t come from port 123, but from an unprivileged port:
here is a log from my internet facing server, also a 4801:

Dec 28 18:23:58 muon kernel: ipfw: 540 Accept UDP 192.3.96.154:32894 
192.168.1.4:123 in via sis0

 so your rules are not allowing the outside requests to get to NTPns. If you 
add logging you will see them Denied .

fixing this is an exercise for the reader.

 I'll investigate NTPns further
 
 -- 
 Cheers,
 David
 Web: http://www.satsignal.eu
 
 ___
 questions mailing list
 questions@lists.ntp.org
 http://lists.ntp.org/listinfo/questions
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntpq -c sysstats (replacing 'ntpdc -c sysstats') ?

[Mike Cook]

Works for me. At least in Win7


 Le 22 déc. 2014 à 22:35, irwin.till...@gmail.com a écrit :
 
 After upgrading to 4.2.8, I'm trying to migrate my use of 'ntpdc -c sysstats' 
 to ntpq.  
 
 The 4.2.8 source seems to indicate that something like 'ntpq -c sysstats' 
 might be the answer, but ntpq says that the 'sysstats' command is unknown. 
 Any other ideas?
 
 ___
 questions mailing list
 questions@lists.ntp.org
 http://lists.ntp.org/listinfo/questions
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers

[Mike Cook]

 Le 14 déc. 2014 à 08:24, Jan Ceuleers jan.ceule...@computer.org a écrit :
 
 On 14/12/14 03:28, Harlan Stenn wrote:
 Not that easy - unless you are one of the lucky few to have encrypted
 access to a NIST source, when it may be automatic.
 
 http://www.ietf.org/timezones/data/leap-seconds.list

 Or the Navy 
wget ftp://tycho.usno.navy.mil/pub/ntp/leap-seconds.3617308800
not sure where the issue is here.
 
 Added to the Wiki at http://support.ntp.org/bin/view/Support/ConfiguringNTP
 
 The IETF also serve their content over SSL if anyone thinks this
 increases the level of trust one can have in that content.
 ___
 questions mailing list
 questions@lists.ntp.org
 http://lists.ntp.org/listinfo/questions
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers

[Mike Cook]

To close this parenthesis I did the test for leap second only being propagated 
by 1 of three servers and Bill’s hypothesis is confirmed with a couple of 
precisions that I would like to share as it might just be a real life case.

a) To start off , in my test all three servers to my one client are sync’d to 
the same time. One of them has a leap file modified for my test. As UTC is 
defined WITH leap seconds, although all servers are sync’d, this is the ONLY 
one serving UTC. It correctly advertises the upcoming leap.
b) When the leap occurs, the server with the leap file correctly inserts the 
leap, as does the client. The client’s NTP correctly detects the step and after 
a few polls correctly flags the UTC server as falsticker as the majority are 
consistently in disagreement with the now updated clock.
Thu Jan 1 01:06:05 CET 2015
remote refid st t when poll reach delay offset jitter
==
*192.168.1.15 .GPS1. 1 u 42 64 377 0.495 999.894 534.506
+192.168.1.17 .GPS1. 1 u 39 64 377 0.564 999.899 654.645
x192.168.1.18 .GPS1. 1 u 66 64 377 0.575 -0.066 0.029
Now we have the full story and the « good » clock has been declared falsticker 
as not part of the majority but the story doesn't end there. A bit later the 
clients clock, which is at the time on UTC with leap second, gets stepped 
forward 1 sec to be in agreement with the majority. This is expected, but we 
have a client which now has not got good time. 
Thu Jan 1 01:11:27 CET 2015
remote refid st t when poll reach delay offset jitter
==
192.168.1.15 .GPS1. 1 u 14 16 3 0.488 -0.039 0.038
*192.168.1.17 .GPS1. 1 u 22 64 1 0.516 -0.044 0.031
192.168.1.18 .GPS1. 1 u 14 16 3 0.566 -999.99 0.052
Thu Jan 1 01:12:31 CET 2015
remote refid st t when poll reach delay offset jitter
==
Final status with the UTC server redeclared as a falsticker.
Thu Jan 1 01:15:38 CET 2015
remote refid st t when poll reach delay offset jitter
==
+192.168.1.15 .GPS1. 1 u 46 64 77 0.488 -0.039 0.047
*192.168.1.17 .GPS1. 1 u 17 64 37 0.520 -0.054 0.032
x192.168.1.18 .GPS1. 1 u 47 64 77 0.575 -999.99 0.053
This test was to verify a worst case scenario but shows that when 
administrators are preparing for a leap, they need to make sure that a majority 
of servers will be making the leap and propagate that info. This is not always 
easy as query commands are routinely blocked by some internet servers.
Note :
There is a possible bug or RFE required somewhere as the clock variable tai is 
not correctly set on the client.
On the server that has the leap file we have the correct update rom 35 to 36 :
mike@raspB4 ~ $ ntpq -c rv 0 tai
tai=36
But on the client which has no leap file (and probably because of this) tai has 
been set to 1. So I think that what is happening is that the server notion of 
tai is not propagated to clients.
mike@cubieez2:~$ ntpq -c rv 0 tai
tai=1
There will most likely be a leap declared for the end of Jul 1 2015 or latest 
Jan 1 2016 so we have a bit of time yet to clean up the park.



 Le 9 déc. 2014 à 14:20, Mike Cook michael.c...@sfr.fr a écrit :
 
 snip
 
 
 
 Three are fine, as long as only one dies or goes nuts.
 
 Again, define goes nuts. You don't seem to like the term 
 falseticker, so how do you define goes nuts? If one goes nuts or 
 even goes offline, if the remaining two do not agree then it is like 
 having no server at all.
 
 No, it is like having two, with one being out. 
 falseticker is a term with a very specific internal definition. Thus a
 server whose time is right on UTC could be a falseticker, because the
 other two servers were both exactly 3 days out, with tiny jitter estimates. 
 I would say then that you had two servers going nuts, and one good, even
 though ntpd would say there were two good and one false ticker.
 
 In fact this does not happen. I just tested the hypothesis.
 What happens depends on how the two wayward get there exaggerated offset:
 a) someone,something resets the date:
   result: ntp on both those servers crashes due to the panic_stop limit.
 
 So in this case  the client has only one reference and continues using that. 
 It is not flagged as a falsticker.
 That is normal.
 
 b) someone restarts ntp on the servers with the wrong date. Here the servers 
 ntpd has no way of knowing that it has bad time and so continues serving 
 normally. 
   On the client. The running ntp sees immediately a huge offset and huge 
 jitter.
 
 Tue Dec  9 13:15:04 CET 2014
remote   refid  st t when poll reach   delay   offset  jitter
 ==
 *192.168.1.15.GPS1.   1 u  320   64  3600.5490.040   0.037
 +192.168.1.16.GPS2.   1 u

Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers

[Mike Cook]

I agree that it is expected. Just wanted to confirm for myself. Habit from my 
admin/support days. Agreed that anyone needing the tai delta would load the 
leap file, but ntpd could propagate that info as well. I haven’t checked the 
code to see if it is supposed to, but in my test it wasn’t.


 Le 12 déc. 2014 à 11:25, Harlan Stenn st...@ntp.org a écrit :
 
 Mike,
 
 I think you are seeing the correct and expected behavior.
 
 The root cause here is that the majority of the upstream servers are
 *incorrectly* not advertising the leap second.
 
 There have been problems before where a misconfigured server has
 incorrectly advertised a non-existent leap-second, and in cases where
 folks had an adequate number of correctly configured servers, this
 mistake was properly ignored.
 
 I have not been closely following this thread, so I might be missing
 something.
 
 It's pretty easy to download and install a leapsecond file, and ntpd
 will pay attention to that...
 
 Or am I missing something?
 -- 
 Harlan Stenn st...@ntp.org
 http://networktimefoundation.org - be a member!
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers

[Mike Cook]

snip
 
 
 
 Three are fine, as long as only one dies or goes nuts.
 
 Again, define goes nuts. You don't seem to like the term 
 falseticker, so how do you define goes nuts? If one goes nuts or 
 even goes offline, if the remaining two do not agree then it is like 
 having no server at all.
 
 No, it is like having two, with one being out. 
 falseticker is a term with a very specific internal definition. Thus a
 server whose time is right on UTC could be a falseticker, because the
 other two servers were both exactly 3 days out, with tiny jitter estimates. 
 I would say then that you had two servers going nuts, and one good, even
 though ntpd would say there were two good and one false ticker.

In fact this does not happen. I just tested the hypothesis.
What happens depends on how the two wayward get there exaggerated offset:
a) someone,something resets the date:
   result: ntp on both those servers crashes due to the panic_stop limit.

 So in this case  the client has only one reference and continues using that. 
It is not flagged as a falsticker.
 That is normal.

b) someone restarts ntp on the servers with the wrong date. Here the servers 
ntpd has no way of knowing that it has bad time and so continues serving 
normally. 
   On the client. The running ntp sees immediately a huge offset and huge 
jitter.

Tue Dec  9 13:15:04 CET 2014
remote   refid  st t when poll reach   delay   offset  jitter
==
*192.168.1.15.GPS1.   1 u  320   64  3600.5490.040   0.037
+192.168.1.16.GPS2.   1 u   37   64  3770.6060.006   0.028
+192.168.1.17.GPS1.   1 u  309   64  3600.5760.027   0.025
Tue Dec  9 13:16:08 CET 2014
remote   refid  st t when poll reach   delay   offset  jitter
==
192.168.1.15.GPS1.   1 u   55   64  3410.5650.042 9660780
*192.168.1.16.GPS2.   1 u   37   64  3770.6060.006   0.024
192.168.1.17.GPS1.   1 u   42   64  3410.5790.041 9660773

After 5 mins the client is unable to resolve this and declares all clock 
falsetickers and then panics. I did not have ntpd in debug mode here, but it is 
reasonable to assume that it panics due to the selected clock being too far out 
and hitting the panic limit.

Tue Dec  9 13:23:37 CET 2014
remote   refid  st t when poll reach   delay   offset  jitter
==
192.168.1.15.GPS1.   1 u   45   64  3770.596  -255600 155.539
*192.168.1.16.GPS2.   1 u   25   64  3770.6140.024   0.008
192.168.1.17.GPS1.   1 u   30   64  3770.583  -255600  52.806
Tue Dec  9 13:24:41 CET 2014
remote   refid  st t when poll reach   delay   offset  jitter
==
x192.168.1.15.GPS1.   1 u   43   64  3770.596  -255600 179.609
x192.168.1.16.GPS2.   1 u   23   64  3770.6140.024   0.008
x192.168.1.17.GPS1.   1 u   27   64  3770.618  -255599   6.009
/usr/local/bin/ntpq: read: Connection refused
Tue Dec  9 13:25:45 CET 2014
/usr/local/bin/ntpq: read: Connection refused

This is exactly what happens if the client is restarted.

clock_filter: n 1 off -255599.997967 del 0.000662 dsp 7.937502 jit 0.02
select: endpoint -1 -255600.000806
select: endpoint  1 -255599.995128
select: survivor 192.168.1.17 0.002839
select: combine offset -255599.997967134 jitter 0.0
event at 1 192.168.1.17 903a 8a sys_peer
clock_update: at 1 sample 1 associd 18641
event at 1 0.0.0.0 c617 07 panic_stop -255600 s; set clock manually within 1000 
s.
event at 1 0.0.0.0 c61d 0d kern kernel time sync disabled

So ntp does NOT continue in your test case. Your case may be better if the time 
difference is less than the panic limit. Say if the two servers do not insert a 
leap second, but the  « correct » one does. I’ll try that for my own 
satisfaction if I can figure how to do it.
  
 

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

Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers

[Mike Cook]

 Le 2 déc. 2014 à 02:59, edstu...@gmail.com a écrit :
 
 Hi,
 
 I am looking to implement an NTP network and I was reading 
 http://support.ntp.org/bin/view/Support/DesigningYourNTPNetwork.  It suggests 
 4 stratum 1 peers and 4 stratum 2 peers well.  I understand, that the 
 document recommends this so that if one of the servers in a stratum dies, 
 there will still be 3 servers from which a majority clique should be found.  
 The problem is that we will be starting out with simply 100 nodes at most.  
 At the same time, we want drift less than 1 second.  However, over the next 7 
 years or so, we should hit ~ 1000 NTP clients.  Is the document's 
 recommendation overkill for my situation?

 The recommendation is really a minimum for whatever the number of clients that 
you are servicing, 1 or 1000. Fortunately, you don’t need to have all the 
upstream servers in your shop, unless you don’t allow connections to the 
internet. If you do, then with the latest versions on NTP you can use the pool 
for a minimal config in your top level servers, and serve the other clients 
locally from them. If you have a good view of the sky, then you could  use very 
cheap GPS sync’d stratum 1 servers in your top level. 1 second is not a 
difficult constraint. 

 
 Thanks,
 Ed Stuart
 
 ___
 questions mailing list
 questions@lists.ntp.org
 http://lists.ntp.org/listinfo/questions
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP shared memory driver

[mike cook]

Le 15 sept. 2014 à 13:54, Rob a écrit :

 Claudio Persico cloudd...@gmail.com wrote:
 Thanks a lot for the explanation.
 
 I've just modified my test application. Now it works till 1 seconds of 
 difference (4 hours is too much even for the first big time jump allowed by 
 -g option).
 

  think about adding a battery backed RTC.

 My question now is: since my system is a battery powered one, and the 
 batteries are very often removed so the time always starts at the epoch time 
 (1970) or something very old, is there a way to make NTP work with a so big 
 time jump?
 
 Use the -g option.

If -g has a limit , then you could use ntpdate -b addr . No limit there

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

Re: [ntp:questions] no drift-file on 2008 R2 vps and the time diff. is getting bigger and bigger?

[mike cook]

Le 14 sept. 2014 à 07:27, gooly a écrit :

  frequency=500.000,

Your clock has a greater than the maximum drift acceptabe to NTP.  
You either need new hardware, or read the VPS doc on clock management.
Is NTP running in some sort of virtual machine? Probably not a good idea.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?

[mike cook]

Le 13 sept. 2014 à 07:46, Rich Wales a écrit :
 
 
 -68.65.164.12.PPS.1 u   13   16  3728.168   -2.126   4.585
 
 -171.67.203.16   204.63.224.702 u2   16  3339.6892.146   3.930
 
 Any thoughts?
 
  I should have added
netstat -i  

are you dropping packets, getting errors

 Rich Wales
 ri...@richw.org
 ___
 questions mailing list
 questions@lists.ntp.org
 http://lists.ntp.org/listinfo/questions

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

Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?

[mike cook]

Le 13 sept. 2014 à 07:46, Rich Wales a écrit :

 Replying to Charles Elliott:
 
 The offset may be a function of distance.  Try this experiment:
 Set up your ntp.conf file to have three servers . . . :
 1.  A relatively unused stratum 1 or 2 server as close to you as possible
 2.  A relatively unused stratum 1 or 2 server about 1,000 miles away
 3.  A relatively unused stratum 1 or 2 server more than 2,000 miles away
 
 OK, here is information taken from two local servers under my control.
 
 ==
 
 This first machine (171.67.203.16) is on the Stanford University campus.  The
 first two peers listed below are located on the Stanford campus; the third
 peer is also run by Stanford but is about 50 miles east of the campus.
 
 +171.64.7.105.PPS.1 u 1012 1024  3770.465   -0.045   0.076
 +171.64.7.67 .PPS.1 u  217 1024  3770.584   -0.043   0.081

  delay is low so you are nearby in a network sense, maybe on the same net 
(what is your netmask).

 *204.63.224.70   .PPS.1 u  737 1024  3771.803   -0.031   0.252
 
 This next peer is my home machine (the one I described earlier as being
 connected to the Internet via a cable modem), with its own local GPS clock.
 
 -68.65.164.12.PPS.1 u   13   16  3728.168   -2.126   4.585

  I thought that you were connecting over a VPN?  The delay is high but not 
exceptionally and you can get  good stability even so. However,  the jitter is 
huge and your link is not stable as your reach is not 377. Here you missing 
polls , possibly due to a timeout or dropped packets.  These are not symptoms 
of link asymmetry, but might be due to unbalanced packet priority or something. 
Do you have HD TV on at the same time. 

 
 Finally, these two servers are in Utah (Xmission) and Poland.
 
 -198.60.22.240   .GPS.1 u  721 1024  377   18.9310.239   0.045
 -213.222.200.99  .PPS.1 u  833 1024  377  172.099   -4.083   1.167
 
 ==
 
 Now, here is the info from my home machine (68.65.164.12).  First, my local
 GPS reference clock:
 
 *127.127.28.1.PPS.0 l   14   16  3770.000   -0.003   0.025
 x127.127.28.0.GPS.8 l7   16  3770.000  -37.762  13.399
 
 Next, my campus machine (see above for details):
 
 -171.67.203.16   204.63.224.702 u2   16  3339.6892.146   3.930

   again, reach is showing a 'broken' link.

 
 And finally, the same two remote servers (in Utah and Poland) that I used on
 my campus machine:
 
 +198.60.22.240   .GPS.1 u   45   64  377   35.2226.542   2.864
 +213.222.200.99  .PPS.1 u   18   64  377  191.1924.890   8.968

  These are not showing bad reach, at least not on these samples. Do they ever 
show a non 377 value?

 
 ==
 
 Any thoughts?

  You are up late. 

 
 Rich Wales
 ri...@richw.org
 ___
 questions mailing list
 questions@lists.ntp.org
 http://lists.ntp.org/listinfo/questions
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?

[mike cook]

Le 11 sept. 2014 à 18:48, Rob a écrit :

 Paul tik-...@bodosom.net wrote:
 As an aside has anyone tried shaping traffic to make the
 upstream/downstream latencies similar?  It would seem more efficient
 to apply network solutions to network problems if possible.
 
 That does not work.  The asymmetry is not caused by traffic but by
 modem parameters.

  Did I miss something? The OP did not offer any evidence that there was path 
asymmetry, just that there was an unexplained offset between two GPS sync'd 
servers. It is often not possible to identify the origin of such an offset, but 
it would help if the suggested feature was implemented to take care of these 
corner cases. I saw that Dr Mills was in agreement back in 2005 but that the 
implementation is complex. If anyone wants a subject for an MSc project, this 
could be it.

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

Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?

[mike cook]

Le 11 sept. 2014 à 21:08, Paul a écrit :

 On Thu, Sep 11, 2014 at 2:08 PM, mike cook michael.c...@sfr.fr wrote:
  Did I miss something?
 
 On Tue, Sep 9, 2014 at 3:17 PM, Rich Wales ri...@richw.org wrote:
 My home LAN is connected to my school's network via a cable modem.
 
 If we make the (safe) assumption of a common cable ISP/FiOS in the
 Palo Alto area the path is asymmetric.

  Yup, AsymmetricDSL does have different up/down bit rates. What I really meant 
was that the difference would not explain his issue. 
  ex: with a 12Mbps down rate and 1.3Mbps up rate, the ratio is around 40usec 
to 300usec transfer of a 48byte NTP packet. 

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

Re: [ntp:questions] ntp-4.2.6p5

[mike cook]

Le 22 août 2014 à 20:09, Steve Clark a écrit :

 Hello,
 
 We are running the above release. It works great until the interface for the 
 default route is
 brought down and then back up. Then after a half hour or so it ntpstat starts 
 returning
 
 
 synchronised to unspecified at stratum 4
   time correct to within 1149 ms
   polling server every 64 s
 
 $ ntpdc -c dmpeers
  remote   local  st poll reach  delay   offset disp
 ===
  ccadmin.cycores 0.0.0.0  2   640 0.03999  0.004545 3.99217
  va-time.techpro 0.0.0.0  2   640 0.05200  0.004608 3.99217
  time.tritn.com  0.0.0.0  2   640 0.07124 -0.004152 3.99217
  167.88.119.29   0.0.0.0  3   640 0.03712 -0.002695 3.99217
 Fri Aug 22 09:06:30 EDT 2014

 snip the rest 
 snip the rest 

I have 
version=ntpd 4.2.6p5@1.2349-o Mon Jul  2 04:47:51 UTC 2012 (1),
on FreeBSD 8.2, Soekris
I have just done a test , bringing down and up the default rout interface and 
see no issue.
NTP is still serving normally. 
Internet:
DestinationGatewayFlagsRefs  Use  Netif Expire
default192.168.1.1UGS 0   328387   sis0

selectron# ntpq -pn
remote   refid  st t when poll reach   delay   offset  jitter
==
o127.127.22.1.PPS1.   0 l4   16  3770.0000.002   0.008
*192.168.1.4 .PPS1.   1 u1   16  3770.8700.180   0.049
145.238.203.14  .INIT.  16 u-   6400.0000.000   0.000
130.159.196.118 193.62.22.98 2 u  23d 10240   25.0340.456   0.000
109.75.188.245  81.169.231.353 u  23d   640   18.327   -4.405   0.000
x194.50.97.12194.50.97.34 4 u   17   64  377   17.623   15.056   0.164
+212.83.133.51   145.238.203.14   2 u4   64  3772.7510.486   0.096

selectron# ifconfig sis0 down; ifconfig sis0 up

Sep  3 08:02:38 selectron su: mike to root on /dev/pts/0
Sep  3 08:05:39 selectron routed[693]: interface sis0 to 192.168.1.50 turned off
Sep  3 08:05:40 selectron routed[693]: interface sis0 to 192.168.1.50 restored

$ ntpchk
ntp is up and running - checking peer status
Wed Sep  3 08:12:28 CEST 2014
remote   refid  st t when poll reach   delay   offset  jitter
==
o127.127.22.1.PPS1.   0 l   10   16  3770.0000.011   0.008
*192.168.1.4 .PPS1.   1 u7   16  3770.9120.191   0.044
145.238.203.14  .INIT.  16 u-   6400.0000.000   0.000
130.159.196.118 193.62.22.98 2 u  23d 10240   25.0340.456   0.000
109.75.188.245  81.169.231.353 u  23d   640   18.327   -4.405   0.000
x194.50.97.12194.50.97.34 4 u7   64  377   17.601   15.555   0.169
+212.83.133.51   145.238.203.14   2 u   63   64  3772.7690.516   0.042

Maybe it's a problem with your OS.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] bad time with a laptop on windows 7

[mike cook]

I also looked at  the doc for your device and concur with Paul. You will most 
likely need to use the PPS BNC connector at the back of the adapter to get that 
signal.  HOWEVER, it seems that PPS over USB has been done with a small mod to 
the connections of some driver chips and the use of the gpsd daemon. See 
http://ei6iz.com/?p=108 for the story. Unfortunately this may not help you as 
the driver chip is probably inside the adapter box and you would lose warranty 
if you stuck a soldering iron in there . Worth checking though, and for others 
the technique may be valuable as laptops rarely have serial ports.

Le 4 août 2014 à 22:46, Greg Hennessy a écrit :

 On 2014-08-03, Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
 Would be nice to see all the details.
 Try the following as you seem to be using gnuplot:
 
 I've uploaded two files, the 4.2.6 version (less good) is at:
 https://docs.google.com/file/d/0B7E_xYSeZSYqc0ZpNENmbXUtZlE/edit
 the 4.2.7 version is at
 https://docs.google.com/file/d/0B7E_xYSeZSYqR2FuOFB3UXhDMU0/edit
 
 Now to try the SerialPortLED file to see if anything useful
 happens.
 
 ___
 questions mailing list
 questions@lists.ntp.org
 http://lists.ntp.org/listinfo/questions
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] LOCL clock reachability not 377?

[mike cook]

Le 1 août 2014 à 00:43, Rob a écrit :

 William Unruh un...@invalid.ca wrote:
 I think you need to read up on the cmos clock. As I said, it reports
 only the seconds, but is settable and readable to microseconds. 
 
 The CMOS clock is running off a 32768Hz crystal, so no way it can be
 more accurately set than 30us.

  Some, such as the venerable MC146818A can use higher clock speeds. 

 
 Even it could be possible in theory to set and read it accurately to
 that value, apparently Linux does not do that.  That makes it questionable
 to me if it can be done.  I could understand when Windows would not
 exploit such a capability, when there is no monetary gain to be made.
 But the Linux developers are too proud and too nerdy to skip such an
 opportunity.

  Inclined to agree. None of the TC data sheets I have looked at show them 
holding microsecond resolution data. All have just one byte recording integral  
seconds. Quite a few RTCs have either a clock out, or programmable square wave 
outputs, which when used could give access to higher resolution, but as you 
point out , access to that is not implemented in general purpose computers, or 
OS's.

 
 The fact that there is a microsecond-accurate API to set and read the
 clock does not indicate anything.  Remember Linux can run on any platform,
 and there may be other platforms, now or in the future, that can use
 this accuracy.
 
 In my experience, the clock always jumps a few hundred milliseconds
 when rebooting a PC.
 
 ___
 questions mailing list
 questions@lists.ntp.org
 http://lists.ntp.org/listinfo/questions
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] LOCL clock reachability not 377?

[mike cook]

Paradoxically , the LCL clock is fine when there are no refclocks. That is, 
when you don't need or want it.

 remote   refid  st t when poll reach   delay   offset  jitter
==
*127.127.1.1 .LOCL.   5 l8   64  3770.0000.000   0.008
+192.168.1.4 .PPS1.   1 u5   16  3770.900   -0.022   0.030
+192.168.1.23.GPS.1 u   23   64  3770.804   -0.134   0.017



Le 30 juil. 2014 à 06:46, Brian Inglis a écrit :

 On 2014-07-29 21:32, Paul wrote:
 On Tue, Jul 29, 2014 at 10:15 PM, Brian Inglis
 brian.ing...@systematicsw.ab.ca wrote:
 As I discovered recently under similar circumstances, offline servers are
 considered falsetickers, and if you have insufficient other candidates, or
 fewer than 3, nothing gets selected.
 
 I don't think I'm seeing what you're seeing but I could be confused.
 I believe I mentioned the same thing last time around on this topic.
 
 Default for minsane is 3, if that is where you are confused.
 Not seen this topic mentioned in the last year or more.
 
 ntpd --version;ntpq -pn
 ntpd 4.2.7p440@1.2483-o Tue Apr 22 11:51:47 UTC 2014 (6)
  remote   refid  st t when poll reach   delay   offset  
 jitter
 ==
 o127.127.22.0.GPPS.   0 l28  3770.000   -0.002   
 0.004
 *127.127.1.0 .LOCL.  12 l   65800.0000.000   
 0.004
  192.168.0.210   .GPS.1 u   22   32  3771.304   -0.080   
 0.028
 
 or just using LOCL ...
 
  remote   refid  st t when poll reach   delay   offset  
 jitter
 ==
 o127.127.22.0.GPPS.   0 l58  3770.000   -0.005   
 0.008
 *127.127.1.0 .LOCL.  12 l   608  2000.0000.000   
 0.008
 
 naturally you need to let NTP discipline your clock and a cold start
 requires something to set it.
 
 These statuses show the same issue with local clock reach, implying if reach 
 stays
 at zero, sync will be lost and PPS become a falseticker without anything to 
 number
 seconds for too long.
 
 Read the thread about the OP's config and problems.
 
 -- 
 Take care. Thanks, Brian Inglis
 ___
 questions mailing list
 questions@lists.ntp.org
 http://lists.ntp.org/listinfo/questions
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] LOCL clock reachability not 377?

[mike cook]

Le 30 juil. 2014 à 11:00, Rob a écrit :

 mike cook michael.c...@sfr.fr wrote:
 
 Paradoxically , the LCL clock is fine when there are no refclocks. That is, 
 when you don't need or want it.
 
 remote   refid  st t when poll reach   delay   offset  jitter
 ==
 *127.127.1.1 .LOCL.   5 l8   64  3770.0000.000   
 0.008
 +192.168.1.4 .PPS1.   1 u5   16  3770.900   -0.022   
 0.030
 +192.168.1.23.GPS.1 u   23   64  3770.804   -0.134   
 0.017
 
 Maybe someone tried to handle that condition and had the sense of
 the test the wrong way around???
 

 Someone who knows the code would pin this down in a second. What I think is 
happening is that the local clock driver along with all other refclocks/servers 
gets polled once at initialization time, so we see reach 1, and then there is 
some condition tested (do we have another, better refclock?) which if true 
causes the local clock to be left out out of the loop and so it's reach drifts, 
2,4,8,10 etc. till the local clock is flagged a false ticker.   


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

Re: [ntp:questions] LOCL clock reachability not 377?

[mike cook]

Rob,

  Looks like a bug anterior to your version. I see the same issue with 
version=ntpd 4.2.6p5@1.2349-o whether or not there is a preferred local clock 
or not, and whether or not there are other active server associations.

One for Harlen if it has not already been flagged.

Tue Jul 29 21:32:48 CEST 2014
 remote   refid  st t when poll reach   delay   offset  jitter
==
 127.127.1.1 .LOCL.   5 l   25   6410.0000.000   0.008
o127.127.22.1.PPS1.   0 l8   1610.0000.002   0.008
...
 remote   refid  st t when poll reach   delay   offset  jitter
==
 127.127.1.1 .LOCL.   5 l  300   64   200.0000.000   0.008
o127.127.22.1.PPS1.   0 l   11   16  3770.0000.004   0.008

 remote   refid  st t when poll reach   delay   offset  jitter
==
 127.127.1.1 .LOCL.   5 l  437   64  1000.0000.000   0.008
o127.127.22.1.PPS1.   0 l4   16  3770.0000.004   0.008

snip

Le 29 juil. 2014 à 19:14, Rob a écrit :
 This appears to work OK, output from the ntpq -p command is now:
 
 remote   refid  st t when poll reach   delay   offset  jitter
 ==
 oPPS(0)  .PPS.0 l   14   16  3770.0000.000   0.001
 *LOCAL(0).LOCL.   5 l   93   6420.0000.000   0.000
 EXTERNAL SERVER .INIT.  16 u-  25600.0000.000   0.000
 EXTERNAL SERVER .INIT.  16 u-  25600.0000.000   0.000
 EXTERNAL SERVER .INIT.  16 u-  25600.0000.000   0.000
 
 Good.
 
 But why is the reach of the LOCAL clock 2 and not 377?
 The reach bit cycles up until it is 0, then the LOCAL clock is no longer
 reference clock, the PPS status changes to x
 
 ___
 questions mailing list
 questions@lists.ntp.org
 http://lists.ntp.org/listinfo/questions
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Embedded solutions

[mike cook]

  I bought one of these to see what it could do and wrote a review on the 
Tindie site. One of the issues I raised was the volume and ad hoc format of 
stats messages he puts out on port 514 for syslog . I just updated that review 
with info on a log message filter I wrote, which makes loopstats data from 
them. I can now graph the data with the same scripts as I use to treat other 
servers I have.
If any of you have one of these, you are welcome to check it out. A link is on 
 stratum1.d2g.com .

Mike


Le 8 juil. 2014 à 19:00, David Taylor a écrit :

 On 08/07/2014 14:37, Paul wrote:
 []
 People looking for inexpensive, low overhead NTP appliances should be
 supporting Partially Stapled's Laureline development.
 
 I would have supported that, partially because I like the chap  what he 
 does, but their server didn't support any of the standard NTP management 
 commands last time I looked
 
 still the case.

 Cheers,
 David
 Web: http://www.satsignal.eu
 
 ___
 questions mailing list
 questions@lists.ntp.org
 http://lists.ntp.org/listinfo/questions
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions