[Git][NTPsec/ntpsec][master] 2 commits: struct timeval elimination.
Eric S. Raymond
gitlab at mg.gitlab.com
Tue Oct 4 22:28:39 UTC 2016
Eric S. Raymond pushed to branch master at NTPsec / ntpsec
Commits:
7d8bbd76 by Eric S. Raymond at 2016-10-04T15:51:37-04:00
struct timeval elimination.
- - - - -
1690b354 by Eric S. Raymond at 2016-10-04T18:26:30-04:00
Replace the rather outdated quickstart page with...
...what we formerly wrote up as the clientstart. But save the
text about the panda along with its image; we might want that
historical flavor back sometime.
- - - - -
5 changed files:
- − docs/clientstart.txt
- docs/index.txt
- + docs/pic/panda.txt
- docs/quick.txt
- tests/libntp/ntpvis.c
Changes:
=====================================
docs/clientstart.txt deleted
=====================================
--- a/docs/clientstart.txt
+++ /dev/null
@@ -1,313 +0,0 @@
-= Quick Start for Client Configurations =
-
-[cols="10%,90%",frame="none",grid="none",style="verse"]
-|==============================
-|image:pic/orchestra.gif[]|
-{millshome}pictures.html[from 'Pogo', by Walt Kelly]
-
-Take it away, boys!
-
-|==============================
-
-
-== Related Links ==
-
-include::includes/hand.txt[]
-
-== Table of Contents ==
-
-* link:#introduction[Introduction]
-* link:#basics[Configuration Basics]
-* link:#pool[Configuring Pool Servers]
-* link:#howmany[How Many Servers?]
-* link:#gps[Configuring A Local GPS]
-* link:#dhcp[Special considerations when using DHCP]
-* link:#sanity[Sanity-Checking Your Time Service]
-
-'''''
-
-[[introduction]]
-== Introduction ==
-
-This page is a quick start for the 99% of NTP configurations that are
-not intended to serve time to others, but just run in client mode and
-optionally have a local GPS reference clock. It describes how to
-write a basic /etc/ntp.conf configuration file for this common case,
-and introduces some concepts that will be useful later on in the
-Handbook.
-
-If your NTP configuration was installed from a binary package (such as
-a deb or RPM file under Linux) you can use this introduction as a
-guide to reading it, but may not have to modify it at all.
-
-If you are using a typical residential setup, in which your machine
-performs DHCP to your ISP's servers and receives a dynamic address,
-your ntp.conf may be altered or generated by DHCP at
-address-allocation time to use the NTP servers provided by DHCP.
-
-[[basics]]
-== Configuration basics ==
-
-An NTP configuration file normally consists of three sections: logging
-controls, security/access controls, and server/refclock declarations. In
-most configurations the first two sections will be a boilerplate set
-of defaults.
-
-The simplest, minimal logging configuration consists of a line like this:
-
-------------------------------------------------------------------
-driftfile /var/lib/ntp/ntp.drift
-------------------------------------------------------------------
-
-This sets up a drift file, which is used to store a measurement of
-the drift frequency of your computer's clock crystal between runs
-of +{ntpd}. The drift is used to converge on correct time more quickly
-after startup.
-
-You might see something more like this:
-
-------------------------------------------------------------------
-driftfile /var/lib/ntp/ntp.drift
-
-statsdir /var/log/ntpstats/
-
-statistics loopstats peerstats clockstats
-filegen loopstats file loopstats type day enable
-filegen peerstats file peerstats type day enable
-filegen clockstats file clockstats type day enable
-
-logfile /var/log/ntpd.log
-logconfig =syncall +clockall +peerall +sysall
-------------------------------------------------------------------
-
-This is a logging section intended to enable maximum statistics and
-diagnostics useful for tuning your time service.
-
-Your security/access section will almost always look a lot like this:
-
-------------------------------------------------------------------
-restrict default kod limited nomodify nopeer noquery
-restrict -6 default kod limited nomodify nopeer noquery
-restrict 127.0.0.1
-restrict -6 ::1
-------------------------------------------------------------------
-
-This disallows configuration or +{ntpq}+ queries from anywhere off the
-local system.
-
-The server/refclock declarations are the most variable part of the
-configuration. They tell +{ntpd}+ what its sources for time are.
-
-In a pre-configured NTP installation set up by an OS vendor or
-distribution packager, you are likely to see a set of time-server
-declarations pointing at a vendor-specific set of NTP pool servers.
-Under Ubuntu Linux, for example, it probably looks like this:
-
-------------------------------------------------------------------
-server 0.ubuntu.pool.ntp.org
-server 1.ubuntu.pool.ntp.org
-server 2.ubuntu.pool.ntp.org
-server 3.ubuntu.pool.ntp.org
-------------------------------------------------------------------
-
-The next section will explain what pool servers are and why you might
-want to change them.
-
-[[pool]]
-== Configuring Pool Servers ==
-
-The NTP pool is a worldwide federation of public-facing NTP servers,
-many equipped with their own local reference clocks, that
-have volunteered to provide time service to anyone who requests it
-through a pool dispatcher machine. The +server+ declarations in your
-/etc/ntp.conf normally point at several of these pool dispatchers.
-When your +{ntpd}+ send a request to one, it picks a random server
-from its part of the pool and hands that address back to your
-+{ntpd}+.
-
-Note: while you could in theory request time service from any specific
-time server in the world, it is considered bad form to use a non-pool
-server unless you know you have permission. This applies, in
-particular, to various public timeservers maintained by corporations
-or academic institutions and intended to be used by their members.
-
-For high-quality time service it is advantageous if your upstream
-servers are located where packet-transit times to you are short and
-there is little random variation in them. Because the NTP pool is
-worldwide, accepting a random assignment from it may give you a
-timeserver on the other side of the world. Thus, the pool is divided
-into subsections, each with its own dispatchers. To improve your
-service, pick a pool section near you on the network.
-
-Unfortunately, "near you on the network" is often difficult to map
-and changes unpredictably over time. However, there is a very
-rough correlation with national boundaries - more so when the
-country in question is geographically small and relatively advanced.
-Accordingly, the NTP pool has national sections for many countries,
-named by ISO country code.
-
-If you are in Great Britain, for example, you might want to use the UK
-section of the pool:
-
-------------------------------------------------------------------
-server 0.uk.pool.ntp.org
-server 1.uk.pool.ntp.org
-server 2.uk.pool.ntp.org
-server 3.uk.pool.ntp.org
-------------------------------------------------------------------
-
-If you know your ISO country code, it is often possible to find an
-analogous group of servers by pinging them.
-
-Ideally, one would like one's servers to use multiple different kinds
-of timesources (as opposed to, say, all being GPS-based) and be split
-across different autonomous networks as a hedge against outages and
-routing probems. Unfortunately, the random nature of pool allocation
-makes this imposssible to guarantee. It is, however, worth keeping in mind if
-you can set up a custom configuration with non-pool servers that you
-have permission to use.
-
-[[howmany]]
-== How Many Servers?
-
-If you have only one server, things are simple. Your system will
-follow that server even if it doesn't have the correct time. (Your
-server might bail if the local clock is too far off - see
-link:clock.html#panic[panic threshold].)
-
-Two servers might seem like a simple redundant setup, but what happens
-if they don't agree? NTP has no way to determine which one is
-correct.
-
-If you have three servers, two can outvote a
-link:ntpspeak.html[falseticker]. But that reduces to two if one of
-them is not responding.
-
-If you are using 4 servers, you still have 3 if one of them stops
-responding. Unless you are serving time to other systems,
-this is a reasonable setup. It is normal for client-only systems
-
-You can add more servers. With 5 servers, you still have 3 if 2 are
-down and 3 can outvote 2 falsetickers. That may be appropriate if you
-need high reliability, say because you are serving hundreds of
-clients.
-
-[[gps]]
-== Configuring A Local GPS ==
-
-Connecting a local GPS to your machine will provide extremely
-accurate time, provided it has link:ntpspeak.html[PPS] capability.
-(However, unless your GPS has a perfect continuous skyview, you will still
-want check servers from the pool.)
-
-The easiest way to arrange this is by installing
-http://catb.org/gpsd/[GPSD] to watch the GPS, and configuring your +{ntpd}+
-to accept time from it. It is also possible to do this with native
-+{ntpd}+ drivers (nmea, jupiter, trimble, oncore), though these are
-less flexible and a bit more difficult to configure.
-
-The following configuration lines tell your +{ntpd}+ to accept time
-from GPSD:
-
-------------------------------------------------------------------
-refclock shm unit 0 refid GPS
-refclock shm unit 1 prefer refid PPS
-------------------------------------------------------------------
-
-For details on setting up the GPSD end, see the
-http://catb.org/gpsd/gpsd-time-service-howto.html[GPSD Time Service
-HOWTO].
-
-[[dhcp]]
-== Special considerations when using DHCP ==
-
-If your machine uses DHCP to get a dynamic IP address from your ISP,
-that handshake may provide you with a list of NTP servers.
-Suspect this if, when you look at your ntp.conf, you
-see server domain names obviously belonging to your ISP or
-your ntpq -p printout doesn't match what you expect.
-
-The way this works is that your DHCP client requests the list,
-then it restarts your +{ntpd}+ with a custom configuration file
-generated from that list.
-
-A good thing about this is that your ISP is likely to hand you servers
-that are close to you on its network and will thus have fairly steady
-ping times. A bad thing is that you may have difficulty making
-configuration of a local reference clock stick.
-
-One family of systems with this behavior is Debian Linux, including
-Ubuntu. On these systems the DHCP client is NetworkManager. If you
-look in your /etc/init.d/ntp file, you may see something like this:
-
-------------------------------------------------------------------
-if [ -e /var/lib/ntp/ntp.conf.dhcp ]; then
- NTPD_OPTS="$NTPD_OPTS -c /var/lib/ntp/ntp.conf.dhcp"
-fi
-------------------------------------------------------------------
-
-The -c option tells +{ntpd} that the path to a generated configuration
-file follows. The generation process might pick up your local changes
-to ntp.conf or it might not; this depends on your OS supplier (Debian
-derivatives normally 'do' base on your local ntp.conf). If it does,
-all is well. If it does not, you may have to modify the hook scripts
-that generate that file, or disable the generation process.
-
-[[sanity]]
-== Sanity-Checking Your Time Service ==
-
-Here's how to tell if and/or how well your time service is working.
-Wait a few minutes for it to sync with upstream servers, then fire
-up ntpq with the -p (peers) option. You should see a display looking
-something like this:
-
-------------------------------------------------------------------
- remote refid st t when poll reach delay offset jitter
-==============================================================================
-*b1-66er.matrix. 18.26.4.105 2 u 871 1024 377 6.655 1.042 0.659
-+tools.ninjaneer 216.218.254.202 2 u 268 1024 377 69.917 0.275 0.858
--96.226.123.230 129.7.1.66 2 u 689 1024 377 43.322 -2.322 0.982
--a1.pcloud.com 18.26.4.105 2 u 861 1024 377 41.805 -2.283 0.453
-+juniperberry.ca 17.253.34.253 2 u 682 1024 377 82.361 0.927 1.370
-------------------------------------------------------------------
-
-If you have a local GPS you should see something like this:
-
-------------------------------------------------------------------
- remote refid st t when poll reach delay offset jitter
-==============================================================================
-xSHM(0) .GPS. 0 l 39 64 377 0.000 -591.41 70.967
-*SHM(1) .PPS. 0 l 43 64 377 0.000 0.003 0.004
-+time-a.timefreq .ACTS. 1 u 5 64 377 48.438 0.487 3.163
--time-a.nist.gov .ACTS. 1 u 23 64 377 73.233 32.901 0.587
--fwwds-1-pt.tunn 173.162.192.156 2 u 11 64 377 48.311 -2.082 2.649
-+clocka.ntpjs.or 192.5.41.40 2 u 22 64 377 13.146 0.743 0.644
-------------------------------------------------------------------
-
-The first two lines represent the refclock.
-
-In both cases, the column to look at first is the "reach". A value of
-377 indicates that your client has been getting samples continuously
-for eight poll intervals. A value of 0 is bad - it means you're not
-communicating with the upstream server or clock at all. To interpret other
-values, you need to interpret the reach column in octal, expand
-it to binary, and read each bit as a yes/no for its poll interval
-Thus, for example, 017 means samples from the last four polls but
-none before that.
-
-Next, you want to look at the line for "preferred" server (marked with
-*). This is the one that is closest to the approximation of UTC that
-NTP's algorithms have computed from its inputs. What you want to see here
-is low jitter. The PPS feed in the second example is pretty good. The
-figures from 18.26.4.105 in the first display are not great, but
-they're not out of line for operation over a WAN. Offset over a
-second is most likely due to asymmetric packet delays; large jitter
-is more likely due to bufferbloat and other sources of variable
-latency under load.
-
-
-'''''
-
-include::includes/footer.txt[]
-
-// end
=====================================
docs/index.txt
=====================================
--- a/docs/index.txt
+++ b/docs/index.txt
@@ -244,7 +244,7 @@ A good deal of tutorial and directive information is available on the
handbook pages. These should be read in conjunction with the command and
option information available on the pages listed on the sitemap page.
-link:clientstart.html[Quick start for client configurations]::
+link:quick.html[Quick start for client configurations]::
Basic configuration for 99% of client installations. Introduces
concepts used later in the Handbook.
link:assoc.html[Association Management]::
=====================================
docs/pic/panda.txt
=====================================
--- /dev/null
+++ b/docs/pic/panda.txt
@@ -0,0 +1,14 @@
+// This is preserved from the old quickstart page in case we ever want
+// the historical flavor again.
+.FAX test image for SATNET (1979).
+image:pic/panda.gif[]
+
+The baby panda was scanned at University College London and used as a
+FAX test image for a demonstration of the DARPA Atlantic SATNET Program
+and the first transatlantic Internet connection in 1978. The computing
+system used for that demonstration was called the
+http://www.eecis.udel.edu/%7emills/database/papers/fuzz.ps[Fuzzball]. As
+it happened, this was also the first Internet multimedia presentation
+and the first to use a predecessor of NTP in regular operation. The
+image was widely copied and used for testing purpose throughout much of
+the 1980s.
=====================================
docs/quick.txt
=====================================
--- a/docs/quick.txt
+++ b/docs/quick.txt
@@ -1,83 +1,313 @@
-= Quick Start =
+= Quick Start for Client Configurations =
-.FAX test image for SATNET (1979).
-image:pic/panda.gif[]
+[cols="10%,90%",frame="none",grid="none",style="verse"]
+|==============================
+|image:pic/orchestra.gif[]|
+{millshome}pictures.html[from 'Pogo', by Walt Kelly]
+
+Take it away, boys!
+
+|==============================
-The baby panda was scanned at University College London and used as a
-FAX test image for a demonstration of the DARPA Atlantic SATNET Program
-and the first transatlantic Internet connection in 1978. The computing
-system used for that demonstration was called the
-http://www.eecis.udel.edu/%7emills/database/papers/fuzz.ps[Fuzzball]. As
-it happened, this was also the first Internet multimedia presentation
-and the first to use a predecessor of NTP in regular operation. The
-image was widely copied and used for testing purpose throughout much of
-the 1980s.
== Related Links ==
-include::includes/install.txt[]
+include::includes/hand.txt[]
+
+== Table of Contents ==
+
+* link:#introduction[Introduction]
+* link:#basics[Configuration Basics]
+* link:#pool[Configuring Pool Servers]
+* link:#howmany[How Many Servers?]
+* link:#gps[Configuring A Local GPS]
+* link:#dhcp[Special considerations when using DHCP]
+* link:#sanity[Sanity-Checking Your Time Service]
'''''
-For the rank amateur the sheer volume of the documentation collection
-must be intimidating. However, it doesn't take much to fly the +{ntpd}+
-daemon with a simple configuration where a workstation needs to
-synchronize to some server elsewhere in the Internet. The first thing is
-to build the distribution for the particular workstation and install in
-the usual place. The link:build.html[Building and Installing the
-Distribution] page describes how to do this.
-
-While it is possible that certain configurations do not need a
-configuration file, most do. The file, called by default
-+/etc/{ntpconf}+, need only contain one command specifying a remote
-server, for instance
-
-+server foo.bar.com+
-
-Choosing an appropriate remote server is somewhat of a black art, but a
-suboptimal choice is seldom a problem. The simplest and best is to use
-the Server Pool Scheme on the link:discover.html[Automatic Server
-Discovery] page. There are about two dozen public time servers operated
-by the http://tf.nist.gov/tf-cgi/servers.cgi[National Institutes of
-Science and Technology (NIST)], http://tycho.usno.navy.mil/ntp.html[US
-Naval Observatory (USNO)],
-http://www.nrc-cnrc.gc.ca/eng/services/time/network_time.html[Canadian
-Metrology Centre (CMC)] and many others available on the Internet. Lists
-of public primary and secondary NTP servers maintained on the
-http://support.ntp.org/Servers/WebHome[Public NTP Time Servers] page,
-which is updated frequently. The lists are sorted by country and, in the
-case of the US, by state. Usually, the best choice is the nearest in
-geographical terms, but the terms of engagement specified in each list
-entry should be carefully respected.
-
-During operation +{ntpd}+ measures and corrects for incidental clock
-frequency error and occasionally writes the current value to a file
-specified by the
-
-+driftfile /etc/ntp.drift+
-
-configuration command. If +{ntpd}+ is stopped and restarted, it
-initializes the frequency from this file and avoids the potentially
-lengthy interval to relearn the correction.
-
-That's all there is to it, unless some problem in network connectivity
-or local operating system configuration occurs. The most common problem
-is some firewall between the workstation and server. System
-administrators should understand NTP uses UDP port 123 as both the
-source and destination port and that NTP does not involve any operating
-system interaction other than to set the system clock. While almost all
-modern Unix systems have included NTP and UDP port 123 defined in the
-services file, this should be checked if +{ntpd}+ fails to come up at all.
-
-The best way to confirm NTP is working is using the
-link:ntpq.html[+{ntpq}+] utility. See the documentation pages for
-further information. Don't forget to check for link:msyslog.html[system
-log messages]. In the most extreme cases the +-d+ option on the +{ntpd}+
-command line results in a blow-by-blow trace of the daemon operations.
-While the trace output can be cryptic, to say the least, it gives a
-general idea of what the program is doing and, in particular, details
-the arriving and departing packets and any errors found.
+[[introduction]]
+== Introduction ==
+
+This page is a quick start for the 99% of NTP configurations that are
+not intended to serve time to others, but just run in client mode and
+optionally have a local GPS reference clock. It describes how to
+write a basic /etc/ntp.conf configuration file for this common case,
+and introduces some concepts that will be useful later on in the
+Handbook.
+
+If your NTP configuration was installed from a binary package (such as
+a deb or RPM file under Linux) you can use this introduction as a
+guide to reading it, but may not have to modify it at all.
+
+If you are using a typical residential setup, in which your machine
+performs DHCP to your ISP's servers and receives a dynamic address,
+your ntp.conf may be altered or generated by DHCP at
+address-allocation time to use the NTP servers provided by DHCP.
+
+[[basics]]
+== Configuration basics ==
+
+An NTP configuration file normally consists of three sections: logging
+controls, security/access controls, and server/refclock declarations. In
+most configurations the first two sections will be a boilerplate set
+of defaults.
+
+The simplest, minimal logging configuration consists of a line like this:
+
+------------------------------------------------------------------
+driftfile /var/lib/ntp/ntp.drift
+------------------------------------------------------------------
+
+This sets up a drift file, which is used to store a measurement of
+the drift frequency of your computer's clock crystal between runs
+of +{ntpd}. The drift is used to converge on correct time more quickly
+after startup.
+
+You might see something more like this:
+
+------------------------------------------------------------------
+driftfile /var/lib/ntp/ntp.drift
+
+statsdir /var/log/ntpstats/
+
+statistics loopstats peerstats clockstats
+filegen loopstats file loopstats type day enable
+filegen peerstats file peerstats type day enable
+filegen clockstats file clockstats type day enable
+
+logfile /var/log/ntpd.log
+logconfig =syncall +clockall +peerall +sysall
+------------------------------------------------------------------
+
+This is a logging section intended to enable maximum statistics and
+diagnostics useful for tuning your time service.
+
+Your security/access section will almost always look a lot like this:
+
+------------------------------------------------------------------
+restrict default kod limited nomodify nopeer noquery
+restrict -6 default kod limited nomodify nopeer noquery
+restrict 127.0.0.1
+restrict -6 ::1
+------------------------------------------------------------------
+
+This disallows configuration or +{ntpq}+ queries from anywhere off the
+local system.
+
+The server/refclock declarations are the most variable part of the
+configuration. They tell +{ntpd}+ what its sources for time are.
+
+In a pre-configured NTP installation set up by an OS vendor or
+distribution packager, you are likely to see a set of time-server
+declarations pointing at a vendor-specific set of NTP pool servers.
+Under Ubuntu Linux, for example, it probably looks like this:
+
+------------------------------------------------------------------
+server 0.ubuntu.pool.ntp.org
+server 1.ubuntu.pool.ntp.org
+server 2.ubuntu.pool.ntp.org
+server 3.ubuntu.pool.ntp.org
+------------------------------------------------------------------
+
+The next section will explain what pool servers are and why you might
+want to change them.
+
+[[pool]]
+== Configuring Pool Servers ==
+
+The NTP pool is a worldwide federation of public-facing NTP servers,
+many equipped with their own local reference clocks, that
+have volunteered to provide time service to anyone who requests it
+through a pool dispatcher machine. The +server+ declarations in your
+/etc/ntp.conf normally point at several of these pool dispatchers.
+When your +{ntpd}+ send a request to one, it picks a random server
+from its part of the pool and hands that address back to your
++{ntpd}+.
+
+Note: while you could in theory request time service from any specific
+time server in the world, it is considered bad form to use a non-pool
+server unless you know you have permission. This applies, in
+particular, to various public timeservers maintained by corporations
+or academic institutions and intended to be used by their members.
+
+For high-quality time service it is advantageous if your upstream
+servers are located where packet-transit times to you are short and
+there is little random variation in them. Because the NTP pool is
+worldwide, accepting a random assignment from it may give you a
+timeserver on the other side of the world. Thus, the pool is divided
+into subsections, each with its own dispatchers. To improve your
+service, pick a pool section near you on the network.
+
+Unfortunately, "near you on the network" is often difficult to map
+and changes unpredictably over time. However, there is a very
+rough correlation with national boundaries - more so when the
+country in question is geographically small and relatively advanced.
+Accordingly, the NTP pool has national sections for many countries,
+named by ISO country code.
+
+If you are in Great Britain, for example, you might want to use the UK
+section of the pool:
+
+------------------------------------------------------------------
+server 0.uk.pool.ntp.org
+server 1.uk.pool.ntp.org
+server 2.uk.pool.ntp.org
+server 3.uk.pool.ntp.org
+------------------------------------------------------------------
+
+If you know your ISO country code, it is often possible to find an
+analogous group of servers by pinging them.
+
+Ideally, one would like one's servers to use multiple different kinds
+of timesources (as opposed to, say, all being GPS-based) and be split
+across different autonomous networks as a hedge against outages and
+routing probems. Unfortunately, the random nature of pool allocation
+makes this imposssible to guarantee. It is, however, worth keeping in mind if
+you can set up a custom configuration with non-pool servers that you
+have permission to use.
+
+[[howmany]]
+== How Many Servers?
+
+If you have only one server, things are simple. Your system will
+follow that server even if it doesn't have the correct time. (Your
+server might bail if the local clock is too far off - see
+link:clock.html#panic[panic threshold].)
+
+Two servers might seem like a simple redundant setup, but what happens
+if they don't agree? NTP has no way to determine which one is
+correct.
+
+If you have three servers, two can outvote a
+link:ntpspeak.html[falseticker]. But that reduces to two if one of
+them is not responding.
+
+If you are using 4 servers, you still have 3 if one of them stops
+responding. Unless you are serving time to other systems,
+this is a reasonable setup. It is normal for client-only systems
+
+You can add more servers. With 5 servers, you still have 3 if 2 are
+down and 3 can outvote 2 falsetickers. That may be appropriate if you
+need high reliability, say because you are serving hundreds of
+clients.
+
+[[gps]]
+== Configuring A Local GPS ==
+
+Connecting a local GPS to your machine will provide extremely
+accurate time, provided it has link:ntpspeak.html[PPS] capability.
+(However, unless your GPS has a perfect continuous skyview, you will still
+want check servers from the pool.)
+
+The easiest way to arrange this is by installing
+http://catb.org/gpsd/[GPSD] to watch the GPS, and configuring your +{ntpd}+
+to accept time from it. It is also possible to do this with native
++{ntpd}+ drivers (nmea, jupiter, trimble, oncore), though these are
+less flexible and a bit more difficult to configure.
+
+The following configuration lines tell your +{ntpd}+ to accept time
+from GPSD:
+
+------------------------------------------------------------------
+refclock shm unit 0 refid GPS
+refclock shm unit 1 prefer refid PPS
+------------------------------------------------------------------
+
+For details on setting up the GPSD end, see the
+http://catb.org/gpsd/gpsd-time-service-howto.html[GPSD Time Service
+HOWTO].
+
+[[dhcp]]
+== Special considerations when using DHCP ==
+
+If your machine uses DHCP to get a dynamic IP address from your ISP,
+that handshake may provide you with a list of NTP servers.
+Suspect this if, when you look at your ntp.conf, you
+see server domain names obviously belonging to your ISP or
+your ntpq -p printout doesn't match what you expect.
+
+The way this works is that your DHCP client requests the list,
+then it restarts your +{ntpd}+ with a custom configuration file
+generated from that list.
+
+A good thing about this is that your ISP is likely to hand you servers
+that are close to you on its network and will thus have fairly steady
+ping times. A bad thing is that you may have difficulty making
+configuration of a local reference clock stick.
+
+One family of systems with this behavior is Debian Linux, including
+Ubuntu. On these systems the DHCP client is NetworkManager. If you
+look in your /etc/init.d/ntp file, you may see something like this:
+
+------------------------------------------------------------------
+if [ -e /var/lib/ntp/ntp.conf.dhcp ]; then
+ NTPD_OPTS="$NTPD_OPTS -c /var/lib/ntp/ntp.conf.dhcp"
+fi
+------------------------------------------------------------------
+
+The -c option tells +{ntpd} that the path to a generated configuration
+file follows. The generation process might pick up your local changes
+to ntp.conf or it might not; this depends on your OS supplier (Debian
+derivatives normally 'do' base on your local ntp.conf). If it does,
+all is well. If it does not, you may have to modify the hook scripts
+that generate that file, or disable the generation process.
+
+[[sanity]]
+== Sanity-Checking Your Time Service ==
+
+Here's how to tell if and/or how well your time service is working.
+Wait a few minutes for it to sync with upstream servers, then fire
+up ntpq with the -p (peers) option. You should see a display looking
+something like this:
+
+------------------------------------------------------------------
+ remote refid st t when poll reach delay offset jitter
+==============================================================================
+*b1-66er.matrix. 18.26.4.105 2 u 871 1024 377 6.655 1.042 0.659
++tools.ninjaneer 216.218.254.202 2 u 268 1024 377 69.917 0.275 0.858
+-96.226.123.230 129.7.1.66 2 u 689 1024 377 43.322 -2.322 0.982
+-a1.pcloud.com 18.26.4.105 2 u 861 1024 377 41.805 -2.283 0.453
++juniperberry.ca 17.253.34.253 2 u 682 1024 377 82.361 0.927 1.370
+------------------------------------------------------------------
+
+If you have a local GPS you should see something like this:
+
+------------------------------------------------------------------
+ remote refid st t when poll reach delay offset jitter
+==============================================================================
+xSHM(0) .GPS. 0 l 39 64 377 0.000 -591.41 70.967
+*SHM(1) .PPS. 0 l 43 64 377 0.000 0.003 0.004
++time-a.timefreq .ACTS. 1 u 5 64 377 48.438 0.487 3.163
+-time-a.nist.gov .ACTS. 1 u 23 64 377 73.233 32.901 0.587
+-fwwds-1-pt.tunn 173.162.192.156 2 u 11 64 377 48.311 -2.082 2.649
++clocka.ntpjs.or 192.5.41.40 2 u 22 64 377 13.146 0.743 0.644
+------------------------------------------------------------------
+
+The first two lines represent the refclock.
+
+In both cases, the column to look at first is the "reach". A value of
+377 indicates that your client has been getting samples continuously
+for eight poll intervals. A value of 0 is bad - it means you're not
+communicating with the upstream server or clock at all. To interpret other
+values, you need to interpret the reach column in octal, expand
+it to binary, and read each bit as a yes/no for its poll interval
+Thus, for example, 017 means samples from the last four polls but
+none before that.
+
+Next, you want to look at the line for "preferred" server (marked with
+*). This is the one that is closest to the approximation of UTC that
+NTP's algorithms have computed from its inputs. What you want to see here
+is low jitter. The PPS feed in the second example is pretty good. The
+figures from 18.26.4.105 in the first display are not great, but
+they're not out of line for operation over a WAN. Offset over a
+second is most likely due to asymmetric packet delays; large jitter
+is more likely due to bufferbloat and other sources of variable
+latency under load.
+
'''''
include::includes/footer.txt[]
+
+// end
=====================================
tests/libntp/ntpvis.c
=====================================
--- a/tests/libntp/ntpvis.c
+++ b/tests/libntp/ntpvis.c
@@ -7,15 +7,7 @@
TEST_GROUP(ntpvis);
#include "ntpd.h"
-#include "timevalops.h"
-
-/* second/usec pair to unsigned lfp */
-#define SECUSECTOTS(sec, usec, ts) \
- do { \
- (ts)->l_ui = (u_long)sec; \
- TVUTOTSF(usec, (ts)->l_uf); \
- } while (false)
-
+#include "timespecops.h"
static struct pkt ExamplePacket1 = {
.li_vn_mode = 6,
@@ -44,8 +36,8 @@ static char *ExampleDump2 = "6:2:3:-21:0:0:47505300:1474021718.5261510001:0.0000
TEST_SETUP(ntpvis) {
/* becomes lfp 1474021718.5261510001 */
- SECUSECTOTS(1474021718, 526151, &ExamplePacket1.reftime);
- SECUSECTOTS(1474021718, 526151, &ExamplePacket2.reftime);
+ struct timespec reftime = {1474021718, 526151000};
+ ExamplePacket2.reftime = ExamplePacket1.reftime = tspec_intv_to_lfp(reftime);
}
TEST_TEAR_DOWN(ntpvis) {}
View it on GitLab: https://gitlab.com/NTPsec/ntpsec/compare/ae7081b7bf1bb6aaa5d88b41fcdc6b9da3a64e9f...1690b3544450ac5d497ecda991646139e1cb70d5
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/vc/attachments/20161004/131ab9d6/attachment.html>
More information about the vc
mailing list