[ntp:hackers] Good evening -- Multitech CDMA Modem clock driver -- where to submit?

Karl Denninger karl at denninger.net
Sat Feb 1 23:23:47 UTC 2014


On 2/1/2014 3:55 PM, Harlan Stenn wrote:
> Karl,
>
> What sort of precision do you get from the clock?
ntpq -c rl reports precision of -19; jitter is around 1ms on average
although without a PPS signal it can (and does) jump around
occasionally, especially if the system is under load.

I'm reasonable impressed with it, especially considering that there are
a lot of these around that nobody wants any more (and thus they're REAL
cheap on the surplus market.)   There are also USB versions;
theoretically those should work too, although there's no driver for the
USB chipset under FreeBSD (what I run here) so I have no immediate way
to find out.  Allegedly there is a driver for Linux; as long as it
exposes a tty-style interface I would expect it to work.
>
> And the answer to your question is: please open a bug report at
> http://bugs.ntp.org and upload your driver as an attachment, and check
> off the "patch review requested" flag.
>
> You're willing to be the maintainer for this refclock, right?
Yes.
>
> Is it something that can be folded in to an existing driver?  That would
> be much better than creating a new refclock type.
>
Maybe.  It does not free-run on output and has to be polled.  The only
close analog I found in the codebase is "dumbclock" which I used as a
template; I could extend that with a mode bit I suppose.  It's a
pretty-simple driver in reality as there's not much to it; the unit
itself looks like a funky Hayes-style modem command-wise but there are
some oddities -- one of them being that it will only sync at 115,200bps
with the serial port.

I could submit it as a patch to extend "dumbclock" without too much
trouble if you think that would be preferable. Would that fit in
easier?  (It would require only one file be patched as opposed to the
config, reference list, etc.)

From what I can determine it appears MultiTech (and likely other
manufacturers looking around the net) have a wide variety of similar
devices and others , all of which return chime on the same command and
in the same format and thus this should work with all of them.

Whether they will all pick up network time from the cell network without
an active subscription is unknown as is the quality of their responses;
the MultiTech CDMA ones pick up network time on their own which makes
them particularly attractive for this purpose.  The only issue with them
is that time is always local to the tower; there's no indication of DST
or time zone offset in the returned stanza.

I played with these devices several years ago and couldn't get the
returned timecode to be stable enough for ntpd to be happy with it; a
fresh look produced this.

-- 
-- Karl
karl at denninger.net




More information about the hackers mailing list