[ntp:hackers] I/O

David L. Mills mills at udel.edu
Tue Feb 15 14:50:21 PST 2005


Danny,

Copied ntp_io.c from yours to /pogo/dist/ntp4/ntpd for test, but it 
failed to compile. Something about specific_interface. As I said in 
another message, you should not have to deal with zero-length chunks, so 
the first should be the last until the next poll.

Dave

mayer at gis.net wrote:

>Dave,
>
>I did another update to the input_handler() code and I'm test running it
>on rackety. This version of the code will do a continuous read of the
>refclock socket until it either gets an error (bytes < 0) or it exceeds
>MAXZEROREADS, currently set to 20, which represents the maximum number
>of consecutive reads of 0 bytes from the socket. I thought this was
>a reasonable compromise to ensure that things don't get stuck on a
>socket which never returns any data. We can adjust that number.
>
>I'm test running the new code on rackety. It's not yet checked in
>but you can pick up a copy from my directory at:
>~mayer/ntp-dev/ntpd/ntp_io.c.
>
>If this is not right either we will need another goaround on this
>code.
>
>Danny
>----- Original Message Follows -----
>
>>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
>>>>   
>>>>
>>>>
>>_______________________________________________
>>hackers mailing list
>>hackers at support.ntp.org
>>https://support.ntp.org/mailman/listinfo/hackers
>>




More information about the hackers mailing list