[ntp:hackers] I/O

David L. Mills mills at udel.edu
Tue Feb 15 10:45:32 PST 2005


The problem apparently is only with the refclocks. It looks as if 
input_handler() is not scarfing up all the buffers that have data. This 
is pretty wierd, as the clock sends messages at one-second intervals.


mayer at gis.net wrote:

>Are we only talking about the refclocks or is this also in the network
>interfaces. I can change the input_handler() code to reread the
>data if the previous read is successful (ie bytecount > 0) and put that
>in a separate buffer or until the recvbuffs fill up. Does that make
>----- Original Message Follows -----
>>On one of my two "identical" Freebies the refclock I/O hangs in a lop;
>>on the other it acts like Solaris. I discover on Solaris no loop, but 
>>apparently some I/O is being lost. What happens is that I/O timecodes 
>>get bottled up in buffers somewhere, but not delivered to the clock 
>>drivers. The drivers expect one timecode line each second, but only 
>>about one per minute show up and the rest are bufferened. After awhile
>>the data get very old and the driver delivers broken updates. This
>>began  happening only recently. All the code I'm running is from
>>Danny's most  recent.
>>hackers mailing list
>>hackers at support.ntp.org

More information about the hackers mailing list