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

[Charles Elliott]

Hello:
Someone wrote on this list that their employer refused to allow them
to use GPS is a time source for an (I believe) embedded system, saying that
spoofing attacks and variations in signal strength made GPS unreliable.
There's actually been quite a bit of discussion on the Internet and
elsewhere about GPS insecurities. New generations of satellites are supposed
to be more secure, but all that is quite expensive.  This is an important
issue now that so much public navigation depends on GPS.

You write that there are $14 and $28 GPS devices available to
provide time, but I would be willing to bet they don't have built-in
spoofing detectors. U-Blox claims to have anti-spoofing detection on its
devices, which I suppose could be verified. Also it's unknown to me how the
user would determine that the signal might be spoofed from a U-Blox device. 

Just something to think about if accurate time is important to you.

Charles Elliott

-Original Message-
From: questions
[mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of
Jim Pennino
Sent: Friday, June 25, 2021 2:07 PM
To: questions@lists.ntp.org
Subject: Re: [ntp:questions] ntp pool servers disappear - more data

chris  wrote:
> On 06/25/21 17:28, Jim Pennino wrote:



>> Or for $14/machine I could use a USB GPS, my machine with PPS GPS, 
>> and A public server that does NOT request use of DNS which yields 3 
>> sources of time without using a pool or DNS lookups.
>>
>> Or for $28/machine I could use 2 USB GPS receivers and my machine 
>> with PPS GPS, which also provides 3 sources of time without any 
>> network access at all.
>>
>>
> 
> Your choice, but when I registered the ntp server here with the pool, 
> I just used the fixed ip address. That's what they ask for and it does 
> bypass dns altogether. The less translation the better, unless you 
> really need it...
 
Actually what I plan to do is to put a $14 USB GPS on the machine that
already has a PPS GPS attached and do away with ALL external machines.

If there are two GPS receivers attached to the machine I have a backup if
one receiver fails.

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

Now if there is a  Carrington-class coronal mass ejection or WWIII breaks
out, I will lose all time references but I will have lots of other things to
worry about that are much more important than the computer clock and it is
likely that all internet access will also be down.

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

These three machines then provide time for all other machines on my network.
The three machines will provide the redundancy needed for when one of those
machines gets rebooted for updates/upgrades.

Done.

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

Yes, this scheme only gets my machines to within 10s of milliseconds to the
actual time, but that is good enough for me.

If I needed better, I would buy one of the $685 GPS GNSS Disciplined
Rubidium clocks off ebay and get time to the nanosecond.


___
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] Score is low and not raising

[Charles Elliott]

You might want to take a look at Misra, P., & Enge, P. (2012). Chapters 1
thru (3-5) in Global Positioning System: Signals, Measurements and
Performance (Second Revised ed., pp. 91-144). Lincoln, Massachusetts, USA:
Ganga-Jamuna Press.

The equations to solve for GPS have 4 unknowns, X, Y, Z, and time, so there
must be at least 4 satellites in view for an accurate, 3D fix.  My u_blox
GPS device routinely has 20-27 satellites in view. With more than four
sources of GPS coordinates available, GPS receivers usually use regression
analysis to arrive at a fix. By the time one subtracts the means from each
column of observations to precondition the X-matrix for inversion, and do
the inversion, a regression analysis solution can take substantial time. In
addition, that solution has to be transmitted to the user's computer, which
also takes finite time. The above book has a small section on how to
estimate these times. I believe it's possible that the 0.5 second difference
between internal and external times is could be the result of not accounting
for the delays incurred because the GPS device has to compute a solution and
then transmit it to the receiver's computer.


Charles Elliott

-Original Message-
From: questions
[mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of
William Unruh
Sent: Wednesday, June 9, 2021 10:13 PM
To: questions@lists.ntp.org
Subject: Re: [ntp:questions] Score is low and not raising

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

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

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

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

Why that offset?

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

[Charles Elliott]

Is your Internet connection asymmetric?  Most cable and DSL (ADSL)
connections are asymmetric with much less speed upstream than downstream.
This severely affects the accuracy of NTPD because, essentially, the time
offset between client and server is measured by the difference between the
packet times to and from the server.  If your Internet connection is
asymmetric, then the time you dispense will always be in error proportional
to the difference between your upstream and downstream speeds.  See RFC 5905
- Network Time Protocol Version 4 Protocol and Algorithms Specification.htm
for the actual formulas; search for "delay" and/or "offset" to find the
equations in T1, T2, T3, and T4, which are the measured times.

Charles Elliott 

-Original Message-
From: questions
[mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of
William Unruh
Sent: Tuesday, June 8, 2021 3:50 AM
To: questions@lists.ntp.org
Subject: Re: [ntp:questions] Score is low and not raising

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

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


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

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

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

Re: [ntp:questions] PPS, prefer keywoard and redundant peers

[Charles Elliott]

Hello:
With GPS clocks that offer sub-millisecond accuracy and seem of last
for months, so far, available for sale
on eBay for less than $100, and without trying to be disparaging, your
suggestion seems to be a solution in search of a
problem.  This is a cost-benefit situation.  NTPD is a large and complex
program.  It would take many man-hours to 
make the change you suggest.  Yet, you are the first and only person to
notice this problem.  To see what I mean, 
look at the page here: https://www.nwtime.org/support.

In any case, this is not the venue to offer your suggestion.  If you
want to be sure your suggestion receives
the attention it deserves, then consider filing a formal enhancement request
here: 
https://bugs.ntp.org/index.cgi.  Click on "File a Bug," create a free
Bugzilla account if you don't have one, login,
click on ntp on the next page, select Enhancement in the severity box of the
form that appears, and copy-and-paste 
your suggestion into the description section.

Thank you for your time and effort.  Without suggestions for
improvement, NTPD would never become
a better program.

Charles Elliott

-Original Message-
From: questions
[mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of
Scott
Sent: Monday, November 23, 2020 11:05 PM
To: questions@lists.ntp.org
Subject: [ntp:questions] PPS, prefer keywoard and redundant peers

Hi all,

the documentation clearly states that for a PPS driver to work one needs to
configure another peer as `prefer'.

I have a set-up with PPS and three network (IP) peers, one of these marked
preferred.

1) why can't the PPS signal be used to discipline all survivors (assuming
they meet the requirements for PPS)?

2) if my preferred peer goes away, NTP will not use PPS at all (it looks
like it becomes the system peer (*) then later a falseticker (x)).  Is there
any way to make PPS survive a prefer peer loss?

Many thanks.
___
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] Realistic Performance Expectation for GPS PPS fed ntpd jitter

[Charles Elliott]

Hello:

The original question was what realistic performance can one
expect from GPS PPS. Based on some reading I did over the weekend here is a
definitive answer:

 

   The 2001 SPS (standard, civilian signal, GPS in the United
States) timing standard was 40 ns with 30 ns accuracy commonly observed. (M
& E, p. 49). 

 

Time and distance are related with GPS (see M&E,  p. 23),
and good differential GPS (DGPS) is supposed to yield approximately 10 times
the distance accuracy of the above specification, which implies one should
be able to achieve 3-4 ns accuracy with GPS timing. The FAA's Wide Area
Augmentation System (WAAS) is supposed to produce 2 m accuracy throughout
the United States. This would imply approximately 8 ns to 6 ns time
accuracy. Of course, you need a recently manufactured chip to pick up DGPS
and WAAS. In addition, most GPS chips require that commands be sent to them
to activate the GPS and WAAS. These commands are available in recent NMEA
manuals published by chip manufacturers that you can find by googling for
them. The 15-year-old GPS chip that I own constantly slips into an out of
DGPS mode, which implies that the command to activate DGPS must be resent to
the GPS chip periodically.

 

The equation that the GPS chip solves every second has four
unknowns: the receiver position in three dimensions and time. This implies
that to solve this equation definitively four satellites must be in view.
However if more than four satellites are in view the equation is
over-determined and the fix is obtained by least-squares regression, which
yields maximum likelihood predictors for the four variables. These
predictors are much, much more accurate than the simple solution of the
equation. A recent chip that picks up American GPS satellites, the Russian
GLONASS satellites, and the European Galileo satellites should produce far
better results than an older chip.  My $40 Alcatel model A503DL Android
phone commonly claims to have 19 or more satellites in view.

 

The GPS fix changes as satellites slip into, or out of,
view. Consequently one can observe jumps in time either forward or backward.
Not to belabor the obvious, but time is monotonically increasing. So any
jumps in time of more or less than about a positive second should be
ignored.

 

The American GPS system has two new signals (L2C and L5)
which will greatly improve accuracy when they are fully operational. They
are being phased in as older satellites are replenished with new models.
L2C first began to appear in 2005 and L5 in 2010. Both are available now,
but in a pre-operational stage so that one uses them at their own risk. A
summary of the signals and their availability appears here:
https://www.gps.gov/systems/gps/modernization/civilsignals/.

 

The best published work on GPS accuracy and NTPD was done by
David Taylor at www.satsignal.eu <http://www.satsignal.eu>  and appears
here: https://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html
<https://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html>  and elsewhere on the
satsignal.eu website. David has found one GPS chip that appears to produce
really remarkable results.

 

M&E = Misra, P. and P. Enge (2012). Global Positioning
System: Signals, Measurements and Performance. Lincoln, Massachusetts, USA,
Ganga-Jamuna Press.



Charles Elliott

 

 

Original Message questions
[mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of
Miroslav Lichvar
Sent: Monday, October 19, 2020 3:50 AM
To: questions@lists.ntp.org
Subject: Re: [ntp:questions] Realistic Performance Expectation for GPS PPS
fed ntpd jitter

 

On Thu, Oct 15, 2020 at 07:52:06AM +0200, Juergen Perlinger wrote:

> Another thing that gets into the way are the energy saving strategies 

> modern CPUs employ, like reducing the clock speed and distribute load 

> over cores. So unless you nail down the IRQ to a certain core and 

> prevent cores from going to full sleep, the interrupt rescheduling can 

> add another few usecs. IRQ processing was never a high speed thing on

> x86 platforms to start with, and it never kept up with speed boost all 

> other parts of the architecture got, AFAIK.

 

Setting the CPU to a fixed frequency (e.g. using the userspace

governor) can help a lot with the stability of timestamping, not just of the
PPS signal, but also received NTP packets.

 

> In short, your numbers look familiar, and I don't know how to improve 

> the much without dedicated hardware. I'm dreaming of some FPGA 

> hardware on a PCIe board at an affordable price...

 

Not an FPGA, but the Intel I210 costs about $50 and it has a nice hardware
clock with PPS input/output, which is well supported in Linux. It's a NIC,
so you can use the same clock for timestamping PPS and NTP packets, avoiding
any asymm

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

[Charles Elliott]

Hello:



> I'm dreaming of some FPGA hardware on a PCIe board at an affordable
price...

 

Have you seen these?  None are on a PCIe board, but they do have GPS, a
timing crystal, and a PPS signal.  

 

LeoNTP Networked Time NTP Server; Price: 300.00GBP 

http://www.leobodnar.com/shop/index.php?main_page=product_info
<http://www.leobodnar.com/shop/index.php?main_page=product_info&cPath=120&pr
oducts_id=272> &cPath=120&products_id=272

 

 

GPSDO GPS Disciplined Oscillator Clock NTP Time Server

https://www.ebay.com/itm/GPSDO-GPS-Disciplined-Oscillator-Clock-NTP-Time-Ser
ver-without-IRIG-B-AC-Code/124253295400?_trkparms=aid%3D1110012%26algo%3DSPL
ICE.SOIPOST%26ao%3D1%26asc%3D225074%26meid%3D65bb838564cd4d1f841f71471cd16c9
3%26pid%3D18%26rk%3D1%26rkt%3D12%26sd%3D124133795048%26itm%3D12425329540
0%26pmt%3D1%26noa%3D0%26pg%3D2047675%26algv%3DPromotedSellersOtherItemsV2%26
brand%3DUnbranded
<https://www.ebay.com/itm/GPSDO-GPS-Disciplined-Oscillator-Clock-NTP-Time-Se
rver-without-IRIG-B-AC-Code/124253295400?_trkparms=aid%3D1110012%26algo%3DSP
LICE.SOIPOST%26ao%3D1%26asc%3D225074%26meid%3D65bb838564cd4d1f841f71471cd16c
93%26pid%3D18%26rk%3D1%26rkt%3D12%26sd%3D124133795048%26itm%3D1242532954
00%26pmt%3D1%26noa%3D0%26pg%3D2047675%26algv%3DPromotedSellersOtherItemsV2%2
6brand%3DUnbranded&_trksid=p2047675.c18.m2219>
&_trksid=p2047675.c18.m2219

 

There are several on this page that range in price from $155 to $219 USD.

 

Right now I am seeing 1-4 usec jitter from a combination of a PPS signal
from an American-made GPS device by Time Machines and a Chinese device from
JinnUSR advertised as "Network Time Server NTP Server for GPS Beidou GLONASS
Galileo QZSS Desktop tpUS," that serves as the system clock and gives the
second.  All this is with the serial PPS DLL supplied by Meinberg.  I do
have the GPS antennas at the end of a ladder that stretches 1/2 way to the
second floor roof of the house.  It is common to have 7-9 satellites in a
fix at one time, which hugely  improves position and perhaps time accuracy.

 

Any success I have had with the GPS is due to Misra, P. and P. Enge (2012).
Global Positioning System: Signals, Measurements and Performance. Lincoln,
Massachusetts, USA, Ganga-Jamuna Press.  Read a little bit, make a few
changes, and better performance results.

 

You might note that with the above GPS devices requiring 3-4 Watts, there is
no way that a PC is an economical time server over the long run.

 

Charles Elliott

 

-Original Message-
From: questions
[mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of
Juergen Perlinger
Sent: Thursday, October 15, 2020 1:52 AM
To: questions@lists.ntp.org
Subject: Re: [ntp:questions] Realistic Performance Expectation for GPS PPS
fed ntpd jitter

 

On 10/7/20 8:45 PM, Andreas Mattheiss wrote:

> Hello,

> 

> I wonder what's a realistic ballpark for the jitter I can expect when 

> feeding a GPS PPS into ntpd?

> 

> My setup is: a cheap u-blox NEO6M has its PPS output connected to a 

> MAX232 level shifter, connected to a true serial port on my desktop 

> PC. I use it at the same time for daily work, so no designated ntp 

> server. The GPS antenna is sitting inside, close to the window, with a 

> building opposite - suboptimal view of the sky. I do feed RTMS 

> corrections to the GPS though (ionospheric corrections etc.). The GPS 

> is set to "stationary" mode, so it's probably set up as good as it gets.

> 

> The jitter values I get do, sorry, jitter. I guess it's a lot to do 

> with the poor view to the sky, mainly. PPS from GPS is claimed to be 

> accurate to say 10's of ns; my jiitter values are around 10 micro s 

> approximately, on avarege, for a well settled system set up as 

> described. They do zoom up, occasionally, to 60 micro s though. I 

> would assume that it's unrealistic to expect ns accuracy from ntpd on a
non-designated system.

> 

> What do you think, is my 10 micro jitter within experience? While I am 

> writing this I just realised a post from David Taylor

> (< <mailto:qgmgcu$2ad$1...@dont-email.me> qgmgcu$2ad$1...@dont-email.me>)
showing

> 

>   remote   refid  st t when poll reach   delay   offset

> jitter

>

==

> o127.127.22.1.uPPS.   0 l-   16  3770.0000.026

> 0.013

> 

 

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

 

I had better numbers (half the jitter) with my old Phenom-II box, but with
the XEON board I'm running now I see jitter in the 10usec range.

With both receivers active at the same time, I have a higher jitter --
clearly interrupt c

Re: [ntp:questions] Regarding step_systime call

[Charles Elliott]

Hello:
It is very difficult to help you if
you don't specify the platform being used,
i.e.,  O/S (publisher, version and updates)
and CPU if at all unusual.

What does this mean: "more than 1000s
clock change done erroneously at the
head-end"?  Does 1000s mean 1000 seconds or
is it an abbreviation for the word
"thousands"?  It is common and natural (i.e.,
planned that way) for NTPD to step the time
on initial startup.

If the O/S is Windows, what does the
Event Log say?  Normally, there will be a
message in the Event Log for every NTPD time
step change.

Is there another clock program in the
system (such as Windows Time) that is also
trying to control the time, so that NTPD and
the other program are fighting?

Have you tried a packet sniffer (such
as Wireshark) to see if an external program
is somehow affecting the time?

Charles Elliott

-Original Message-
From: questions
[mailto:questions-bounces+elliott.ch=comcast.
n...@lists.ntp.org] On Behalf Of Srihari
Raghavan
Sent: Tuesday, January 21, 2020 1:03 AM
To: questions@lists.ntp.org
Subject: [ntp:questions] Regarding
step_systime call

Hi all

In one of our research network lab devices,
that use an implementation based off of
ntp.org 4.2.8p12 in NTP client mode - I see a
spurious "stepped" system clock change under
certain conditions (more than 1000s clock
change done erroneously at the head-end)
BEFORE the actual NTP triggered clock change
via known NTP log message around
"step_systime" call
- and am trying to track down the spurious
clock change that happened first.  There
could be other actors that could have changed
the system clock via 'date' etc., but I am
trying to rule out the obvious.

I have added logs around step_systime call in
the code ntp_loopfilter.c and also in
ntp_timer.c and also via ntpd_time_stepped
and I don't see any of them being being
triggered for the 'spurious' case.

Are there any other calls/paths/APIs in
NTP.org code, besides step_systime
way, that can potentially step the system
clock?   Scoured the NTP.org code
(ntpdate is not being used) for the same
without success and hence my request and
email.

Thanks in advance for any help.

Regards
SR
_
__
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] Trying to reply to an NTP Questions request I get this

[Charles Elliott]

FWIIW, ever since NTP.org transferred its email lists from ISC I have received 
a tiny fraction of the NTP-related email that I had in the past.  For example, 
now I see two or three requests for assistance a month, whereas in the past 
there were 2-3 a day.  Also, I only see bug reports when Perlinger or Stenn 
announce the bugs are fixed, and never the original requests.  Although for me 
this is a huge timesaver, I am assuming that there may be something broken with 
the way NTP email is being handled now.

Charles Elliott

-Original Message-
From: questions [mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] 
On Behalf Of David Taylor
Sent: Thursday, August 22, 2019 1:34 AM
To: questions@lists.ntp.org
Subject: Re: [ntp:questions] Trying to reply to an NTP Questions request I get 
this

On 21/08/2019 21:01, David Woolley wrote:
> On 21/08/2019 17:42, David Taylor wrote:
>> You are not allowed to post to this mailing list From: a domain which 
>> publishes a DMARC policy of reject or quarantine,
> 
> blueyonder doesn't appear to publish any DMARC policy.  Did you 
> actually use a blueyonder address as the header From:?  It is also 
> possible that they tried one and it broke too many things.
> 
> They do seem to have a DKIM signature that includes the subject, so 
> any mailing list that rewrites the subject will break the signature.  
> Most mailing lists rewrite the subject, if it doesn't have the list tag in it.
> 
> I imagine the list software isn't doing a fully analysis of DMARC and 
> DKIM to see if relayed mail will fail, but just looking for specific 
> things in the DMARC policy to know whether a failure would be a 
> problem for the list.
> 
> I'm assuming it is well behaved and rewrites the envelope from so that 
> SPF will pass the mail. Otherwise it will be generating SPF failures, 
> downstream.

Thanks for your comments.  As a major ISP, I would expect Virgin Media (a.k.a. 
blueyonder) to get things right - if only!  Yes, I simply used my blueyonder 
e-mail which has worked without issue in the past.  I've been advised to use a 
gmail address instead which I've now done, and await to see whether I now get 
two copies of the messages.

I did try to contact the list manager (johnl@.) but mail to him got a 
"retry timeout exceeded"!  What a mess!

--
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] Garmin LVC 18x jitter problem

[Charles Elliott]

Hello:
This email actually identifies two
problems:

1.  The pictures show that the algorithm
stops working after a while.

2.  The control algorithm is not precise
enough to control the frequency effectively
when PPS is the driver.

I put print statements in the refclock_sample
routine and have watched problem 1 occur.
Part of this is documented in Mills' book
(Mills, D. L. (2011). Computer Network Time
Synchronization: The Network Time Protocol on
Earth and in Space (Second ed.). Boca Raton,
FL: CRC Press.),  which says that if an error
is discovered in the NMEA output the PPS is
turned off (and allegedly other, external,
clocks are used to set the time.)  It is true
that the PPS is being turned off, but I have
not been able to discover who or what is
doing that.  It looks and acts like the NMEA
clock is being un-configured, but again I
can't find out how that is occurring.  The
symptom is that pp->io.fd is being changed
from a positive integer file descriptor to
-1.  In any case, instead of NTPD defaulting
to a different time server, it keeps changing
the frequency to eliminate the error in the
PPS signal, which has now become a constant.
As the pictures show that is why the error
becomes larger and larger.  There is no point
in turning off the PPS signal if NTPD
discovers an error in one NMEA sentence.  If
anyone can figure out how this is occurring I
would appreciate hearing about it.

Another question is, "Why does the NMEA
driver think there is an error such that the
PPS needs to be turned off?"  The GPS clock
that I am using dumps about 1194 bytes into
the UART buffer every second; the buffer is
only 1024 bytes in length.  Changing the send
and receive buffer lengths to 1024+256 in
line 345 of termios.c right now seems to have
fixed this problem, but it doesn't always.
In any case, making the buffers larger does
no harm. 


Problem 2 is also alluded to in Mills' book,
which says that initially, right after
startup, NTPD makes large corrections in
frequency to try to bring the clock into
synchronization, but as time goes on the
correction factor is made smaller and smaller
until a constant is reached.  On my system
this constant is too large to make the tiny
corrections necessary at microseconds
accuracies.  So my system hunts back and
forth across zero when it is controlled by
the PPS input.  This is not PID (Proportional
+ Integral + Derivative) control, and not
even PID - I = PD control, where the integral
term is forgotten about because it often
results in a yo-yo effect and is difficult to
get right.  The gods have asked me to put
fuzzy PD control into NTPD, but I simply
haven't had time to do it yet.  I built the
fuzzy PD control example of a truck backing
into a parking slot from an AI book several
years ago, and it works quite well, or at
least that example did.

Hope this helps.

Charles Elliott

-Original Message-
From: questions
[mailto:questions-bounces+elliott.ch=comcast.
n...@lists.ntp.org] On Behalf Of David Taylor
Sent: Thursday, July 11, 2019 12:42 AM
To: questions@lists.ntp.org
Subject: Re: [ntp:questions] Garmin LVC 18x
jitter problem

On 10/07/2019 22:15, Michael Haardt wrote:
> I use a Garmin LVC 18x with a Raspberry Pi,
process NMEA with gpsd 
> (SHM driver) and acess PPS by GPIO (kernel
PPS driver).  gpsd allows 
> monitoring and passing PPS right into ntpd
avoids gpsd conversion of PPS.
> 
> Sometimes this works, but then there are
times where both clocks are 
> thrown out as falsetickers.  I believe
that's due to the strange 
> jitter behaviour of the NMEA data.  If I
understood the clock 
> selection right, then basically the
measured jitter forms an interval 
> around the offset and the intersection
interval is the root 
> dispersion.  Should the NMEA clock have no
intersection with the used 
> PPS clock, it is a falseticker, but since
PPS depends on it, PPS is so as well.
> 
> I graphed offset and jitter from two days
peerstats where I was locked 
> on PPS (tos mindist 0.1) and the system ran
stable without the need to 
> adjust the crystal frequency at constant
environment temperature.
> The first day was mostly fine, but in the
middle of the second day, 
> the GPS jittered really bad and there are
many occasions where the 
> jitter interval did not intersect with 0.
The ntpd jitter estimation 
> works as expected for a normal
distribution, but the distribution is 
> clearly
> different:
> 
> http://www.moria.de/~michael/tmp/offset.svg
> http://www.moria.de/~michael/tmp/jitter.svg
> 
> Using the tos mindist extends the
intersection interval, but that 
> effects the root dispersion.  That's
correct if it is needed to have 
> an intersection between different clocks of
low jitter, but in my case 
> the problem is a wrong (too low) jitter
estimation of a clock I only 
> need as PPS reference.
> 
> Is there any way 

[ntp:questions] NTP Timestamp

[Charles Elliott]

Hello:

Kelly Kinkade on Quora here
(https://www.quora.com/To-fix-the-year-2038-problem-why-cant-we-simply-chang
e-the-epoch-time-to-something-like-January-1-2000-instead-of-1970-You-do-rea
lize-1970-was-48-years-ago) wrote that the length of the NTP timestamp had
been changed from 64 to 128 bits as a solution to the 2038 epoch problem.  I
had not read or heard anything before about such a change.

 

Does anyone who reads this email list know anything about
changing the length of the NTP timestamp?

 

Charles Elliott

 

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

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

[Charles Elliott]

For one thing, 10110 may be the wrong port number to use: "The registered ports 
are those from 1024 through 49151. IANA maintains the official list of 
well-known and registered ranges.[3] The dynamic or private ports are those 
from 49152 through 65535. One common use for this range is for ephemeral 
ports." (https://en.wikipedia.org/wiki/Port_(computer_networking))  Second, 
port 10110 may be reserved for NMEA-0183 Navigational Data (on GPS devices).  
See 
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?
 
<https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?&page=117>
 &page=117.  You might want to consider a port number in [49152, 65535] on 
192.168.13.100, if that is your computer’s IP address.  I am referring to these 
error messages:

 

> Aug  6 19:28:16 computer gpsd[374]: gpsd:ERROR: UDP device open error can't 
> connect to host/port pair.

> Aug  6 19:28:16 computer gpsd[374]: gpsd:ERROR: initial GPS device 

> udp://192.168.13.100:10110 open failed Aug  6 19:28:16 computer 

 

Third, you may want to try to limit the GPS output to just $GPRMC messages.  
That is the only NMEA message NTPD needs; it has to sort through all the other 
messages to find $GPRMC, and it sometimes becomes confused doing so, since 
characters are put in a buffer one at a time, and the computer reads the buffer 
almost instantaneously, only part of a message may be returned to NTPD, i.e., 
one complete message plus a fragment of another.  If I recall correctly, part 
of the 127.127.28.1 clock indicator tells NTPD which NMEA message to look for, 
but in any case there is a code for it.  I believe there is a standard NMEA 
message to limit the rates of the various messages a GPS device will output.  
Just limit the rates of all but $GPRMC to zero.  You can find a an NMEA manual 
by searching for it on the Internet.

 

I agree with the person who wrote that he had never heard of accessing a GPS 
device with UDP; NTPD is not set up for that, although using shared memory may 
be a good workaround.  I am not so sure of the PPS signal coming in that way 
though.  NTPD is set to detect PPS from the rising or falling edge of a single 
RS-232 port pin, DCD if I recall correctly.

 

Charles Elliott


  

-Original Message-
From: questions [mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] 
On Behalf Of juergen perlinger
Sent: Monday, August 21, 2017 4:06 AM
To: questions@lists.ntp.org
Subject: Re: [ntp:questions] How to get shared memory access from gpsd to ntpd 
to work?

 

On 08/16/2017 02:52 PM, Etaoin Shrdlu wrote:

> Hi all,

> 

> I've been battling for some time with getting ntpd to set the 

> date/time from gpsd's shared memory locations. My GPS device is on the 

> network and sends GPS messages every minute over UDP. This is picked 

> up by gpsd and it appears I get a good fix with all the required data. 

> It also looks as if the shared memory locations are being set up 

> correctly. But whatever I do, ntpd time source "reach" stubbornly 

> remains at zero, even when running ntpd as root. I would be most 

> grateful if someone could cast their eyes on the configurations and 

> log output below, and let me know if you can see were it's going wrong!

 

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

 

> 

> P.S. This has been cross-posted from  <mailto:gpsd-us...@nongnu.org> 
> gpsd-us...@nongnu.org, where I 

> failed to get any response to my query.

> 

> 

> # syslog gpsd startup: 

> 

> Aug  6 19:28:16 computer gpsd[374]: gpsd:INFO: launching (Version 

> 3.11) Aug  6 19:28:16 computer gpsd[374]: gpsd:INFO: listening on port 

> gpsd Aug  6 19:28:16 computer gpsd[374]: gpsd:PROG: NTPD shmat(0,0,0) 

> succeeded, segment 0 Aug  6 19:28:16 computer gpsd[374]: gpsd:PROG: 

> NTPD shmat(32769,0,0) succeeded, segment 1 Aug  6 19:28:16 computer 

> gpsd[374]: gpsd:PROG: NTPD shmat(65538,0,0) succeeded, segment 2 Aug  

> 6 19:28:16 computer gpsd[374]: gpsd:PROG: NTPD shmat(98307,0,0) 

> succeeded, segment 3 Aug  6 19:28:16 computer gpsd[374]: gpsd:PROG: 

> successfully connected to the DBUS system bus Aug  6 19:28:16 computer 

> gpsd[374]: gpsd:PROG: shmat() succeeded, segment 131076 Aug  6 

> 19:28:16 computer gpsd[374]: gpsd:PROG: shared-segment creation succeeded, 
> Aug  6 19:28:16 computer gpsd[374]: gpsd:INFO: stashing device 
> udp://192.168.13.100:10110 at slot 0 Aug  6 19:28:16 computer gpsd[374]: 
> gpsd:INFO: opening UDP feed at 192.168.13.100, port 10110.

> Aug  6 19:28:16 computer gpsd[374]: gpsd:ERROR: UDP device open error can'

Re: [ntp:questions] Random Observation

[Charles Elliott]

FWIIW, on my machine and with the servers I use, IPv6 has longer and more
variable transit times than does IPv4, although the ISP (Comcast) and modem
are native IPv6.  This leads to slightly higher offsets and jitters with
IPv6 connections versus IPV4.  I tested the connections with ping, and the
transit time differences and their deviations are real.  Consequently,
generally I prefer to use IPv4 for NTP.  

It is pure speculation, but because IPv4 is much older that IPv6, the
carriers may have more experience optimizing the equipment, routes, and
connections with IPv4.

Caveat emptor: Unsolicited comments are often worth exactly what you pay for
them.  Do your own testing.

Charles Elliott

-Original Message-
From: questions
[mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of
Richard Thomas
Sent: Sunday, June 25, 2017 5:58 AM
To: questions
Cc: Bob McDonald
Subject: Re: [ntp:questions] Random Observation

Hi Bob,

It appears that you are right.  Observe that "us.pool.ntp.org" just gives
IPv4 addresses - the same 4 addresses in random order.
I presume that the particular set of 4 addresses will be a slowly varying
function of time: wait an hour and you'll get a different group of 4.
though I haven't done that experiment.

But "2.us.pool.ntp.org" gives 4 IPv4 addresses and 4 IPv6 addresses.

I assume it's a deliberate choice, but I have no idea what the reasoning
behind it might be.

> almini:~ rbthomas$ host us.pool.ntp.org us.pool.ntp.org has address 
> 154.16.245.246 us.pool.ntp.org has address 209.133.217.165 
> us.pool.ntp.org has address 50.112.150.45 us.pool.ntp.org has address 
> 71.248.190.29

> almini:~ rbthomas$ host us.pool.ntp.org us.pool.ntp.org has address 
> 71.248.190.29 us.pool.ntp.org has address 50.112.150.45 
> us.pool.ntp.org has address 209.133.217.165 us.pool.ntp.org has 
> address 154.16.245.246

> almini:~ rbthomas$ host 2.us.pool.ntp.org 2.us.pool.ntp.org has 
> address 104.131.53.252 2.us.pool.ntp.org has address 204.2.134.162 
> 2.us.pool.ntp.org has address 142.4.196.99 2.us.pool.ntp.org has 
> address 66.135.44.92 2.us.pool.ntp.org has IPv6 address 
> 2600:3c00::f03c:91ff:fe91:5dd8 2.us.pool.ntp.org has IPv6 address 
> 2604:a880:800:10::1:9001 2.us.pool.ntp.org has IPv6 address 
> 2001:470:0:2c8::2 2.us.pool.ntp.org has IPv6 address 
> 2607:fcd0:100:c21::1f2a:e81b almini:~ rbthomas$
> 

Enjoy!
Rick

On Jun 22, 2017, at 7:33 AM, Bob McDonald  wrote:

> It seems as though when I use a config similar to the following I get 
> no
> IPv6 servers in my pool selections.
> 
> pool us.pool.ntp.org iburst
> pool north-america.pool.ntp.org iburst pool pool.ntp.org iburst
> 
> only when I add a number prefix (as below) to the entries do I get 
> IPv6 servers in my candidate list.
> 
> pool 2.us.pool.ntp.org iburst
> pool 2.north-america.pool.ntp.org iburst pool 2.pool.ntp.org iburst
> 
> Do I just not understand what *should* be configured?
> 
> Regards,
> 
> Bob
> ___
> 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] Looking for a NTP stratum 2 appliance

[Charles Elliott]

There is a way of securing a free NTP appliance, but I am not sure, but it
might be limited to Stratum 1, and it has to be public facing.  And the
network connection must not be asymmetric.  All the recipient has to do is
pay the operating cost (electricity and maintenance).  The latter might be
an issue though, since none that I have been acquainted with have stayed
live for any considerable period, e.g., USTime Corp.

Judah Levine (judah.lev...@nist.gov, jlev...@boulder.nist.gov,
judah.lev...@colorado.edu) has available NTP appliances for people who are
willing to provide public time servers.  The criteria for receiving one are
fairly strict.

Charles Elliott

-Original Message-
From: questions
[mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of
Miroslav Lichvar
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

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

[ntp:questions] NTPD hunts after reboot

[Charles Elliott]

Some time ago, NTPD used to hunt for several hours after a reboot
until it settled down to providing good time.  Then it stopped doing that,
and now it is doing it again.

I was going thru the NTPD listing looking for something else, when I
came across a paragraph of comments describing a controversy over whether or
not to reset the computer's battery clock as NTPD slewed the clock to reach
an equilibrium.  I did not read the whole paragraph, and cannot find it
quickly now.

In any case, my question now is, if NTPD is no longer resetting the
computer's battery clock to match its estimate of the current time, would
that explain why NTPD now indicates a big jump in time after a reboot, hunts
back and forth within a range of about 30+ milliseconds for about an hour
after a reboot, and takes about 4 hours before it is providing good time
again?

Charles Elliott


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

Re: [ntp:questions] NTP server - Number of received petitions.

[Charles Elliott]

Will you please go to http://bugs.ntp.org/enter_bug.cgi and file a bug report 
saying that the ntpq mrulist command is not working for you, if that is the 
case as you allege.  In the alternative, please go to the same Web page 
(http://bugs.ntp.org/enter_bug.cgi) and file a request for enhancement saying 
exactly what your requirements are and why you need them.

If your English language skills are a barrier, then send me a copy of your 
request in Spanish.  I live in an Hispanic neighborhood, and will try to find 
someone to translate your email request.  No guarantees, but I am surrounded by 
Spanish speakers.  I should be able to find someone to translate.

Charles Elliott

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

Re: [ntp:questions] NTP server - Number of received petitions.

[Charles Elliott]

I defined it for him, in depth, from a dictionary, both noun and verb,
transitive and intransitive, but apparently nothing will change his mind.  

He has not said what he does not like about ntpq mrulist.

I believe he wants to know the addresses of people who are using his server.
Perhaps he is a stalker for one of the security agencies, in which case, we
should ask exactly what they need and supply it.  On the other hand, he may
actually mean "petition," in the sense of enough people praying for some new
dispensation i.e., the squeaky wheel theory of government. After all, many
of us do live in democracies.

Why doesn't someone ask him exactly what he wants and how much he is willing
to pay for it, if his requirements require programming?

Charles Elliott

-Original Message-
From: questions
[mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of
Mauricio Tavares
Sent: Monday, March 20, 2017 6:23 AM
To: questions@lists.ntp.org
Subject: Re: [ntp:questions] NTP server - Number of received petitions.

On Mon, Mar 20, 2017 at 6:10 AM, David Woolley
 wrote:
> On 08/03/17 10:53, Micron wrote:
>>
>> Recently, I've added my NTP server in the pool and I'm looking for 
>> the way to know the number of petitions received from clients.
>
>
> Please could you indicate where petition is defined in the context of NTP.
> I have never seen it used before.
>
  He probably meant "request", but google translate got the best of him.

> ___
> 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] Monitoring Number of Clients

[Charles Elliott]

Hello,

 

  There are three sets of facts you may want to consider.  First, in
reports of how security consultants handle denial-of-service defense
engagements, the consultants seem to develop ad hoc solutions to determining
where the flood of packets are coming from.[1]  Second, in one study of
Internet time server usage[2, Fig, 2], it was found that one server received
requests with these frequencies:

 

DayTime and Time requests (TCP) ~10*2.2 to ~10*2.4 per second (sec).

 

NTP requests (UDP, port 123) ~10^3 per sec with bursts of 10^3.2 to 10^3.4
per sec every 5 minutes.

 

NTP packet requests (UDP, other ports) between ~10^3.2 and ~10^3.5 per sec
(depending on the hour of the day) with bursts up to ~10^4 per sec every
minute.

 

In total this server experienced a steady stream of about 30,000 requests
for time per second (rps), with peaks to 90,000 rps every hour, and smaller
peaks to 40,000 rps every half hour.  Another server in this group had a
steady stream of about 5,000 rps, with peaks to ~40,000 rps every half hour.
Both these servers had very heavy peaks of requests at midnight.

 

 

Third, in my reading of the source code for the Network Time Protocol Daemon
(NTPD), the program is optimized to handle a high number of requests per
second, not to record who is making the requests.

 

 

My conclusions from these facts and observations are:

 

1. Determining who is using an NTP time server is, almost by definition, a
Big Data problem, and may require a Big Data solution, but do search with
Bing and/or Google first.

 

2. If you want a high quality solution to finding out who is using an NTP
timer server, you may have to provide it yourself.  You can download the
source code from www.ntp.org and modify it to serve your needs.

 

3. The book [3] has examples in it of applying open-source big data software
to big data problems.  I could not make these examples run under Windows,
but the book's author assured me that they ran well under Linux.  In any
case, the examples did not use Spark, which apparently is much easier to use
and faster than Hadoop.

 

Charles Elliott

 

References:

[1]  Menn, Joseph. (2010). Fatal System Error: The Hunt for the New Crime
Lords Who Are Bringing Down the Internet. New York, NY: PublicAffairs.

 

[2]  Sherman, Jeff A., & Levine, Judah. (2016). Usage Analysis of the NIST
Internet Time Service. Journal of Research of the National Institute of
Standards and Technology (JRES). doi: http://dx.doi.org/10.6028/jres.121.003
(nvlpubs.nist.gov/nistpubs/jres/121/jres.121.003.pdf)

 

[3] Marz, Nathan, & Warren, James. (2015). Big Data: Principles and Best
Practices of Scalable Real-Time Data Systems. Shelter Island, NY: Manning
Publications.

 

 

 

-Original Message-
From: questions
[mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of
Johannes Weber
Sent: Monday, February 6, 2017 3:11 PM
To: questions@lists.ntp.org
Subject: [ntp:questions] Monitoring Number of Clients

 

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

 

Thanks in advance!

 

Johannes

 

--

Johannes Weber

Webernetz.net - Network Security Consulting

mail: <mailto:johan...@webernetz.net> johan...@webernetz.net

mobile:  +49 174 1880211

 

blog: <https://blog.webernetz.net> https://blog.webernetz.net

twitter: @webernetz [1] 

 

Links:

--

[1]  <https://twitter.com/webernetz> https://twitter.com/webernetz

___

questions mailing list

 <mailto:questions@lists.ntp.org> questions@lists.ntp.org

 <http://lists.ntp.org/listinfo/questions>
http://lists.ntp.org/listinfo/questions

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

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

[Charles Elliott]

There is a Garmin GPS 18x High-Sensitivity LVC Sensor 010-00321-36 for sale
on eBay here:
http://www.ebay.com/itm/Garmin-GPS-18x-High-Sensitivity-LVC-Sensor-010-00321
-36-/77215324?hash=item33c0c1245c:g:L-gAAOSwOyJX-6Dn&vxp=mtr for only
$45.86 USD, $59.99 C in Canada.  I bought one from eBay for $39 not too long
ago, so all you really have to do is look.

The Sure device works, but for me it was too difficult to make the PPS work.
I bought two and was unable to make either one output a detectable PPS.  The
PPS was there, my scope told me so, but I could not make the computer detect
it.  On the other hand, I am very clumsy, and have little experience with
electronics.

Charles Elliott

-Original Message-
From: questions
[mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of
William Unruh
Sent: Thursday, February 2, 2017 1:06 AM
To: questions@lists.ntp.org
Subject: Re: [ntp:questions] Time syncing with something other than ntpd

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

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

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


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

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

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

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

[Charles Elliott]

> Do you know if there are any means to configure server B so that it does
not allow server A to mobilize > a dynamic symmetric association (meaning B
should still provide time services to A, but should not > consider A as a
time source)? Maybe there is a similar option to nopeers, but I cannot find
any in NTP >documentation.

But this is the normal (Unicast) situation.  Unless I am missing something
here, just don't tell B that A exists.  B does not have to know anything
about A for NTPD to work correctly.  The peer relationship is rarely used.
In fact, I don't remember anyone ever asking about the peer option before.

Charles Elliott



-Original Message-
From: questions
[mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of
Moser, Stefan
Sent: Monday, January 23, 2017 3:53 AM
To: questions@lists.ntp.org
Subject: [ntp:questions] Can I stop authenticated peers from mobilizing
symmetric associations

Hello everyone,

for unauthenticated peers, there is the restrict nopeer directive that stops
unknown peers to initialize dynamic symmetric associations with an NTP
server. However, from my own tests in my lab (and from NTP documentation),
it seems that nopeer does not pertain to authenticated peers. In my lab, I
saw this: If server A knows the authentication key of Server B and has a
peer IP_address_of_server_B directive in its ntp.conf, A is able to form a
dynamic symmetric association with server B even if server B has no
configuration for server A at all, and server B lists server A in its
association table (ntpq -p, type shown as S).

Do you know if there are any means to configure server B so that it does not
allow server A to mobilize a dynamic symmetric association (meaning B should
still provide time services to A, but should not consider A as a time
source)? Maybe there is a similar option to nopeers, but I cannot find any
in NTP documentation.

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

Re: [ntp:questions] Testing IPv6 code

[Charles Elliott]

Time-d.nist.gov serves time from 2610:20:6F15:15::27; I know that because I
use it, but 

7:38 Wed 01/18>nslookup 2610:20:6F15:15::27 127.0.0.1
Server: 127.0.0.1
Address:127.0.0.1#53

** server can't find
7.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.1.0.0.5.1.f.6.0.2.0.0.0.1.6.2.ip6.arpa:
NXDOMAI

Scott could try turning off automatic DNS name resolution from external
servers and put the addresses he needs in the hosts file.  That works with
time servers that no longer publish their IP addresses.

Charles Elliott

-Original Message-
From: questions
[mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of
Dan Geist
Sent: Tuesday, January 17, 2017 10:40 AM
To: Robert Scott
Cc: questions
Subject: Re: [ntp:questions] Testing IPv6 code

Robert, that host doesn't look to have a v6 record:

[dan@shell ~]$ host time-d.nist.gov
time-d.nist.gov has address 129.6.15.27

Obviously, you're getting the ipv4 address correctly, though.

Here's a good primer on IPv6 application porting:
http://long.ccaba.upc.edu/long/045Guidelines/eva/ipv6.html

Dan 

- Original Message -
> From: "Robert Scott" 
> To: "questions" 
> Sent: Tuesday, January 17, 2017 10:25:17 AM
> Subject: Re: [ntp:questions] Testing IPv6 code

> Perhaps the problem is with my understanding of socket coding.  I 
> found "time-d.nist.gov" that is supposed to have an IPv6 address of 
> 2610:20:6F15:15::27, but when I get its address info, it always says 
> IPv4, 129:6:15:27.  I see the 15 and 27, so there is some translation 
> going on that I don't understand.  My getaddrinfo is apparently 
> returning the IPv4 mapped equivalent.  Does anyone know how to force 
> just IPv6 addresses?
> 
> -Robert Scott
> Hopkins, MN
> 
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions

--
Dan Geist dan(@)polter.net
___
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] restrict source available from which version?

[Charles Elliott]

> And only use minpoll and/or maxpoll on local ref clocks.

Have you ever watched NTPD output when the polling interval reaches 10 (= 1024 
seconds) or higher?  NTPD acts just like the integral term in PID control, 
i.e., the yo-yo effect: Over several hours the offset drops to between -2 and 
-3 milliseconds; then over a period of 10 hours, or so, it reaches about +2 
milliseconds offset.  Then over the next 8 hours it slowly and fitfully drops 
to between -2 and -3 milliseconds again.  It that 8 hour decline from +2 to -2 
to -3 millis, in each case when I looked at it (11/24-11/27/16), it made a 
sudden (2 hour) spurt at the midpoint of the 8 hours to zero offset, but then 
resumed its slow and fitful decline to between -2 and -3 millis.  Given that it 
is not hard to maintain sub-millisecond offsets (if the NTPD client is using 
stratum 1 timeservers and has a fast (over 20-25 Mbps) connection to the 
Internet), a constant swing of ~5 milliseconds in offset from the correct time 
is discouraging.  I would wager that the offsets are larger with pool servers.

Charles Elliott

-Original Message-
From: questions [mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] 
On Behalf Of Brian Inglis
Sent: Sunday, January 1, 2017 1:19 PM
To: questions@lists.ntp.org
Subject: Re: [ntp:questions] restrict source available from which version?

On 2016-12-31 01:09, Brian Inglis wrote:
> On 2016-12-30 16:32, Ask Bjørn Hansen wrote:
>> On Tuesday, September 6, 2016 at 1:41:10 AM UTC-7, Miroslav Lichvar wrote:
>>> On 2016-09-05, a...@ntppool.org  wrote:
>>>> My draft has the following as the recommendation for someone using 
>>>> the pool (on 4.2.8 or later):
>>>> driftfile /var/lib/ntp/ntp.drift
>>>> restrict default kod nomodify notrap nopeer noquery restrict -6 
>>>> default kod nomodify notrap nopeer noquery
>>> I think this line shouldn't be necessary as restrict default 
>>> specified without -4 and -6 should apply to both.
>> Ok, thank you. Is that the case for older versions of ntpd, too? 
>> There's obviously a bit of cargo cult going on here, I appreciate the 
>> help getting to an actual best practices recommendation. :-/ For 
>> Martin's comment about kod and limited:
>> I'm not sure if 'limited' works on a reasonably busy NTP server 
>> (hundreds to a few thousand queries a second) and I don't think 
>> anyone has shown that KoD packets does something useful for a 
>> meaningful number of the "bad clients", so I should probably just 
>> take 'kod' out.
> Works with typical bad clients but most ignore KoD packets anyway so 
> just avoid the MRU list overhead and sending KoD - see 
> http://doc.ntp.org/current-stable/rate.html for how it works.
>>>> restrict source notrap nomodify noquery
> restrict source added with pool in 4.2.7p22 2010/04/02, docs updated 
> in 4.2.7p24 2010/04/13.
>>>> restrict 127.0.0.1
>>>> restrict -6 ::1
>>>>
>>>> pool 0.pool.ntp.org
> Add preempt to pool statements to drop unselected servers and acquire 
> new servers to maintain a majority clique - see below.
>>> How many servers should the client use at the same time? The default 
>>> value of tos maxclock is 10, so it would use 10 servers.
>>> That seems a bit excessive. If it should be equivalent to the 
>>> current recommendation, the config would need to include
>>> tos maxclock 4
> Keep it odd - tos maxclock 5 - for sync, majority clique requires 
> truechimers *>* falsetickers - truechimers == falsetickers is
> *unsynced* - 5 allows 2 servers "off" in some way at the same time 
> (e.g. during weekend maintenance windows when servers often drop out
> - YMMV) see http://doc.ntp.org/current-stable/select.html .
>>> Also, how about adding the iburst option? Considering that a 
>>> significant part of NTP traffic is from ntpdate (which sends four 
>>> packets in 2s interval) and that most Linux distributions seem to 
>>> use iburst in their default ntp.conf, I think it could be 
>>> recommended to everyone.
>> Hmm, I could get convinced of that.
> Also add iburst to pool statements.
> And only use minpoll and/or maxpoll on local ref clocks.

May also want to unrestrict all LAN addresses - safe for small home or business 
LANs, not for e.g. campus situations - or add but comment out? 

restrict10.0.0.0 mask 255.0.0.0   # private net allow all packets
restrict  172.16.0.0 mask 255.240.0.0 # private net allow all packets restrict 
192.168.0.0 mask 255.255.0.0 # private net allow all packets

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada 
___
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] Query NTP status on windows7

[Charles Elliott]

First of all, please, you should never ask a question about computers
without

stating what your platform is, O/S and version, CPU, and memory size.  When 

asking a question about NTPD, you should state what version you are using.

 

Second, people can help more if you tell them what you are trying to do, 

what your goal is.

 

Third, it would help if you would identify yourself, name and organization, 

or at least organization type.  I, for one, am opposed to giving advice to 

terrorists.

 

All that being said, I used the ntpq program, which is in the ntp/bin
directory,  

for something similar to what you want.  The documentation for ntpq is in 

ntp/doc/HTML/ntpq.html.  I was working in Java, so I used the ProcessBuilder


class to start ntpq and pipe its output back to my program.  I issued the 

host command to ntpq to set the IP address of the queried computer.  Then 

I repeatedly issued the peers command and parsed the output, which is:

 

ntpq> peers

 remote   refid  st t when poll reach   delay   offset
jitter


==

FreeNAS 192.168.1.1003 u   14   1670.257   -0.353
0.310

+209.51.161.238  .CDMA.   1 u   13   167   16.4991.689
0.480

-time-c.nist.gov .ACTS.   1 u   13   165   87.567   34.167
0.714

-time-d.nist.gov .ACTS.   1 u   13   165   86.541   34.231
0.596

-bonehed.lcs.mit .CDMA.   1 u9   167   24.8621.969
1.437

-timelord.w1nr.n 200.98.196.212   2 u9   167   13.593   -0.543
2.816

+ntp1.conectiv.c .IRIG.   1 u   13   167   22.165   -0.793
0.598

-lookingglass.ed 74.104.167.114   2 u7   167   16.441   -1.988
0.996

*time.falk.us.GPS.1 u8   167   24.969   -0.128
0.698

 

The first column is the tally code.  The '*' is the server synced to, '+'
are sync 

candidates, and '-' means discarded by the cluster algorithm.  Space ' ' 

means designated no select, in my case.

 

An easier way, according to the documentation, is to issue the rv 0 command
to ntpq, 

where 0 stands for system variables, and rv means readvar or read variables.
A 

typical return is:

 

ntpq> rv 0

associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,

version="ntpd 4.2.8p8@1.3265-o Jun 18 15:51:19.34 (UTC+01:00) 2016  (1)",

processor="x86-SSE2", system="Windows", leap=00, stratum=2,

precision=-22, rootdelay=12.119, rootdisp=2.987, refid=209.51.161.238,

reftime=db8be1e9.5be1a5a3  Tue, Sep 20 2016 12:27:21.358,

clock=db8be1eb.c0fab301  Tue, Sep 20 2016 12:27:23.753, peer=37206, tc=5,

mintc=3, offset=0.132622, frequency=-15.726, sys_jitter=0.382788,

clk_jitter=0.754, clk_wander=0.021, tai=36, leapsec=20150701,

expire=20161228 

 

According to the documentation "clock_sync" means the system is synchronized


and "refid" is the peer synced to, but I have never personally used these 

for this purpose.  The status word is described in decode.html and 

might possibly be useful to you.

 

Charles Elliott

 

-Original Message-
From: questions
[mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of
sneha b
Sent: Tuesday, September 20, 2016 6:49 AM
To: questions@lists.ntp.org
Subject: [ntp:questions] Query NTP status on windows7

 

Hi,

 

Is there a way to find out whether the sync was successful or not.

In vxworks we have ipsntp_query_time, is there something similar to this so
that I can use it programmatically and return success/failure.

 

Thanks

___

questions mailing list

 <mailto:questions@lists.ntp.org> questions@lists.ntp.org

 <http://lists.ntp.org/listinfo/questions>
http://lists.ntp.org/listinfo/questions

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

Re: [ntp:questions] Query regarding Ntp 4.2.8 p6, leap second tests

[Charles Elliott]

You are using an old, out-of-date leapseconds file.  The current file is
leap-seconds.3676060800.

I have attached a copy to this email.  If you do not receive it, send me an
email address of a site that accepts attachments.

Charles Elliott

-Original Message-
From: questions
[mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of
Sowmya Manapragada
Sent: Saturday, April 23, 2016 7:20 AM
To: Martin Burnicki; questions@lists.ntp.org
Subject: Re: [ntp:questions] Query regarding Ntp 4.2.8 p6, leap second tests

Thank you Martin for all the details. These helped a lot and i could get the
leap file accepted by the server, but always leap bit leap=11 in the rv
output of server even when ,leap file is accepted by server ( i could see in
server ntpq rv 0 op as .leapsec=20150701,expire=20161228 , but
leap=11)

Please see details below:
 Server Machine> Windows 7
1:> server ntp.conf:>
  server 127.127.1.0  #sync to local clock
  fudge stratum 10
  leapfile "c:\\\\\leap-seconds.3629404800"  #path to leap
sec file 2:> server machine:
   "You should set the time of your NTP server at least 30 minutes
before
the time of the leap second event, e.g. to 2015-06-30 23:30:00 UTC,
and
then restart the NTP service"
Done exactly the same , leap sec file is accepted . (changed my
server local clock to UTC 2015-06-30 23:30:00 UTC)
ntpq -c rv 0 :> associd=0 status=c016 leap_alarm, sync_unspec, 1,
event,restart,refid=INIT,peer=0,tc=3,
version "ntpd 4.2.8p4@1.3265 ... leap=11 
leapsec=20150701,expire=20161228
3:>I waited for around 1 hrserver time now UTC 2015-07-01
12:30:00 , but could never see this
"Also, the output should contain something like "leap=01"
during the
 hours before the leap second."
  In my case leap was always "leap=11"even when the leap
file is accepted.

Am i missing something , kindly suggest. how do i know if leap sec is added
when leap=11 always, even when leap file is accepted by server.
Also any way to identify in a client taking this server time that a leap sec
is added.
Thank's in advance.

thanks,
Shyam


On Tue, Apr 19, 2016 at 5:29 PM, Sowmya Manapragada 
wrote:

> Thank you, will try the steps you suggested.
>
> thanks,
> Shyam
>
> On Mon, Apr 18, 2016 at 4:34 PM, Martin Burnicki < 
> martin.burni...@burnicki.net> wrote:
>
>> Sowmya Manapragada wrote:
>> > Hello All,
>> > Request for inputs regarding a small leap second test which i am 
>> > trying
>> to
>> > do with my ntp4.2.8p6..
>> >
>> > Environment :
>> >Windows 7 client and windows 7 server test machines in a small
>> networked
>> > LAN.
>> > For Leap second configuration referred the following link:
>> >
>> >  :
>> > http://support.ntp.org/bin/view/Support/ConfiguringNTP#Section_6.14
>> > ./
>> > Steps: followed:>
>> >
>> > 1)  Configured leap-second (and  impend leap seconds on Jul 1 Jul 2015)
>> >   2) server side: included this leapsecond file, and made it as 
>> > orphan server.
>>
>> You should set the time of your NTP server at least 30 minutes before 
>> the time of the leap second event, e.g. to 2015-06-30 23:30:00 UTC, 
>> and then restart the NTP service. Please note leap seconds are 
>> scheduled for
>> *UTC* midnight, not midnight of some local time zone.
>>
>> If you set the system time on your NTP server too short before 
>> midnight then ntpd may run in "frequency" mode for a while, and if
"frequency"
>> mode lasts until after midnight then your NTP server may not insert 
>> the leap second properly. See:
>> http://bugs.ntp.org/show_bug.cgi?id=2838
>>
>> You can run the command "ntpq -c rv" to check if your server has 
>> accepted the leap second file. If it has then the output should 
>> contain something like:
>>
>> leapsec=20150701, expire=20161228
>>
>> Also, the output should contain something like "leap=01" during the 
>> hours before the leap second.
>>
>> >   3) client side:Moved back in time (just for testing) (example> 
>> > moved
>> back
>> > to by june 31st 11.56 pm .)
>>
>> In *any* case you should restart ntpd when you have changed the 
>> system time. Otherwise it will take up to 15 minutes until accepts a 
>> time step, and if the time has changed by more than ~1000 seconds the 
>> service will even stop itself with an appropriate message in the
application event log.
>>
>> Martin
>>
>>
>
___
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] Restrict problems

[Charles Elliott]

Can you use a packet sniffer, like Wireshark, to find out how far the
packets are going toward the non-responding NTPD?

-Original Message-
From: questions
[mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of
A C
Sent: Sunday, April 10, 2016 1:50 PM
To: NTPD Questions List
Subject: [ntp:questions] Restrict problems

I'm trying to figure out why two servers with the same ntp version (4.2.6p5,
that's what's in the repository) are behaving differently with respect to
peer queries from other local subnet hosts.

One server (A) is configured:
[server list]
restrict -4 default kod notrap nomodify nopeer noquery restrict -6 default
kod notrap nomodify nopeer noquery restrict 127.0.0.1 restrict ::1 restrict
10.0.0.0 mask 255.255.0.0

The other server (B) is configured exactly the same:
[server list]
restrict -4 default kod notrap nomodify nopeer noquery restrict -6 default
kod notrap nomodify nopeer noquery restrict 127.0.0.1 restrict ::1 restrict
10.0.0.0 mask 255.255.0.0

I copied and pasted from each server just to make sure I didn't miss
anything.

Now, I can remotely query server A from another client on 10.0.0.0/16 using
ntpq -pn .  It gives me the list of peers as expected.

Doing the same to server B results in a timeout error.  Neither machine has
a firewall set up so I'm not sure what I've missed in configurations.
___
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] Idea to improve ntpd accuracy

[Charles Elliott]

Thank you very much for the paper reference on temperature compensation.
The paper and its results are excellent.  A self-calibration feature (that
worked) so that each user could have it configured for his/her own computer
should not be too hard to implement.  I wonder why NTPD never picked it up?

Charles Elliott

-Original Message-
From: questions
[mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of
Hal Murray
Sent: Saturday, February 27, 2016 11:19 PM
To: questions@lists.ntp.org
Cc: Hal Murray
Subject: Re: [ntp:questions] Idea to improve ntpd accuracy


> I thought of that too but rejected it as way too machine-specific.  
> Because the clock PLL does not track frequency ramps feed-forward 
> could  be very effective (e.g. order of magnitude). To make this work 
> however,  you need to first discover which one of many potential 
> temperature  sensors on the MB are most closely correlated with 
> frequency, then  measure a rough linear gain from temperature to PPM. 
> Seemed too  hardware-instance-specific to me, but perhaps there's a way...

You want to measure the temperature of the crystal.

Several/many years ago, Linux used to use the RTC/TOY clock for the main
timekeeping.  Now, the main CPU clock is used.  You want to get a temperate
probe on that.


Mark Martinec has a wonderful web page on that.
NTP temperature compensation
  https://www.ijs.si/time/temp-compensation/


--
These are my opinions.  I hate spam.



___
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] Idea to improve ntpd accuracy

[Charles Elliott]

Here are two other ideas you might want to consider to improve accuracy:
Feed forward (PID) control on system temperature and significant changes in
system load.  Let me describe the situation.  Right now I have only 3
computers on a home LAN.  Two, one of which is my main system for email and
dictating research notes, process BOINC/Einstein@Home work units and one
serves only as an external-facing NTP client that distributes time to the
other two.  Due to environmental pressures and the need to conserve energy,
the two computers processing Einstein@Home WUs stop that at midnight and
resume at 5 AM automatically.  Ambient temperature affects all 3 computers
equally, thought its effect is most noticeable on the external-facing NTP
client.

When the two computers shed the load at midnight, the offsets immediately
decrease to between -1 and -2 ms; then, both machines spend all night
recovering to zero offset at about 5 AM, whereupon the offsets jump up to
between +0.5 and +1 ms when the load is resumed.  At about 8 AM both
machines are back to zero offset.  

All during the night, the ambient temperature is falling because
BOINC/Einstein@Home consumes between 450 and 500 watts of GPU and CPU power
on each machine on which it runs.  Consequently, the frequency offset (in
ppm) declines all night, reaching a minimum at 5 AM, and then increases
steadily on all three machines until it reaches a steady state at about 10
AM.  It hovers at a fairly steady state until midnight, whereupon the fall
and rise pattern is repeated.

PID control is proportional + integral + derivative.  Normally, a control
signal is proportional to an error signal, such as offset error, in
proportion to the sum of (offset) errors (integral), and in proportion to
the change in (offset) error (jitter). However, for temperature, there is no
concept of error; it is what it is.  For control as a function of
temperature (T), there clearly is a direct functional relationship between
ppm and T, such as ppm = Kp T.  Jitter lags both temperature and system load
changes by about 2 hours, so I am not sure derivative control is wise or
even possible.  Integral control is what yanks the elevator up to floor
level when the brakes are slipping.  It can be hard to get right because of
the yo-yo effect.  Obviously, more thought has to be put into all this.  But
I have been watching these relationships for several weeks with NTP Plotter,
and they are obvious and fairly consistent.   

What started me off on this, is that CPUID (www.cpuid.com), makers of CPU-z,
HardwareMonitor, and HardwareMonitorPro, the latter two of which do an
excellent job of monitoring all manner of system and peripheral
temperatures, is offering a "System Monitoring SDK" for evaluation.  The
idea would be to record the relationships between various temperature
measurements and ppm and then try to adjust the PPM adjustment with
temperature to see if any improvement is offsets results.  However, CPUID
never replied to my email.

Charles Elliott

-Original Message-
From: questions
[mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of
Weber
Sent: Thursday, February 25, 2016 4:52 PM
To: questions@lists.ntp.org
Subject: [ntp:questions] Idea to improve ntpd accuracy

This may or may not be worthwhile, but I thought I'd throw it out there and
see what happens:

Recent work testing some microsecond-accurate NTP servers lead me to an idea
that could improve accuracy of measurements made by ntpd. These NTP servers
have hardware timestamps on receive but that's not possible on transmit w/o
a custom NIC. I've seen this issue discussed before.

The next best thing is to generate the transmit timestamp based on a guess
as to how long it takes the NIC to get on the wire and send the packet. That
works pretty well as long as there's no other network traffic. In this
situation, it is possible to make use of microsecond accuracy in an NTP
server.

Now, add some typical network traffic and the time it takes the NIC to get
on the wire becomes unpredictable to the tune of 200us or more (for
100 base-T Ethernet). The server's microsecond accuracy is largely lost in
the noise.

The NIC generates an interrupt after the packet is sent which can result in
a fairly accurate trailing hardstamp. The problem is...the packet is already
gone and has the wrong transmit timestamp.

Here's my idea:

What if the poll response packet contained a flag or indication of some sort
which means "this is an approximate transmit timestamp". That packet would
then be immediately followed by a second response packet with a more
accurate transmit time. The second packet could be otherwise identical to
the first, or it could be a new flavor of packet that contained only the
transmit time (that would save on network bandwidth).

The ntpd process would need to use the receive time of the first packet (the
one with an approximate tx timestamp) and m

Re: [ntp:questions] NTP refuse to sync

[Charles Elliott]

>* Inner NTP Server- 1 was used to be synced only to its Local, that
way inner 2 and inner 1 had a > minor offset. I must maintain this behavior.

I don't understand this sentence completely.  Is having Server-1 sync only
to its local clock something you did in the past and are now not doing since
you are using an external NTP server/client?

>* Once adding the external sync- we would like to support 5 min
offset as maximum (running ntpd >in slew mode -x under inner 1), Inner NTP
server-1, accept the external NTP as a valid source >synchronization, and
starts a synchronization process with the external ntp. While NTP server-1
is >synching (offset is getting down in a rate of not more then 0.5 MS per
second), Server NTP 2 refuse to >sync for a while, getting to gain offset
from inner NTP-server1 - which I must avoid. (after 13 hours >running we get
low offsets(I have all outputs...))

I don't think you will ever make NTPD tolerate a 5 minute offset between
computers.  Upon reboot or start up, NTPD is setup to reset the clock to the
current time and restart itself when it is more than a few second offs from
the server; I don't remember the exact tolerance value, and I can't find the
-x option.  Where did you see that?  The NTPD -g command line option ("allow
big initial time step") controls this, and most people use it.  OW, NTPD
just exits when there is a big time difference between the client and the
server. 

How long server-2 takes to sync to server-1 depends on 1) whether server-1
thinks it has good time from the external server (that takes a few minutes
after a reboot), and 2) how recent a version of NTPD you are using; more
recent versions of NTPD converge much faster than older ones, and 3) the
accuracy of the computer clock on server-1 and server-2.  You don't say what
O/Ss you are running, and I can't help much with Linux.  Windows 8, 8.1 has
a clock precise to 100 nanoseconds; the Windows 7 clock is all over the map,
and you never will be able to sync a Windows 7 machine to less than several
hundred microseconds.  The recency of the CPU and motherboard also matter.
More recent CPUs have a timestamp counter (TSC) that does not vary with the
CPU frequency, while older ones don't.  That matters because NTPD can use
the TSC for interpolation between clock ticks (whose interrupt period is
15.625 msecs).  You cannot let your computers sleep; NTPD cannot work if the
CPU enters certain sleep states.  I use and much prefer using the High
Performance Event Timer (HPET) to the TSC for interpolation since it has a 3
times higher frequency than the TSC.  Others may say that the HPET has a
higher latency than the TSC, which is true.  How you set up the computer to
do this depends on the O/S.  Under Windows 7 and later "run cmd as admin and
paste 'bcdedit /set {current} useplatformclock Yes'" (w/o the single or
double quotes).  My copy of FreeBSD always chooses the HPET; I am not sure
what Linux uses for a performance counter for timing.

>* Is there any why to force NTP server-2 to trust NTP server-1 no
matter what?

The NTP Cheat Sheet here
(https://www.meinbergglobal.com/english/sw/ntp.htm#ntp_cheat_sheet) lists a
true option for the conf file, as in

server 192.168.0.5 iburst minpoll 4 maxpoll 4 true

While I have never used this option, the Cheat Sheet says it makes the host
computer think the server is always a true chimer.

>* Is there any why to run under Inner NTP server-1 , two services
of ntpd(one as client and one >for server). The server will sync externally,
and the client will serve  Inner NTP server-2 by syncing to >it's
disciplined clock.

No, I don't think so.  NTPD completely takes over the computer's clock by
changing the nominal interval between clock ticks (the time adjustment
factor), so every time the clock interrupt hits, more or less time is added
to the current time.  I don't think there is any why more than one program
could control the time adjustment factor.

Charles Elliott

-Original Message-
From: questions
[mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of
Natalie Abravanel
Sent: Wednesday, February 10, 2016 12:55 PM
To: questions@lists.ntp.org
Subject: [ntp:questions] NTP refuse to sync

Hey,
I have the following requirements for syncing:

* External NTP : it can be any configuration, active directory,
Centos, virtual machine.

* Inner NTP server-1 sync only to one server source (the external
NTP above), and also uses orphan mode in case the external is not reachable.

* Inner NTP server -2 - sync only to one server source (the inner
NTP 1)
Description & questions

* Inner NTP Server- 1 was used to be synced only to its Local, that
way inner 2 and inner 1 had a minor offset. I must maintain this behavior.

* Once adding the external sync- we would 

Re: [ntp:questions] What prevents continuous time within an operating system ?

[Charles Elliott]

> Affinity is best set to CPU (nprocs-1) to minimize cache thrashing, and
ensure that time stamps >are consistent, as not all systems sync their
clocks across all CPUs at startup, leading to skews >between time stamps
from different CPUs.

My bosses will not let me do this, citing:

1.  There is little if any evidence that limiting NTPD to one CPU is
beneficial.

2.  NTPD's main loop experiences between 1 and 7 context switches a second.
Two other threads run
sporadically, but apparently at no fixed frequency, one of them very
often.  Two threads, on
Windows, just sit there.  One can see this with Process Explorer.  This
implies two
conclusions:
  A. Occasionally, NTPD needs more than one CPU simultaneously.
  B. When NTPD requests a CPU, and another process at a lower priority owns
NTPD's assigned CPU,
 then NTPD has to wait one time slice for access.  It is called priority
inversion and is the
 bane of systems everywhere.

In addition, it is not clear to me that limiting NTPD to one CPU is NTP
official policy.

Do you have any hard evidence that limiting NTPD to one CPU has any
beneficial impact?

Charles Elliott

-Original Message-
From: questions
[mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of
Brian Inglis
Sent: Thursday, January 21, 2016 9:01 PM
To: questions@lists.ntp.org
Subject: Re: [ntp:questions] What prevents continuous time within an
operating system ?

On 2016-01-20 12:37, MAYER Hans wrote:
>> Set a preferred source to label the PPS ticks e.g. server ... prefer.
>> Add good LAN or nearby internet sources.
>
> Here I can't follow you.
> I have two PPS sources at the same server. The measured offset for 
> each is  typically in a range of +- 5 us ( see image ) Any time source
over the network is much worse.  Typically by a factor of 10.
> And I need this with a poll interval of 64 time seconds or less.
> Finally I don't want to poll a foreign time server in minute intervals.

With PPS sources you also need some GPS or network source(s) to provide UTC
time to "label" the PPS ticks, otherwise the PPS sources can not be used to
discipline UTC time. If a source is marked prefer, and is selected, that
will be used to provide the UTC "label" for the PPS interrupt.
Any selected network source is better than the alternative of using the
local clock driver and the "wristwatch and eyeball" method of setting the
system time, or using an RTC if your system even has one.

>> Have you set affinity for ntpd or is it pinned to a non-zero CPU to 
>> reduce contention?
>
> What do you mean ?  Never heard "non-zero CPU"
> I googled a little bit but results didn't make sense for me.

Primary (boot) CPU core is normally labelled zero - try:
less /proc/cpuinfo
Affinity is best set to CPU (nprocs-1) to minimize cache thrashing, and
ensure that time stamps are consistent, as not all systems sync their clocks
across all CPUs at startup, leading to skews between time stamps from
different CPUs.

>> Have or can you disable any power management features?
>
> There is nothing like this. Always running, always idle.

Many systems nowadays, even single board SoCs, apply power management to
reduce energy use, so they drop the CPU clock speed, and power down internal
components, when they become idle, causing variations in timing, and delays
coming out of "sleep" states, which make it difficult for ntpd to correctly
estimate the CPU clock frequency drift. To reduce RFI at the clock
frequency, they may also vary the clock frequency randomly, often called
"Spread Spectrum", which allows them to pass government RFI interference
tests that could restrict their use from retail or commercial premises. For
example, you may not want to run a system with a 1.5GHz clock (or
submultiple) near a GPS receiver!

These "green" power saving features can often be disabled in the BIOS or
system configuration by digging into "advanced" menus and checking config
docs.

Newer AMD/Intel systems have a time stamp counter (TSC) which is invariant
(/proc/cpuinfo should show ...constant_tsc...nonstop_tsc) regardless of the
CPU power management state. Some BIOSes/OSes/clock drivers can sync the TSC
values across cores on the same socket at startup, and may set up machine
status registers (TSC AUX MSRs) with identifiers or offsets per CPU,
readable using recently added instructions.

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
___
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 orphan sync time after boot

[Charles Elliott]

I just answered a question about NTPD's broadcast mode for someone else, so
perhaps it is on my mind.  Nevertheless, it might be the answer to your
problem.  How to set it up is in confopt.html in the NTP standard
documentation, in the C:\Program Files (x86)\NTP\doc\HTML directory in the
Meinberg NTP distribution for Windows.  If you broadcast the time at the
highest rate possible, all the computers will sync as fast as possible.

You need a figure for the broadcast delay option, but this might be a way to
see if broadcast mode will work for you.  For a few days, make, using the
"week" option, the loopstats file on each computer.  Then pull several in to
Excel or another spreadsheet program.  Compute the average and the standard
deviation of the delay column; half the delay is the packet flight time
between computers.  If the ratio of the StdDev/Average is "small" on each
computer, then the computers are more likely to be closely synched.  You
could also plot the delay against the time in the second column on the left
to see if it is a nice, straight line.

As an aside, you might consider the wisdom of shutting down each computer
each night, for energy savings I suppose, versus the wear and tear of
starting up delicate electronics each morning.  The new motherboards and
CPUs from Supermicro and Intel use a small fraction of the wattage of their
predecessors.

Charles Elliott

-Original Message-
From: questions
[mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of
Rini van Zetten
Sent: Thursday, January 14, 2016 9:26 AM
To: questions@lists.ntp.org
Subject: [ntp:questions] ntp orphan sync time after boot

Hello,

We have several devices connected to each other without internet connection.
They have to be synchronised, but the absolute time is not important.
I have set up the ntpd on each device in orphan mode with one device as
server.
This works fine.

The problem we have is that it takes about 5 minutes after boot before the
devices are synchronised.
Is there anything possible to speed up this process ?

Thanks,

Rini



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

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

Re: [ntp:questions] How to specify interface for multicastclient

[Charles Elliott]

How to configure broadcast mode is in confopt.html in the NTP documentation
that comes with the Meinberg distribution for Windows.  It is easy to set up
too.  For the broadcast delay option, I averaged the delay between computers
from loopstats and divided by 2.  For me, back in the day when I was running
several computers for processing SETI@Home work units, it was a huge
success.  Jitter went down to almost nothing, and the computers were in
lockstep with each other timewise, but a LAN in a home environment is VERY
lightly loaded.  The results could be different on a LAN with a lot of
chatter.

BTW, the way I found the documentation again for broadcast mode was by
pointing AstroGrep at C:\Program Files (x86)\NTP\doc\HTML, searching for
"broadcast," and then reading the files located until I recognized the
correct page.  Since the letter 'C' comes near the head of the alphabet, it
did not take long.

Charles Elliott

-Original Message-
From: questions
[mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of
Brian Inglis
Sent: Thursday, January 14, 2016 3:16 AM
To: questions@lists.ntp.org
Subject: Re: [ntp:questions] How to specify interface for multicastclient

On 2016-01-13 20:10, Brian Inglis wrote:
> On 2016-01-13 14:30, brian utterback wrote:
>> I am sure this has been asked before but I can't find the answer. On 
>> a multihomed system, is there anyway to specify which interfaces you 
>> want multicastclient to listen on? If so, how. If not, why not? I 
>> would have expected it to listen on all interfaces, but it doesn't do
that.
>
> Relevant links:
> https://www.eecis.udel.edu/~mills/ntp/html/miscopt.html#interface
> https://www.eecis.udel.edu/~mills/ntp/html/discover.html#bcst
> https://www.eecis.udel.edu/~mills/ntp/html/confopt.html#broadcast
> https://www.eecis.udel.edu/~mills/ntp/html/confopt.html#multicastclien
> t
>
> Address options:
> https://en.wikipedia.org/wiki/Multicast_address
> https://tools.ietf.org/html/rfc2365
> http://tools.ietf.org/html/rfc5771
> http://www.iana.org/assignments/multicast-addresses/multicast-addresse
> s.xhtml

e.g. you should be able to set multicast address 239.1.1.1 as the broadcast
address on one interface and 239.2.1.1 on the other, specify two lines with
the broadcast addresses in ntp.conf, and have all clients specify both as
the multicastclient addresses in their ntp.conf.
If the servers are used for anything but NTP, YMMV: see last 4 links.

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
___
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] set server to a non utc time by hand

[Charles Elliott]

This is probably not exactly what you want, but perhaps the idea will help.
In the class java.time.Clock documentation, the authors show users how to
inject a version of the Clock class into their program that will dispense
any time needed for debugging purposes.  In other words, within a Java
program one version of the clock can be used for debugging and another for
regular time in a production environment.

BTW, NTPD at least used to have a simulator mode that it could be started
in.  I am not sure if that mode is still supported, nor do I know how to use
it.  You could ask on this list if the simulator mode still exists and if
documentation exists for it.

Charles Elliott

-Original Message-
From: questions
[mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of
Harlan Stenn
Sent: Monday, December 21, 2015 11:42 PM
To: h3x32000-sf
Cc: questions@lists.ntp.org
Subject: Re: [ntp:questions] set server to a non utc time by hand

h3x32000-sf writes:
> Hello all,
> 
> i would like to set up an ntp-server thats does not give back the 
> correct utc time, but for example utc-1 or another "wrong" time 
> computed before. Until now the only way I reach ed that result was to 
> set the local clock to the wished time and to sychronize then with 
> 127.127.1.
> 1.
> 
> This method seems to me a little unsatisfactory because i have to 
> manipulate the local time what i actually do not want.
> 
> I already asked google but i couldnt find a solution... does anybody 
> could give me a hint or the key-word that is needed...
> 
> Thanks, doxi

I'm not aware of anything available at the moment, but what you describe is
exactly what I have planned for NTPv5, using the General Timestamp API,
which supports multiple timescales.

Are you doing this for fun?
--
Harlan Stenn 
http://networktimefoundation.org - be a member!
___
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] IPv6 link local

[Charles Elliott]

Using the link-local address does not work on my LAN.  The external facing
server on my LAN is 192.168.0.78/192.168.1.78 and has link-local IPv6
address fe80::41f5:e784:2a07:5e55.  I can ping and tracert
fe80::41f5:e784:2a07:5e55, but if I put fe80::41f5:e784:2a07:5e55 in the
ntp.conf file, this computer cannot access the time from 78.  In addition,
if I put fe80::41f5:e784:2a07:5e55, instead of 192.168.0.78 or 192.168.1.78,
in the Meinberg NTP Time Server Monitor in the Configuration tab, I can no
longer monitor the status of 192.168.0/1.78.

Charles Elliott

-Original Message-
From: questions
[mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of
Greg Dowd
Sent: Wednesday, December 16, 2015 4:46 PM
To: questions@lists.ntp.org
Subject: [ntp:questions] IPv6 link local

Does open source ntpd support using IPv6 link local addresses for
client/server/peer modes?  I have not been able to use link local addresses
to peer 2 servers on the same subnet.

Thanks...Greg

___
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] Observation with ntp4.2.8@p4-request inputs

[Charles Elliott]

FWIIW, I have seen a similar phenomenon, only with one server.  If the time
server on my network stops dispensing time for some reason, the computers on
the LAN will still stay sync'ed to its last observation long after the reach
indicator goes to zero.  Not sure if that is right.

Charles Elliott

-Original Message-
From: questions
[mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of
Sowmya Manapragada
Sent: Wednesday, December 9, 2015 10:26 PM
To: questions@lists.ntp.org
Subject: [ntp:questions] Observation with ntp4.2.8@p4-request inputs

Hello All,
Just wanted to check if what I am observing with4.2.8p4 is as expected or I
missed out something because I don't see this with older 4.2.8p2/p3 :I have
a client having 2 NTP servers (both servers in my LAN ), client makes one as
a peer ( to which it is currently synced) and other as a candidate; the peer
(server) goes down, my client at least waited 7 to 8 min to reject this peer
server and choose the available one... Checked in Mein berg monitor tool
also and rv0 command ... The status word just don't show that client
rejected server until 7 to 8 minutes... Wire shark correctly shows no
packets exchanged between my clint and peer ( right from moment when server
which is down)..my client ntp.conf is standard with an iburst...
Thanks in advance
Shyam
___
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] Synchronize distributed PCs with GPS 1 PPS and NTPD for OWD measurements

[Charles Elliott]

The USGlobalSAT MR350P or MR350PS4 is a pretty good COTS 
GPS unit with PPS.  You can find the data sheet here: 
http://usglobalsat.com/s-18-serial.aspx.  You must look 
on the datasheet to find the PPS because it is not advertized.  
I have a MR350P, so I know there are two problems with it.

1.  The PPS signal is not brought out to a connector, so you 
have to cut the cable to find it; the data sheet says it is 
in yellow.  But cutting the cable w/o damaging the wires 
presents a barrier.

2. My Samsung Galaxy S4 consistently finds 22 or more satellites 
in a sky that the MR350P finds at most 6-8 satellites, and that 
is with the MR350P puck outside taped to the top of a fence post.  
But the phone cost $650 and the MR350P was about $65, so that 
result may be logical.  When the MR350P is stationary on the fence 
post, the average of 4 days of GPS location readings is 39.99321667N, 
-75.12598333W.  The Samsung S4, located right next to the MR350P, 
says the location is 39.993218N, -75.125984W (after 10 minutes), and 
that position locates on Google Maps only about 5-6 feet south of its 
actual location, whereas the MR350P's coordinates place it about 2 
feet east of the fence and maybe 2 feet south of its actual location.  
So, over a period of time the MR350P is pretty accurate, position-wise.

W/O PPS the time signal on the MR350P is unusable.  It wanders around 
about +- 60ms about the correct time with a frequency of about 36 hours.

I never could make myself cut the cable on the MR350P to find the PPS, 
since I am about as handy with electrical stuff as Gordon was untying 
knots.  But if you could find a MR350P at a decent price, it is a COTS 
GPS with PPS.

Charles Elliott

> -Original Message-
> From: questions [mailto:questions-
> bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of sandip
> gangakhedkar
> Sent: Monday, September 21, 2015 12:24 PM
> To: Joachim Fabini
> Cc: questions@lists.ntp.org
> Subject: Re: [ntp:questions] Synchronize distributed PCs with GPS 1 PPS
> and NTPD for OWD measurements
> 
> Joachim,
> 
> Thanks for your detailed solution, which was along the lines of my
> thinking..
> 
> Do you know of any off-the-shelf GPS receiver with RS232 and PPS
> capability?
> 
> Hal,
> 
> >> What sort of distance accuracy are you expecting?
> 
> Not very stringent..up to 10m will do.
> 
> 
> >> What sort of distances will you be operating over?
> 
> 50m - 1000m
> 
> >> How unreliable is your link?
> 
> Very. The packet error rate can vary between 0 - 100%.
> 
> >> I would ignore NTP and do everything yourself.
> >>
> >> Do something like ping.  That takes 2 packets, but you don't need to
> know the
> >> time on the other end.  If both ends need to know the distance, you
> can
> make
> >> a measurement with 3 packets.
> >>
> >> Or you can send a dozen packets and use the minimum time assuming
> the
> others
> >> had delays in the interrupt handler.  (and use the spread in the
> times
> as an
> >> indication of quality)
> >>
> >> You will probably need to calibrate the response times of the CPUs
> and
> the
> >> delays through the radios so you can subtract it out.  The radio
> delays
> may
> >> may depend on signal strength which varies with distance, but will
> also
> >> change if you go behind mountains or trees or buildings.
> 
> Interesting technique, but for One way delay measurements, it will
> introduce a lot of measurement error, particularly as the links are
> unreliable and asymmetric (uneven delays).
> 
> 
> Best,
> Sandip
> 
> 
> On Mon, Sep 14, 2015 at 1:40 PM, Joachim Fabini
>  > wrote:
> 
> > On 14.09.2015 12:43, Hal Murray wrote:
> >
> > > Joachim Fabini said:
> > >> - Re-compile your kernel for LinuxPPS support, following the
> > instructions on
> > >> http://linuxpps.org/wiki/index.php/LinuxPPS_installation .
> > >
> > > That hasn't been necessary for a long long time.
> >
> > Most recent distributions have PPS line support enabled by default.
> > Still, kernel build is necessary if you have special driver
> requirements
> > or change options -  I recompile measurement kernels for increasing
> the
> > Hz rate. The page contains some outdated information but some of it
> is
> > valuable (in particular the reference to the ppstools repository and
> > timepps.h copy that is essential for building ntp).
> >
> > > What version of the kernel are you using?
> >
> > 3.8 - 3.13
> >
> > > Recent kernels need something like:
> > >   ldattach 18 /dev/ttyS0
> > >

Re: [ntp:questions] Synchronize distributed PCs with GPS 1 PPS and NTPD for OWD measurements

[Charles Elliott]

> 
> The goal is to have a setup for measuring One Way Delay of UDP packets
> between two moving nodes, over a long-range wireless network.
> 

I understand that you are trying to measure accurately the packet
flight times between two computers over a long-range wireless network.  
You know, of course, of ntpd's monitoring options, which are described 
in "monopt.html" which comes with the ntpd distribution in the 
...\ntp\doc\HTML folder.  To secure the data you need you can perform 
a "join" (in the SQL sense) of the rawstats files of the two computers, 
which will give you the actual send and receive times of the packets, 
and/or a "join" of the peerstats files, which will give you what NTPD thinks

are the delay times.  For the rawstats files, the join can be performed on 
the packet IP address and the packet times; the send IP address on one 
computer must match exactly the receive IP address of the other computer, 
and vice versa.  To make sure the two rawstats files are measuring the same 
packet, you need to choose the packets with the closest times.  The same is 
roughly true if you use the peerstats data.  Of course, here I am assuming 
you want to measure the flight times of NTP packets.  This joining process 
can be confusing.  I first did it with a spreadsheet, and then once I got 
the technique straight in my mind, I wrote a short Java program to perform 
the join automatically, and more consistently correctly than a human can 
achieve alone.  Parenthetically, I set ntpd's statistics facility to output 
weekly reports, rather than daily; there is a lot less paper shuffling that
way.

On a slightly different aspect of your goal, I urge you to pay close
attention 
to Charles Swiger's advice, to wit:"Heck, if you choose your upstream
NTP 
servers well, you can even get a stratum-2 server without a refclock
to maintain ~1ms accuracy, but that depends on having a decent net link
also."

I am only running three computers at present 192.168.0.1, ... 78, and ...
100.  
78 gets its time from five close by stratum 1 servers and two stratum 2
servers.
I access NTP with a 30 Mbps cable connection. 
I chose these servers after a several-week period of measuring the delay and

jitter of many stratum 1 and 2 NTP servers, and chose the ones with the
lowest 
delay and jitter, and that were consistently selected by ntpd as
"true-chimers."  
78's average offset (the difference between the best outside clock and its
clock) 
is normally between + and - 0.2 ms, and almost always between +- 0.6 ms.
Its 
measured average jitter is 0.25 ms.  (I will try to send you a copy of its
offset 
v. time graph for 9/2 thru 9/6 so you can see these numbers for yourself.)

Much better news is 192.168.0.100's performance; 100 gets its time from 78.
100's 
offset is normally within +- 50 microseconds (us), and almost always within
+- 200 us.  
100's average jitter is about 30 us.

Based on Swiger's advice and my experience, I urge you to consider setting
up 
two ntpd client/server machines (one remote and one local) to access their 
time from up to 9 (per each) carefully chosen external sources (or GPS).
Then 
attach a client computer to each of the client/server machines, and measure
the 
packet flight times between the two clients.  The use of the client
computers 
has a smoothing effect of greatly reducing any jitter in your measurements.

I believe you can achieve all the accuracy you need this way without the 
expense of buying and setting up two GPS sources of time.  GPS is great on
paper, 
(and in real life, if you can afford expensive receivers) but unless you
have 
fairly good craftsmanship skills, it can be incredibly difficult (and/or 
expensive) to get GPS to work well and consistently.

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

Re: [ntp:questions] Reargding ntp (ntp 4.2.8 or higher) on Wince /WEC 2013

[Charles Elliott]

For what it is worth, ntpd runs more than adequately on FreeNAS, 
which uses FreeBSD as its underlying O/S. 

Why do you write ntpd will only run on NT-based machines?

Charles Elliott

> -Original Message-
> From: questions [mailto:questions-
> bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of Danny Mayer
> Sent: Monday, August 31, 2015 5:04 PM
> To: Sowmya Manapragada; questions@lists.ntp.org
> Subject: Re: [ntp:questions] Reargding ntp (ntp 4.2.8 or higher) on
> Wince /WEC 2013
> 
> On 8/31/2015 1:18 PM, Sowmya Manapragada wrote:
> > Hello All,
> > I am trying to use ntp  (ntp-4.2.8 in specific) on wince environment.
> Just
> > wanted to check if anybody compiled ntpd for wince (Windows embedded
> > compact-2013 in specific). I am trying compiling, but I see lots of
> errors
> > on open-ssl front. Any information will help.
> >
> 
> ntpd will only run on NT technology O/S's because of the library
> functions being used. OpenSSL is pretty straightforward to compil.
> 
> Danny
> 
> > Thanks a lot
> > Shyam
> 
> ___
> 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] iburst and NIST servers

[Charles Elliott]

I use minpoll 4 maxpoll 5 on the client that accesses external servers and
minpoll 4 maxpoll 4 on the LAN.  The results justify the means: consistent
sub-100 millisecond offsets on the LAN (presently -0.011 on this computer).
The only time I have been knocked off an NIST server was when I switched
from one computer to another as the external gateway.  Because of the NAT,
time-d and time-d.nist.gov picked up the fast request rate right away when
both clients were briefly active, and would not let me back on for a day or
so.

Charles Elliott

> -Original Message-
> From: questions [mailto:questions-
> bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of Charles
> Swiger
> Sent: Sunday, August 2, 2015 10:34 AM
> To: Mike Cook
> Cc: Questions List
> Subject: Re: [ntp:questions] iburst and NIST servers
> 
> On Aug 2, 2015, at 2:31 AM, Mike Cook  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
> 
> ___
> 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] reachability register

[Charles Elliott]

Hello:

All I can say is, it does that sometimes.  I think what might be
happening is that ntpq caught ntpd before the reachability register was
updated, although it updates that fairly early in the game.  You can see the
code in proto.c in a recent source distribution, like here:

Tarball:

http://archive.ntp.org/ntp4/ntp-dev/ntp-dev-4.3.14.tar.gz 

MD5 sum:

http://archive.ntp.org/ntp4/ntp-dev/ntp-dev-4.3.14.tar.gz.md5

If you want to see it work correctly and you are using Windows,
start the Meinberg NTP Monitor and set it to monitor your Internet-facing
NTP client.  On a non-Windows O/S, just use the host command to set ntpq to
the Internet-facing NTP client and repeatedly send it the peers command.

In any case, then unplug your Internet modem and your router.  Wait
a few seconds (~60), plug the modem back in, then after a few seconds (~30)
plug in your router.  Then watch the Meinberg NTP Monitor or the ntpq peers
output of the reachability register.  You should see something like the
following:

 BinaryOctal
  100   100
 1001   201
   11 3
  111 7
 17
137
   1177
  111   177
    377

Charles Elliott

> -Original Message-
> From: questions [mailto:questions-
> bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of MAYER Hans
> Sent: Wednesday, April 8, 2015 9:23 AM
> To: questions@lists.ntp.org
> Subject: [ntp:questions] reachability register
> 
> 
> Dear all,
> 
> I have a question about the reachability register. For my opinion this
> is a left shift 8-bit register.
> I looked in one of our internal ntp-server with "ntpq" and found a
> value of 376 to a peer configured internal server. After waiting the
> time difference between "poll" and "when" I can find the value of 377.
> How is it possible ? For my understanding this could only happen after
> 8 times the poll interval. The next value should be 375 and after that
> 373. And so on shifting the 0-bit to the left.
> 
> Kind regards
> Hans
> 
> 
> 
> ___
> 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] chrony as a server

[Charles Elliott]

If you don't mind me asking, why is chrony superior to NTPD 
for tracking a PPS signal, or even in general?

Charles Elliott

> -Original Message-
> From: questions-bounces+elliott.ch=comcast@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On
> Behalf Of Rob
> Sent: Tuesday, February 17, 2015 3:27 AM
> To: questions@lists.ntp.org
> Subject: Re: [ntp:questions] chrony as a server
> 
> David Woolley  wrote:
> > On 15/02/15 22:40, Rob wrote:
> >> it is tracking very nicely
> >
> > Tracking what?
> 
> The PPS signal.
> 
> ___
> 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

[Charles Elliott]

Programmers universally compute the number of days between two dates by
determining the seconds of the two dates (by using a function such as
getTimeInMillis() for each date), computing the difference in seconds
between the two dates, and dividing the difference by 86,400.

I proved this to myself by performing the following experiment with three of
Java's date classes, GregorianCalendar, Date, and ZonedDateTime.  In
pseudocode:

For year = 1997 to 2015
  Date1 = year, month =1, day =1, hour = minute = second =0
  Date2 = year+1, month =1, day =1, hour = minute = second =0
  Duration = Date2 - Date1 (in seconds)
  Print Date1, Date2, Duration

Date1 = 1997, month =1, day =1, hour = minute = second =0
Date2 = Date1 + 31_536_000 * 18 + 4 * 86_400 //Add 18 yrs (in secs) + 4 days
for leap years
Print Date1, Date2

For each of Java's date classes, the Duration was equal to 31,536,000
seconds (= 365 * 86,400) for all years except leap years, when the duration
was 31,622,400 (=31,536,000 + 86,400) for 366 days.  In the second part,
Date1 = Jan 1, 1997 and Date2, which was equal to Date1 plus 18 years of
31,536,000 seconds per year + 4 leap days, equaled Jan 1, 2015.

But we know that the duration in seconds of 1997, 1998, 2005, 2008, and 2012
was actually 31,536,001 seconds because each of these years had a leap
second added.  So, why does it work?

Java, at least, is pretty upfront about why it works.  Java describes
ZonedDateTime (and its various cousins Instant, LocalDateTime, and
OffsetDateTime) as implementing a proleptic calendar, where in this case
proleptic means what the data and time would have been in times past if they
had been using our calendar system.  In addition, the Java documentation
implies that the new date/time classes (ZonedDateTime, Instant,
LocalDateTime, and OffsetDateTime) cannot be used for astronomical
calculations.  Why?  Because they won't be correct.  Jan 1, 2015 minus 18
years of 31,536,000 seconds per year - 4 leap days * 86,400 seconds will not
produce the time a computer would have indicated on Jan 1, 1997; instead,
there will be 5 seconds difference for the 5 leap seconds introduced in that
interval.

Oracle's justification for their approach is:

"Given the complexity of accurate timekeeping ..., (the) Java API defines
its own time-scale, the Java Time-Scale. 

"The Java Time-Scale divides each calendar day into exactly 86400
subdivisions, known as seconds. These seconds may differ from the SI second.
It closely matches the de facto international civil time scale, the
definition of which changes from time to time. 

"The Java Time-Scale has slightly different definitions for different
segments of the time-line, each based on the consensus international time
scale that is used as the basis for civil time. Whenever the
internationally-agreed time scale is modified or replaced, a new segment of
the Java Time-Scale must be defined for it. Each segment must meet these
requirements: 

."the Java Time-Scale shall closely match the underlying international civil
time scale;
."the Java Time-Scale shall exactly match the international civil time scale
at noon each day;
."the Java Time-Scale shall have a precisely-defined relationship to the
international civil time scale." (Source: Oracle documentation for the
java.time.Instant class.)

In other words, the only aspect of time that matters to Java is that the
clock, in the present, be perfectly accurate each day at noon.  Thus the
time Java displays and uses will be accurate, and up to spec, if and only if
the user's clock is accurate.

BTW, proleptic can be defined as:

The representation or assumption of a future (past?) act or development as
if presently existing or accomplished.
(http://www.merriam-webster.com/dictionary/prolepsis, parentheses added)

Proleptic calendar, a calendar that is applied to dates before its
introduction. (http://en.wikipedia.org/wiki/Proleptic)

Hope this helps.

Charles Elliott

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

Re: [ntp:questions] Nice fanless high-perf NTP server: Fitlet!

[Charles Elliott]

"Never tell a person he is wrong ..."
Carnegie, Dale (1981). How to Win Friends & Influence People. New
York, Pocket Books  (Simon & Shuster).

Note the word influence in the book title.  If one want to make this a
better world, then one wants influence, not a reputation for being
impossible to get along with.

Charles Elliott

> -Original Message-
> From: questions-bounces+elliott.ch=comcast@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On
> Behalf Of Rob
> Sent: Friday, January 16, 2015 3:52 AM
> To: questions@lists.ntp.org
> Subject: Re: [ntp:questions] Nice fanless high-perf NTP server: Fitlet!
> 
> Paul  wrote:
> > On Thu, Jan 15, 2015 at 4:40 PM, Terje Mathisen
> 
> > wrote:
> >
> >> Not in my msg, but in the subject of the entire thread. :-)
> >
> >
> > I'm so used to nomail@example being wrong I had a knee-jerk reaction.
> My
> > bad.
> 
> You just can't stand being pointed at errors.  When I point at an
> error, you are already in the "I presume he is wrong" mode and do are
> no longer able to think rationally.
> 
> ___
> 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] Red Hat vote for chrony

[Charles Elliott]

> Variable speed fans are available now and motherboards support them.
> Tachometer outputs have been around for a long time, and because fans
> use brushless "DC" motors (i.e. synchronous motors with electronics to
> generate the AC) they all have to have rotational phase detectors
> (although it may be done by monitoring the coil current, rather than a
> separate sensor).  Heavy use of these tends to be associated with
> "quiet
> PCs", so the BIOS may well be set for minimal cooling, rather than
> keeping a low temperature.

The biggest problem, IMHO, is that as soon as Windows boots up the fan 
speed goes to 1/2 to 1/4 of its previous speed, and Windows has no control, 
that I know of, to alter that behavior.  Fans are cheap now.  I set the 
BIOS for max fan speed and disable automatic control.

This is a real issue for people who run SETI@Home. Since all of
S@H's applications are heavily optimized, they use all the CPUs, 
all of the logic therein, all the time, and throw off huge numbers 
of BTUs.

Charles Elliott

> -Original Message-
> From: questions-bounces+elliott.ch=comcast@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On
> Behalf Of David Woolley
> Sent: Tuesday, December 9, 2014 3:09 AM
> To: questions@lists.ntp.org
> Subject: Re: [ntp:questions] Red Hat vote for chrony
> 
> On 09/12/14 07:06, Charles Swiger wrote:
> > Yes, I also find it a bit surprising than modern desktop CPUs and
> GPUs
> > are willing to run right up to their thermal trip points of ~80 C or
> so
> > rather than bump up fan speed a little more to keep them more around
> 50 C.
> 
> Cost engineering, for what is a throwaway product with a fashion life
> of
> less than 3 years.  Also,
> >
> > Older systems tended to use more aggressive cooling, especially
> laptops.
> >
> > Well, smarter firmware and Hall effect sensors to measure fan speed
> means
> > you can spin the fans more slowly than if you needed to apply 40%
> minimum
> > speed just to be sure that the fan would spin up from idle.
> 
> Variable speed fans are available now and motherboards support them.
> Tachometer outputs have been around for a long time, and because fans
> use brushless "DC" motors (i.e. synchronous motors with electronics to
> generate the AC) they all have to have rotational phase detectors
> (although it may be done by monitoring the coil current, rather than a
> separate sensor).  Heavy use of these tends to be associated with
> "quiet
> PCs", so the BIOS may well be set for minimal cooling, rather than
> keeping a low temperature.
> 
> ___
> 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

[ntp:questions] Raspberry Pi

[Charles Elliott]

Newegg.com is selling a
<http://www.newegg.com/Product/Product.aspx?Item=N82E16813142003&utm_medium=
Email&utm_source=IGNEFL112714&nm_mc=EMC-IGNEFL112714&cm_mmc=EMC-IGNEFL112714
-_-EMC-112714-Index-_-EmbeddedSolutions-_-13142003-S1A2B> Raspberry Pi B+
Broadcom SoC ARM11 700 MHz Low Power ARM1176JZFS Applications Processor
Motherboard/CPU/VGA Combo for $29.99 + $0.99 shipping today (Thanksgiving)
only.

 

Charles Elliott

 

 

 

http://promotions.newegg.com/NEemail/Nov-0-2014/Thanksgiving-Sale-blkdeals-e
blast-27/index-landing.html?utm_medium=Email
<http://promotions.newegg.com/NEemail/Nov-0-2014/Thanksgiving-Sale-blkdeals-
eblast-27/index-landing.html?utm_medium=Email&utm_source=IGNEFL112714&nm_mc=
EMC-IGNEFL112714&cm_mmc=EMC-IGNEFL112714-_-EMC-112714-Index-_-E0-_-PromoWord
&et_cid=13405&et_rid=9430498&et_p1=>
&utm_source=IGNEFL112714&nm_mc=EMC-IGNEFL112714&cm_mmc=EMC-IGNEFL112714-_-EM
C-112714-Index-_-E0-_-PromoWord&et_cid=13405&et_rid=9430498&et_p1=

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

[ntp:questions] Does an IPV6 address work with NTPD?

[Charles Elliott]

The U.S. Government (NIST) has a new time server (time-d.nist.gov) 

whose address is 2610:20:6F15:15::27.  When I put that address into 

ntp.conf the Meinberg Time Server Monitor indicates "Unknown clock 

type" in the Type column and Reach remains 000.  However, when 

2610:20:6F15:15::27 is pinged the return is "General failure".   

(Dr.) Judah Levine, Time and Frequency Division, NIST Boulder, says 

2610:20:6F15:15::27 works as far as he can tell.  So, do IPV6 addresses 

result in anything useful when used in NTPD?

 

 

Charles Elliott

 

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

Re: [ntp:questions] ntp and anycast

[Charles Elliott]

I respectfully do not agree that anycast is useless.

I have used, not anycast, but multicast on my home (gigabit) LAN
quite successfully.  One server only on the LAN sees the time
from  external NTP servers. The other 3, 4, etc. ntp clients,
which only existed to process SETI@Home work units, accessed their
time from that server using multicast.  The time differences between
the clients were very small, but I can't supply a firm number, since
I have switched to using FreeNAS as the time server connected to 
external ntp servers, and I have not had time to figure out how to
make FreeNAS's NTP do multicast.  In any case, the offsets and jitters
of the ntp clients on the LAN were also extremely small.  The Gigabit
Ethernet
LAN was/is very lightly loaded, and it is not connected to the Internet.


If anyone else tries this, I would urge them to read the reviews of
Gigabit switches first.  There are real differences in the switching
speeds of these devices, and you may see these differences reflected 
in ntp delay statistics (when in unicast mode).

Charles Elliott

> -Original Message-
> From: questions-bounces+elliott.ch=comcast@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On
> Behalf Of Rob
> Sent: Friday, October 31, 2014 3:17 PM
> To: questions@lists.ntp.org
> Subject: Re: [ntp:questions] ntp and anycast
> 
> Markus Moeller  wrote:
> > Hi,
> >
> > What do I need to consider when using an anycast IP for a NTP
> servers ?
> > If I remember right a client should have at least 3 better 4 ntp
> servers
> > configured to identify the best sources, but if you use anycast IP
> for a
> > server the client would have only one server configured, so how would
> the
> > client find out any drift, bad time source ?
> >
> > Thank you
> > Markus
> 
> When you use anycast, you probably don't worry about that.
> Anycast is good for "get an approxmate time" in environments that are
> more like SNTP than NTP.  E.g. to set the time of a home router.
> 
> For keeping accurate time and using the kernel phase locked loop,
> anycast is worthless.
> 
> ___
> 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 server not reducing polling interval on upstream hosts

[Charles Elliott]

Could ntp.org outsource the work with Mechanical Turk or at 
one of the volunteer social networking sites, whose names
I don't know; I have just read exist.

> -Original Message-
> From: questions-bounces+elliott.ch=comcast@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On
> Behalf Of Rob
> Sent: Thursday, October 23, 2014 12:43 PM
> To: questions@lists.ntp.org
> Subject: Re: [ntp:questions] NTP server not reducing polling interval
> on upstream hosts
> 
> Harlan Stenn  wrote:
> > Please email me the bug numbers.
> >
> > We don't have nearly enough volunteers to get the work done.
> >
> > This is why I frequently solicit volunteer help as well as financial
> > support.  If we get enough financial support I can start hiring
> > developers.
> 
> I think it is unrealistic to get enough money from donations to hire
> professional developers.  You may get enough money to buy some hardware
> to facilitate development, or to pay hosting or hardware for a website
> or source archive, etc.  When I would donate money it would be like
> $50,
> that would be insignificant when compared to a professional developer
> tariff.
> 
> ___
> 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 on CubieBoard

[Charles Elliott]

I don't understand this paragraph at all:

>The correct quality measure is jitter, rather than offset.  offset 
>varies from sample to sample but still doesn't tell you the systematic 
>error in the time.

>From Mills, D., et al., (2010) RFC 5906: Network Time Protocol Version 4: 
Protocol and Algorithms Specification, Internet Engineering Task Force
(IETF),
P. 8:
"The NTP performance model
   includes four statistics that are updated each time a client makes a
   measurement with a server.  The offset (theta) represents the
   maximum-likelihood time offset of the server clock relative to the
   system clock.  The delay (delta) represents the round-trip delay
   between the client and server.  The dispersion (epsilon) represents
   the maximum error inherent in the measurement.  It increases at a
   rate equal to the maximum disciplined system clock frequency
   tolerance (PHI), typically 15 ppm.  The jitter (psi) is defined as
   the root-mean-square (RMS) average of the most recent offset
   differences, and it represents the nominal error in estimating the
   offset."

In other words, offset is defined an estimator of the difference between 
the server clock (or a consensus of several server clocks if NTPD 
believes it is in synchronization) and the client clock.
Jitter is an estimate of error in computing the offset.

Do you have any quarrel with those two statements?


"The four most recent timestamps, T1 through T4, are used to compute
   the offset of B relative to A

   theta = T(B) - T(A) = 1/2 * [(T2-T1) + (T3-T4)]

   and the round-trip delay

   delta = T(ABA) = (T4-T1) - (T3-T2)."  (Mills, et al, RFC 5905)

where T1 is the departure time of the NTP packet measured on the client
computer
  T2 is the packet arrival time measured on the server
  T3 is the packet departure time measured on the server
  T4 is the packet arrival time measured on the client computer.

Since ultimately system offset is a weighted average of offsets in times
between
the client and server computers, how could it be anything but an estimate of
the
time difference between the client computer time and UTC standard time?


On my system, there are two sources of systematic error in the time.
When the load is shed at 11:00 PM the delay immediately declines from
about 0.23 ms to about 0.19 ms.  From 11:00 PM to about 5:00 AM, the
frequency offset changes from about -52.3 ppm to about -54.4 ppm, and
then rises slowly to about -52.3 by 10:00 AM, whereupon it
seems to vary randomly between -52.55 and -51.9 ppm until about 11:00 PM.
These values were read from NTP_Plotter displays.

Do you know of any other sources of systematic error in NTPD's computation
of time? 


Charles Elliott

> -Original Message-
> From: questions-bounces+elliott.ch=comcast@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On
> Behalf Of David Woolley
> Sent: Monday, October 13, 2014 5:52 AM
> To: questions@lists.ntp.org
> Subject: Re: [ntp:questions] NTP on CubieBoard
> 
> On 13/10/14 09:23, Rob wrote:
> > On the PC platform, with a recent development ntpd I can achieve
> > PPS sync with offset within a couple of us on systems in normal
> > environment, and well within 1us in a temperature conditioned room.
> 
> The correct quality measure is jitter, rather than offset.  offset
> varies from sample to sample but still doesn't tell you the systematic
> error in the time.
> 
> ___
> 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?

[Charles Elliott]

>>>Really accurate time requires a physical machine
>>> and another operating system than Windows.

NUTS!  I regularly see sub-microsecond offsets; right now offset is 0.080
and jitter is 0.031.

I have 28.xx Mbps Internet service and use Gigabit Ethernet LAN.  I am also
using version 4.2.7p467 of NTPD and Windows 8.  I connect to a mixture of 9
stratum 1 and 2 external NTP servers that are physically close to me.  I
also use the HPET as the QPC via the following

run cmd as admin and paste "bcdedit /set {current} useplatformclock Yes".

Also all computers on the LAN are double-homed, with GB Ethernet for data
exchange between computers and NTPD and Fast Ethernet for the Internet
connection.  I use 
minpoll 4 maxpoll 5.

It is true that the NTP client that connects to the external NTPD servers is
on
a machine that runs FreeNAS, which in turn runs on FreeBSD.  The Windows 8
machine 
gets its time from that machine. 

Charles Elliott

> -Original Message-
> From: questions-bounces+elliott.ch=comcast@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On
> Behalf Of Phil W Lee
> Sent: Tuesday, September 16, 2014 4:30 PM
> To: questions@lists.ntp.org
> Subject: Re: [ntp:questions] no drift-file on 2008 R2 vps and the time
> diff. is getting bigger and bigger?
> 
> Rob  considered 14 Sep 2014 11:35:54 GMT the
> perfect time to write:
> 
> >gooly  wrote:
> >>> When you want to sync it yourself, ntpd is not required at all,
> Windows
> >>> can do this itself.  Lookup the documentation for the windows time
> >>> service, you can configure it to use an external NTP server.
> >> I know! But w32tm is started to resync every x seconds. So it can
> happen
> >> that  w32tm changes the time while I am logging which will disable a
> >> later time-sort!
> >
> >In the later versions of Windows including 2008 R2 it is possible to
> >use a "real NTP" mode instead of the SNTP that was used before.
> >I think it should try to lock on the reference instead of jumping all
> >the time.  But it does a poorer job than ntpd.
> >However, when the clock in the system is so bad as you describe, both
> >of these programs will fail to lock it.
> >
> >>> It is not very accurate, but when you require really accurate time
> >>> a VPS is not for you.  Really accurate time requires a physical
> machine
> >>> and another operating system than Windows.
> >> But I can insist to require a clock with an offset less than 1
> second
> >> per hour or per 2 hours - no?
> >
> >Well, I see that Windows virtual machines in the hands of poor
> operators
> >have difficulty to be within 2 seconds all the time.  However, that is
> >two seconds overall, not per 2 hours.
> >Microsoft considers this "good enough" because they use time only for
> >kerberos, not for real timing work.
> >
> >Don't believe stories that it will never work on a VM.  I know I can
> >keep a Linux VM within 20ms all the time and within 2-5ms most of the
> >time.  However, Linux is not Windows and not all VMs are configured
> >reasonably.
> 
> It's certainly possible to run accurate tome on a VM, if the VM is
> running on a host which makes some reasonable attempt to keep good
> time in the first place.
> I run FreeBSD, Linux, and several versions of windows in this way -
> but I control the host they run on, and it keeps pretty good time.
> If the host machine is badly configured and outside the control of the
> VM operator, there is little that the operator of a VM running on it
> can do to resolve the situation.
> Except change providers.
> Of course, losing customers may just encourage the vendor to configure
> ntp properly on his host machines.
> 
> ___
> 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?

[Charles Elliott]

>>>Really accurate time requires a physical machine
>>> and another operating system than Windows.

NUTS!  I regularly see sub-microsecond offsets; right now offset is 0.080
and jitter is 0.031.

I have 28.xx Mbps Internet service and use Gigabit Ethernet LAN.  I am also
using version 4.2.7p467 of NTPD and Windows 8.  I connect to a mixture of 9
stratum 1 and 2 external NTP servers that are physically close to me.  I
also use the HPET as the QPC via the following

run cmd as admin and paste "bcdedit /set {current} useplatformclock Yes".

Charles Elliott

> -Original Message-
> From: questions-bounces+elliott.ch=comcast@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On
> Behalf Of Phil W Lee
> Sent: Tuesday, September 16, 2014 4:30 PM
> To: questions@lists.ntp.org
> Subject: Re: [ntp:questions] no drift-file on 2008 R2 vps and the time
> diff. is getting bigger and bigger?
> 
> Rob  considered 14 Sep 2014 11:35:54 GMT the
> perfect time to write:
> 
> >gooly  wrote:
> >>> When you want to sync it yourself, ntpd is not required at all,
> Windows
> >>> can do this itself.  Lookup the documentation for the windows time
> >>> service, you can configure it to use an external NTP server.
> >> I know! But w32tm is started to resync every x seconds. So it can
> happen
> >> that  w32tm changes the time while I am logging which will disable a
> >> later time-sort!
> >
> >In the later versions of Windows including 2008 R2 it is possible to
> >use a "real NTP" mode instead of the SNTP that was used before.
> >I think it should try to lock on the reference instead of jumping all
> >the time.  But it does a poorer job than ntpd.
> >However, when the clock in the system is so bad as you describe, both
> >of these programs will fail to lock it.
> >
> >>> It is not very accurate, but when you require really accurate time
> >>> a VPS is not for you.  Really accurate time requires a physical
> machine
> >>> and another operating system than Windows.
> >> But I can insist to require a clock with an offset less than 1
> second
> >> per hour or per 2 hours - no?
> >
> >Well, I see that Windows virtual machines in the hands of poor
> operators
> >have difficulty to be within 2 seconds all the time.  However, that is
> >two seconds overall, not per 2 hours.
> >Microsoft considers this "good enough" because they use time only for
> >kerberos, not for real timing work.
> >
> >Don't believe stories that it will never work on a VM.  I know I can
> >keep a Linux VM within 20ms all the time and within 2-5ms most of the
> >time.  However, Linux is not Windows and not all VMs are configured
> >reasonably.
> 
> It's certainly possible to run accurate tome on a VM, if the VM is
> running on a host which makes some reasonable attempt to keep good
> time in the first place.
> I run FreeBSD, Linux, and several versions of windows in this way -
> but I control the host they run on, and it keeps pretty good time.
> If the host machine is badly configured and outside the control of the
> VM operator, there is little that the operator of a VM running on it
> can do to resolve the situation.
> Except change providers.
> Of course, losing customers may just encourage the vendor to configure
> ntp properly on his host machines.
> 
> ___
> 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?

[Charles Elliott]

The offset may be a function of distance.
Try this experiment:

Set up your ntp.conf file to have three servers (all examples assume you
are located in Eastern USA):
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 (e.g., 
ntp.melancthon.net)
3.  A relatively unused stratum 1 or 2 server more than 2,000 miles away
(e.g., ntp1.tp.pl, ntp2.tp.pl, time.coi.pw.edu.pl, ntp.certum.pl).

On my computer, the offset is proportional to distance:

Remote Refid StratumTypeWhenPoll
Reach  Delay  OffsetJitter
BR-350P GPS 0  Local clock  7   16
017 0.000-17.6532.345
FreeNAStime-c.nist.gov  2  Unicast server   16  16
017 0.238  0.0080.037
nist1-pa.ustiming.org ACTS  1  Unicast server   15  16
017 28.844   0.135  3.158
2a01:1102:0:b::2ATOM1  Unicast server   16
16  017 120.732 -5.145  2.151
2a01:1100:1::2  ATOM1  Unicast server   15  16
017 128.756 -3.931  4.635
213.222.200.99  PPS   1Unicast server   13  16
017 110.727 -0.968  4.119
ntp.coi.pw.edu.pl  OCX0   1Unicast server   14
16  017 122.100 -4.253  0.584
serenity.melancthon.net india.colorado.edu 2 Unicast server 35  32
003 53.520   2.019  3.556

Charles Elliott

> -Original Message-
> From: questions-bounces+elliott.ch=comcast@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On
> Behalf Of mike cook
> Sent: Thursday, September 11, 2014 2:08 PM
> To: Questions List
> Subject: Re: [ntp:questions] Compensating for asymmetric delay on a
> per-peer/server basis?
> 
> 
> Le 11 sept. 2014 à 18:48, Rob a écrit :
> 
> > Paul  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

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

[Charles Elliott]

You can do it in broadcast mode, but I am not sure it works,
or has even been tried on a WAN.  Broadcast mode was solid
as a rock on my LAN for more than a year, especially after 
I started using GB Ethernet.

I don't use broadcast mode now after switching to using FreeNAS
as a time server, it addition to its other duties.  

Charles Elliott

> -Original Message-
> From: questions-bounces+elliott.ch=comcast@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On
> Behalf Of Rob
> Sent: Wednesday, September 10, 2014 3:34 AM
> To: questions@lists.ntp.org
> Subject: Re: [ntp:questions] Compensating for asymmetric delay on a
> per-peer/server basis?
> 
> Rich Wales  wrote:
> > Replying to "Rob":
> >
> >> Yes, you can use:  fudge 1.2.3.4 time1 -0.002  or similar.
> >> see the manual.
> >
> > This didn't work.  And the following error message appeared in my
> syslog:
> >
> > inappropriate address 10.0.229.163 for the fudge command,
> > line ignored
> >
> > As best I can tell from the online manual, the "fudge" command is
> > defined only for local reference clocks and has no effect on peers or
> > servers.
> 
> Ok you are right.  In fact I filed bug #2598 myself for a similar
> situation...   In my case I wanted to compensate for the delay
> asymmetry
> for external users using my GPS reference via my ADSL line.  So I would
> like to apply such a fudge command to a network interface, not to a
> peer server.
> 
> I forgot that it is not even possible to apply it to a server, what you
> would like to do.  I think the only thing you can do is apply an offset
> to your GPS and live with the fact that you are always 2ms off.  At
> least then you don't have a time wander when you switch to your backup
> and the external users of your system get the correct time.  That is
> what I did as a workaround until someone fixes this in ntpd.
> 
> ___
> 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] Questions from people whose return address is gmail, googlemail, Yahoo, etc.

[Charles Elliott]

It is not a prank, and I am not sure why the message came 
thru as double spaced.

I use Outlook, 2007.  William Unruh constantly complains that
the long message lines transmitted by Outlook are not easily
read in Linux-based email clients.  So I edited the message
to produce narrow lines by inserting carriage returns.  
Perhaps the result was the double 
spacing.  However, that is the first time I have seen that
result.  Unruh, whose return address is un...@invalid.ca,
which does not accept email, complained anyway.  To Hell
with him.

While my examples were not particularly realistic, my point was
that I object to giving out detailed, highly technical, information
to people who we cannot identify, particularly if it is security 
related.

I used to work for a company that manufactures real time
computer control systems for the electrical power generation
industry.  The current president of that company's successor
is one of my PhD advisors.  The only justification for a 
computer in a power Station is that it greatly increases safety.  
AFAIK, there has never been a major disaster in a power plant 
controlled by a real time computer system.

Time is very important to electric power generating stations
because of the equipment damage that can result from connecting
a tie line to an electrical generator if the two are not in
electrical synchronization, i.e., in phase with each other.

Some electric power companies, such as Hurricane Electric,
also serve up time via NTPD.

Therefore, as a safety measure, I don't want to help people
we cannot identify to understand the inner workings of NTPD,
particularly its security features.  Is it too much to ask
that NTP questions list users give identifiable email 
return addresses so we can find out where they are located
and who they represent?

Charles Elliott


> -Original Message-
> From: questions-bounces+elliott.ch=comcast@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On
> Behalf Of Paul
> Sent: Sunday, September 7, 2014 12:09 PM
> To: questions@lists.ntp.org
> Subject: Re: [ntp:questions] Questions from people whose return address
> is gmail, googlemail, Yahoo, etc.
> 
> On Sat, Sep 6, 2014 at 8:21 AM, Charles Elliott
>  wrote:
> > Some day, is it going to be important to ISIS to have accurate time
> to
> > coordinate a massive strike on the electric, railroad, or bridge
> > infrastructure in some Western country?
> 
> To charles.elliott...@comcast.net, assuming this isn't a troll, no.
> 
> However despite the previously expressed somewhat fringe views from
> elliott.ch@verizon and elliott.ch@comcast the message at hand seems
> odd.  E.g. why is it the only message I've seen (admittedly a quick
> look) that is double spaced and from charles.elliott...@comcast.net?
> The concepts and proposals are so completely absurd that I suspect a
> prank.
> ___
> 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

[ntp:questions] Questions from people whose return address is gmail, googlemail, Yahoo, etc.

[Charles Elliott]

Hello:

 

  The questions@lists.ntp.org mail list server receives some of

the most detailed, highly technical, arcane, time-consuming-to-answer, 

and security-related questions from people whose return address is gmail.com

and other, essentially anonymizing, email addresses.  For example, early

this past summer, the list received mail from a young man who claimed to 

be in London and working on a project somehow associated with Princeton 

University, which is located in the State of New Jersey in the United 

States, and needing incredibly accurate time for some reason.  The 

domain name of his return address was gamil.com.  Doesn't that 

strike you as being somewhat improbable?  Is this the 

same man who recently narrated the beheading of two American 

Journalists in the Middle East?  How do you know it is not?

ISIS members have become incredibly adroit in using social 

Media Websites for their purposes, even thoughtfully giving the

parents of their beheading victims several days advance notice

of their son's demise.  Some day, is it going to be important to

ISIS to have accurate time to coordinate a massive strike on

the electric, railroad, or bridge infrastructure in some

Western country?  Are list members going to facilitate that?

 

Another example was the person, allegedly from South Africa, who was asking

detailed, technical, and arcane questions about NTP whose return email

address was neither in the whois database nor pingable.

 

  I propose that in the short term NTP questions list members not
respond to

inquires from people whose return address is a bulk email provider, and in
the long

run the NTP list server be made to reject email from bulk providers, such as
Google,

Yahoo, and Microsoft, and from domains that are not in the whois database or
that

do not respond to pings.

 

Charles Elliott

316 E Cambria St

Philadelphia, PA 19134-3324

(215) 425-5222

 

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

[ntp:questions] Why does NTPD precision decline when using the HPET ves. the Performance Counter?

[Charles Elliott]

When the platform clock is changed from the 
performance counter (freq: 3.554 MHz) to the
HPET (freq: 14.318 MHz) the NTP protocol
precision declines from -22 to -20.  This
occurs both in versions 4.2.7p442@1.2483-o May 09 10:14:35.18
and 4.2.7p467@1.2483-o Aug 28 12:01:29.42.  
The NTPD_USE_INTERP_DANGEROUS=1 environment 
variable is set.  Here are the relevant messages from 
the Event Log:

8/23/2014 3:34:59 PM ntpd 4.2.7p442@1.2483-o May 09 10:14:35.18 (UTC-04:00)
2014  (1): Starting   
8/23/2014 3:34:59 PM Command line: G:\Program Files (x86)\NTP\bin\ntpd.exe
-U 3 -M -g -c G:\NTP_Conf\ntp.conf   
8/23/2014 3:34:59 PM Raised to realtime priority class   
8/23/2014 3:34:59 PM Clock interrupt period 15.625 msec (startup slew -0.7
usec/period)   
8/23/2014 3:34:59 PM Performance counter frequency 3.554 MHz
8/23/2014 3:34:59 PM proto: precision = 0.200 usec (-22)   
8/23/2014 3:34:59 PM proto: fuzz beneath 0.100 usec   


8/23/2014 3:52:37 PM ntpd 4.2.7p442@1.2483-o May 09 10:14:35.18 (UTC-04:00)
2014  (1): Starting   
8/23/2014 3:52:37 PM Command line: G:\Program Files (x86)\NTP\bin\ntpd.exe
-U 3 -M -g -c G:\NTP_Conf\ntp.conf   
8/23/2014 3:52:37 PM Raised to realtime priority class   
8/23/2014 3:52:37 PM Clock interrupt period 15.625 msec   
8/23/2014 3:52:37 PM Performance counter frequency 14.318 MHz   
8/23/2014 3:52:38 PM proto: precision = 0.800 usec (-20)   
→ → No "proto: fuzz beneath ... " message ← ←

9/4/2014 5:57:34 AM ntpd 4.2.7p467@1.2483-o Aug 28 12:01:29.42 (UTC+01:00)
2014  (1): Starting   
Repeats exact same sequence as on 8/23/2014 3:52:37 PM

Is this the way it should be, that the protocol precision
declines when the clock is more than 4 times faster?

Charles Elliott

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

Re: [ntp:questions] ntp-4.2.6p5 on Win 7 x64

[Charles Elliott]

If the reach is not 377, have you used WireShark or another TCP/IP
monitoring program to find out what is happening to the NTP packets?  It is
not all hard to use.

> -Original Message-
> From: questions-bounces+elliott.ch=comcast@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On
> Behalf Of Nick
> Sent: Thursday, July 17, 2014 1:08 PM
> To: questions@lists.ntp.org
> Subject: Re: [ntp:questions] ntp-4.2.6p5 on Win 7 x64
> 
> Brian
> 
> thank you for your reply.
> 
> Please see comments below.
> 
> Nick
> 
> On Wed, 16 Jul 2014 05:32:59 +, Brian Inglis wrote:
> 
> > It is easier to change the registry to have Windows manage the
> hardware
> > clock in UTC, and necessary when you dual boot with Unix; you can
> then
> > use any timezone setting you prefer in regional settings and the
> > hardware clock will stick on UTC.
> 
> I did the tz change to the registry, and confirm that it works.  But it
> made no difference to the original problem i.e.
> 
> >> Restarting the service 'fixes' it for a few minutes, then it all
> begins
> >> to 'diverge' again.
> >>
> 
> > NTP requires system time to stay within 128ms of UTC (except at
> startup
> > if you use the -g (panicgate) option, otherwise it steps the system
> > clock to correct it. Ensure you have iburst on all your pool or
> server
> > lines in ntp.conf.
> 
> Understood.  The RTC on the motherboard is capable of this because ntpd
> works well under Mint 17 on the same machine.
> 
> > Wait until all reach values show 377 and check the system status with
> > ntpq -c rv, which should show something like (taken from a leap
> second
> > example on the web, leap is normally 00):
> 
> Reach never gets anywhere near 377...
> 
> C:\Users\nick>ntpq -pn
>  remote   refid  st t when poll reach   delay   offset
> jitter
> ===
> ===
> +83.170.75.28129.215.42.240   3 u   22   64   17   29.272  1678.03
> 502.466
> +91.212.90.20212.83.131.333 u   26   64   17   33.001  2234.68
> 866.070
> +94.125.129.7195.66.241.102 u   29   64   17   29.231  2096.80
> 754.306
> *87.117.251.3129.215.42.240   3 u   35   647   30.169  2057.24
> 721.950
> 
> C:\Users\nick>ntpq -c rv
> associd=0 status=c613 leap_alarm, sync_ntp, 1 event, spike_detect,
> version="ntpd 4.2.7p450@1.2483-o Jul 17 7:20:46.78 (UTC+01:00) 2014
> (1)",
> processor="x86", system="Windows", leap=11, stratum=4, precision=-10,
> rootdelay=40.347, rootdisp=2373.606, refid=87.117.251.3,
> reftime=d7725e20.9a026670  Thu, Jul 17 2014 15:37:20.601,
> clock=d7725e90.71d4a9d9  Thu, Jul 17 2014 15:39:12.444, peer=21225,
> tc=6,
> mintc=3, offset=0.00, frequency=441.549, sys_jitter=333.000556,
> clk_jitter=0.977, clk_wander=0.210
> 
> 
> > If the precision estimate is -10 (MM timer frequency), restart
> Windows
> > as ntpd will never be able to sync, and just restarting ntp service
> does
> > not seem to help.
> 
> Starts off OK but soon diverges again.
> 
> > When the frequency stops changing in one direction, and starts
> > oscillating, which may take hours on Windows, depending on your
> hardware
> > clock drift rate and network jitter, you have your clock drift rate
> and
> > your offset should be about as close as it will get to UTC, normally
> > single or low double digits, about 10ms.
> 
> My old XP box with the Meinberg release on it shows offsets of < 10ms
> in
> 15 minutes or so.
> 
> > You can improve the consistency of your time by pinning/setting
> affinity
> > on the ntpd process to your last (highest numbered and least used)
> > processor if you have moe than one core.
> > You can do this on Windows in Task manager, by showing all processes,
> > right click on ntpd, choose Set Affinity, and select the bottom check
> > box; you can automate this with a PowerShell script run at startup,
> > those run after services like ntpd are started.
> 
> Good idea, but there's something else going on here that needs to be
> fixed first.  Are there any issues running a 32 bit executable on Win 7
> x64 in your experience?
> 
> ___
> 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 on Win 7 x64

[Charles Elliott]

> This performance is marginal for WSJTX.  I need 10ms offset or less after
> 15 minutes.

One more time, this is what I have done to achieve sub-millisecond
accuracy (currently 0.092 offset and 0.033 jitter):

Make sure you are using a recent version of NTPD; I am using ntpd
4.27p442, May 09, 10:14:35.18 (UTC -04:00) 2014 that I downloaded from
http://archive.ntp.org/ntp4/ntp-dev/ntp-dev-4.2.7p446.tar.gz, compiled with
Visual Studio Express 2013, and copied to C:\Program Files (x86)\NTP\bin,
after renaming the old bin directory.  Although compiling NTPD yourself is
not that hard it does take some experience; Harlan Stenn  may
have a pre-compiled for Windows version; consider asking.

Enable HPET: run cmd as admin and paste "bcdedit /set {current}
useplatformclock Yes"; some people complain that the cost of reading the
HPET periodically outweighs its benefits, but I have not seen that.

Put NTPD_USE_INTERP_DANGEROUS=1 in your system environment
variables.

Do not use the pool servers!  They are mostly junk, are not well
attended and maintained, and in my experience their time is often
unacceptably variable.  Find stratum 1 and 2 (preferable) servers that are
geographically close to you (~ 50 - 75 miles), that provide consistent
offsets, and that are lightly loaded.

Use iburst minpoll 4 maxpoll 5; in my area, I was never able achieve
fast synchronization and quick recovery from Internet congestion with
maxpoll 64.

Use 5 to 9 external servers; weed out the ones that rarely make the
cut, but keep the number that are used up around 5.

If the computers on your LAN must be consistent, then consider
Gigabyte Ethernet on the LAN.  Gigabyte Ethernet will work over good quality
Cat 5 cable, so all you may need is a new router.

The faster your connection to the Internet, the less variable the
time you serve will be.  15 to 28 Mbps works well here.

Please use a working email address.  It takes a long time to write
this stuff, only to have the email returned as undeliverable.

Charles Elliott

> -Original Message-
> From: questions-bounces+elliott.ch=comcast@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On
> Behalf Of Nick
> Sent: Friday, July 18, 2014 4:09 PM
> To: questions@lists.ntp.org
> Subject: Re: [ntp:questions] ntp-4.2.6p5 on Win 7 x64
> 
> Brian
> 
> thanks for your useful reply...
> 
> On Fri, 18 Jul 2014 02:03:48 +, Brian Inglis wrote:
> 
> > Windows is using the MM timer as its high precision time source, not
> PM
> > timer, HPET or TSC.
> 
> Yes.  I found the entry in the application log.  I checked the old XP
> box
> where ntp works well and that's using the MM timer.
> 
> > This is always my sign that ntpd offset will diverge, and requires a
> > system restart, or more.
> 
> > Also when leap=11 that is the alarm state that says there are issues.
> 
> Does leap=11 mean the server is not sync'd?
> 
> > Wait until reach is 377 on all sources and check again for leap=00.
> 
> I removed the -M from the service executable command and rebooted.
> 
> After 15 minutes I got this
> 
> C:\Users\nick>ntpq -pn
>  remote   refid  st t when poll reach   delay   offset
> jitter
> ===
> ===
> -143.210.16.201  158.43.192.662 u   33   64  377   32.491  181.643
> 121.179
> +85.119.80.233   110.116.250.33   3 u   29   64  377   29.461   59.626
> 88.079
> +176.74.25.228   193.47.164.283 u   21   64  377   30.159   91.825
> 72.384
> +176.74.25.227   193.11.166.8 2 u   32   64  377   30.065   20.692
> 117.706
> +5.39.184.5  87.195.109.207   3 u   26   64  377   37.018   -3.686
> 138.898
>  94.228.220.14   .INIT.  16 u-   6400.0000.000
> 0.000
> *130.88.212.143  193.62.22.90 2 u   36   64  377   37.078   62.566
> 93.284
> 
> C:\Users\nick>ntpq -c rv
> associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
> version="ntpd 4.2.7p450@1.2483-o Jul 17 7:20:46.78 (UTC+01:00) 2014
> (1)",
> processor="x86", system="Windows", leap=00, stratum=3, precision=-22,
> rootdelay=46.020, rootdisp=139.381, refid=130.88.212.143,
> reftime=d773f6dd.29fb24ea  Fri, Jul 18 2014 20:41:17.163,
> clock=d773f753.cf14ee36  Fri, Jul 18 2014 20:43:15.808, peer=40459,
> tc=6,
> mintc=3, offset=67.250982, frequency=431.145, sys_jitter=54.722048,
> clk_jitter=36.149, clk_wander=0.139
> 
> ntp.conf...
> 
> restrict default nomodify notrap nopeer noquery
> restrict 127.0.0.1
> restrict -6 ::1
> driftfile "C:\Tools (x86)\NTP\etc\ntp.drift"
> server 0.uk.pool.ntp.org iburst  minpoll 6

Re: [ntp:questions] About use of PPS in NTP sync

[Charles Elliott]

Hello:

  

  I built a NAS out of an older model, but new, Super Micro mobo ($140),
an older model Intel CPU ($15), good ECC memory ($100), and FreeNAS built on
FreeBSD.  The NAS only uses about 40 Watts, so it is not expensive to run.
As luck would have it, FreeNAS came with NTPD built in.

 

  The NAS usually runs all the time.  So when I turn on the other
computers in the morning, they generally sync up with the NAS in under a
minute.  This is the configuration line in ntp.conf:

 

server 192.168.1.1 iburst minpoll 4 maxpoll 5 prefer

 

The offset (time difference) between my computers and the NAS is usually
only a few microseconds, although now, for some reason, the offset between
this computer and the NAS is 0.145 secs.  Likewise the jitter is usually
low, something on the order of 0.0XX or less (currently 0.030).

 

The key to achieving reasonably good and stable time readings out of NTPD is
a fast Internet connection (currently 29 Mbs from Comcast), use of Gigabyte
Ethernet on the LAN, and finding  and attaching to 5-9 close-by (< 100
miles) stratum 1 or 2 NTP servers that are uncongested.  (Every word of that
last phrase is critical.  I gathered several weeks of peerstats and
loopstats statistics from NTPD for several weeks and plotted them with
NTP_Plotter before I found several sufficiently stable and consistent
servers.  Avoid the NTP pool servers.)

 

It is possible to distribute more accurate and stable time using a local GPS
device, either home built (e.g.,
http://www.satsignal.eu/raspberry-pi/index.html) or purchased (e.g.,
http://www.meinberg-usa.com/products/network-time-server.htm), but the
original cost is greater and/or can take a long time to get working
satisfactorily.  

 

Charles Elliott

 

> -Original Message-

> From: questions-bounces+elliott.ch=comcast@lists.ntp.org

> [mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On

> Behalf Of jthul...@gmail.com

> Sent: Sunday, June 15, 2014 11:30 PM

> To: questions@lists.ntp.org

> Subject: [ntp:questions] About use of PPS in NTP sync

> 

> Hello,

> I'm looking for a way to speed up the ntp convergence of a system which

> would be restarted after several days being off. Does the use of PPS

> improve this convergence time ?

> This is local configuration, with one LAN and one NTP server, with

> about 30 NTP clients.

> 

> Thank you.

> JT

> 

> ___

> 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] Can NTP sync within 1ms

[Charles Elliott]

  I use Windows 8.1 and regularly see offsets of less than 1 ms.  

Right now the offset is -0.105 and the jitter is 0.028.  Twas not 

always thus; several factors contributed to these results:

 

1. Use of Gigabyte Ethernet on the LAN, and the LAN is lightly loaded.  

 

2. A high speed Internet connection; either 15 Mbps or about 28 

   Mbps will improve accuracy because the delays between your 

   LAN timer server and the Internet time servers are more consistent 

   and more than halved WRT to a 1-3 Mbps connection.

 

3.  The NTP client and LAN server is on a computer that runs FreeNAS, 

which is lightly loaded.  FreeNAS runs on FreeBSD.  Anecdotally, 

NTPD serves more accurate time on FreeBSD.

 

4. The ISP router to which you are connected really matters.  

   If that router is congested so that delays through it vary by time 

   of day, or increase greatly every time a neighbor downloads a movie 

   or other long file, then you will serve widely varying time to the LAN.

 

5. The Internet Stratum 2 or 1 time servers you choose should be close-by 

   (50-75 miles) and lightly loaded.  If your LAN time server accesses 

   time from a heavily loaded network and/or server, or the servers are 

   more than 50-75 miles away, there is little hope of serving time with

   low jitter.  You can find a list of U.S. Government time servers and 

   their status by searching for "NIST time servers," and of course 

   there is a complete list of servers on www.ntp.org.

 

 

Charles Elliott

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

Re: [ntp:questions] Has anyone thought about this?

[Charles Elliott]

Ntpd on my system uses a frequency offset (according to NTP Plotter, 
thank you very much) of -26 to -28 ppm fairly consistently.  If I 
understand it correctly, that corresponds to a correction of 26 to 
28 microseconds on every clock tick.  Is there any way that measuring 
t4p = PC(t4) - PC(t1) is not going to be more accurate, given that 
the PC driven by the HPET has a resolution of ~70 ns, than 
t1 = system time and t4 = system time? 

It would be easy to test.  Just record the PC value when p_org (= t1) 
is set, and record the PC again when p_rec (= t4) is saved.  Then 
send the difference between the new PC values (as t4p, say) to the 
rawstats log at the end of the line.  It would only take a few hours 
to see if t4 <> t4p.

My new DIY NAS has ntpd running on FreeBSD.  It keeps pretty good time.  
I recorded the ping time (pinging constantly for 5 minutes) from the 
NAS to two computers here.  Below is a table of average ping times and 
delay as computed by ntpd:

Avg.
pingntpd
Computertimedelay
1 0.264681 0.236   ms  (Win 7, Core i7 3820, GA-X79-UD3 (rev 0) mobo, 
Gigabit Ethernet)
2 0.337169 0.321   ms  (win 8, Core i7 3820, GA-X79-UD3 (rev 1) mobo, 
Gigabit Ethernet)

Note that they are different.

Charles Elliott

-Original Message-
From: questions-bounces+elliott.ch=verizon@lists.ntp.org 
[mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On Behalf Of 
Terje Mathisen
Sent: Thursday, April 10, 2014 10:21 AM
To: questions@lists.ntp.org
Subject: Re: [ntp:questions] Has anyone thought about this?

Brian Utterback wrote:
> On 4/10/2014 3:22 AM, Terje Mathisen wrote:
>>
>> The maximum ntpd slew is   500 ppm, which means that the absolute 
>> maximum possible slew between UTC and the local clock would be 1000 
>> ppm (i.e. the clock is maximally bad, at +500 ppm, and we are 
>> currently slewing at -500 ppm), in which case the maximum error 
>> component from this would be 1/1000th of the actual time delta. (In 
>> real operating systems the actual errors are several orders of 
>> magnitude less! Typical clock frequency adjustments due to 
>> temperature cycling are in the single ppm range, but even a few tens 
>> of ppm gives relative errors in the 1e-4 to 1e-5 range, which doesn't 
>> impact the control loop at all.
>
> I am pretty sure that the   500 ppm is absolute and is already the sum 
> of the frequency correction and the current clock slewing. But one of

Oh sure, that is why I wrote that this is the theoretical maximum possible, 
with real-life servers being at least an order of magnitude better behaved.

> the reasons for having a maximum in the first place is to put a cap on 
> the error introduced because if the instantaneous frequency 
> corrections taking place at the time the timestamps are taken. This is 
> all covered in chapter 11, Analysis of Errors, in the first edition of 
> Das Buch (Computer Network Time Synchronization, Mills, 2006). I am 
> pretty sure that it is also in the 2nd ed, but I don't have access to that 
> one.

Neither do I, but I am absolutely sure Dr Mills included this error component 
in his stability and convergence calculations. :-)

If you do allow far higher slew rates, like some other programs do, then you 
would indeed have to separate the offset slew from the frequency correction, 
and use the frequency clock only to measure delta-Ts.

The easiest way to do this is of course to keep a sw delta clock around, this 
one would start out the same as the OS clock, but then only include any 
frequency adjustments to its rate, and not any slew adjustments. At this point 
either HPET or RDTSC could be used as the common frequency source for both 
clocks.

Terje

--
- 
"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] Windows: SerialPPS Performance Counter/Processor Cycle Counter offset issue

[Charles Elliott]

FWIW, I found that both my Windows 7 and Windows 8 machines were using 
the RTC to drive the Performance Counter (PC).  On a Windows machine, 
you can tell what counter is driving the PC by looking at the line
"Performance counter frequency X.X MHz" in the Event Log, put 
there by ntpd when it is starting up.  If the X's = 3.516 then I 
believe it is using the RTC, but if the X's are 14.318 MHz, then 
it is using the HPET.  The latter should be more accurate
since it corresponds to a period of ~70 ns, while the former 
has a period of ~284 ns.

In Windows 7 & 8, to make the PC use the HPET, run cmd as admin 
and paste "bcdedit /set {current} useplatformclock Yes".

Charles Elliott

-Original Message-
From: questions-bounces+elliott.ch=verizon@lists.ntp.org
[mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On Behalf Of
James Gibb
Sent: Monday, April 14, 2014 8:21 AM
To: questions@lists.ntp.org
Subject: [ntp:questions] Windows: SerialPPS Performance Counter/Processor
Cycle Counter offset issue

I've found that an offset can be introduced when using SerialPPS on Windows
XP/2003.  Unless --usepcc is specified, NTPD will likely add an offset to
the PPS timestamps caused by the difference between times worked out within
NTPD and externally, i.e. the timestamping of the DCD events in the
SerialPPS.sys driver.  I've submitted a bug for this, 2599.  I'd be
interested to know if other Windows systems suffer the same problem.
___
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

[ntp:questions] Has anyone thought about this?

[Charles Elliott]

In ntp_proto.c the delay and offset are computed as follows:

t34 = t3 - t4;

t21 - t2 - t1;

p_del = t21 - t34;

offset = (t21 - t3)/2.;

 

where t1 = client send time

   t2 = server receive time

   t3 = server send time

   t4 = client receive time.

 

However, t1 and t4 are not really in seconds if the client clock is slewing.
That is, the 

difference t4 - t1 will be shorter than seconds if the clock is being slowed
down

and larger if the clock is being sped up.  Hence the clock slew may be a
source of 

variation that is not presently being accounted for.

 

One some systems the frequency of the Performance Counter (PC) is constant

because it is driven by the High Performance Event Timer (HPET).  And 

according to one article on the Internet, the PC can be made to be driven

by the HPET on Win 8 by this edit: " run cmd as admin and paste 

'bcdedit /set {current} useplatformclock Yes'".

 

Would NTPD have less variation in offset and delay if, say, t4 were measured

by the difference in PC readings between the time t1 is measured and the

time T4 is presently measured?

 

Charles Elliott

 

 

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

Re: [ntp:questions] Asymmetric Delay and NTP

[Charles Elliott]

>The basic approach is to express each packet flight in a one-line equation
(a row) in a linear-system >matrix equation, where the system matrix (the A
in the traditional y=Ax+b formulation, where b is zero in >the absence of
noise), where A is 4 columns wide by a variable number of rows long (one row
to a packet >flight), and show that one column of A can always be computed
from the two other columns that describe who >is added and subtracted from
who.  In other words, these three columns are linearly dependent on one
>another.  The forth column contains measured data.

What are the columns of your A matrix, and why do you assume they are
linearly related?

My point is that y=Ax+b can be solved even if it is rank-deficient, and the
solution may even be unique.  See
http://en.wikipedia.org/w/index.php?title=Moore%E2%80%93Penrose_pseudoinvers
e&oldid=600094895, the section entitled "Obtaining all solutions of a linear
system."

Have you considered what might happen if some entity, such as the US Naval
Observatory, broadcast the time every second, on the second. Obviously, this
would eliminate the asymmetrical delay problem.  (It is known that time
distribution on a LAN can be made substantially more accurate by
broadcasting the time from a local server, in lieu of waiting for clients to
ask for it.  Broadcast mode works well on a LAN, and there is a special IP
address for it, as there may also be for time broadcast over the Internet.
It is in the NTP RFC.)

Other factors you might consider is that every second has a name, and
seconds have constant time apart.  The first second this year was named Jan.
1, 2014 00:00:01, then a second later came second named Jan. 1, 2014
00:00:02, etc.  Since the distance between the Naval Observatory and any
given receiver is constant (as long as the receiver is not mobile), and the
speed of light (s) is constant, let the distance between the Observatory and
the receiver (dist) be measured in light-seconds.  Then every packet
received from the Observatory is essentially just a repeated measure of Jan.
1, 2014 00:00:01 since every second afterwards is related to that one by an
integral multiple.  Let d = the time received by the receiver minus the name
of the second broadcast by the Observatory.  Then let d^ be the mean of all
the d's received so far.  d^ is related to the physical distance (dist) by
some constant factor a since the speed of light and the physical distance
between the receiver and the Observatory are constant.  Hence, isn't a*d^ +
the name of the second broadcast by the Observatory the best estimate of the
correct time the packet was received, and d^ - d an estimate of the flight
time error?

What I am trying to say here is IF you could get the government to broadcast
the time over the Internet (and that is a big IF since all routers may not
propagate NTP broadcasts) then could you not use the fact that the seconds
are a constant second apart to get rid of a lot of the uncertainty in your
equation y=Ax+b?

Charles Elliott




-Original Message-
From: questions-bounces+elliott.ch=verizon@lists.ntp.org
[mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On Behalf Of
Joe Gwinn
Sent: Friday, March 21, 2014 12:04 PM
To: questions@lists.ntp.org
Subject: Re: [ntp:questions] Asymmetric Delay and NTP

Magnus,

In article <532b5ab9.4070...@rubidium.dyndns.org>, Magnus Danielson
 wrote:

> Joe,
> 
> On 19/03/14 11:55, Joe Gwinn wrote:
> > In article <5328aaa6.70...@rubidium.dyndns.org>, Magnus Danielson 
> >  wrote:
> >
> >> On 18/03/14 01:36, Joe Gwinn wrote:
> >>> In article <5327757e.5040...@rubidium.dyndns.org>, Magnus 
> >>> Danielson  wrote:
> >>>
> >>>> Is that formal enough for you?
> >>>
> >>> It may be.  This I did know, and would seem to suffice, but I 
> >>> recall a triumphant comment from Dr. Mills in one of his documentation
pieces.
> >>> Which I cannot recall well enough to find.  It may be the above 
> >>> analysis that was being referred to, or something else.
> >>
> >> I can't recall. The above I came up with myself some 10 years ago or
so.
> >
> >
> > When I awoke the day after writing the above, I saw two problems 
> > with the above analysis.
> >
> > First is that with added message-exchange volleys, one does not get 
> > added variables and equations, one instead gets repeats of the 
> > equations one already has.  If there is no noise, the added volleys 
> > convey no new information.  If there is noise, multiple volleys 
> > allows one to average random noise out.
> 
> True. What does happen over time is:
> 1) Clocks drift away from each other due to systematics and noises
> 2) The path delay shifts, sometimes becaus

Re: [ntp:questions] NIST wonders if it makes sense to outsource NTP over the public Internet

[Charles Elliott]

The ustiming.org NTP server in NYC was consistently wrong for a long time; 
I have not looked at it lately.  If the government is going to privatize 
serving time, then it has to exercise more effective oversight.

The other side of the coin is, where is the money in serving time?
The management of private, stockholder-owned corporations has a 
legal obligation to protect and try to enhance stockholder wealth.
The legal measure of that obligation is the internal rate of return
on invested assets.  It follows that in most corporations, managers
are rated on, and promoted according to, their contributions to profit.

But time servers cost money to run, maintain, monitor for accuracy, and
provide Internet access to.  How does management satisfy its legal
obligation to wring a return from those computer assets and ongoing
expenses?

Perhaps ntp.org could contribute here:
Could/should every NTP packet have room for an optional message such as,
"This time brought to you by Cheerioes."
Could/should NTPD post a message box every so often saying something like,
"This time brought to you by US Steel -- the best in bridge girders."
Could/should some way be found to charge NTP time users one mil per packet,
say?
My point is that corporate management is legally required to be able to 
point to an increase in an asset as a result of the costs of serving time. 
That asset could be good public relations or the development
of a reputation for public service, but even that is tricky as some
corporate
gadfly might stand up in the annual meeting and ask, legitimately, why are
we
spending thousands of dollars (Euros, shekels, etc.) to send out the time of
day when the XYZ division is operating with 20-year-old equipment and losing
tens of thousands of dollars (Euros, shekels, etc.) every month?

If the government is going to pay for the distribution of accurate time,
then
there has to be  a showing of public benefit, which, of course, there is in
the 
increased accuracy and uniformity of the timing of transactions.  But then
one 
more time the rich are being asked to pay for something everyone benefits
from, 
which in the US right now is not going over well.

Charles Elliott


-Original Message-
From: questions-bounces+elliott.ch=verizon@lists.ntp.org
[mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On Behalf Of
E-Mail Sent to this address will be added to the BlackLists
Sent: Wednesday, March 19, 2014 3:21 PM
To: questions@lists.ntp.org
Subject: Re: [ntp:questions] NIST wonders if it makes sense to outsource NTP
over the public Internet

Paul wrote:
> https://www.fbo.gov/index?s=opportunity&mode=form&id=4f5c8b176af03d89a
> bb1a318624c944b
> SUMMARY: National Institute of Standards and Technology  (NIST), 
> Department of Commerce, seeks information from  the public on NIST's 
> potential transition of time services  from a NIST-only service to 
> private sector operation of  an ensemble of time servers that will 
> provide NIST-traceable  time information in a number of different 
> formats over the  public Internet.


Certichron (Time-Evidence Services) via
  (USTS) The United States Time Server Foundation
  is already doing that?
 They are already a significant portion of the NIST NTP servers;
  They operate Eleven out of Thirty Four (Thirty Two Percent).
   <http://tf.nist.gov/tf-cgi/servers.cgi>

 They have Commercial Private Access NTP servers / services as well.


--
E-Mail Sent to this address 
  will be added to the BlackLists.

___
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] Atom PPS with parallel port

[Charles Elliott]

Several years ago, I was asked to evaluate the Real Time O/S that Intel was
offering 
for sale as a project in an electrical engineering course.  Interrupt
latencies and
servicing times are very important in real time control, so I evaluated the
parallel port.  As I recall, I output a signal to one pin on the parallel
port and then
sent out a digital output to a point where I could measure it with an
oscilloscope after
receipt of the interrupt in my test program.  I used the oscilloscope to
measure
the time from the first signal to its recognition by my program.  I don't
remember
the exact results, but I do remember that the latencies were highly
variable.
Intel subsequently sold the real time O/S, and I have not seen it for sale
since.

Charles Elliott





-Original Message-
From: questions-bounces+elliott.ch=verizon@lists.ntp.org
[mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On Behalf Of
Rob
Sent: Sunday, February 23, 2014 12:36 PM
To: questions@lists.ntp.org
Subject: Re: [ntp:questions] Atom PPS with parallel port

David Lord  wrote:
> Rob wrote:
>> I would like to use the Atom driver (22) on a Linux system with a 
>> parallel port.  It is not clear to me from the scattered info I have 
>> found on internet if this is going to work.
>> 
>> Using a modern Linux kernel with the PPS module, is it possible to 
>> symlink /dev/pps0 to a parallel port device and then connect the PPS 
>> signal to the ACK input (pin 10)?
>> 
>> If not, what else is required to get this working?
>> 
>> Examples always refer to the use of a serial port DCD input, but for 
>> best accuracy (in the microsecond range) I think the parallel port is 
>> better.
>> (no RS232 drivers/receivers, no funny UART that may delay interrupts)
>> 
>> Any other suggestions for an accurate PPS input?
>
> On NetBSD with stock ntpd, pre 2010, I did comparisons of pps from 
> Sure GPS with output from dcd at ttl level vs the "serial" dcd but 
> didn't really see any consistent difference.

Did you try the parallel port?
I am interested not only in jitter but also in any constant offset between
the PPS pulses and system time on different systems (possibly using
different makes of serial card).  4-6 us would be good enough for my
purpose, but it would not be good when one system had a 10us offset because
of a propagation delay in a linedriver/receiver.

___
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 NMEA driver

[Charles Elliott]

The config file should have this format

server 127.127.20.1 mode 65 minpoll 4 maxpoll 4 prefer
fudge 127.127.20.1 time2 0.363352  
fudge 127.127.20.1 flag4 0


Charles Elliott
-Original Message-
From: questions-bounces+elliott.ch=verizon@lists.ntp.org
[mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On Behalf Of
rajputaja...@gmail.com
Sent: Thursday, February 6, 2014 4:58 AM
To: questions@lists.ntp.org
Subject: Re: [ntp:questions] NTP NMEA driver

Dear Sir,

I am trying to synchronize AM335x processor based linux 3.2 with Motorola
GPS receiver using its Serial based NMEA frame and 1pps signal. I have
connected nmea frame to ttyO1 port. I am using buildroot based filesystem
for NTP configuration. NTP version used is 4.2.6p5. 

I have configured ntp.conf file for nmea driver 20 for nmea and 1pps
options. (refer:
http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver20.html)

# Ajay - for nmea driver 20
server 127.127.20.0 mode 0 minpoll 4 maxpoll 4 prefer fudge 127.127.20.0
flag1 1 flag2 0 flag3 1 time2 0.500.

time2 is set to 0.600 since delay between 1pps signal rising edge and end of
nmea frame is approx 500ms.

i am issuing below command for nmea driver 20 before starting ntp service:
 
ldattach pps /dev/ttyO1.

[   94.658905] pps_core: source OMAP-SERIAL1 got cdev (253:0)
[   94.658935] pps pps0: new PPS source OMAP-SERIAL1
[   94.663787] pps pps0: source "/dev/ttyO1" added



Also, while kernel booted it already had registered pps for kernel line
discopline as per below message:
[0.181427] pps_core: LinuxPPS API ver. 1 registered
[0.181427] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo
Giometti 


ln -s /dev/ttyO1 /dev/gps0 (for linking ttyO1 to /dev/gps0 for nmea driver
20) (as per http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver20.html)
and
ln -s /dev/pps0 /dev/gpspps0 (for linking pps0 to /dev/gpspps0 for nmea
driver 20) (as per
http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver20.html)

Now, when i start the ntp service, i get below output for ntpq -p command:


 remote   refid  st t when poll reach   delay   offset
jitter

==
*GPS_NMEA(0) .GPS.0 l4   16  3770.000  4526.86
1269.17

Problem: Though i have configured my ntp.conf file for nmea and 1pps both
(using flag1 1), i do not see any entry for PPS in ntpq -p command.
if kernel has registered pps0 as pps source, why there is not PPS entry. I
have connected pps signal of 3.3v level to my dcd pin of ttyO1.

Also, the offset in NMEA output continously increases insteed of reducing.

Thanks & Regards,
Ajay

___
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 request retry?

[Charles Elliott]

Discussion:

It is definitely, definitely true that offset (error) is highly 
correlated with the distance between the client and the server.  For 
a time, one of the stratum 2 servers in the USA State of New Jersey 
was using a server at a technical university in Poland as a source of
time.  When the New Jersey server was connected to a server in New
York (maybe 20-25 miles away), its time output was in sync with 
everyone else's, but when it was connected to the one in Poland,
its time was ~30 ms slower than everyone else's.  Perhaps the time
it took the New Jersey server to warm up its local DNS (or ARP???) 
to  access the IP address of the Poland server accounts for this
error.  Nothing or no one else has been able to account for it.
And I have checked the formulas for delay and offset in the RFC
and in the implementation in NTPD dozens of times and can find 
no error (as long as the server and the client are relatively
close (within a few years) to each other in time).

On that same note, NTPD could rid itself of all those bit-twiddling
macros to compute time differences by recognizing that 32-bit
arithmetic is with us now and unsigned 64-bit arithmetic is built
in to most modern compilers.  In addition, Microsoft's Visual Studio
Express, I believe, sets the rounding mode of the FPU to convert
everything to 63 bits of significant, whereas the default rounding
mode of the FPU is to compute everything with the original bits of
the arguments and then to round off to the value closest to the 
exact result.  Therefore, it might be possible to pick up a bit or
two of precision by setting the rounding mode of the FPU to its
default before converting from NTP timestamp format to doubles.
I am not sure if the FPU rounding mode is preserved between context
switches or not, but if it is, then the rounding mode of the FPU
could be set in NTPD initialization code and forgotten elsewhere.


C Elliott

-Original Message-
From: questions-bounces+elliott.ch=verizon@lists.ntp.org
[mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On Behalf Of
Harlan Stenn
Sent: Monday, January 27, 2014 7:55 PM
To: Brian Utterback
Cc: questions@lists.ntp.org
Subject: Re: [ntp:questions] NTP request retry?

Brian Utterback writes:
> On the other hand, I have definitely observed that phenomenon as a 
> source of asymmetric round trip time. The outgoing request packet gets 
> delayed for ARP request and reply at each hop, but the return packet 
> has no such delay. Quite a while ago I suggested a special burst mode 
> where two packets were sent, one shortly after the other and the first 
> one would be ignored. Dr. Mills said that the first would generally be 
> ignored because of the longer round trip time (delay), but I thought 
> that treating the first packet as a throw away would be better because 
> otherwise you end up with half the number of "good" samples in the 
> billboard. Anyway, nothing every came of the discussion.

I'm game to see this discussion warmed up.

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] NTP request retry?

[Charles Elliott]

The only way that NTPD works well is to find 4 to 9 stratum 2 servers 
near your location by searching the server lists at www.ntp.org.
Then observe the servers over a few days so that none of the ones you 
pick have highly variable transit times.  
Then set your clients facing external servers to minpoll 4 maxpoll 5.
There is no way on earth that NTPD can detect and compensate for
intermittent transit delays, which are endemic to the Internet, by
sampling every 2^10 = 1024 seconds = 17 minutes, 4 seconds.  Shannon's
or Nyquist's, whichever, law applies here as everywhere.
Then within your own LAN use broadcast mode.  That will give you
much lower offset and jitter readings because delay times are
not considered, as they should be non-existent.
If you can, use Gigabit Ethernet on your LAN.  You will then see
transit times with ping go from >1 ms to <1 ms.  But the real
advantage is that the temporal gap between packets on Gb Ethernet
is much (~10X) larger than on fast Ethernet, so the exponential back-off
algorithm rarely kicks in, virtually eliminating variable delays.

The doomsayers on this list will tell you that minpoll 4 maxpoll 5 is
abuse and cite the tragedy of the commons. They have a point, but not
a valid one.  It is true that the fact that everyone and his brother 
insists on using the stratum 1 servers has ruined them as a source of time,
especially the government's servers.  But so far, the stratum 2 servers are
not stressed.  And the rules (I don't remember where I read them)
specifically
say that 16 seconds between packets are OK for short bursts, and that 32
seconds between packets are OK anytime.

C Elliott

-Original Message-
From: questions-bounces+elliott.ch=verizon@lists.ntp.org
[mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On Behalf Of
Rob
Sent: Monday, January 27, 2014 4:45 PM
To: questions@lists.ntp.org
Subject: Re: [ntp:questions] NTP request retry?

Rick Jones  wrote:
> Brian Inglis  wrote:
>
>> You don't specify which system and devices you are using, so here are 
>> a couple of articles about changing ARP timeouts:
>> http://www.embeddedsystemtesting.com/2013/01/arp-timeout-value-for-li
>> nux-windows.html
>> http://support.microsoft.com/kb/949589
>
> And if indeed these are all the OP's own systems, he can add 
> hardwired, "permanent" ARP cache entries via the arp command (under 
> most *nixes at least).

I'm still not sure if ARP is really the problem, but fixing the clients to
maxpoll 6 seems to cure it.
(at least the reach now sticks at 377)

> If a mix of wired and wireless is involved, if there is some way to 
> get traces at the point where the two join that would be goodness.

If both would be WiFi, I would point at the WiFi.  However, one is connected
to the wired network (a switch where the server is connected as well).

I can ping it as much as I like, no loss:
1571 packets transmitted, 1571 received, 0% packet loss, time 20468ms rtt
min/avg/max/mdev = 0.702/0.845/1.168/0.090 ms

But when ntpd is allowed to climb to 1024-second polls, it gets almost no
replies.

___
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 request retry?

[Charles Elliott]

Have you considered the possibility that the computer has an "energy saver"
NIC, 
and NTPD activity is insufficient to wake it?

C Elliott

-Original Message-
From: questions-bounces+elliott.ch=verizon@lists.ntp.org
[mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On Behalf Of
Rob
Sent: Monday, January 27, 2014 1:11 PM
To: questions@lists.ntp.org
Subject: Re: [ntp:questions] NTP request retry?

Marco Marongiu  wrote:
> On 01/26/2014 08:08 PM, Rob wrote:
>> My hypothesis is that the ARP entry for the NTP server has timed out, 
>> and when ARP has to resolve an entry in some implementations the 
>> first packet is always lost (it is not cached pending a reply).
>> When the cycle is 1024 seconds, the ARP entry has again timed out the 
>> next poll cycle and the issue is the same.
>
> If you believe that it is the problem, and you own the servers you're 
> polling, then you may set maxpoll so that the polling interval is 
> always smaller then the ARP cache timeout.

Despite lots of tracing I still cannot really pinpoint the problem.

The only thing I see is that ping has absolutely zero loss and all usual
protocols work fine, but ntp indicates a high loss when there is no other
network activity.

When the network is kept busy, ntp works fine as well.
Very strange.

However, I do not like to "fix" it by increasing frequency, it may not even
help.  I'd like to have some "burst until there is a reply, up to X tries"
option.
It appears to be a function of other NTP clients, but not of ntpd.

___
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] strange ntptrace behaviour on different ntp-clients

[Charles Elliott]

Can you use a packet sniffer, like Wireshark (which only works for 
Windows & Mac OS X 10.5.5), to look at the NTP packets and try 
to determine the reasons you are receiving the response you have?

Charles Elliott

-Original Message-
From: questions-bounces+elliott.ch=verizon@lists.ntp.org
[mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On Behalf Of
Brian Utterback
Sent: Thursday, January 23, 2014 9:04 AM
To: ardi; questions@lists.ntp.org
Subject: Re: [ntp:questions] strange ntptrace behaviour on different
ntp-clients

What version of Solaris were you using? If you were using Solaris 10, then
the ntptrace command is the old version that uses the ref field as the IPv4
address of the server. Since it does not rely on control or private packets
it can work even if "noquery" was specified on one of the servers in the
chain. Since the ref field cannot hold an IPv6 address, the ntptrace program
was changed in NTP version 4 to use control packets to find out the IP
address of each server. This works with both IPv4 and IPv6, but requires all
the servers to allow control packets.

On 1/23/2014 2:52 AM, ardi wrote:
> I have tried to set up 3-level for ntp-setting:
>
> xx.xx.xx.aa stratum 1 server (taking time from GPS)
> ---
> xx.xx.xx.b1
> xx.xx.xx.b2 are stratum 2 servers acting as ntp-servers
> 
> xx.xx.xx.c1
> xx.xx.xx.c2 are stratum 3 ntp-clients
> 
>
>
> NOTE: all clients have stratum 2 servers defined as ntp-server time
sources.
>
> a)
> when doing ntptrace from  a client (without parameter), I am getting 
> Timed out :
>
> NOK:
> client.c1 # ntptrace
> localhost: stratum 3, offset -0.33, synch distance 0.000230
> xx.xx.xx.b1: timed out, nothing received ***Request timed out
> client.c1 #
>
> NOK:
> client.c1 # ntptrace xx.xx.xx.b1 #towards stratum 2 server
> xx.xx.xx.b1: timed out, nothing received ***Request timed out
>
> OK:
> client.c1 # ntptrace xx.xx.xx.aa #stratum 1 ntp-server
> aa.dfdsf.sdff.lab: stratum 1, offset -0.02, synch distance 0.00,
refid 'GPS'
> client.c1 #
>
> doing it from another client, which is solaris:
>
> OK:
> bash-3.00# ntptrace
> localhost: stratum 3, offset 0.26, synch distance 0.01694
> xx.xx.xx.b1: stratum 2, offset 0.000160, synch distance 0.00133
> aa.dfdsf.sdff.lab: stratum 1, offset 0.000315, synch distance 0.00021,
refid 'GPS'
> bash-3.00#
>
> NOTE:
> for xx.xx.xx.b1 the first line of ntp.conf is the following:
>
> restrict default noquery nomodify notrap
>
> b)
> when i remove noquery parameter on stratum 2 ntp-server xx.xx.xx.b1 and
restart ntpd:
>
> for xx.xx.xx.b1 the first line of ntp.conf is the following:
>
> restrict default nomodify notrap
>
> then ntptrace from client.c1 is ok
>
> What causes that solaris clients work in both cases and for client.c1 
> only in case, when noquery is removed from stratum 2 server?
>
> Peter
>
> ___
> 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] better rate limiting against amplification attacks?

[Charles Elliott]

I looked up "amplification attack."  Such an attack occurs when an attacker
can send a small UDP packet with a spoofed source address and elicit a many
times larger response sent to the spoofed source.  Doesn't that describe
NTPD almost perfectly, considering what ntpdc and ntpq can do?  But the same
website that defined amplification attack also described the solution: Use
TCP/IP.

Is not that just one more reason to switch ntpd, nptq, and ntpdc from UDP to
TCP for query processing?

Charles Elliott

-Original Message-
From: questions-bounces+elliott.ch=verizon@lists.ntp.org
[mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On Behalf Of
Rob
Sent: Friday, December 27, 2013 11:50 AM
To: questions@lists.ntp.org
Subject: Re: [ntp:questions] better rate limiting against amplification
attacks?

Brian Utterback  wrote:
> On 12/27/2013 5:24 AM, Rob wrote:
>> What is the NTP developers position on implementation of better rate 
>> limiting options in ntpd?
>>
>> There are more and more amplification attacks against ntp servers, 
>> similar to those against open DNS resolvers.  A small packet sent 
>> with a spoofed source address (allowed by a lame ISP) results in a 
>> large reply from ntpd, sent to the victim of the attack.
>>
>> Possible candidates are of course the commands to retrieve the list 
>> of clients (similar to "ntpdc -c monlist") and and the list of 
>> associated servers ("ntpq -p").
>
> In the current code monlist is replaced by mrulist. The mrulist 
> command requires a handshake, so a spoofed address would not be possible.
> However, it might be wise to limit the number of packets sent per 
> exchange. Currently the client sets the number but a man in the middle 
> attack would still be possible. We could set the maximum number of 
> packets sent per return packet to relatively small. The current 
> implementation on the client sets it to 32, but we could allow a 
> maximum of 4 or 8.
>
> Is a peer list really a big problem? It generally doesn't make sense 
> to have much beyond 10 peers. Are there really a lot of servers with a 
> lot of peers?
>
> Brian Utterback

Are you doubting the fact that NTP is used for amplification attacks?
It is a fact...  and many ntp pool members have faced the consequences
already.

I think what has to be discussed is the countermeasures, not the fact.

___
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] better rate limiting against amplification attacks?

[Charles Elliott]

Yeah, but the Meinberg installer for Windows, and the accompanying
documentation including the "Cheat Sheet," sure makes setting up a default
configuration easier.

However, I grant that almost nothing beats reading the NTP documentation,
especially for novices.

Charles Elliott

-Original Message-
From: questions-bounces+elliott.ch=verizon@lists.ntp.org
[mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On Behalf Of
Steve Kostecke
Sent: Friday, December 27, 2013 7:09 PM
To: questions@lists.ntp.org
Subject: Re: [ntp:questions] better rate limiting against amplification
attacks?

On 2013-12-27, detha  wrote:

> A first step would be to have a default configuration where any 
> functionality that can be used for reflection attacks with more than a 
> say
> 2:1 ratio needs to be explicitly enabled, with warnings about this in 
> the sample config file(s).

The NTP Reference Implementation has no default use case. So there is no
"baked-in" sensible default configuration. Some view this as a feature.

--
Steve Kostecke 
NTP Public Services Project - http://support.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] NTP to multiple networks via one interface.

[Charles Elliott]

I don't know much about VMs and nothing about xenserver, so beware of free
advice.  Here are three suggestions off the top of my head.

1. Would it be possible to have NTPD broadcast on both networks, x.x.75.x
and x.x.75.x?

2. Under Windows it appears to be possible to bridge connections on a dual
homed host.  Can xenserver bridge the two networks 75 and 69?

3. In a book on Java and networking the author offered an example of a
"repeater" written in Java.  All the program did, as I recall, was listen on
one interface and retransmit some packets to another interface.  I tried it,
and it worked.  I could try to find that book again, if it would help.

-Original Message-
From: questions-bounces+elliott.ch=verizon@lists.ntp.org
[mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On Behalf Of
sc0tt.v3r...@gmail.com
Sent: Thursday, December 12, 2013 11:09 PM
To: questions@lists.ntp.org
Subject: [ntp:questions] NTP to multiple networks via one interface.

Hi,

We have a xenserver host.  We manage it via an interface on x.x.75.x which
is the only network that is actually plumbed in on the host.  It has other
interfaces but they are virtualised by xen and don't have IP's.

We have several VM's on this host on the same x.x.75.x network so we have
set the xenserver to broadcast ntp (it syncs from network switches) and the
VM's to be broadcast clients .  NTP is working ok in this scenario.

However we've added a new network to xenserver on x.x.69.x but VM's on this
network don't receive the NTP broadcast packets as they don't have an
interface on the x.x.75 network.

Is there any way to get the NTP packets to all VM's without dual homing
either the xenserver or the VM's.

Thanks in advance,

Scott

___
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 not syncing

[Charles Elliott]

You might be able to do better.  In QC an average of a randomly gathered 
sample of a continuous variable is distributed as normal (Gaussian).
If NTPD kept a few more statistics (state), it could measure the freq
and determine if it is outside of 3 standard deviations of the grand
mean of past observations of freq.  If it is outside then gather several
more observations of freq (5 total would be best, but 2 or three might
do) and compute the average.  If that average is outside 3 stdDev of 
the mean, then the probability of that result is so low (< 0.05) that
it could not have happened by chance; something has changed.  NTPD must
use the new average as the current freq and include it in the grand mean,
but the user should be warned that something is awry.  On the other hand,
if the 2 or 3 new observations of the freq are not close to the original,
then just throw away the latter.

Charles Elliott

-Original Message-
From: questions-bounces+elliott.ch=verizon@lists.ntp.org
[mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On Behalf Of
unruh
Sent: Friday, December 6, 2013 3:47 AM
To: questions@lists.ntp.org
Subject: Re: [ntp:questions] NTP not syncing

On 2013-12-06, David Taylor  wrote:
> On 04/12/2013 21:25, Terje Mathisen wrote:
> []
>> It is very common, IF you are running on Linux!
>>
>> The base frequency is recalculated each time you restart, which means 
>> that steps of 100-200 ppm from one reboot to the next can be expected.
>>
>> Terje
>
> I'm surprised to hear of this problem, as I've not been aware of it in 
> years of running FreeBSD systems, and in more than a year of running
> (now) five Raspberry Pi Linux systems.  Perhaps I've been lucky?  As 
> they are mainly experimental PCs, the RPi cards are rebooted more than
most.
>

As I said, I think that in the more recent kernels Linux has fixed this.
Since the RPi is only about 2 years old, its linux is a recent kernel. 


___
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] WinNT Port Performance Counter Stability and Drift

[Charles Elliott]

The result of reading the timestamp counter can vary wildly due to EIST
(speed step technology), turbo modes, and owner overclocking, in addition to
differences in CPUs, as noted.  There is quite a bit about this on the
Internet.  As I recall, most writers recommend not using it, but if one
must, using it only for short interval timing and after repeatedly measuring
the frequency of the counter.  The latter can take quite a bit of time, as
it should be done several times, and for different interval lengths, and
taking the average or median of the results.

Most authors recommend using QueryPerformanceCounter and
QueryPerformanceFreq if it can be determined that these functions are tied
to the High Performance Event Timer (HPET), which they are on most modern
systems.  I believe that code to do this is already in NTPD.  You can tell
this from the messages in the Event Log (on Windows) when NTPD starts up.
NTPD chooses the timer whose frequency is that of the HPET.

Charles Elliott

-Original Message-
From: questions-bounces+elliott.ch=verizon@lists.ntp.org
[mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On Behalf Of
David Taylor
Sent: Friday, November 8, 2013 1:59 AM
To: questions@lists.ntp.org
Subject: Re: [ntp:questions] WinNT Port Performance Counter Stability and
Drift

On 07/11/2013 22:15, Brian Inglis wrote:
>  From the attached extract from my ntp log the current performance
> counter appears to have much higher drift ~25PPM than my hardware clock;
> my own calibration, timings, and loopstats over the last couple of years
> show ~0.9PPM.
>
> A possible reason is that currently when calibrating and using PCC only
> a bare rdtsc instruction is used.
>  From discussions in various places, summarized well in the article
> linked below, rdtsc may be executed out of order, adding jitter.
> These discussions recommend rdtsc be preceded by mfence (as it works on
> all PCs that support rdtsc) to avoid out of order execution during
> calibration loops.
> The calibration also needs to be wired to a single cpu, results from the
> first call to the calibration function discarded to eliminate cache and
> pipeline fill delays, and all results significantly higher than average
> discarded because the hardware can switch into System Management Mode
> BIOS at random, mainly to handle USB devices like mice, keyboards, drives.
> See
> http://lists.freebsd.org/pipermail/freebsd-amd64/2012-July/014756.html,
> links from that, and similar articles on the LKML and MSDN.

Sounds like one for the NTP Bugzilla

   http://bugs.ntp.org/index.cgi

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

[ntp:questions] ntp.conf on FreeBSD

[Charles Elliott]

Hello:



I built a NAS using FreeNAS, which is in turn based on
FreeBSD, which has ntpd installed.  I need to find ntp.conf so I can
configure it for broadcast mode and maybe the GPS, but I cannot find it.
It is not in /etc.

 

Does anyone know where I should expect to find ntp.conf on
FreeBSD?

 

Thanks in advance.

 

Charles Elliott

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

Re: [ntp:questions] Trying to use Dimension 4 time keeper

[Charles Elliott]

> Run the usb port
> >> as fast as possible (high baud rate), and after some observation
> with
> >> the machine connected to the internet as well, determine what the
> usb
> >> data time offset is and subtract it out using the time2 option to
> the
> >> driver.

Also, suppress all the nmea messages except RMC, ZDA, etc., whichever 
ONE message you choose from which to extract the time.  Make that one
message be output every second.  You may want
to do this because it makes sense that the NTPD clock driver would
have lower jitter if it did not have to wade through all the GSV, etc.
messages to get to the one message it uses to access the time.  However, 
there is a paucity of empirical evidence to support this view.  You 
can find the format of the nmea suppression (output rate) messages 
for the SURE board by Searching for "MTK NMEA Packet User Manual"
and for SiRF-based GPS devices by searching for "NMEA Reference
Manual" or for "SiRF NMEA Reference Manual" or by looking for it
on the usglobalsat.com website.  You can also completely control
SiRF-based GPS devices by using the "SiRF Demo, ver. 3.87," which
can also be searched for.  This is a very fine program.
Even better, post a request for
enhancement on the www.ntp.org website that ntp.conf be given
A GPS initialization section, such as 

[begin gps init]
"$PSRF103,02,00,01,01*";  # Last 01 enables checksum 
"$PSRFTXT, WAAS Enable*";
"$PSRFTXT, POS: 1256058 -4729245 4077408*";
"$PSRFTXT CHNL: 20*";
***
[end gps init]

Then in its initialization code NTPD could compute the checksum
and add it and "\n\r" to every message and output it to the GPS
device.

There is already such a request for enhancement (Bug # 2280),
to which you could add your name and prestige. 

Charles Elliott

> -Original Message-
> From: questions-bounces+elliott.ch=verizon@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On
> Behalf Of Richard B. Gilbert
> Sent: Saturday, September 21, 2013 11:54 AM
> To: questions@lists.ntp.org
> Subject: Re: [ntp:questions] Trying to use Dimension 4 time keeper
> 
> On 9/10/2013 9:47 PM, W. eWatson wrote:
> > ...
> >>>>
> >>>>>
> >>>>> I tried Meinberg for quite some time, but it flops fairly often.
> As I
> >>>>
> >>>> flops? What are the symptoms? Also, if time is important why not
> invest
> >>>> in a GPS (35 dolalrs or so) with PPS.
> >>>
> >>> It moves many seconds in a short time, say a day or two. How is GPS
> >>> going to help? Does it provide access via a USB port.
> >>
> >> It-- which noun does that "it" point to?
> >> Sure, you can have gps provide access via a usb port. The Sure GPS
> even
> >> has a usb port on board that you can directly connect to. It is not
> >> great timekeeping but you can probably get it to within .1 sec or
> so.
> >> The main problem is that you cannot use the PPS via a usb
> connection, so
> >> you have to rely on the timing from the nmea sentences. Run the usb
> port
> >> as fast as possible (high baud rate), and after some observation
> with
> >> the machine connected to the internet as well, determine what the
> usb
> >> data time offset is and subtract it out using the time2 option to
> the
> >> driver.
> > It = GPS. What is PPS?
> > ...
> 
> Pulse per second ???
> 
> ___
> 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] which servers should be peers?

[Charles Elliott]

In my experience, s2 servers are less used and hence less congested than 
s1 servers.  But the best advice is that given to carpenters: "Measure
twice; 
cut once."  

1. Find a number (you once wrote 15) of the closest servers to your location
from here (http://support.ntp.org/bin/view/Servers/StratumOneTimeServers)
and 
here (http://support.ntp.org/bin/view/Servers/StratumTwoTimeServers).

2. Set up the ntp.conf file to enable statistics.  The statistics files are 
   documented here (D:\Program Files\NTP\doc\HTML\monopt.html).
   Here are the commands I use:
enable stats
statsdir "X:\NTPStats\"
statistics loopstats peerstats clockstats
filegen peerstats type week
filegen loopstats type week
filegen clockstats type week 

3. Don't fiddle with the system for a week, Sunday thru Saturday.

4. Select some criterion of excellence, such as lowest mean jitter or
   offset.  

5. Using the peerstats file compute your criteria of excellence for
   each external server.

6. The 9 servers with the best showing on your criterion of excellence
   may be the servers to use.

7.  Be aware that things change all the time: servers come and go, shit
happens.

Charles Elliott

> -Original Message-
> From: questions-bounces+elliott.ch=verizon@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On
> Behalf Of Maria Iano
> Sent: Thursday, September 19, 2013 9:04 AM
> To: questions@lists.ntp.org
> Subject: Re: [ntp:questions] which servers should be peers?
> 
> Thank you all for your responses, this has been very helpful. I have an
> additional question now, which is once I have this all set up with the
> S1 and S2 servers, should I then point the clients to only the S2
> servers? Currently they point to our four S1s.
> 
> Thanks,
> Maria
> 
> ___
> 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] which servers should be peers?

[Charles Elliott]

IMHO, you don't want 15 servers; you want 9.  You could start out with 15
and ntpd will mark the ones it finds lacking with a #.  After a few days
you could then whittle the list down to 9 based on the ones most
frequently marked with a #.  I am fairly sure ntpd only uses 9 servers
in its final filtering and smoothing algorithms.

I suggest you pick servers that are close to you.  Accuracy is heavily
influenced by distance, as it the possibility of congestion increasing
jitter.

I would and do use stratum 2 servers.  At least in the U.S., the
stratum 1 servers are so heavily overloaded that at the end of the
day you will have more accurate time with stratum 2.

This is highly controversial, and many on this list will say its
abusive, but I use the iburst keyword and minpoll 4 (16 secs) maxpoll 5 
(32 secs).  Otherwise, when the Internet becomes busy and a wave of
congestion flows thru the system, the higher poll rates greatly slow
ntpd's recovery of accurate time.  For the same reason, I use the
keyword line:

tinker huffpuff 7200

I believe it produces a moderate improvement.

Charles Elliott

> -Original Message-
> From: questions-bounces+elliott.ch=verizon@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On
> Behalf Of Maria Iano
> Sent: Monday, September 16, 2013 11:25 AM
> To: questions@lists.ntp.org
> Subject: [ntp:questions] which servers should be peers?
> 
> I have four data centers all able to communicate both over our internal
> network and over the internet. I have a stratum 1 ntp appliance
> pointing to GPS at each data center; so a total of 4. Each appliance
> has an interface on our internal network and an interface on the
> external internet-routable network. I am getting ready to deploy 12
> physical servers which will act as stratum 2 ntp servers. I'm not
> primarily doing this to spread the load, but to try to cope with a
> worst case scenario in which all of our stratum 1 servers suddenly go
> insane.
> 
> Each data center will have at least one of these stratum 2 servers on
> the internal network and one on the external network. Our internal
> clients will point to the stratum 1 appliances and the internal stratum
> 2 servers, and our external clients will point to the stratum 1
> appliances and external stratum 2 servers.
> 
> From my reading, I believe that each stratum 1 appliance should peer
> with all 15 other servers, both stratum 1 and stratum 2. Is that
> correct? Assuming that is correct, my question is whether I should have
> all of the stratum 2 servers peer with all 15 others as well?
> 
> I appreciate any advice you can give.
> 
> Thanks,
> Maria
> ___
> 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] maxpoll

[Charles Elliott]

What platform are you running on and what version of NTPD are you using?

> -Original Message-
> From: questions-bounces+elliott.ch=verizon@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On
> Behalf Of Michael
> Sent: Wednesday, September 11, 2013 4:53 AM
> To: questions@lists.ntp.org
> Subject: [ntp:questions] maxpoll
> 
> Hi,
> 
> I am syncing to a private stratum 1 server.
> 
> I am using minpoll 6 maxpoll 6
> 
> However after an amount of time ntpq shows the polling interval to be
> 1024.
> 
> Any ideas why the maxpoll parameter is not being obeyed.
> 
> 
> TIA Michael
> 
> ___
> 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] GPS/PPS and "enable calibrate"

[Charles Elliott]

> -Original Message-
> From: questions-bounces+elliott.ch=verizon@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On
> Behalf Of unruh
> Sent: Friday, September 6, 2013 12:23 PM
> To: questions@lists.ntp.org
> Subject: Re: [ntp:questions] GPS/PPS and "enable calibrate"
> 
> On 2013-09-06, Charles Elliott  wrote:
> > Calibrate has not worked for several years, although it is possible
> it is
> > fixed now.  Someone on this list investigated and reported that there
> was
> > just pro forma or "suggestive" code in ntpd as to how it could work.
> >
> > I plotted the data on Windows with the Meinberg "NTP Tome Server
> Monitor,"
> > but it can be done with NTP Plotter (which Google) or a spreadsheet.
> I
> > plotted Offset v. time and computed the average.  Then I adjusted
> time2 and
> > after a day ot two, plotted again and again computed the average.
> Each time
> > I adjusted time2 I did it 1/2 the average offset or 1/2 the average
> time
> 
> Why? Why not just do it the average offset?

Many inexpensive GPS devices exhibit a saw tooth pattern of their offsets
relative to
a known good time source, where the period is less than constant, and the
amplitude 
often is plus or minus 60 ms relative to 0 offset.  According to Dave Hart,
this
saw tooth pattern is inherent in the GPS device itself (the time between fix
and 
time output "wanders") and not caused by NTPD processing.  Regardless of its

cause, until one understands this saw tooth pattern it appears like no time2
adjustment works for any length of time, hence the attempt to sneak up on
it.

One could avoid the ineffective sneaking by recording and plotting the GPS
time offset for at least a week.  Then set time2 to be the average of the
top
and bottom of the saw-toothed wave.  Then GPS time, w/o PPS assist, will be
accurate about twice a day.

I suppose faced with a saw toothed offset with non-constant period and
uncertain 
amplitude relative to known good time, programmers and pundits have paused
in
their efforts to devise a calibrate algorithm that would do much good.


Charles Elliott
> 
> > distance between the consensus time of several (9) external time
> servers and
> > the GPS device time, set to noselect mode.  I was very careful of the
> > algebraic signs of the adjustment; it is not obvious.  Fortunately,
> time2
> > has always been positive for me, probably because the GPS device
> takes time
> > to compute and emit the time after a fix, it is needs a several
> hundred
> > millisecond boost to bring its time up to the present.  I am not sure
> if PPS
> > needs a time2 adjustment.
> 
> It should be within a usec of UTC. If the receiver emits a pulse more
> than 1 us off it is seriously broken. And the interrupt processing
> should not take more than a us or two unless the machine is really
> overloaded.
> 
> 
> >
> > Charles Elliott
> >
> >> -Original Message-
> >> From: questions-bounces+elliott.ch=verizon@lists.ntp.org
> >> [mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On
> >> Behalf Of Horvath Bob-BHORVAT1
> >> Sent: Friday, September 6, 2013 9:20 AM
> >> To: david-tay...@blueyonder.co.uk; questions@lists.ntp.org
> >> Subject: Re: [ntp:questions] GPS/PPS and "enable calibrate"
> >>
> >> Sorry for top posting, but Outlook is quoting things correctly.
> >>
> >> I did check out your site and based my original setup on it.  Lots
> of
> >> impressive stuff there!
> >>
> >> The part I couldn't figure out the fudge time2 values.  Using the
> one
> >> that was pointed out to me by Wolfgang is working very nicely with
> the
> >> other image.
> >>
> >> I am curious how that value is determined.  I am assuming someone
> that
> >> understood it used the calibrate capability to come up with the
> 0.496
> >> number that works for rpi-gpio cases.
> >>
> >> -Original Message-
> >> From: questions-
> bounces+bob.horvath=motorolasolutions@lists.ntp.org
> >> [mailto:questions-
> >> bounces+bob.horvath=motorolasolutions@lists.ntp.org] On Behalf
> Of
> >> David Taylor
> >> Sent: Friday, September 06, 2013 6:10 AM
> >> To: questions@lists.ntp.org
> >> Subject: Re: [ntp:questions] GPS/PPS and "enable calibrate"
> >>
> >> On 05/09/2013 21:00, Horvath Bob-BHORVAT1 wrote:
> >> []
> >> > Hi,
> >> > this runs perfectly for me:
> >> > <http://open.konspyre.org/blog/2012

Re: [ntp:questions] GPS/PPS and "enable calibrate"

[Charles Elliott]

Calibrate has not worked for several years, although it is possible it is
fixed now.  Someone on this list investigated and reported that there was
just pro forma or "suggestive" code in ntpd as to how it could work.

I plotted the data on Windows with the Meinberg "NTP Tome Server Monitor,"
but it can be done with NTP Plotter (which Google) or a spreadsheet.  I
plotted Offset v. time and computed the average.  Then I adjusted time2 and
after a day ot two, plotted again and again computed the average.  Each time
I adjusted time2 I did it 1/2 the average offset or 1/2 the average time
distance between the consensus time of several (9) external time servers and
the GPS device time, set to noselect mode.  I was very careful of the
algebraic signs of the adjustment; it is not obvious.  Fortunately, time2
has always been positive for me, probably because the GPS device takes time
to compute and emit the time after a fix, it is needs a several hundred
millisecond boost to bring its time up to the present.  I am not sure if PPS
needs a time2 adjustment.

Charles Elliott

> -Original Message-
> From: questions-bounces+elliott.ch=verizon@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On
> Behalf Of Horvath Bob-BHORVAT1
> Sent: Friday, September 6, 2013 9:20 AM
> To: david-tay...@blueyonder.co.uk; questions@lists.ntp.org
> Subject: Re: [ntp:questions] GPS/PPS and "enable calibrate"
> 
> Sorry for top posting, but Outlook is quoting things correctly.
> 
> I did check out your site and based my original setup on it.  Lots of
> impressive stuff there!
> 
> The part I couldn't figure out the fudge time2 values.  Using the one
> that was pointed out to me by Wolfgang is working very nicely with the
> other image.
> 
> I am curious how that value is determined.  I am assuming someone that
> understood it used the calibrate capability to come up with the 0.496
> number that works for rpi-gpio cases.
> 
> -Original Message-
> From: questions-bounces+bob.horvath=motorolasolutions@lists.ntp.org
> [mailto:questions-
> bounces+bob.horvath=motorolasolutions@lists.ntp.org] On Behalf Of
> David Taylor
> Sent: Friday, September 06, 2013 6:10 AM
> To: questions@lists.ntp.org
> Subject: Re: [ntp:questions] GPS/PPS and "enable calibrate"
> 
> On 05/09/2013 21:00, Horvath Bob-BHORVAT1 wrote:
> []
> > Hi,
> > this runs perfectly for me:
> > <http://open.konspyre.org/blog/2012/10/18/raspberry-pi-time-server/>.
> >
> > OK, maybe I'll have to try that image.
> >
> > In general though, when it comes to this line...
> >
> >fudge 127.127.20.0 flag1 1 time2 0.496
> >
> > ... how do you know what value to set for time2?
> >
> > Did you got through the instructions here?
> >
> > http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver20.html
> >
> > ... or are you using 0.496 - what is shown on the
> http://open.konspyre.org/blog/2012/10/18/raspberry-pi-time-server/ ?
> >
> >
> >
> > Bob
> 
> No need to change the Kernel,Bob.  There's a program which does /not/
> require you to change the OS - it runs the PPS collection in user-mode
> rather than kernel-mode, and the performance is only a shade worse than
> the kernel-mode version:
> 
> Program:
>http://vanheusden.com/time/rpi_gpio_ntp/
> 
> Using:
>http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html#user-mode
> 
> Performance:
>http://www.satsignal.eu/mrtg/performance_raspi-4.php
> 
> All my Raspberry Pi experiments with different NTP versions and
> different GPS receivers are here:
> 
>http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html
> 
> so I hope you find something of interest 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] Strange jumps in PPM

[Charles Elliott]

Several people on the mail list have suggested that the nmea clock driver
estimate the accuracy of the time reading by the divergence of the indicated
location from the GPS device's true location.  Right now the nmea driver
does not look at the lat/long readings.

You can find an accurate estimate of your true position by averaging the 
lat/long readings in clockstats over several days, if you are using the RMC
sentence.  Enter the average into Google maps and the little arrow should
point
exactly at your location.

Then plot, say, the sum of SQRT( (trueLat - lat(i))^2 + (trueLong -
long(i))^2 )
divided by the number of readings against the GPS clock offset to see if
there 
is any relationship.  This is easily done in Excel or another spreadsheet,
though it would take time.

Another interesting experiment would be to determine if WAAS active or
inactive
makes any difference in the accuracy of the time.

Charles Elliott

> -Original Message-
> From: questions-bounces+elliott.ch=verizon@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On
> Behalf Of E-Mail Sent to this address will be added to the BlackLists
> Sent: Wednesday, August 21, 2013 8:08 PM
> To: questions@lists.ntp.org
> Subject: Re: [ntp:questions] Strange jumps in PPM
> 
> Harlan Stenn wrote:
> > I'd love to see NTP be able to query and use this sort of
> information.
> 
> Several of the NMEA sentences have fix quality,
>  for binary Refclock drivers if the feature exists,
>  there is sure to be packets that include the fix quality.
> 
> I guess we'd have to look at the driver source to see if
>  if make use of any of the fix quality fields.
> 
> Of the messages it appears the NMEA driver supports,
>  GPRMC, GPGGA, GPGLL, GPZDG, PGRMF
>   Have some variety of detail of Fix Quality
> 
>  GPZDA Does NOT have fix quality
> 
>   So the advantage of using _only_ ZDA's compact / short sentence
>to get date & time, is slightly devalued by not getting any
>quality indications?
> 
> 
> If does appear to read and use them, See: parse_qual LEAP_NOTINSYNC
> 
> 
> ...
>   if (pp->leap == LEAP_NOTINSYNC)
>   return PPS_RELATE_NONE; /* clock is insane, no chance */
> ...
>   /* if whole system out-of-sync, do not try to PLL */
>   if (sys_leap == LEAP_NOTINSYNC)
>   return PPS_RELATE_EDGE; /* cannot PLL with atom code */
> ...
>* Grab fields depending on clock string type and possibly wipe
>* sensitive data from the last timecode.
>   switch (sentence) {
>   case NMEA_...:
>   /*Check quality byte, fetch data & time */
>   pp->leap = parse_qual ...
> ...
>   /* check clock sanity; [bug 2143] */
>   if (pp->leap == LEAP_NOTINSYNC) {   /* no good status? */
>   refclock_report(peer, CEVNT_BADREPLY);
>   up->tally.bad++;
> ...
>  * Check sync status
>  * If the character at the data field start matches the tag value,
>  * return LEAP_NOWARNING and LEAP_NOTINSYNC otherwise. If the
> 'inverted'
>  * flag is given, just the opposite value is returned. If there is no
>  * data field (*cp points to the NUL byte) the result is
> LEAP_NOTINSYNC.
> ...
> 
> 
> --
> E-Mail Sent to this address 
>   will be added to the BlackLists.
> 
> ___
> 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] Start of new GPS 1024 week epoch

[Charles Elliott]

> Is SHM supported on Windows?  I know that it /could/ be as the
> mechanisms exist within the OS, but /is/ it?

It is my understanding that it is not; I think I read that in its 
documentation.  I tried it once, but the "receiver" could not find 
an open endpoint.  That does not mean too much though as my Windows 
programming skills have atrophied from meager.

Charles Elliott

> -Original Message-
> From: questions-bounces+elliott.ch=verizon@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On
> Behalf Of David Taylor
> Sent: Tuesday, August 20, 2013 10:49 AM
> To: questions@lists.ntp.org
> Subject: Re: [ntp:questions] Start of new GPS 1024 week epoch
> 
> On 20/08/2013 13:25, Martin Burnicki wrote:
> []
> > There were 2 fields in the SHM segment which were previously unused
> and
> > are now used to take the nanoseconds from the refclock and from the
> > system time.
> >
> > Thus programs like gpsd can now write the nanoseconds in addition to
> the
> > microseconds. If there's an old version of ntpd running then it just
> > evaluates the microseconds, but new versions (ntp-dev for now) check
> if
> > the nanoseconds fields are filled up and use them if this is the
> case.
> >
> > Thus an old ntpd works with a new gpsd, and a new ntpd works with an
> old
> > gpsd. See:
> >
> > Bug 1232 - nanosecond support in SHM driver
> > https://bugs.ntp.org/show_bug.cgi?id=1232
> >
> > Martin
> 
> Is SHM supported on Windows?  I know that it /could/ be as the
> mechanisms exist within the OS, but /is/ it?
> --
> 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] manual change on clock time seems to inhibit ntp service.

[Charles Elliott]

The -g option allows NTPD to take a large time jump on startup, so you 
should be able to restart NTPD and watch it sync the computer to 
external time in a few minutes.  I know of no mechanism that would
allow NTPD to jump 10 minutes without a restart.

Charles Elliott

> -Original Message-
> From: questions-bounces+elliott.ch=verizon@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On
> Behalf Of Sebastien WILLEMIJNS
> Sent: Tuesday, August 20, 2013 3:59 AM
> To: questions@lists.ntp.org
> Subject: [ntp:questions] manual change on clock time seems to inhibit
> ntp service.
> 
> Hello,
> 
> i installed meinberg release on windows 7 with default conf.
> 
> at startup, time is "well clocked" but after 2 minutes i decided to
> change time (10 minutes later or 10 minutes less), poll and when values
> seems to be frozen after this change
> 
> why time isn't now updated  ?
> ___
> 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 -p command query

[Charles Elliott]

If he is using broadcast mode, what earthly difference does it make how
often he 
broadcasts?  After 10:02:25:57 of uptime, on my time server NTPD has only
used 
00:04:25 of CPU time.  A broadcast takes NTPD literally less than a
microsecond, 
and less than a millisecond to reach the clients.  
It broadcasts the time to my home network every 16 seconds. It is also
connected 
to 9 nearby stratum 2 time servers with a minpoll of 4 and a maxpoll of 5 (=
32 
seconds).  Unless this list is it, no one has ever criticized me for
querying a 
time server too frequently.  It is completely unrealistic to query a time
server
every 1024 seconds (poll = 10) and expect accurate time thru a WAN whose
delay 
varies between about 40 ms and about 200 ms continually and unpredictably.
Where
the normal delay is closer to 40 ms, one reading thru a delay of 180 ms can
throw
the time off for hours, given that offset is significantly and negatively
correlated 
with delay.  For example, one of my favorite time servers is
clock02.sctn01.burst.net
(or clock01).  This guy often uses ntp.coi.pw.edu.pl as a time server, which
is
at a technical university in Warsaw, Poland. When he does connect to that
server,
his proffered time is about 17 ms less than the consensus of the other 8
stratum 2
servers.  The same is nearly true when he uses a Microsoft time server
located in
Redmond, WA.  Until and unless Internet congestion abates, and until and
unless
NTPD figures out why delay and offset are highly negatively correlated, a
poll
interval of 32 to 64 seconds is the only way to maintain accurate time, in
my
humble opinion.

Do correct me if I am wrong.

Charles Elliott

> -Original Message-
> From: questions-bounces+elliott.ch=verizon@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On
> Behalf Of unruh
> Sent: Tuesday, July 30, 2013 3:31 PM
> To: questions@lists.ntp.org
> Subject: Re: [ntp:questions] ntpq -p command query
> 
> On 2013-07-30, Biswajit Panigrahi  wrote:
> > Hi,
> >
> > I have configured the ntp server and ntp client on two machine.
> >
> > Both are communicating properly. I would like to test when the
> > connectivity between those two goes down, after how much time the
> > "reach" option in ntpq -p command becomes zero.
> >
> > For that I stopped the ntp server  and I executed the ntpq -p in
> > client's  console,
> >
> > The reach option will still  keep on increase to 377 then gradually
> > decreases to zero. The time duration to come to zero is almost 20
> > minute.
> >
> > Can we reduce the time gap ?
> 
> Why? Why do you care how rapidly the reach option goes to 0?
> ntpd only queries the server occasionally (default is 2^6 (about 1min
> on
> startup and 2^10 (about 20 min) sec after things have stabilized.) Each
> time one of those attempts fails, one bit is lost from the reach, so it
> will go to zero after about 3 hrs. That is the way that ntpd works.
> Now you can if you wish have the client query more often. If you own
> the
> server that is fine. If you do not own the server, that is considered
> very bad manners, and the server may refuse to serve you anymore.
> 
> 
> A shorter poll interval means that the offset is smaller but the rate
> correction is more inaccurate, meaning that if your system goes down
> the
> clock will become inaccurate more rapidly. Since on a local net,
> keeping
> the times within a few 10s of microseconds is very doable, it is not
> clear what youwant.
> 
> >
> >
> >
> > Please find the ntp.conf in client:
> >
> >
> >
> > server 10.16.48.19 key 1
> >
> > restrict 10.16.48.19 mask 255.255.255.255 nomodify notrap noquery
> >
> > restrict 127.0.0.1
> >
> > broadcastclient novolley
> >
> > broadcastdelay 0
> >
> > keys /var/ntp/keys
> >
> > trustedkey 1
> >
> > logfile /var/log/ntp/ntpd.log
> >
> > driftfile /var/log/ntp/ntp.drift
> >
> > statsdir /var/log/ntp/
> >
> > statistics loopstats peerstats
> >
> > filegen loopstats file loopstats type day enable
> >
> > filegen peerstats file peerstats type day enable
> >
> >
> >
> > Any suggestion will really appreciated.
> 
> Stop worrying.
> 
> 
> >
> >
> >
> > Regards,
> >
> > Biswajit
> >
> >
> >==
> ==
> > Disclaimer:  This message and the information contained herein is
> proprietary and confidential and subject to the
> >  Tech Mahindra policy statement, you may review the policy at 

[ntp:questions] Can't wait on Refclock: err=22, 'Invalid argument'

[Charles Elliott]

Does anyone know from where this NTPD error comes from?

 

Event Viewer output:


System

 



-

Provider

 


[ Name] 

NTP

 



-

EventID

1



Level

2



 



Task

0

 




Keywords

0x80


-

EventData



 


Can't wait on Refclock: err=22, 'Invalid argument'

 

 

Using AstroGrep 4.2.5, for Windows, a search on 'Can't wait on Refclock' in
ntp-dev-4.2.7p375 in files *.c and 

*.h returns nothing.  Searching on the individual words, 'Can't', 'wait',
and 'Refclock' returns a few lines

each, but nothing that seems related to this error.

 

What is happening is that the MR-350P, an inexpensive GPS device with a PPS
output that works well and

unceasingly when connected to a Windows 7 machine thru the RS-232 port,
fails (with the above error)

about every 8 hours when attached to a Windows 8 machine using either one of
two RS-232 to USB

adapters.  A BU-353-S4 attached to the Win 8 system natively thru the USB
port used to run forever, 

albeit with inaccurate time.  When I stop NTPD and attach SiRFDemo to the
port the MR-350P is connected

to, the NMEA data is perfect.  

 

There have been a few problems with the USB ports after a recent spate of
Windows automatic updates, so this problem could be related to that.

 

Charles Elliott

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

Re: [ntp:questions] what is the meaning of dash in the type field of ntpq -p output?

[Charles Elliott]

On a Windows 8 machine,
according to the "route print" command,
0.0.0.0 is a valid network address.  It maps to
192.168.0.100 on this machine, which is one of two
interfaces, the other being 192.168.1.100.  Putting

server 0.0.0.0 iburst minpoll 4 maxpoll 5 noselect

in ntp.conf, it displays in ntpq -p as 'p' type and 
as "Unknown clock type" in NTP Time Server Monitor by
Meinberg.

Putting  

server 0.0.0.1 iburst minpoll 4 maxpoll 5 noselect

in the ntp.conf file, in ntpq -p it displays as 'u' clock
type and in the NTP Time Server Monitor by
Meinberg, the type indicator was "Unknown clock type."

Charles Elliott

> -Original Message-
> From: questions-bounces+elliott.ch=verizon@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On
> Behalf Of Brian Utterback
> Sent: Saturday, June 22, 2013 10:42 AM
> To: questions@lists.ntp.org
> Subject: [ntp:questions] what is the meaning of dash in the type field
> of ntpq -p output?
> 
> A long standing question that I have been asked is what is the mean of
> a
> dask ("-") in the type field of the output of "ntpq -p". The type field
> is decoded from the destination address. Here is the code that
> determines the type:
> 
>  ch = (char)(((dummy&0xf000)==0xe000) ? 'm' :
>  ((dummy&0x00ff)==0x00ff) ? 'b' :
>  ((dummy&0x)==0x7f01) ? 'l' :
>  ((dummy&0xffe0)==0x) ? '-' :
>  'u');
> 
>  From this we can see that if the first octet of the IP is 224, then it
> is mutlicast. If the last octet is 255, then it is boradcast. If it is
> 127.0.0.1 then is it is localhost. If everything except the last 5 bits
> are zero, then it is the dash. And if it isn't any of these, then it is
> unicast.
> 
> Of course, all of these definitions have problems, but I am totally
> flummoxed by the "-" test. I can't figure out what it is trying to find
> at all. Any ideas?
> 
> --
> blu
> 
> Always code as if the guy who ends up maintaining your code will be a
> violent psychopath who knows where you live. - Martin Golding
> ---
> |
> Brian Utterback - Solaris RPE, Oracle Corporation.
> Ph:603-262-3916, Em:brian.utterb...@oracle.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] How to determine hardware latency for PPS offset given simple tools.

[Charles Elliott]

You may be making a mistake using stratum 1 servers; especially the
government servers are way over used, and there can be large, variable, and
indeterminate delays just pushing a packet thru them.  Stick with stratum 2
servers; few people know about them apparently.

And this is not off-topic.  You efforts may be aided by having one computer
connected to 9 or 10 external servers (using the huff puff option) and to
your two local clocks (using the noselect option).  That way you can tell
which local clock is closer to the truth and how much they differ.  For the
computer connected to the external servers, don't run anything else on it
while you are experimenting.  A high load, shouldn't, but does affect how
fast NTPD can adjust to changing conditions.  Also, watch the offsets and
jitter.  When they become high, the router your ISP uses is jammed up with
movie downloads or commercial data.  You should wait until the Internet is
quiescent before observing or taking measurements.

Best of luck!

Charles Elliott

> -Original Message-
> From: questions-bounces+elliott.ch=verizon@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On
> Behalf Of Paul G
> Sent: Friday, June 21, 2013 10:16 AM
> To: questions@lists.ntp.org
> Subject: Re: [ntp:questions] How to determin hardware latency for PPS
> offset given simple tools.
> 
> On Thursday, June 20, 2013 5:51:50 PM UTC-4, E-Mail Sent to this
> address will be added to the BlackLists wrote:
> >
> >
> >
> > enable stats [etc. etc.]
> 
> As noted earlier I've done that or it's not applicable.  E.g. I only
> use the
> PPS driver and my seconds are numbered by an appliance that doesn't run
> ntpd.
> 
> >
> >  On one system at a time, ...
> >   have several other NTP servers configured {I usually shoot for 6 to
> 10}
> 
> I don't have six to ten stratum one servers (but maybe I should) and it
> doesn't
> seem useful to compare my << 500 microsecond offsets to non-local
> clocks.
> 
> >with all involved systems continuously running for more than one
> day;
> > take an average ...
> 
> In another thread (and some here) I explain how I've done that and I
> don't
> really like the e.g. 124 microsecond time1 I derived.  However it does
> result
> in O(1) microsec. offsets between some of my clocks.
> 
> >  perhaps the PPS signal is inverted?
> 
> It's not.
> 
> > It seemed like David Taylor covered that on may 25th.
> 
> Yes.  While I appreciate the suggestions and the good will behind them
> they don't seem informed by my question/problem description.
> 
> My key point is that ntpq appears to be telling me odd things.  E.g. my
> network
> is low latency, symmetric and consistent but some of my offsets are one
> or two
> orders of magnitude beyond other offsets.
> 
> So my question is how to find what I hope is hardware latency using the
> tools
> at hand or the coverse given multiple S1 clocks with O(10) microsecond
> offsets
> which one is right.
> 
> I expect I will move a set of them to a 10/100 switch and see if that
> makes a
> difference.
> 
> Ideally all my clocks pairs would look like this (both have time1 0):
> 
> localhost oPPS(0) .PPS. ... 3770.0000.001   0.001
> black +aster  .PPS. ... 3770.065   -0.003   0.004
> 
> localhost oPPS(0) .PPS. ... 3770.0000.000   0.004
> aster +black  .PPS. ... 3770.0660.007   0.010
> 
> But maybe some of them are just not up to the task:
> aster *ntp1   .PPS. ... 3770.5260.129   0.166
> 
> ___
> 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 connect gpsd shared memory driver

[Charles Elliott]

> When you want to use the receiver both for
> time sync and position info, the data somehow has to be multiplexed.

While this does not help the present problem, it may be possible to
multiplex GPS device output under Windows and using a SiRF receiver.  The
new SiRF demo program (Version 3.87) says it can read a SiRF receiver using
SiRF's proprietary protocol binary output, and the demo program will output
corresponding NMEA ASCII messages to a virtual COM port.  If that works, and
I have not tried it, one could see position, time, and a satellite map in
the demo program and NTPS could still receive the NMEA messages.

One can find SiRFDemo (3.87) by searching for it with Google or Bing.

Charles Elliott

> -Original Message-
> From: questions-bounces+elliott.ch=verizon@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On
> Behalf Of Rob
> Sent: Tuesday, June 18, 2013 4:47 PM
> To: questions@lists.ntp.org
> Subject: Re: [ntp:questions] ntpd connect gpsd shared memory driver
> 
> Richard Cagley  wrote:
> > Does "removing a definition" refer to removing one of the timeservers
> from
> > the ntp.conf file? Presently, I don't have pps support built into my
> kernel.
> 
> I'm sorry, but I am not familiar with it.
> I use gpsd+ntpd on a system without pps support.
> 
> I think it can be done in two ways (but I am not sure):
> 1. by using a driver inside ntpd to support a GPS receiver
> 
> 2. by using some program to tell the kernel where to look for pps
> pulses.
> 
> That program is then probably called somewhere in system startup.
> But I don't have any details on that.
> 
> What should be clear is that you *cannot* use the ntpd driver for a
> GPS receiver and gpsd at the same time.  They would have to share the
> data from the serial port.
> 
> In fact this is one of the reasons why gpsd exists at all, and why it
> has time sync functions.   When you want to use the receiver both for
> time sync and position info, the data somehow has to be multiplexed.
> 
> (it seems there is some limited function in one of the ntpd GPS drivers
> to save the position info somewhere where it can be accessed by other
> programs)
> 
> ___
> 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 connect gpsd shared memory driver

[Charles Elliott]

You can slightly improve NTPS's performance by suppressing all the NMEA
messages except the one NTPD needs for the time, such as RMC.  That way the
program does not have to sort through the receive buffer looking for the
particular message type it needs, and there is much less traffic on the
RS-232 line.  Many GPS device manufacturers have manuals that tell how to
change the NMEA message output rate.  If you have a SiRF or SURE chip, I can
help with such a manual.

Charles Elliott

> -Original Message-
> From: questions-bounces+elliott.ch=verizon@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On
> Behalf Of Richard Cagley
> Sent: Tuesday, June 18, 2013 2:16 PM
> To: A C
> Cc: questions@lists.ntp.org
> Subject: Re: [ntp:questions] ntpd connect gpsd shared memory driver
> 
> On Tue, Jun 18, 2013 at 11:06 AM, A C  wrote:
> 
> > I suspect you may have a conflict between the kernel attempting to
> control
> > PPS and gpsd attempting to use it.  Try adding "disable kernel" to
> the
> > ntp.conf to shut off the kernel's use of PPS and see if that wakes up
> gpsd.
> >  If so, your serial driver doesn't want to play nice and share the
> DCD line
> > between two processes.
> 
> 
> Yeah, I agree. This definitely seems like the problem. I have pps
> support
> built into the kernel. Should I remove that support? It's slightly
> confusing to me who "controls" the pps line as there are several actors
> in
> play here...gpsd, ntpd, the kernel.
> 
> With the new entry "disable kernel" in ntpd.conf...
> ---
> server 127.127.28.0 minpoll 4 maxpoll 4
> fudge 127.127.28.0 time1 0.420 refid GPS
> server 127.127.28.1 minpoll 4 maxpoll 4 prefer
> fudge 127.127.28.1 refid GPS1
> server clock.redhat.com
> server 0.us.pool.ntp.org
> server 1.us.pool.ntp.org
> server 2.us.pool.ntp.org
> server 3.us.pool.ntp.org
> disable kernel
> ---
> I get this after about 5 min...
> ---
> / # ntpq -p
>  remote   refid  st t when poll reach   delay   offset
>  jitter
> ===
> ===
> *SHM(0)  .GPS.0 l   14   16  1770.000   20.062
>  12.250
>  SHM(1)  .GPS1.   0 l-   1600.0000.000
> 0.000
>  clock1.redhat.c .CDMA.   1 u   56   643   81.138  -165.16
>  14.327
>  vimo.dorui.net  198.82.1.203 3 u   56   643   81.730  -166.40
>  14.743
>  soft-sjc-01.ser 64.250.229.100   2 u   56   643   12.289  -165.71
>  10.420
>  199.4.29.16664.113.32.5  2 u   56   643   74.375  -162.43
>  11.199
>  66-162-15-65.li 64.236.96.53 2 u   59   643   64.446  -159.15
>  10.202
> ---
> ___
> 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] Meinberg NTP client continuously resync to server

[Charles Elliott]

TimeTime 
NTPDTime to  to
Computer  O/S  Version OffsetSync?  Sync<0 Offset
Configuration line
T   Server 2003 4.2.7p273   Shut Down   Yes 1:14
0:18:14server mmm.nnn.ooo.ppp iburst minpoll 4 maxpoll 5
LukeWin 8 4.2.7p348 +10 min Yes 3:143:14
server 192.168.1.89 iburst minpoll 4 maxpoll 4
J   Win 7 4.2.7p310 -10 min Yes 3:14 Never -- Internet
went wild -- offset = 2.111 at 00:29:41
P   Win 7 4.2.6p5   -3 min  Yes 3:14 0:20:45
server 192.168.1.89 iburst minpoll 4 maxpoll 4
L   Win 7 4.2.7p348 +3 min  Yes 3:148:57
server 192.168.1.89 iburst minpoll 4 maxpoll 4

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

Re: [ntp:questions] Meinberg NTP client continuously resync to server

[Charles Elliott]

Hello:

 

  I have one server, T, and 4 client computers.  The server is attached
to 11 close-by stratum 2 Internet time servers and operates in broadcast
mode.  It is about 10 PM in Philadelphia, PA, USA, and the Internet is
relatively quiet.  The clients connect to the server in broadcast client
mode.  I performed the following experiment;  

 

The server was shut down.

The clients were set to various time offset shown in the table below.

The server was restarted.

The time for the server and clients to synchronize was approximately noted.

 

Here are the results:



   Time to


Computer

O/S

NTPD Ver

Time Offset

Sync?

Time to Sync

< 0 Offset

Configuration line


T

Server 2003

4.2.7p273

Shut Down

Yes

0:01:14

0:18:14

server mmm.nnn.ooo.ppp iburst minpoll 4 maxpoll 5


Luke

Win 8

4.2.7p348

+10 min

Yes

3:14

3:14

server 192.168.1.89 iburst minpoll 4 maxpoll 4


J

Win 7

4.2.7p310

-10 min

Yes

3:14

Never -- Internet went wild -- offset = 2.111 at 00:29:41


P

Win 7

4.2.6p5

-3 min

Yes

3:14

0:20:45

server 192.168.1.89 iburst minpoll 4 maxpoll 4


L

Win 7

4.2.7p348

+3 min

Yes

3:14

8:57

server 192.168.1.89 iburst minpoll 4 maxpoll 4

 

Charles Elliott

 

 

> -Original Message-

> From: questions-bounces+elliott.ch=verizon@lists.ntp.org

> [mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On

> Behalf Of renoandy...@gmail.com

> Sent: Friday, May 17, 2013 6:43 PM

> To: questions@lists.ntp.org

> Subject: [ntp:questions] Meinberg NTP client continuously resync to

> server

> 

> I am using the Meinberg ntpd 4.2.4 deamon to syncronize a client pc to

> another server pc on my network.  The client time cannot be trusted.

> The problem I am having is that if the client time drifts out too far

> as a result of a network loss, it does not appear to resync and correct

> its clock to conform to the server's true time.

> 

> Does anyone know how to configure this application to have the client

> always bust and update its clock to lock onto the NTP server ?

> 

> 

> ___

> questions mailing list

>  <mailto:questions@lists.ntp.org> questions@lists.ntp.org

>  <http://lists.ntp.org/listinfo/questions>
http://lists.ntp.org/listinfo/questions

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

Re: [ntp:questions] ntpd 4.2.6p5 will not synchronize to broadcast servers

[Charles Elliott]

>interface listen wildcard
>interface listen all

I tried these on a Windows 8, 64-bit machine.  It does not solve any
problems; NTP still puts the following messages into the Event Log on
startup:

bind(308) AF_INET 192.168.1.255#123 flags 0x419 failed: Can't assign
requested address
failed to listen for broadcasts to 192.168.1.255 on interface #3 Ethernet 5

bind(308) AF_INET 192.168.0.255#123 flags 0x419 failed: Can't assign
requested address
failed to listen for broadcasts to 192.168.0.255 on interface #5 Ethernet 4

Unable to listen for broadcasts, no broadcast interfaces available

However, broadcasts still work fine, with the exception that now, with the
above two copied lines in the conf file, NTPD now puts the following two
lines in the Windows Event Log every 16 seconds:

192.168.1.88 local addr 192.168.1.100 -> 0.0.0.0   
192.168.1.88 local addr 0.0.0.0 -> 192.168.1.100   

192.168.1.88 is the broadcast server, and 192.168.1.100 is this machine, one
of the recipients.

Charles Elliott

> -Original Message-
> From: questions-bounces+elliott.ch=verizon@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On
> Behalf Of Gary Johnson
> Sent: Thursday, April 25, 2013 2:35 PM
> To: questions@lists.ntp.org
> Subject: Re: [ntp:questions] ntpd 4.2.6p5 will not synchronize to
> broadcast servers
> 
> Brian Utterback  wrote:
> > I think this is a duplicate of bug 629.
> >
> > On 4/24/2013 9:54 PM, Harlan Stenn wrote:
> > > Gary,
> > >
> > > The short answer is "I don't know".  I believe we have successfully
> used
> > > broadcast clients in 4.2.6.
> > >
> > > Please see if ntp-dev works for you though - if there is a problem
> there
> > > we want to fix that before releasing 4.2.8.
> > >
> > > And having written the above:
> > >
> > >   http://bugs.ntp.org/show_bug.cgi?id=2261
> 
> Thank you both!  I had found those bug reports earlier, but I didn't
> think that wildcards and "255.255.255.255" applied in my case, so I
> didn't look closely at either one.  I read the discussions associated
> with both last night and applied Dave Hart's suggestion at the bottom
> of
> the bug 629 discussion to add
> 
> interface listen wildcard
> interface listen all
> 
> to my /etc/ntp.conf.  Broadcast now works!
> 
> I changed the simple test case I posted originally to
> 
> $ ntpd -4 -b -D2 -c /etc/ntp.conf.test &
> 
> where /etc/ntp.conf.test contains only those two interface commands.
> It
> still emits the message
> 
> 25 Apr 16:50:38 ntpd[31987]: Unable to listen for broadcasts, no
> broadcast interfaces available
> 
> but broadcast works anyway.
> 
> I then added those two interface commands to the top of our normal
> /etc/ntp.conf file and broadcast now works in the context of our
> application as well.
> 
> Does it matter where in /etc/ntp.conf those commands are put?
> 
> I will download and install ntp-dev later today and let you know how
> that goes.
> 
> Thanks again,
> Gary
> 
> ___
> 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

[ntp:questions] FW: Deal/Day: Discover our 5-★ ebooks for 2013 + SAVE 50% on the Top 25 best-reviewed titles

[Charles Elliott]

 

 

 


Save 50% - 25 5-Star ebooks   (

View in browser) 

 


 O'Reilly Media
 

Deal of the Day

 



Discover Our 5-Star Ebooks for 2013


Save 50% on the Top 25 - Today Only 


 



 

Ebooks in Deal
 

We keep a running tally of our top-performing, five-star titles. These are
the books that have most impressed and earned praise from readers like you.
We're now sharing the list with the added incentive of a special offer: for
one day only, get these five-star ebooks for 50% off. 

Ebooks from

oreilly.com are DRM-free. You get free lifetime access, multiple file
formats, and free updates. Sync with Dropbox - your files, anywhere.


 
View the 5-Star Rated Ebooks   →

Use discount code: DEAL 
This deal expires April 25, 2013 at 11:59pm PT and cannot be combined with
other offers. Offer does not apply to Print, or "Print & Ebook" bundle
pricing.

 


Spreading the knowledge of innovators 

 
oreilly.com 

 


You are receiving this message because you purchased directly from O'Reilly
or registered titles. Keep up on all things O'Reilly by signing up for our

email alerts and newsletters.

To ensure delivery to your inbox (not bulk or junk folders), please add
 orei...@post.oreilly.com to your address
book.

To unsubscribe from all email announcements from O'Reilly,

click here.

O'Reilly Media, Inc. 1005 Gravenstein Highway North, Sebastopol, CA 95472
(707) 827-7000




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

Re: [ntp:questions] Syncing and peering for a multi-continent deployment

[Charles Elliott]

I don't think you will ever achieve acceptable synchronization between the
data centers without accurate external clocks, such as GPS-based clocks,
attached to a time server in each location.  Internet traffic acts as waves
of high use and periods of quiescence.  During these periods of high traffic
your data centers will differ by 250 ms or more and will take some time to
resynchronize during quiescent periods.  This problem is greatly exacerbated
by the large distances between your data center locations.  NTPD cannot
prevent that.  Nor is it really NTPD's fault.  The ISPs have installed very
large buffers in front of their routers to prevent dropping packets and
sending choke packets to the data originators, as the Internet was
originally designed.  Hence the Internet is not automatically rerouting
packets when traffic patterns change, again as originally designed.  Money
is the root of all evil.

Charles Elliott 

> -Original Message-
> From: questions-bounces+elliott.ch=verizon@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On
> Behalf Of Blair Zajac
> Sent: Saturday, April 6, 2013 9:01 PM
> To: questions@lists.ntp.org
> Subject: [ntp:questions] Syncing and peering for a multi-continent
> deployment
> 
> I'm working on deploying a large number of servers to data centers on
> three continents, say US, Europe and India.  Because each data center
> will be writing data and timestamping the data, I want them all to
> think
> they are at the same time, even if it isn't exactly the correct UTC
> time.  The data will be synced to other data centers, so relative
> ordering of when something happened can be important.
> 
> To not ping stratum-1 and -2 level servers from a large number of
> boxes,
> I'm setting up three stratum-3 NTP servers in each data center.
> 
> Here's what I've read:
> 
> 1) Each ntp server should have 4 to 7 upstream clocks [1], [2], [3].
> 
> 2) The three stratum-3 NTP servers in each data center should be peers
> of each other [4].  So each NTP server would have at most 2+7=9
> connections.
> 
> Questions:
> 
> 1) Should each data center use nearby stratum-2 clocks or pick a set of
> stratum-2 clocks that are network wise in the center between all data
> centers (it may not be possible to get a true center)?
> 
> 2) Should each stratum-3 server in a single data center use all 4-7
> upstream clocks?  Or should the 4-7 be split between the three stratum-
> 3
> servers?  The diagram at [4] suggests they should be split?  If that's
> the case, then how are falsetickers identified?
> 
> 3) Should I have all the stratum-3 servers in each data center be peers
> of each other, so each would have 8 peers?  This would ensure that all
> my clocks think they are at the same time.  If I do this, then I would
> need to increase maxclocks to support up to 7 (upstream) + 8 (peers)=15
> clocks?
> 
> 4) Or, should I not peer data centers to each other and trust that the
> stratum-2 clocks near each data center will be close to the other
> clocks?
> 
> Other random questions:
> 
> 1) It doesn't appear that its necessary to set up symmetric keys for
> peers?
> 
> 2) Is there a way to tell which peer is the "master" peer?  Looking
> through ntpdc and ntpq I didn't see anything.
> 
> Thanks,
> Blair
> 
> [1]
> http://support.ntp.org/bin/view/Support/SelectingOffsiteNTPServers#Sect
> i
> [2]
> http://support.ntp.org/bin/view/Support/SelectingOffsiteNTPServers#Sect
> i
> [3]
> http://support.ntp.org/bin/view/Support/StartingNTP4#Section_7.1.4.3.2.
> [4] http://www.ntp.org/ntpfaq/NTP-s-config-adv.htm#AEN3101
> ___
> 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] high jitter on serial gps causes big time offsets

[Charles Elliott]

I would test the local clock before relying on it for time.  In the bad old
days, around year 2000, when I first started processing SETI@Home (S@H) work
units (WUs), I could actually see that WUs were being processed faster in
the cool early morning hours than they were in the hot afternoons.  The
caveat is that an Intel tech support rep denied that that was possible.  In
any case, many others have commented on this list that the timing crystals
installed in typical motherboards vary significantly with temperature.  If
you price timing crystals with guaranteed accuracy you may well believe that
they don't install them in typical motherboards; they cost at least as much.

Charles Elliott

> -Original Message-
> From: questions-bounces+elliott.ch=verizon@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On
> Behalf Of Robert Scott
> Sent: Friday, April 5, 2013 10:02 AM
> To: questions@lists.ntp.org
> Subject: Re: [ntp:questions] high jitter on serial gps causes big time
> offsets
> 
> On Fri, 5 Apr 2013 11:09:29 GMT, Nickolay Orekhov 
> wrote:
> 
> >Hello!
> >I've got the following configuration:
> >
> >tos mindist 0.128
> >tinker panic 0 stepout 60
> >
> ># TSIP,PPS reference clock
> >
> >server 127.127.8.0 mode 10 prefer maxpoll 3 true
> >fudge 127.127.8.0 refid TSIP time1 0.08
> >
> >server 127.127.22.0 maxpoll 3
> >fudge 127.127.22.0 refid PPSI
> >
> >The main goal: I want 1 ms or better precision always, even with gps
> >quality going high and low.
> >
> >When satellites appear and disappear again, serial clock could be
> selected
> >before PPS clock. Or maybe some gps receivers will show good quality
> before
> >PPS will appear or will be selected.
> >
> >In general, I want ntpd to skip adjustments coming from specific
> server or
> >ref clock according to some constant precision. For example, I know
> that
> >gps serial jitter is about 30-40 ms. So I want ntpd to do no
> adjustments
> >lower than this value...
> 
> I don't understand how this rule of not adjusting less than 30-40
> msec. offers any practical help to you.  You say you don't want to
> adjust by amounts less than this for fear of adjusting based on
> unreliable GPS serial timing.  But if you ever have to adjust by more
> than 30-40 msec., that is an admission that you were previously off by
> much more than your stated requirement of 1 msec. "always".  So the
> effect of this rule is to never adjust.  In short, you can't use the
> magnitude of the timing error to decide if the new GPS information is
> coming from the jittery serial data or from the PPS clock.  If you
> want to avoid using unreliable timing data you have to have some
> independent way of deciding if the data is unreliable.  I don't know
> enough about the indications from the GPS device to say how this is
> done, but it seems that the GPS device itself knows if it has valid
> PPS timing availble.
> 
> If you want to maintain precision through low GPS quality periods you
> could fall back on your local clock, which hopefully has been
> rate-trimmed over a long period of time so its drift rate is small
> enough to maintain 1 msec. accuracy for as long as the GPS quality
> remains low.
> 
> Robert Scott
> Hopkins, MN
> 
> ___
> 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] NIST vs. pool.ntp.org ?

[Charles Elliott]

In the US, the stratum 2 time servers are much less used than the stratum 1
servers, and they dispense fairly accurate time.  The stratum 1 time servers
frequently have erratic and lengthy processing delays.  You can find time
servers here http://support.ntp.org/bin/view/Servers/WebHome
and finding ones near you is well worth the effort.  Nothing will help
though if your neighbor decides to download a movie or two.

Charles Elliott

> -Original Message-
> From: questions-bounces+elliott.ch=verizon@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On
> Behalf Of Magnus Danielson
> Sent: Thursday, March 28, 2013 8:32 AM
> To: questions@lists.ntp.org
> Subject: Re: [ntp:questions] NIST vs. pool.ntp.org ?
> 
> Hi again Robert,
> 
> On 03/28/2013 04:22 AM, Robert Scott wrote:
> > On Thu, 28 Mar 2013 02:50:17 GMT, unruh  wrote:
> > You really should read my posts before responding.  No, I do not
> > intend to hard-code NIST or any other server.  I never said I wanted
> > to.  No, the app is not intended for all musicians.  It is intended
> > for professional piano tuners only.  I sell about one per day.  And I
> > never said the pool would not be good enough for my needs.  I only
> > asked about the relative benefits of the pool vs. NIST, which "E-mail
> > sent...Blacklists" answered very nicely.
> 
> There is no real benefit in using either, rather you should use the mix
> of servers which gives you good confidence in removing false-tickers as
> well as good precision due to use of short distances.
> 
> Look at the NTP code and book, as many of the filtering steps aims at
> removing noise which polute the time and frequency errors. Do the to-
> way
> time-transfer.
> 
> Cheers,
> Magnus
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions

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

Re: [ntp:questions] How do I validate my PPS clocks?

[Charles Elliott]

I performed the same kind of test on a commercial real-time O/S at
the time sold by Intel, but since divested.  I put code in a program to
output a digital pulse when the mock application program received
notification of the parallel port interrupt and measured the interrupt
service delay between generating the interrupt and sensing it with two
channels of an oscilloscope, which was HIGHLY variable, although I can't
recall the numbers.

You could do the same thing by patching NTPD to output a pulse when
the PPS signal was processed and then measuring the time difference between
the actual PPS signal and the digital pulse with an oscilloscope.  Compared
to what I paid for one in the 1990s, oscilloscopes are dirt cheap now.
There are people who sell them on eBay too.

Charles Elliott

> -Original Message-
> From: questions-bounces+elliott.ch=verizon@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On
> Behalf Of unruh
> Sent: Monday, February 25, 2013 3:33 PM
> To: questions@lists.ntp.org
> Subject: Re: [ntp:questions] How do I validate my PPS clocks?
> 
> On 2013-02-25, Miroslav Lichvar  wrote:
> > On Mon, Feb 25, 2013 at 01:44:02PM +0100, Kasper Pedersen wrote:
> >> From the PPS arrives, and to the kernel timestamps it, is a very
> long time.
> >> I wrote this to measure it:
> >>  http://n1.taur.dk/edgetest.c
> >> (you will need a linux machine, gcc, and kernel-headers to compile)
> >
> > Very interesting, thanks! For my machine it shows that the interrupt
> > latency is around 12 us.
> >
> > I'm wondering if the kernel module could have an option which would
> > enable a polling method to time stamp the PPS events.
> 
> When I ran a test many years ago I used a program to put out a rising
> pulse onto one of the printer port output pins, and then connected that
> to the parallel port nack pin. I timestamped the time just before I put
> out the pulse, and the time at which the interrupt occured and got
> roughtly 1 to 2 microseconds delay. Ie, the interrupt service was of
> the
> order of 1us.  12us seems really long. Now this might be a difference
> between the serial and parallel interrupts or a difference in the
> interrupt sevice routine, but 12us still seems a long time.
> 
> 
> >
> 
> ___
> 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 NMEA driver

[Charles Elliott]

Here:
http://www.sparkfun.com/datasheets/GPS/NMEA%20Reference%20Manual-Rev2.1-Dec0
7.pdf

Or here: http://www.ekf.de/c/cgps/cg2/inf/nmea_reference_manual.pdf


SiRF Proprietary Binary Protocol Manual:
http://www.usglobalsat.com/downloads/SiRF_Binary_Protocol.pdf

 Or search on (SiRF) NMEA Reference Manual; it returns 14,600 entries.

Charles Elliott

> -Original Message-
> From: questions-bounces+elliott.ch=verizon@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On
> Behalf Of David Taylor
> Sent: Tuesday, February 12, 2013 5:25 AM
> To: questions@lists.ntp.org
> Subject: Re: [ntp:questions] NTP NMEA driver
> 
> On 12/02/2013 09:54, Rob wrote:
> []
> > You are describing implementation details in some particular
> receiver.
> > Why not read the actual specs of the protocol instead?
> []
> 
> Do you have the URL of the official $GPZDA protocol, please?  Is it any
> more than the receiver's best guess, given that there is no "locked"
> indicator?
> 
> Oh, and a URL which the mere mortal can read:
>http://www.nmea.org/pub/0183/  =>  no permission.
> --
> 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] NTP NMEA driver

[Charles Elliott]

> None, not even ZDA put out current time. They all put out time in the
> past. It takes a long time for any of the messages to be composed in
> the
> receiver, to be queued, to be sent at 300-9000 bits per second, and to
> be interpreted.
> 



It is easy to change most GPS receivers to send NMEA messages at a faster
rate than 300-9000 bps.  A rate of  57,600 works better and is easily
achievable.  For SiRF receivers there are two ways:

1. Search for SiRFDemo.exe.  It will control most SiRF GPS receivers.  The
interface is intuitive, but as I recall, click on "Action/Switch Message
Rate."

2. While most GPS boards have similar, you can search for 'SiRF NMEA
Reference Manual.'  This manual lists all the input/output NMEA messages
that SiRF supports.  Then write a small program to output the messages you
need.  It is trivial if you have a copy of Visual Studio (Express); just
copy NTPD's GPS initialization code, but send out your own messages.  I have
this manual; if you can't find it on the Internet, send me an email and I
will send you a copy.

Please stop ragging us about carriage returns in email messages.

Charles Elliott

> -Original Message-
> From: questions-bounces+elliott.ch=verizon@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On
> Behalf Of unruh
> Sent: Monday, February 11, 2013 6:57 PM
> To: questions@lists.ntp.org
> Subject: Re: [ntp:questions] NTP NMEA driver
> 
> On 2013-02-11, Rob  wrote:
> > unruh  wrote:
> >> Please put carriage returns into your posts. These run on sentences
> can
> >> be very hard to read.
> >
> > Please get a decent newsreader instead of picking on posting format.
> 
> I thought the OP was trying to communicate with us, not doing us a
> favour
> by writing down his least burps to send out into the world. If the
> former is true, then it is up to him to try to make it as easy on the
> listener/reader , not expect them to go out of their way to
> conform to his peculiarities.
> 
> Again, Please put carriage returns into  posts.
> 
> >
> >> Secondly, many messages provide time informations. Why do you pick
> out
> >> one of the bunch? And No other messages do not provide the time of a
> >> position fix, they mark the time of the nearest second that has
> already
> >> occured.  None of the NMEA sentences mark the time of PPS pulse
> because
> >> they all occur long long after that pulse ( on the microsecond
> scale).
> >
> > You are obviously wrong here.  The messages that provide position
> data
> > do not include the current time, they include the "time of fix".
> 
> None, not even ZDA put out current time. They all put out time in the
> past. It takes a long time for any of the messages to be composed in
> the
> receiver, to be queued, to be sent at 300-9000 bits per second, and to
> be intrpreted.
> 
> > You are at the mercy of the receiver outputting the message shortly
> > after the calculation of the fix.  The OP was right.
> 
> You are always at the mercy of the receiver.
> And it is not the fix time. ZDA puts out only to the nearest 10 ms. the
> others to the nearest second or 10ths of a second.  Fix
> times are in the nanosecond realm. They put out times which are the
> time
> label of the latest second (or they should if they are not
> incompetently
> designed as the Garmin 18x was.)
> 
> 
> ___
> 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