[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