[ntp:hackers] I/O

David L. Mills mills at udel.edu
Tue Feb 15 19:51:21 PST 2005


Greg,

I checked in ntp-dev and found SMAX 80, which is where it started, not 
64. I don't know what happened, but I put it back to 256.

Dave

Greg Dowd wrote:

>Speaking of mixups, I noticed an anomaly looking at the changesets for
>ntpd/refclock_acts.c.  Dave's last change (1.20) had updated SMAX to
>256.  However, the latest (1.21) wrote back to 64.  Intentional?
>
> 
>
>
>Greg Dowd
>gdowd at symmetricom dot com (antispam format)
>Technologist, TT&M Div.
>Symmetricom, Inc. 
>www.symmetricom.com
>
>
>
>
>-----Original Message-----
>From: hackers-bounces at support.ntp.org
>[mailto:hackers-bounces at lists.ntp.isc.org] On Behalf Of mayer at gis.net
>Sent: Tuesday, February 15, 2005 3:17 PM
>To: David L. Mills
>Cc: hackers at support.ntp.org
>Subject: Re: [ntp:hackers] I/O
>
>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
>>
>_______________________________________________
>hackers mailing list
>hackers at support.ntp.org
>https://support.ntp.org/mailman/listinfo/hackers
>




More information about the hackers mailing list