[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