[ntp:hackers] FreeBSD serial ports

Greg Dowd GDowd at symmetricom.com
Mon Feb 14 15:10:24 PST 2005


Would you expect this to also address my problem with maxpoll clamping
at 2^^10? 

>From my email 2/8/05

Last time I checked was the middle of Jan but I'm still waiting.  Having
made the change, I've run the driver with good results (~2.5ms rms) but
I have an issue that maxpoll clamps at 2^^10(1024).  Ergo, 900 phone
calls over my 1 week test.  Luckily, it's not my phone bill.  Any
guesses on that?


server 127.127.18.3 prefer  # I needed the prefer to keep it from
switching to my local s1 ntp server?
phone ATDT13034944774
server 192.168.19.7  # local subnet GPS based ntp server # Disallow all
ntpdc commands from everybody...
restrict default nomodify
# ...but allow ntpdc from loopback
restrict 127.0.0.1
trustedkey 1 2 3 4 5 6 7 8 9 10 11 13 14 15 16 99 keys
/usr/local/etc/ntp.keys statsdir /tmp/ statistics peerstats rawstats
loopstats 


Greg Dowd
gdowd at symmetricom dot com (antispam format)
Technologist, TT&M Div.
Symmetricom, Inc. 
www.symmetricom.com




-----Original Message-----
From: mayer at gis.net [mailto:mayer at gis.net] 
Sent: Monday, February 14, 2005 2:46 PM
To: Greg Dowd; David L. Mills; hackers at ntp.org
Subject: RE: [ntp:hackers] FreeBSD serial ports

----- Original Message Follows -----
> Sorry, my bad. The code is right, the comment is wrong on the acts 
> modem init string in the latest dev pull.  &C0 is correct, DCD always 
> on.  The comment needs to change to &C0 as well.
> 

Probably because I only check this in this weekend. The looping problem
should also be fixed. If not please let me know. It was all a very nasty
mess. You should also have seen this in my response to your bug report
#367.

Danny

> 
> Greg Dowd
> gdowd at symmetricom dot com (antispam format) Technologist, TT&M Div.
> Symmetricom, Inc. 
> www.symmetricom.com
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> The information transmitted is intended only for the person or entity 
> to which it is addressed and may contain confidential and/or 
> privileged material.  Any review, retransmission, dissemination or 
> other use of, or taking of any action in reliance upon, this 
> information by persons or entities other than the intended recipient
> are prohibited.   If you received this in error, please contact the
> sender and delete the material from any computer.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> 
> 
> -----Original Message-----
> From: hackers-bounces at support.ntp.org 
> [mailto:hackers-bounces at support.ntp.org] On Behalf Of Greg Dowd
> Sent: Monday, February 14, 2005 1:31 PM
> To: Danny Mayer; David L. Mills; hackers at ntp.org
> Subject: RE: [ntp:hackers] FreeBSD serial ports
> 
> 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
> 




More information about the hackers mailing list