[ntp:hackers] I/O
David L. Mills
mills at udel.edu
Tue Feb 15 11:10:06 PST 2005
Danny,
Yes; slurp up all the data as fast as possible. Don't leave anything
around that a slurpee could use. So far as refclocks are concerned, it
doesn't matter that data can be fragmented over multiple buffers (in raw
mode it normally is); the refclock interface assembles the data in lines
where necessary. Even zero length chunks are useful, as they can
represent a timeout.
Dave
mayer at gis.net wrote:
>Dave,
>
>Okay, so probably what needs to happen is to keep reading until there
>is nothing more to read and then move on? I assune you need to put
>each set of data in its own recvbuff and if you run out of buffers
>keep reading but drop them on the floor so that the system doesn't
>get clogged with data.
>
>Danny
>
>----- Original Message Follows -----
>
>
>>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
>>>>
>>>>
>>>>
>>>>
>>_______________________________________________
>>hackers mailing list
>>hackers at support.ntp.org
>>https://support.ntp.org/mailman/listinfo/hackers
>>
>>
More information about the hackers
mailing list