[ntp:hackers] Joy of ACTS, but some sorrow otherwise

David L. Mills mills at udel.edu
Sat Feb 26 18:06:36 PST 2005


Danny,

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

To see the evidence, start the daemon with -d -d and watch the trace.

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.

Dave

Danny Mayer wrote:

> Dave,
>
> I borrowed rackety for a while this afternoon and I see absolutely 
> nothing
> wrong with the input_handler() code. I did do some cleanup and other 
> changes
> and I will do a little more tonight/tomorrow. The SPECTRACOM does
> not come up. I see an fd gets used but I never see it signal that it has
> data to transmit so I can only assume that there's something wrong either
> in the driver or the hardware itself.
>
> I looked at mort and it seems to be running fine with the last integrated
> changed I made (though it looks like MAXZEROREADS is still set to 20).
> So I don't think that there's anything wrong with the input_handler() 
> code
> unless you can show me otherwise in which case I'd probably like to
> borrow mort for a short while. I checked the flock and I can see that,
> for example, bridgeport is running fine as a multicast client. Which ones
> are mcast clients that are not working?
>
> Danny
>
> At 04:54 PM 2/25/2005, David L. Mills wrote:
>
>> Danny,
>>
>> I read somewhere that you said the input_handler bug has been fixed, 
>> but I can't confirm that in the ntp-dev branch here. I took out the 
>> "clock read" error comment, so at least malarky has joy of modem. 
>> Neither rackety nor clone mort have joy of the radio clocks. Both 
>> consume prodigious volumes of CPU cycles; mort actually can read the 
>> clock, but rackety cannot. The input_handler bug (if that's what it 
>> is) and various multicast bugs continue to haunt here.
>>
>> Dave
>




More information about the hackers mailing list