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

In article <433C0260.1060305@xxxxxxxxxxxxxx> Tom Smith
<smith@xxxxxxxxxxxxxx> writes:
>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'll raise you one, here is ntp-dev-4.2.0b-20050926:

remote refid st t when poll reach delay offset jitter
==============================================================================
10.1.1.234 .INIT. 16 u - 64 0 0.000 0.000 0.002
10.1.1.235 .INIT. 16 u - 64 0 0.000 0.000 0.002
10.1.1.236 .INIT. 16 u - 64 0 0.000 0.000 0.002

It has surely never received a packet from any of those "servers", since
they simply don't exist.

> 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.

Absolutely agreed. And even if ntpd kept trying them without showing
them in 'ntpq -p' it would be a loss I think.

--Per Hedeland
per@xxxxxxxxxxxx
.

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)