[ntp:hackers] I/O

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


Danny,

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.

Dave

mayer at gis.net wrote:

>Dave,
>
>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
>refclocks
>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
>sense?
>
>Danny
>
>----- Original Message Follows -----
>  
>
>>Guys,
>>
>>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.
>>
>>Dave
>>
>>_______________________________________________
>>hackers mailing list
>>hackers at support.ntp.org
>>https://support.ntp.org/mailman/listinfo/hackers
>>    
>>




More information about the hackers mailing list