[ntp:hackers] I/O

mayer at gis.net mayer at gis.net
Tue Feb 15 15:24:02 PST 2005


Dave,

In that case if you set MAXZEROREADS to 1 it will work that way.
We can always change the code afterwards.

Danny
----- Original Message Follows -----
> 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
> >>
> 
> _______________________________________________
> hackers mailing list
> hackers at support.ntp.org
> https://support.ntp.org/mailman/listinfo/hackers



More information about the hackers mailing list