[Bug 3583] synchronization error

 - update docs on 'tos basedate'

bk: 5cc7e689hhgZEMvhttkyABTZjTMQ-Q

diff --git a/html/miscopt.html b/html/miscopt.html
index 247f5329040b3375ba78b76ec5b122fcc9524128..5e98b6492c3c5de3d76c1e9904525496b75d7be9 100644 (file)
--- a/html/miscopt.html
+++ b/html/miscopt.html
@@ -147,12 +147,16 @@
       <dd>Specifies the stepout threshold in seconds. The default without this command is 300 s. Since this option also affects the training and startup intervals, it should not be set less than the default. Further details are on the <a href="clock.html">Clock State Machine</a> page.</dd>
     </dl>
   </dd>
-  <dt id="tos"><tt>tos [basedate <i>date<i> | bcpollbstep <i>poll-gate</i> | beacon <i>beacon</i> | ceiling <i>ceiling</i> | cohort {0 | 1} | floor <i>floor</i> | maxclock <i>maxclock </i>| maxdist <i>maxdist</i> | minclock <i>minclock</i> | mindist <i>mindist </i>| minsane <i>minsane</i> | orphan <i>stratum</i> | orphanwait <em>delay</em>]</tt></dt>
+  <dt id="tos"><tt>tos [basedate <i>date</i> | bcpollbstep <i>poll-gate</i> | beacon <i>beacon</i> | ceiling <i>ceiling</i> | cohort {0 | 1} | floor <i>floor</i> | maxclock <i>maxclock </i>| maxdist <i>maxdist</i> | minclock <i>minclock</i> | mindist <i>mindist </i>| minsane <i>minsane</i> | orphan <i>stratum</i> | orphanwait <em>delay</em>]</tt></dt>
   <dd>This command alters certain system variables used by the the clock selection and clustering algorithms. The default values of these variables have been carefully optimized for a wide range of network speeds and reliability expectations. Very rarely is it necessary to change the default values; but, some folks can't resist twisting the knobs. It can be used to select the quality and quantity of peers used to synchronize the system clock and is most useful in dynamic server discovery schemes. The options are as follows:</dd>
   <dd>
     <dl>
       <dt><tt>basedate <i>date</i></tt></dt>
-      <dd>Set NTP era anchor. <tt><i>date</i></tt> is either a date in ISO8601 format (<i>YYYY-MM-DD<i>) or an integer giving the days since 1900-01-01, the start of the NTP epoch. <tt>ntpd</tt> will clamp the system time to an era starting with the begin of this this day (00:00:00Z), covering a range of 2<sup>32</sup> seconds or roughly 136 years. The default is the begin of the UNIX epoch, 1970-01-01.</dd>
+      <dd>Set NTP and GPS era anchor. <tt><i>date</i></tt> is either a date in ISO8601 format (<i>YYYY-MM-DD</i>) or an integer giving the days since 1900-01-01, the start of the NTP epoch. <tt>ntpd</tt> will clamp the system time to an era starting with the begin of this this day (00:00:00Z), covering a range of 2<sup>32</sup> seconds or roughly 136 years. The lowest accepted value is effectively 1970-01-02.<br>
+           The GPS era base is the next Sunday on or following the base date, but obviously not before 1980-01-06. GPS time stamps are mapped into the 1024 weeks following the GPS base.<br>
+       The default value is derived from the repository or build time stamp, minus 11 days. 1970-01-02 was chosen as lower bound so the <em>local</em> time is always after 1970-01-01,00:00. Some systems get into trouble if this is not the case.<p>
+       <b><u>ATTENTION:</u></b> If the system clock is before the effective (implied or specific) basedate, the system clock will be set to the base date once and immediately when <tt>ntpd</tt> starts. This helps systems that have lost time completely to recover. Though not noticeable under normal conditions, it <em>can</em> happen. Check the logs if starting <tt>ntpd</tt> causes sudden clock moves.     
+      </dd>
       <dt><tt>bcpollbstep <i>poll-gate</i></tt></dt>
       <dd>This option will cause the client to delay believing backward time steps from a broadcast server for <tt>bcpollbstep</tt> poll intervals.  NTP Broadcast networks are expected to be trusted, and if the server's time gets stepped backwards then it's desireable that the clients follow this change as soon as possible.  However, in spite of various protections built-in to the broadcast protocol, it is possible that an attacker could perform a carefully-constructed replay attack and cause clients to erroneously step their clocks backward.  If the risk of a successful broadcast replay attack is greater than the risk of the clients being out of sync in the event that there is a backward step on the broadcast time servers, this option may be used to cause the clients to delay beliveving backward time steps until <i>poll-gate</i> consecutive polls have been received.  The default is 0, which means the client will accept these steps upon receipt.  Any value from 0 to 4 can be specified.</dd>
       <dt><tt>beacon <i>beacon</i></tt></dt>