[ntp:hackers] FreeBSD serial ports

David L. Mills mills at udel.edu
Tue Feb 15 19:20:24 PST 2005


Greg,

No. The maxpoll/minpoll values are initialized in newpeer() in 
ntp_peer.c before the refclock code. It's the same with all 
associations. YOu get to set it from the configuration file. While the 
defaults are inappropriate for the ACTS driver, I'm reluctant to take 
away the means to change the values. The user can't override the default 
values in the driver either, unless as you suggested they are fixed. The 
current code can operate over a much wider range of poll values than the 
former. Without the state machine the maximum minpoll was 1024 s. As you 
see, mine is set at 4096 s.

Greg Dowd wrote:

>Are you saying that if the max and min poll values are initialized in
>the driver, they overwrite any ntp.conf server options?  If that's the
>case, then I don't want to upset that behavior.  I'll use the ntp.conf
>method.  But, doesn't that violate the least astonishment principle?  It
>would be nice to have the driver suggest baseline values and have the
>user override them if desired.  A minpoll of 64 and a maxpoll of 1024
>seconds for a modem driver seems incorrect.  Neither would they be for a
>gps receiver, right?
>
>As for the i/o changes, how about if you and Danny finish whatever as
>this is the exact same code that we are discussing in parallel.  I'm
>happy to test the updated change in Linux and report results for both
>&C0 and &C1.  If the driver itself still needs a patch, I'm happy to
>volunteer.
>
>
>
>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 support.ntp.org] On Behalf Of David L. Mills
>Sent: Tuesday, February 15, 2005 2:44 PM
>Cc: hackers at ntp.org
>Subject: Re: [ntp:hackers] FreeBSD serial ports
>
>Greg,
>
>If you make the minpoll/maxpoll changes, users will not be able to
>select other settings using the server command options. That's why I
>took the original defaults out. In fact, I use minpoll 12, maxpoll 17. 
>In any case, your maxpoll is a factor of two greater than what the loop
>is designed for. Make that 18 a 17. The FIXPOLL set by default clamps
>the poll to minpoll, whatever it is set to. If the bit is cleared, the
>association will manage it just like an ordinary server.
>
>The backup mode was broken and had nasty circularities. The intent of
>backup mode is to run only when the "primary" server has failed and that
>only after some time in that state. It would be nice if "no other server
>except this one" was the case instead, but that requires some quirky
>logic in clock_select(). I might to that yet.
>
>I checked the code and found in raw mode the timeout function is
>disabled, so the Unix driver code will never return a zero length chunk.
>
>That makes life easier for input_handler().
>
>I'm not an I/O expert, so will not comment about that.
>
>Dave
>
>Greg Dowd wrote:
>
>
>>Cool.  We agree on the &C0 flag then.  The comment still needs to 
>>change.
>>
>>Poll interval.
>>The 1.11 rev (big change to support NIST/USNO/PTB/NPL) about 6 months 
>>ago was where the poll interval code got lost.  I'll put them back to 
>>what they were and add the code to the init routine again.
>>-#define ACTS_MINPOLL	10	/* log2 min poll interval (1024 s) */
>>-#define ACTS_MAXPOLL	18	/* log2 max poll interval (16384 s) */
>>And
>>-	peer->minpoll = ACTS_MINPOLL;
>>-	peer->maxpoll = ACTS_MAXPOLL;
>>Do I need to do this after FIXPOLL is masked?  
>>
>>Loop problem.
>>Do you want to do more than just set the flag properly?  I'd be happy 
>>to hook io_rcv and tell input_handler to dump the buff on 0 length in 
>>refclock_acts but that won't fix the problem since there is a forever 
>>loop on select.  Next step might be to set a MAX_ZERO_BUF that gets 
>>incremented by 0 length io_rcv and zeroed by real data read.  Hit the 
>>ceiling and we shut down the driver and log an error?
>>
>>A larger issue might be dealing with nasty refclock drivers that hog 
>>system resources.  If all buffers are exhausted and a check indicates 
>>that all are in use by a single driver, I'd be tempted to boot that 
>>driver.  Of course, it's probably typical to use just a single refclock
>>
>
>>driver at a time so you'd expect them to be owned by a single driver.
>>Maybe a bandwidth filter where if all bufs exhausted, owned by a single
>>
>
>>driver and timestamps differ by less than MIN_VAL out you go.
>>
>>Operating mode:
>>I liked the old MODE_BACKUP.  I'll have to study the MODE_PREFER more 
>>to understand the difference.  I don't get peer->unreach check.  
>>Wouldn't you want something from sys_peer?
>>
>>       /*
>>        * In prefer mode the calling program runs continuously as long
>>        * as the prefer peer is unreachable.
>>        */
>>       case MODE_PREFER:
>>               if (sys_prefer != NULL) {
>>                       if (peer->unreach >= NTP_UNREACH)
>>                               pp->sloppyclockflag |= CLK_FLAG1;
>>               }
>>               break;
>>
>>
>>Poll mechanism:
>>This is a different issue from poll interval.  I agree that the new 
>>implementation of 1hz callback is much cleaner and easier to control.
>>
>>Good stuff.
>>
>>
>>
>>
>>
>>
>>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 support.ntp.org] On Behalf Of David L. Mills
>>Sent: Tuesday, February 15, 2005 11:45 AM
>>Cc: hackers at ntp.org
>>Subject: Re: [ntp:hackers] FreeBSD serial ports
>>
>>Greg,
>>
>>Sorry; got the wrong flag. As I said, it's not my string and I trust 
>>others. As far as the loop is concerned, that should be fixed, as there
>>
>
>>are other cases (raw mode timeout) where a zero-length string is 
>>significant. The modem doesn't know about EOF, just the state of the 
>>modem control leads. Different operating systems might interpret them 
>>differently and, in some modes, Unix ignores them entirely.
>>
>>I expected that not many people would use the driver and those that do 
>>would prefer to use it only when disconnected from a net server. With 
>>the explosion of calling plans with no per-call charge, that usage may 
>>change. I did confirm it works with the European services.
>>
>>The poll mechansism was always awkward for the ACTS driver. It has been
>>
>
>>replaced by a one-second interrupt call. The replacement code is much 
>>smaller and the state machine is much simpler and more straighforward, 
>>especially for error recovery. It should, however, behave in the same 
>>manner as the old.
>>
>>Dave
>>
>>Greg Dowd wrote:
>>
>>
>>
>>>I'll submit a diff but I think these changes have to be approved by 
>>>you
>>>
>>>
>>>if I remember correctly.  Someone removed the whole POLL init 
>>>mechanism
>>>
>>>
>>>including #defines and code. Also, can we please agree to use &C
>>>(AMPERSAND) when discussing this init string parameter?  The dropping 
>>>of the ampersand confuses things since they are completely different 
>>>variables.
>>>
>>>Although I've seen very little traffic regarding the acts driver, I 
>>>presume that you get many threads of query.  My current understanding 
>>>is that the &C0 is required, by parties foreign and domestic.  Without
>>>
>
>>>this flag, unless an individual modem has defaulted the value, the 
>>>driver will hang when a connection is dropped.  The input_handler hits
>>>
>
>>>select infinitely, eats buffers, etc.  My reading (I profess 
>>>ignorance)
>>>
>>>
>>>is that eof is a valid state for the modem and results in an infinite 
>>>series of 0 length reads and selects.  The input_handler will hard 
>>>loop
>>>
>>>
>>there.
>>
>>
>>>With the &C0, everybody is a happy camper.
>>>
>>>
>>>
>>>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 support.ntp.org] On Behalf Of David L. Mills
>>>Sent: Tuesday, February 15, 2005 11:04 AM
>>>Cc: hackers at ntp.org
>>>Subject: Re: [ntp:hackers] FreeBSD serial ports
>>>
>>>Greg,
>>>
>>>The FIXPOLL flag is initialized at 1, which means all drivers will 
>>>normally not monkey with the poll interval. It is masked off in ACTS, 
>>>as that driver does need to fiddle the poll interval. I didn't change 
>>>the poll machine and it should still run the poll program as before.
>>>
>>>I din't make up the modem initialization string; somebody else swore 
>>>by
>>>
>>>
>>>it. Last I saw it was C1, but I see somebody changed it to C0. I was 
>>>told that wouldn't work with US modems, so I tried it just now (with
>>>C0) and it worked like a charm, at least with a USR modem. Is this the
>>>
>
>>>way you want it? I'd rather it be C1, as that gives another 
>>>opportunity
>>>
>>>
>>>for the server to clear the call quickly. If this causes ntpd to loop 
>>>on a zero-length message, let's fix ntpd.
>>>
>>>Dave
>>>
>>>Greg Dowd wrote:
>>>
>>>
>>>
>>>
>>>
>>>>I understand, and agree, that the current modem initialization string
>>>>
>
>>>>is correct.  The comment is wrong.  We had this discussion in the 
>>>>bugtrack with respect to C1 versus &C0(but I think sometimes we show 
>>>>as
>>>>  
>>>>
>>>>
>>>>
>>>anonymous
>>>
>>>
>>>
>>>
>>>>to you).   
>>>>
>>>>However, I have another concern which is that you removed the driver 
>>>>setting of minpoll/maxpoll in the driver init which ends up clamping 
>>>>the poll interval to 1024.  There is some code I don't recognize with
>>>>
>
>>>>FIXPOLL which is only present (and masked off) in the acts refclock 
>>>>driver.  Is this some temporary state?  I understand that there could
>>>>
>
>>>>be an issue that a call may not be complete before the next poll 
>>>>interval ticks but I don't see how this impacts maxpoll.
>>>>
>>>>And I still liked the backup mode which I understand had a bug but I 
>>>>think could have been corrected with a change in ntp_io but I can't 
>>>>remember when I walked this code.
>>>>
>>>>All said, the conversion to raw mode is great.  I have no idea how 
>>>>many
>>>>  
>>>>
>>>>
>>>>
>>>
>>>
>>>>other refclock drivers this will break which is why I didn't dare 
>>>>suggest it myself.  Thanks for the good work.
>>>>
>>>>
>>>>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 support.ntp.org] On Behalf Of David L. 
>>>>Mills
>>>>Sent: Tuesday, February 15, 2005 5:39 AM
>>>>Cc: hackers at ntp.org
>>>>Subject: Re: [ntp:hackers] FreeBSD serial ports
>>>>
>>>>Greg,
>>>>
>>>>Let me be very clear. The explicit and purposeful intent is to use 
>>>>the
>>>>
>>>>
>>>>given initialization string. The US modems don't work otherwise. It 
>>>>may
>>>>  
>>>>
>>>>
>>>>
>>>
>>>
>>>>well be that Europeans need to use a different one and I am warm to 
>>>>that. In any case, a zero length buffer should not hang the driver.
>>>>
>>>>Dave
>>>>
>>>>Greg Dowd wrote:
>>>>
>>>>
>>>>
>>>>  
>>>>
>>>>
>>>>
>>>>>Here's the reply that I got from Dave talking about his serial
>>>>>
>>>>>
>>driver.
>>
>>
>>>>> 
>>>>>
>>>>>    
>>>>>
>>>>>
>>>>>
>>>>>>>Greg,
>>>>>>>
>>>>>>>     
>>>>>>>
>>>>>>>The code should return a zero length buffer anyway, as that 
>>>>>>>conforms
>>>>>>>
>>>>>>>     
>>>>>>>
>>>>>>>        
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>to the Unix termios semantics. In raw mode >>the ioctl specifies the
>>>>>
>
>>>>>number of characters and/or the time to wait. What happens here is 
>>>>>there are no >>characters and the timer expires.
>>>>>
>>>>>
>>>>> 
>>>>>
>>>>>    
>>>>>
>>>>>
>>>>>
>>>>>>>I expect the bug has been around for a long time, as there have 
>>>>>>>been
>>>>>>>
>>>>>>>     
>>>>>>>
>>>>>>>        
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>occasions when these symptoms appear with >>no clear explanation.
>>>>>
>>>>>
>>>>> 
>>>>>
>>>>>    
>>>>>
>>>>>
>>>>>
>>>>>>>Dave
>>>>>>>
>>>>>>>     
>>>>>>>
>>>>>>>        
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>What we were talking about is the refclock read routine in 
>>>>>ntpd/ntp_io.c's input_handler.  My primary problem was, and still 
>>>>>is,
>>>>>
>>>>>
>>>>>with the ACTS refclock driver.  There is still a bug, at least for 
>>>>>Linux, in that the value of &C is incorrectly set to &C0 (DCD
>>>>>override)
>>>>> 
>>>>>
>>>>>    
>>>>>
>>>>>
>>>>>
>>>>  
>>>>
>>>>
>>>>
>>>>>in the modem initialization string.  I thought I had convinced Dave 
>>>>>when the comment got updated but the code never did.  The end result
>>>>>
>
>>>>>is
>>>>> 
>>>>>
>>>>>    
>>>>>
>>>>>
>>>>>
>>>>  
>>>>
>>>>
>>>>
>>>>>that the serial code will return 0 (eof) if the phone line gets
>>>>> 
>>>>>
>>>>>    
>>>>>
>>>>>
>>>>>
>>>>dropped.
>>>>
>>>>
>>>>  
>>>>
>>>>
>>>>
>>>>>This causes an endless loop in input_handler.
>>>>>
>>>>>Anyway, looking at the input_handler refclock read routine, you'll 
>>>>>see
>>>>>    
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>>>that read will accept a 0 length receive and load it into a buf.  If
>>>>>
>
>>>>>the input device keeps returning 0 length reads, the code loops 
>>>>>until
>>>>>
>>>>>
>>>>>exhausting all the buffers and then continues to loop discarding
>>>>>    
>>>>>
>>>>>
>>>>>
>>>input.
>>>
>>>
>>>
>>>
>>>>>A reference clock driver doesn't get a chance to notice or correct 
>>>>>the
>>>>>    
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>>>behavior as the upcall never happens unless the driver specifies a 
>>>>>io_rcv function to note the 0 length and return 0 which tells the 
>>>>>input_handler to drop the buffer.
>>>>>
>>>>>For the acts ref clock driver, the easy fix is to correct the init 
>>>>>string.  For a belt and suspenders approach, the driver could hook 
>>>>>io_rcv and discard 0 length buffers.
>>>>>
>>>>>For the rest of the drivers and the io subsystem, I don't know.  I 
>>>>>have
>>>>> 
>>>>>
>>>>>    
>>>>>
>>>>>
>>>>>
>>>>  
>>>>
>>>>
>>>>
>>>>>never seen a definition of the refclock io system interface other 
>>>>>than
>>>>>    
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>>>reading the code or asking Dave.  An occasional 0 length timeout and
>>>>>
>
>>>>>read would, presumably, be handled by most functional drivers 
>>>>>without
>>>>>
>>>>>
>>>>>choking, although the acts and Dave's serial driver refute that.
>>>>>Having said that, I'm confused about what purpose a 0 length 
>>>>>callback
>>>>>
>>>>>
>>>>>with timestamp would serve.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>Greg Dowd
>>>>>gdowd at symmetricom dot com (antispam format) Technologist, TT&M
>>>>>
>>>>>
>>Div.
>>
>>
>>>>>Symmetricom, Inc. 
>>>>>www.symmetricom.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>-----Original Message-----
>>>>>From: Danny Mayer [mailto:mayer at gis.net]
>>>>>Sent: Friday, February 11, 2005 7:06 PM
>>>>>To: Greg Dowd; David L. Mills; hackers at ntp.org
>>>>>Subject: RE: [ntp:hackers] FreeBSD serial ports
>>>>>
>>>>>At 12:27 PM 2/10/2005, Greg Dowd wrote:
>>>>>
>>>>> 
>>>>>
>>>>>    
>>>>>
>>>>>
>>>>>
>>>>>>Dave,
>>>>>>    That may be fixed by changing the 0 length read to drop the 
>>>>>>recvbuf and continue.  That fix didn't work for ACTS since the 
>>>>>>daemon
>>>>>>      
>>>>>>
>>>>>>
>>>>>>
>>>
>>>
>>>>>>would hard loop there forever since 0 length read meant eof without
>>>>>>
>
>>>>>>&C
>>>>>>   
>>>>>>
>>>>>>      
>>>>>>
>>>>>>
>>>>>>
>>>>  
>>>>
>>>>
>>>>
>>>>>>change.  If the problem is a momentary glitch in hardware, perhaps 
>>>>>>it
>>>>>>      
>>>>>>
>>>>>>
>>>>>>
>>>
>>>
>>>>>>would recover?
>>>>>>
>>>>>>The daemon really shouldn't be allocating a recvbuf on a 0 length 
>>>>>>read
>>>>>>   
>>>>>>
>>>>>>     =20
>>>>>>
>>>>>>
>>>>>>
>>>>  
>>>>
>>>>
>>>>
>>>>>>anyway, should it?  There's no state that I know of where you would
>>>>>>
>
>>>>>>need to timestamp the hangup in refclock.
>>>>>>
>>>>>>   
>>>>>>
>>>>>>      
>>>>>>
>>>>>>
>>>>>>
>>>>>Greg, can you send me detailed information on this? I'm in the 
>>>>>process
>>>>>    
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>>>of cleaning up the code.
>>>>>
>>>>>Danny
>>>>>
>>>>>
>>>>> 
>>>>>
>>>>>    
>>>>>
>>>>>
>>>>>
>>>>_______________________________________________
>>>>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