[ntp:hackers] FreeBSD serial ports

Greg Dowd GDowd at symmetricom.com
Tue Feb 15 11:24:22 PST 2005


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
>>>      
>>>
>
>  
>
>>>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




More information about the hackers mailing list