[ntp:questions] Re: ACTS - too many recvbufs allocated (40) (Correct the Version of ntp-dev)

David L. Mills mills at udel.edu
Mon Feb 21 18:37:20 UTC 2005


I don't know if it makes any sense to prolong this discussion.

1. The atom driver is not the only one to use PPS. Many of the GPS 
drivers use PPS as well.

2. Whether or not a Hayes command exists, my modems are reset to factory 
default, which should correspond to the Bell 103 state machine.

3. The atom driver receives no data on its open device, only PPSAPI 
interrupts. It doesn't make sense to use O_NOCTTY, especially since the 
open could apply to another open on the same device for data.

4. The symptoms you report have nothing in common with the looping 
behavior noticed on one of our systems.

5. CLOCAL has nothing to do with canon/raw mode. Raw mode is selected in 
refclock_open() by the LDISC_RAW flag, which selects ICANON or not.

I tire of this discussion. Can we move on to something else?


Ronan Flood wrote:
> 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.

More information about the questions mailing list