[ntp:hackers] I/O

David L. Mills mills at udel.edu
Tue Feb 15 19:46:00 PST 2005


Danny,

At least in the first few minutes, Solariba deacon and pogo appear okay 
as well as Freebie mort. However, Freebie rackety, which is configured 
like mort and should be running the same (your) code, apparently loops. 
Start it with two -d's and watch the refclock_gtraw() trace. I'm not 
sure we are out of the woods on the other machines; I'll let them run a bit.

Dave

mayer at gis.net wrote:

>Dave,
>
>Looks like you got mixed versions. I thought we were uptodate in the
>source pool. Pull ~mayer/ntp-dev/ntpd/cmd_args.c as well. I had
>added the capability of specifying an interface on the command line
>for people who wanted to limit the interfaces that the server
>listens on. Harlan will have to replenish the source pool.
>
>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