[ntp:questions] Re: ACTS - too many recvbufs allocated (40) (Correct the Version of ntp-dev)
Ronan Flood
ronan at noc.ulcc.ac.uk
Mon Feb 21 17:10:13 UTC 2005
On Fri, 18 Feb 2005 23:06:00 +0000, "David L. Mills" <mills at udel.edu> wrote:
> Some kernels require CLOCAL to be set for remote connections in order to
> enable modem control interrupts and some do not. On the Ultra10s here
> the DSR bit is dark, so the modem has not asserted Data Set Ready. It
> should come up only after the call is answered. Your modems, internal
> and external, should operate the same way. Start with the trace turned
> on and look for the line with "modem status". The hex number displayed
> is the status bits defined in the termios.h header file. If the
> TIOCM_DSR (400) bit is lit, your modem does not conform to the Bell 103
> specification. It might well be that some Hayes command can turn it off.
Not my modems, I'm not using any. cipo's modems in the case at hand.
There does appear to be a Hayes command to govern the behaviour, &Sn.
&S0 asserts DSR at all times, &S1 asserts DSR when a call is active.
I don't know which is the default, or which is "correct".
> If DSR is lit at startup, the port is presumed connected to a PPS source
> and interrupts are enabled.
Indeed, but could that not be done in atom_start() and similar places,
when ntpd knows from ntp.conf that it's expecting PPS?
(And BTW shouldn't atom_start() be using O_NOCTTY when it opens the device,
like refclock_open() does?)
> I suspect your internal modem does provide a
> DSR signal at startup, which would be an error. However, in either case,
> there should be no I/O error and the modem should continue normally. I
> can't reproduce your problems here.
I noticed on ntp:hackers you mentioned a problem with your system
"rackety" which looked very like this. Possibly turning on soft
carrier would fix this without affecting other behaviour.
> At least for the ACTS and USNO services, the driver must run in raw mode
> in order to capture an accurate timestamp for the on-time character.
I don't think the state of CLOCAL affects that.
--
Ronan Flood <R.Flood at noc.ulcc.ac.uk>
working for but not speaking for
Network Services, University of London Computer Centre
(which means: don't bother ULCC if I've said something you don't like)
More information about the questions
mailing list