[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