f



ntp.conf configuration

Setting up ntp.conf for a Windows 10 laptop for a hobby application where I=
 want correct time within a few tenths of a second. The built-in Windows fa=
cility for time synchronization doesn't seem to be sufficient (checking wit=
h time.is on a browser sometimes says laptop time is more than one second d=
ifference). This laptop is used while traveling. Meinberg NTP seems to prod=
uce good results. The "default" ntp.conf produced by their installer has 5 =
server lines:

 server 0.pool.ntp.org iburst minpoll 6 maxpoll 7
 server 1.pool.ntp.org iburst minpoll 6 maxpoll 7
 server 2.pool.ntp.org iburst minpoll 6 maxpoll 7
 server 3.pool.ntp.org iburst minpoll 6 maxpoll 7
 server 4.pool.ntp.org iburst minpoll 6 maxpoll 7

which ends up giving me 4 pool responses when I enter ntpq -p, but not all =
4 are actually "working". It's not unusual to get 1 or more responses which=
 are in INIT state after a computer restart.

Currently I am trying this ntp.conf, suggested by posting by Ask Bj=C3=B8rn=
 Hansen on Sept 5 (modified drift file location for Windows 10):

driftfile "C:\Program Files (x86)\NTP\etc\ntp.drift"
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
restrict source notrap nomodify noquery
restrict 127.0.0.1
restrict -6 ::1
pool 0.pool.ntp.org iburst
tos maxclock 4

The original posting did not have the tos maxclock 4, but this was suggeste=
d in the reply by Miroslav Lichvar on Sept 6. Without the tos maxclock 4 li=
ne, I get 10 responses from the pool when I run ntpq -p, which seems excess=
ive load on pool for my hobby application.

This seems to work OK, typically giving a result like the following(after r=
estart computer and wait 15 minutes or so):

     remote           refid      st t when poll reach   delay   offset  jit=
ter
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
 0.pool.ntp.org  .POOL.          16 p    -   64    0    0.000    0.000   0.=
000
-dns4.net.rpi.ed 18.26.4.105      2 u   37   64  377   73.669    8.715  25.=
257
+ntp3.junkemailf 216.218.254.202  2 u   37   64  377   53.296   10.926  23.=
129
*ec2-52-6-160-3. 209.51.161.238   2 u   30   64  377   76.280    5.887  24.=
779
+pyramid.latt.ne 192.12.19.20     2 u   34   64  377   71.388    4.559   8.=
397

On a different Windows 10 computer, I got the following result after 30 min=
utes (using the same ntp.conf file contents):

     remote           refid      st t when poll reach   delay   offset  jit=
ter
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
 0.pool.ntp.org  .POOL.          16 p    -   64    0    0.000    0.000   0.=
001
-biisoni.miuku.n 129.250.35.251   3 u  117  128  377   51.668  -21.208   9.=
741
+208.53.158.34 ( 216.93.242.12    3 u  119  128  377   47.029  -27.605   6.=
195
*ada.selinc.com  .GPS.            1 u  115  128  377   64.892  -37.675   7.=
496
+fairy.mattnordh 204.9.54.119     2 u  119  128  377   71.638  -32.737   4.=
882

Does this seem reasonable and minimal? The offset results are acceptable fo=
r my needs.

Jim
0
James
10/22/2016 8:04:24 PM
comp.protocols.time.ntp 4895 articles. 2 followers. Post Follow

7 Replies
166 Views

Similar Articles

[PageSpeed] 17

On 22/10/2016 21:04, James Kajder wrote:
> Setting up ntp.conf for a Windows 10 laptop for a hobby application where I want correct time within a few tenths of a second. The built-in Windows facility for time synchronization doesn't seem to be sufficient (checking with time.is on a browser sometimes says laptop time is more than one second difference). This laptop is used while traveling. Meinberg NTP seems to produce good results. The "default" ntp.conf produced by their installer has 5 server lines:
>
>  server 0.pool.ntp.org iburst minpoll 6 maxpoll 7
>  server 1.pool.ntp.org iburst minpoll 6 maxpoll 7
>  server 2.pool.ntp.org iburst minpoll 6 maxpoll 7
>  server 3.pool.ntp.org iburst minpoll 6 maxpoll 7
>  server 4.pool.ntp.org iburst minpoll 6 maxpoll 7
>
> which ends up giving me 4 pool responses when I enter ntpq -p, but not all 4 are actually "working". It's not unusual to get 1 or more responses which are in INIT state after a computer restart.
>
> Currently I am trying this ntp.conf, suggested by posting by Ask Bjørn Hansen on Sept 5 (modified drift file location for Windows 10):
>
> driftfile "C:\Program Files (x86)\NTP\etc\ntp.drift"
> restrict default kod nomodify notrap nopeer noquery
> restrict -6 default kod nomodify notrap nopeer noquery
> restrict source notrap nomodify noquery
> restrict 127.0.0.1
> restrict -6 ::1
> pool 0.pool.ntp.org iburst
> tos maxclock 4
>
> The original posting did not have the tos maxclock 4, but this was suggested in the reply by Miroslav Lichvar on Sept 6. Without the tos maxclock 4 line, I get 10 responses from the pool when I run ntpq -p, which seems excessive load on pool for my hobby application.
>
> This seems to work OK, typically giving a result like the following(after restart computer and wait 15 minutes or so):
>
>      remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
>  0.pool.ntp.org  .POOL.          16 p    -   64    0    0.000    0.000   0.000
> -dns4.net.rpi.ed 18.26.4.105      2 u   37   64  377   73.669    8.715  25.257
> +ntp3.junkemailf 216.218.254.202  2 u   37   64  377   53.296   10.926  23.129
> *ec2-52-6-160-3. 209.51.161.238   2 u   30   64  377   76.280    5.887  24.779
> +pyramid.latt.ne 192.12.19.20     2 u   34   64  377   71.388    4.559   8.397
>
> On a different Windows 10 computer, I got the following result after 30 minutes (using the same ntp.conf file contents):
>
>      remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
>  0.pool.ntp.org  .POOL.          16 p    -   64    0    0.000    0.000   0.001
> -biisoni.miuku.n 129.250.35.251   3 u  117  128  377   51.668  -21.208   9.741
> +208.53.158.34 ( 216.93.242.12    3 u  119  128  377   47.029  -27.605   6.195
> *ada.selinc.com  .GPS.            1 u  115  128  377   64.892  -37.675   7.496
> +fairy.mattnordh 204.9.54.119     2 u  119  128  377   71.638  -32.737   4.882
>
> Does this seem reasonable and minimal? The offset results are acceptable for my needs.
>
> Jim

Jim,

I would suggest setting a region when using the pool directive:

   http://www.satsignal.eu/ntp/setup.html#pool

if you are in the UK, for example:

     # Use pool NTP servers
     pool uk.pool.ntp.org  maxpoll 6 iburst

if you are in the US, for example:

     # Use pool NTP servers
     pool us.pool.ntp.org  maxpoll 6 iburst

As a 20 ms offset is acceptable, the results seem reasonable. 
Personally, I would leave maxclock alone, and not reduce it from the 
default of 10.  I also recommend installing NTP outside the Program 
Files tree.

   http://www.satsignal.eu/ntp/setup.html

-- 
Cheers,
David
Web: http://www.satsignal.eu
0
David
10/23/2016 9:22:08 AM
On 22/10/16 21:04, James Kajder wrote:
> I want correct time within a few tenths of a second. The built-in Windows facility for time synchronization doesn't seem to be sufficient

That should  be easy for the built in implementation; you just have to 
configure it properly.  The default configuration only polls about once 
a week.

Note that, in this context, Meinberg only do an installer.  The NTP 
software is generated from the same source code as ntpd supplied with Linux.

Also note that offset is offset between the measured and predicted time. 
  It says nothing about how accurate the measured time is.
0
David
10/23/2016 1:05:08 PM
On Sunday, October 23, 2016 at 3:22:09 AM UTC-6, David Taylor wrote:
> Jim,
>=20
> I would suggest setting a region when using the pool directive:
>=20
>    http://www.satsignal.eu/ntp/setup.html#pool
>=20
> if you are in the UK, for example:
>=20
>      # Use pool NTP servers
>      pool uk.pool.ntp.org  maxpoll 6 iburst
>=20
> if you are in the US, for example:
>=20
>      # Use pool NTP servers
>      pool us.pool.ntp.org  maxpoll 6 iburst
>=20
> As a 20 ms offset is acceptable, the results seem reasonable.=20
> Personally, I would leave maxclock alone, and not reduce it from the=20
> default of 10.  I also recommend installing NTP outside the Program=20
> Files tree.
>=20
>    http://www.satsignal.eu/ntp/setup.html
>=20
> --=20
> Cheers,
> David
> Web: http://www.satsignal.eu

Thanks for your reply!

Why do you suggest maxpoll 6 with Windows 10? Meinberg suggests maxpoll 7 a=
nd minpoll 6 in the file their install creates. I have tried leaving maxpol=
l / minpoll out, and it doesn't seem to "hurt" anything - browsing to time.=
is I still get "Your time is exact" even after the computer being on all da=
y and the poll interval is 1024.

Jim
0
James
10/23/2016 4:05:25 PM
On Sunday, October 23, 2016 at 7:05:14 AM UTC-6, David Woolley wrote:
> On 22/10/16 21:04, James Kajder wrote:
> > I want correct time within a few tenths of a second. The built-in Windo=
ws facility for time synchronization doesn't seem to be sufficient
>=20
> That should  be easy for the built in implementation; you just have to=20
> configure it properly.  The default configuration only polls about once=
=20
> a week.
>=20
> Note that, in this context, Meinberg only do an installer.  The NTP=20
> software is generated from the same source code as ntpd supplied with Lin=
ux.
>=20
> Also note that offset is offset between the measured and predicted time.=
=20
>   It says nothing about how accurate the measured time is.

Concerning the built in Windows implementation, I have tried changing a reg=
istry key to poll every hour. And usually time.is reports "Your time is exa=
ct", but sometimes during the day time.is would report my time was differen=
t from their time by several tenths of a second.

Concerning offset, thanks for feedback! I should say that when I browse to =
time.is, it report "Your time is exact", and therefore I believe my compute=
r is set to "correct" time.

Jim
0
James
10/23/2016 4:11:57 PM
On 23/10/2016 17:05, James Kajder wrote:
[]
> Thanks for your reply!
>
> Why do you suggest maxpoll 6 with Windows 10? Meinberg suggests maxpoll 7 and minpoll 6 in the file their install creates. I have tried leaving maxpoll / minpoll out, and it doesn't seem to "hurt" anything - browsing to time.is I still get "Your time is exact" even after the computer being on all day and the poll interval is 1024.
>
> Jim

Jim, you are quite right, I should have updated my Web site to "maxpoll 
7" and also my answer.  I am after better precision - the best which NTP 
can get whether driver from Internet or local reference clocks. Windows 
8 or later helps with getting better than millisecond precision.

I actually have many of my PCs driven from GPS/PPS clocks.  I am 
comparing the timing of events from a satellite link with other stations 
in different parts of Europe, and an accurate timestamp can be helpful 
in disambiguating events.

It's good fun, too!

-- 
Cheers,
David
Web: http://www.satsignal.eu
0
David
10/23/2016 4:38:04 PM
On 23/10/16 17:11, James Kajder wrote:
>
> Concerning the built in Windows implementation, I have tried changing a registry key to poll every hour. And usually time.is reports "Your time is exact", but sometimes during the day time.is would report my time was different from their time by several tenths of a second.

There are registry settings that should allow you to make w32time 
operate in much the same way as version 3 ntpd, including multiple 
servers and adaptive polling intervals.

If the time is exact is coming from a web site, it will be subject to 
all the same sorts of disturbance as doing ntpd at only one point in 
time.  Real NTP used measurements made at different times.

If you are getting discrepancies at only some times of day, the most 
likely reason is that the measurements are being affected by different 
asymmetries in the round trip time.
>
> Concerning offset, thanks for feedback! I should say that when I browse to time.is, it report "Your time is exact", and therefore I believe my computer is set to "correct" time.
>

If you want to know if your clock is accurate, you need a clock that is 
an order of magnitude better as a reference.  The time measured by a web 
site is going to have at least the level of uncertainty in a single ntpd 
poll.  ntpd itself will have smoothed this by considering the results of 
multiple polls, and by taking steps to eliminate the worst poll results. 
  You will not be reporting true time, as you will not know what 
asymmetries exist that would bias the time one way or the other.

0
David
10/24/2016 9:04:53 AM
James Kajder wrote:
> Why do you suggest maxpoll 6 with Windows 10? Meinberg suggests
> maxpoll 7 and minpoll 6 in the file their install creates. I have
> tried leaving maxpoll / minpoll out, and it doesn't seem to "hurt"
> anything - browsing to time.is I still get "Your time is exact" even
> after the computer being on all day and the poll interval is 1024.

ntpd for Windows contains a workaround for Windows Vista / Windows 7 and
corresponding server versions where small time adjustments are not
handled properly by the windows timekeeping:

"SetSystemTimeAdjustment May Lose Adjustments Less than 16"
https://support.microsoft.com/de-de/kb/2537623

This workaround works only properly if the polling interval is 6 (64s)
or greater. When using pool servers and other public servers the minimum
polling interval should no be less than 6 anyway, thus the "minpoll 6"
in the default configuration.


Also, there is a bug report in NTP bugzilla saying that time
synchronization can become unstable if the polling interval grows above
7 (128s), and personal tests have shown that this at least *can* happen.
See:
https://www.meinbergglobal.com/download/burnicki/time_synchronization_accuracy_with_ntp.pdf

Personally I've seen that "maxpoll 6" yields even better results than
"maxpoll 7", but the operators of pool and other public servers don't
like their servers to be polled more often than necessary, which I
understand well.

On the other hand, if you don't limit ntpd's polling rate it can happen
that ntpd itself decides to stay at poll 6 (64s), so this can happen anyway.

Thus the "maxpoll 7" in the ntp.conf created by the installer, but I'd
use "maxpoll 6" for clients polling my *own* server.


Concerning the "pool" directive, unless I'm missing something:

The pool DNS servers now use geolocation of IP addresses to provide a
client with "near" IP addresses.

Especially when using a laptop, if you override this by using something like

pool uk.pool.ntp.org  maxpoll 7 iburst

you are still stuck with "far" NTP servers when you are travelling to
other countries, while geolocation should should get servers which are
"near" to your location, even when you're traveling.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany
0
Martin
10/24/2016 9:08:45 AM
Reply: