Re: Servers just doen't work (after following the troubleshooting page)

Danny Mayer wrote:

I've spent a lot of time debugging this stuff. The fact is that if a server is not reachable in the first place it won't show up in the scoreboard and there is no association created. A refid of 0.0.0.0 doesn't mean a lot since we don't know what kind of ntp is responding to the requests. Other implementations may not even set the refid. We don't know since that not a piece of information we've been given.


At least through 4.2.0a, as long as a configured server has an address it
will show up on the billboard whether it's reachable or not. The only thing
that keeps it off is a name that doesn't resolve. I really wouldn't want to
see it any other way. Otherwise, if your server happens to be down when you
start, it will never be used.

Depending on the version of ntpd, a server that has not yet been reached
will show one of the following (which is, I think, indistinguishable from
a server that is reachable but that has never been synchronized since
the client ntpd started):

4.2.0a on WinXP:
 unreachable  .STEP.          16 u    -  128    0    0.000    0.000 4000.00
   [There IS a bug here, because that server is now reachable AND synchronized.
    It wasn't when ntpd started.]

4.2.0 on Tru64
 unreachable  .INIT.          16 u    - 1024    0    0.000    0.000 4000.00

4.1.2 on Linux
 unreachable  0.0.0.0         16 u    - 1024    0    0.000    0.000 4000.00

3.5f on HP-UX
 unreachable  0.0.0.0         16 -    -   64    0    0.000    0.000 16000.0

3-5.93e on Solaris
 unreachable  0.0.0.0         16 -    - 1024    0    0.000    0.000 16000.0

-Tom
.

Relevant Pages

  • Re: Master Time Server Help
    ... It looks like in this case your server can't resolve jac21797 IP address. ... ICMP: 23ms delay. ... NTP: -0.0094663s offset from JSTDC.johnstownamerica.com ... RefID: JSTDC.johnstownamerica.com ...
    (microsoft.public.windows.server.setup)
  • Re: refid on client differs from refid on local server
    ... I'm not aware of any mission calculated to "change my mind," much less whether to attempt DNS deconstruction of the refid field, on which I have no opinion. ... The common problem occurs when running a reference clock driver at elevated stratum, in which case the refid used to look like a mangled IP address, but now reveals the clock type instead. ... The refid's on the client distro's, when running ntpq> pe show the original IP address, as on the website for the stratum 2 servers, but the refid IP addresses on my server,are different. ...
    (comp.protocols.time.ntp)
  • Re: refid on client differs from refid on local server
    ... > Hi Danny. ... > whichever client is booted up always shows a valid IP address, ... the refid IS an IP address. ... but it's not a good or reliable indicator of where the remote server is ...
    (comp.protocols.time.ntp)
  • Re: Troubleshooting whos at fault
    ... itself as a stratum 2 with a refid of either 73.78.73.84 or LOCAL, ... The PTS -is- it's reference. ... our NTP hierarchy is not supposed to be individual time islands ... since only the RHEL server has a listing of possible ...
    (comp.protocols.time.ntp)
  • Re: refid on client differs from refid on local server
    ... >> server,are different. ... >> server just shows alternative hostnames under refid for the same ... Admittadly FC1 is using a slightly earlier version of NTP. ... and the relevant ntpq> pe outputs below that. ...
    (comp.protocols.time.ntp)