[ntp:hackers] Joy of ACTS, but some sorrow otherwise
David L. Mills
mills at udel.edu
Sat Feb 26 19:40:08 PST 2005
I confirmed with multicast/anycast server malarky that client bridgeport
behaves as I described previously. The association starts out with the
expected unicast address of malarky, then switches to its multicast
address, which wrecks Autokey. The newpeer() routine does the
initialization, which is correct. Nowhere else in the peer or protocol
code is dstadr modified. I conclude it has to be in the ntp_io.c, but I
can't find it.
Note as I said previously, the multicast and broadcast code behaves
differently. In that case the dstadr turns up zeros.
Danny Mayer wrote:
> At 09:06 PM 2/26/2005, David L. Mills wrote:
>> Host rackety has used some 192 minutes of CPU cycles in less than a
>> day. Before I axed out the error comment in ntp_io.c, an attempt to
>> read the clock resulted in a continuous scroll of error messaged. The
>> WWVB driver on rackety is identical to the one on pogo, which runs as
>> To see the evidence, start the daemon with -d -d and watch the trace.
> So why don't I see the dial string on rackety when I do this? I have a
> very large
> log file from this afternoon on rackety. There is no evidence that beyond
> opening a file decriptor that it knew what to do. That's why I wondered
> about broken hardware. Isn't it identical to mort's config?
>> The problem is not just a multicast client, it's an Autokey
>> multicast/broadcast client. I've described the problem in detail a
>> number of times recently. If you wish, I will describe it again.
> That's what bridgeport is using. It works fine as a multicast IPv4
More information about the hackers