mayer at gis.net
mayer at gis.net
Tue Feb 15 10:55:24 PST 2005
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.
----- Original Message Follows -----
> 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
> mayer at gis.net wrote:
> >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?
> >----- Original Message Follows -----
> >>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.
> >>hackers mailing list
> >>hackers at support.ntp.org
> hackers mailing list
> hackers at support.ntp.org
More information about the hackers