[ntp:hackers] I/O

mayer at gis.net mayer at gis.net
Tue Feb 15 14:30:40 PST 2005


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