home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / protocol / time / ntp / 861 < prev    next >
Encoding:
Text File  |  1992-09-02  |  4.8 KB  |  117 lines
  1. Newsgroups: comp.protocols.time.ntp
  2. Path: sparky!uunet!walter!porthos!iscp.bellcore.com!jhc
  3. From: jhc@iscp.bellcore.com (Jonathan Clark)
  4. Subject: Newbie xntp user seeks enlightenment
  5. Organization: Bellcore
  6. Date: Wed, 2 Sep 92 15:15:15 GMT
  7. Message-ID: <1992Sep2.151515.10956@porthos.cc.bellcore.com>
  8. Sender: netnews@porthos.cc.bellcore.com (USENET System Software)
  9. Lines: 106
  10.  
  11. Greetings.
  12.  
  13. I have XNTP v3.1 (tar file dated Aug 24 from louie) up and running on an
  14. IBM RS6000 workstation under AIX 3.2, and I have some naive questions
  15. about what I'm seeing when I query the server and in the logfile. Rather
  16. than hacking through the code, I thought I'd ask the net. Note that I
  17. am by no means a guru in this topic, and my use of language is probably
  18. woefully imprecise, but please bear with me.
  19.  
  20. For example, I have the following output:
  21.  
  22. rain$ /usr/lbin/xntpdc -p
  23.      remote           local      st poll reach  delay   offset   disp
  24. ======================================================================
  25. *flash.bellcore. 128.96.144.169   1   64    7  0.0144  0.009685 7.8921
  26.  
  27. I read this as meaning that I'm:
  28.  
  29.     - I'm currently synchronized to flash
  30.     - which is running at stratum 1 (it has a WWVB clock),
  31.     - I poll flash every 64 seconds,
  32.     - the next poll is in 37 seconds,
  33.     - the reachability was 7 (octal)
  34.     - the filter delay was 0.0144s, 14.4ms,
  35.     - the offset was -0.009685s, 9.68ms, and
  36.     - the dispersion was 7.8921s, or 7892.1ms.
  37.  
  38. First set of questions. Am I correct in believing that:
  39.  
  40.     - the reachability is the number of queries which were
  41.       successfully processed, so in this case the last 3 packets
  42.       were good (and something nasty happened before that)?
  43.     - the filter delay is measurement of how long it takes xntpd
  44.       to do its processing?
  45.     - the offset is the amount the server differs from its clock?
  46.     - the dispersion is the difference between the local time and
  47.       the time reported by the server?
  48.  
  49. From the 'sysinfo' command of xntpdc I have a sync distance of 0.0115
  50. and a sync dispersion of 1.3065 (this was about 15 minutes later).
  51.  
  52.     - the sync distance is an estimate of the round-trip packet
  53.       time in seconds?
  54.     - the sync dispersion means the same as above, but the time
  55.       difference between me and flash is now rather less.
  56.  
  57. Consecutively to the above I issued an 'ntpq -p' command, which gave me:
  58.  
  59. rain$ /usr/lbin/ntpq -p
  60.      remote           refid      st when poll reach  delay  offset   disp
  61. =========================================================================
  62. #flash.bellcore. .WWVB.           1   37   64    7    14.4    9.68 7892.1
  63.  
  64. ie basically the same thing except with a factor of 1000 thrown in.
  65. From this I conclude that one of the two man pages is in error, since
  66. both claim that they print out their results in seconds. I presume that
  67. xntpdc actually produces seconds and ntpq milliseconds, am I right?
  68.  
  69. Turning now to the log files, I think I have the various system and peer
  70. status flags sorted out. However, I get messages like these occasionally:
  71.  
  72.     offset -0.006618 freq -0.76593 comp 0
  73.  
  74. This is part of the hourly statistics. The offset is as above (the
  75. amount the kernel clock is off?), and am I correct in thinking that
  76. the freq field is the amount the hardware clock needs adjusting to
  77. keep perfect time? comp seems to be ``log2 of time constant'', but
  78. what's that?
  79.  
  80.     adjust: STEP dropped (128.96.32.20 offset 0.556186199) 
  81.     adjust: STEP 128.96.32.20 offset 0.555446148 
  82.  
  83. These two mean that the difference between kernel time and the server's
  84. time was greater than could be corrected by slewing the clock, and that
  85. the kernel time was stepped? In the first case the time wasn't actually
  86. stepped because it was too soon since the last correction.
  87.  
  88. Now, if anyone is still reading, I have some questions about my target
  89. configuration. This is for an isolated network without a radio clock,
  90. and set up pretty much as a tree. Right now I have one workstation set
  91. up as a master, using its local clock, with this config file:
  92.  
  93.     # local ref clock at stratum 1
  94.     server 127.127.1.1
  95.     fudge 127.127.1.1
  96.  
  97. When I use xntpdc -p this successfully tells me that I'm claiming to have
  98. a stratum 1 clock. However, four of the five workstations I have which
  99. are using me as a server, all with identical binaries and config files,
  100. which consist of the single line:
  101.  
  102.     server 128.96.144.169
  103.  
  104. see me as being on stratum 16, while the other one sees me at startum 2,
  105. which is what I expect! This one machine used to see me at stratum 16,
  106. but apparently changed its mind overnight. Anyone care to share some
  107. light about what's going on? Or can someone tell me how to set up my
  108. various configuration files so that this works like I want?
  109.  
  110. All help and comments gratefully accepted. If there's interest and people
  111. respond by mail, I'll summarize.
  112.  
  113. Jonathan Clark
  114. jhc@iscp.bellcore.com
  115.  
  116. The Englishman never enjoys himself except for some noble purpose.
  117.