[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