Differences

This shows you the differences between two versions of the page.

Link to this comparison view

reference:ntp [2011/09/29 23:13]
simon
reference:ntp [2011/09/30 15:00] (current)
simon
Line 15: Line 15:
  
 The start of each entry is prefixed by a character: The start of each entry is prefixed by a character:
-| x | **Falsetick:** The peer is discarded by the intersection algorithm as a falseticker. | +**x** | **Falsetick:** The peer is discarded by the intersection algorithm as a falseticker. | 
-| . | **Excess:** The peer is discarded as not among the first ten peers sorted by synchronization distance and so is probably a poor candidate for further consideration. | +**.** | **Excess:** The peer is discarded as not among the first ten peers sorted by synchronization distance and so is probably a poor candidate for further consideration. | 
-| - | **Outlyer:** The peer is discarded by the clustering algorithm as an outlyer. | +**-** | **Outlyer:** The peer is discarded by the clustering algorithm as an outlyer. | 
-| + | **Candidate:** The peer is a survivor and a candidate for the combining algorithm. | +**+** | **Candidate:** The peer is a survivor and a candidate for the combining algorithm. | 
-| # | **Selected:** The peer is a survivor, but not among the first six peers sorted by synchronization distance. If the assocation is ephemeral, it may be demobilized to conserve resources.  | +**#** | **Selected:** The peer is a survivor, but not among the first six peers sorted by synchronization distance. If the assocation is ephemeral, it may be demobilized to conserve resources.  | 
-| * | **sys.peer:** The peer has been declared the system peer and lends its variables to the system variables. | +***** | **sys.peer:** The peer has been declared the system peer and lends its variables to the system variables. | 
-| o | **pps.peer:** The peer has been declared the system peer and lends its variables to thesystem variables. However, the actual system synchronization is derived from a pulse-per-second (PPS) signal, either indirectly via the PPS reference clock driver or directly via kernel interface. |+**o** | **pps.peer:** The peer has been declared the system peer and lends its variables to thesystem variables. However, the actual system synchronization is derived from a pulse-per-second (PPS) signal, either indirectly via the PPS reference clock driver or directly via kernel interface. |
  
 The following values are described below: The following values are described below:
  
 **remote:** **remote:**
 +
 IP address of peer IP address of peer
  
 **refid** **refid**
 +
 IP address of reference for peer IP address of reference for peer
  
-|st Stratum of peer | +**st:** 
-|Type of peer (Local, unicast, multicast or broadcast) | + 
-when When the last packet was received (number of seconds ago)<html><br /></html>+Stratum of peer 
 + 
 +**t:** 
 + 
 +Type of peer (Local, unicast, multicast or broadcast) 
 + 
 +**when:** 
 + 
 +When the last packet was received (number of seconds ago)
 Every time a when count reaches the poll number in the same line, the NTP daemon queries the time from the corresponding time source and resets the when count to 0. The query results of each polling cycle are filtered and used as a measure for the clock's quality and reachability.  Every time a when count reaches the poll number in the same line, the NTP daemon queries the time from the corresponding time source and resets the when count to 0. The query results of each polling cycle are filtered and used as a measure for the clock's quality and reachability. 
-| poll | Polling interval (seconds) | 
  
-How often the time server is queried  +**poll:** 
-Reachability register (octal)+ 
 +Polling interval (seconds) - How often the time server is queried. 
 + 
 +**reach:**
  
-The column reach shows if a reference time source could be reached at the last polling intervals, i.e. data could be read from the reference time source, and the reference time source was synchronized.+The column reach (reachability register - octal) shows if a reference time source could be reached at the last polling intervals, i.e. data could be read from the reference time source, and the reference time source was synchronized.
  
 The value must be interpreted as an 8 bit shift register whose contents is displayed as octal values. If the NTP daemon has just started, the value is 0. Each time a query was successful a '1' is shifted in from the right, so after the daemon has been started the sequence of reach numbers 0, 1, 3, 7, 17, 37, 77, 177, 377.  The value must be interpreted as an 8 bit shift register whose contents is displayed as octal values. If the NTP daemon has just started, the value is 0. Each time a query was successful a '1' is shifted in from the right, so after the daemon has been started the sequence of reach numbers 0, 1, 3, 7, 17, 37, 77, 177, 377. 
Line 46: Line 59:
 The maximum value 377 means that the eight last queries were completed successfully. The NTP daemon must have reached a reference time source several times (reach not 0) before it selects a preferred time source and puts an asterisk in the first column.  The maximum value 377 means that the eight last queries were completed successfully. The NTP daemon must have reached a reference time source several times (reach not 0) before it selects a preferred time source and puts an asterisk in the first column. 
 Estimated delay (miliseconds) Estimated delay (miliseconds)
 +
 +**delay:**
  
 The delay value is derived from the roundtrip time of the queries.  The delay value is derived from the roundtrip time of the queries. 
-Offset (miliseconds) 
  
-The offset value shows the difference between the reference time and the system clock. If the reference clock is ahead of the system clock, you'll have a positive number.  +**offset:** 
-Dispersion/jitter (miliseconds).+ 
 +The offset (miliseconds) in value shows the difference between the reference time and the system clock. If the reference clock is ahead of the system clock, you'll have a positive number.  
 + 
 +**jitter:** 
 + 
 +The jitter (dispersion - miliseconds) value indicates the magnitude of jitter between several time queries
  
-The jitter value indicates the magnitude of jitter between several time queries.  
  
 ===== NTP Drift ===== ===== NTP Drift =====
  
 The calculated system NTP drift value is stored in ntp.drift. This is the error in the intrinsic frequency of the clock on the computer it is running on. The calculated system NTP drift value is stored in ntp.drift. This is the error in the intrinsic frequency of the clock on the computer it is running on.
 +
 Its recorded in PPM (parts per million), and is the systematic frequency error of the system clock (i.e. the clock permanently loses time or gains time). If ntp.drift contains 0.000, your clock perfectly keeps time (except for random errors). Its recorded in PPM (parts per million), and is the systematic frequency error of the system clock (i.e. the clock permanently loses time or gains time). If ntp.drift contains 0.000, your clock perfectly keeps time (except for random errors).
 +
 +<code>
 100 PPM = 8.64 seconds / day 100 PPM = 8.64 seconds / day
 12 PPM correspond to one second per day roughly. 12 PPM correspond to one second per day roughly.
 500 PPM mean the clock is off by about 43 seconds per day. 500 PPM mean the clock is off by about 43 seconds per day.
 +</code>
 +
 Therefore, a value of -13.409 in ntp.drift implies the system clock is approximately 1.16 seconds slower than the reference clock a day. Therefore, a value of -13.409 in ntp.drift implies the system clock is approximately 1.16 seconds slower than the reference clock a day.
-NTP Frequency Errors: + 
-Frequency error ? exceeds tolerance 500 PPM+=====  NTP Frequency Errors =====  
 + 
 +**Frequency error ? exceeds tolerance 500 PPM:** 
 The hardware clock frequency error exceeds the rate the kernel can correct. This could be a hardware or a kernel problem.  The hardware clock frequency error exceeds the rate the kernel can correct. This could be a hardware or a kernel problem. 
-Log Error clk_fault: 
-clock LOCAL(1) event 'clk_fault' (0x03) 
-The message simply results from a variable which has not been properly initilized so that the message is printed before the clock's status has been checked. You can simply ignore it. 
  
 +**Log Error clk_fault - clock LOCAL(1) event 'clk_fault' (0x03):**
 +
 +The message simply results from a variable which has not been properly initilized so that the message is printed before the clock's status has been checked. You can simply ignore it.
  
-===== NTP Slew:=====  
  
 +===== NTP Slew ===== 
  
-Whilst NTP daemon is runningit will only ever slew the clock, it will never step it – this will prevent MLS/GTS failures+Under ordinariy conditionsntpd adjusts the clock in small steps so that the timescale is effectively continuous and without discontinuities. Under conditions of extreme network congestion, the roundtrip delay jitter can exceed three seconds and the synchronization distance, which is equal to one-half the roundtrip delay plus error budget termscan become very large
  
-Slew rate is a maximum of 500PPM, which is ~ 0.5ms/second correction+The ntpd algorithms discard sample offsets exceeding 128 msunless the interval during which no sample offset is less than 128 ms exceeds 900sThe first sample after that, no matter what the offset, steps the clock to the indicated time. In practice this reduces the false alarm rate where the clock is stepped in error to a vanishingly low incidence.
  
-Under ordinariy conditions, ntpd adjusts the clock in small steps so that the timescale is effectively continuous and without discontinuities. Under conditions of extreme network congestion, the roundtrip delay jitter can exceed three seconds and the synchronization distance, which is equal to one-half the roundtrip delay plus error budget terms, can become very large. The ntpd algorithms discard sample offsets exceeding 128 ms, unless the interval during which no sample offset is less than 128 ms exceeds 900s. The first sample after that, no matter what the offset, steps the clock to the indicated time. In practice this reduces the false alarm rate where the clock is stepped in error to a vanishingly low incidence. 
 As the result of this behavior, once the clock has been set, it very rarely strays more than 128 ms, even under extreme cases of network path congestion and jitter. Sometimes, in particular when ntpd is first started, the error might exceed 128 ms. This may on occasion cause the clock to be set backwards if the local clock time is more than 128 s in the future relative to the server. In some applications, this behavior may be unacceptable. If the -x option is included on the command line, the clock will never be stepped and only slew corrections will be used. As the result of this behavior, once the clock has been set, it very rarely strays more than 128 ms, even under extreme cases of network path congestion and jitter. Sometimes, in particular when ntpd is first started, the error might exceed 128 ms. This may on occasion cause the clock to be set backwards if the local clock time is more than 128 s in the future relative to the server. In some applications, this behavior may be unacceptable. If the -x option is included on the command line, the clock will never be stepped and only slew corrections will be used.
 +
 The issues should be carefully explored before deciding to use the -x option. The maximum slew rate possible is limited to 500 parts-per-million (PPM) as a consequence of the correctness principles on which the NTP protocol and algorithm design are based. As a result, the local clock can take a long time to converge to an acceptable offset, about 2,000 s for each second the clock is outside the acceptable range. During this interval the local clock will not be consistent with any other network clock and the system cannot be used for distributed applications that require correctly synchronized network time. The issues should be carefully explored before deciding to use the -x option. The maximum slew rate possible is limited to 500 parts-per-million (PPM) as a consequence of the correctness principles on which the NTP protocol and algorithm design are based. As a result, the local clock can take a long time to converge to an acceptable offset, about 2,000 s for each second the clock is outside the acceptable range. During this interval the local clock will not be consistent with any other network clock and the system cannot be used for distributed applications that require correctly synchronized network time.
 A slewed clock never moves backwards; it is just slowed down. A slewed clock never moves backwards; it is just slowed down.
 +
 The maximum slew rate is 500PPM, which corresponds to a maximum adjustment of 0.5ms / second correction. The maximum slew rate is 500PPM, which corresponds to a maximum adjustment of 0.5ms / second correction.
-Enabling Logging: 
-logconfig =all 
  
 ===== Single Daily Correction =====  ===== Single Daily Correction ===== 
 +
 ntpd -q -M -g -c "c:\Program Files\NTP\etc\ntp.conf" ntpd -q -M -g -c "c:\Program Files\NTP\etc\ntp.conf"
  
  
  
 
reference/ntp.txt · Last modified: 2011/09/30 15:00 by simon
 
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki