Karl Denninger wrote:
> I'm hacking a copy of the NMEA driver to work with the CDMA modems
> (which provide a clock signal even if not subscribed - kinda
> interesting) and have it talking to the device.
>
> But - even though the dispersion looks reasonable and so does jitter,
> the application refuses to consider it "synced".
>
> I have the following.....
>
> ntpdc> sysi
> system peer: CDMA(0)
> system peer mode: client
> leap indicator: 11
> stratum: 16
> precision: -19
> root distance: 0.00000 s
> root dispersion: 0.00165 s
> reference ID: [67.68.77.0]
> reference time: 00000000.00000000 Thu, Feb 7 2036 0:28:16.000
> system flags: auth monitor ntp kernel stats
> jitter: 0.001129 s
> stability: 0.000 ppm
> broadcastdelay: 0.003998 s
> authdelay: 0.000000 s
> ntpdc> peer
> remote local st poll reach delay offset disp
> ================================================== =====================
> *CDMA(0) 127.0.0.1 0 16 377 0.00000 0.241065 0.00697
> ntpdc>
>
> Obviously, I'm missing SOMETHING....... the dispersion looks reasonable,
> but it will not lock up on the clock. Any idea where I start?

I think you may be missing the "*" in column one above. That indicates
that ntpd has your CDMA(0) clock as the synchronization source.

The offset looks a little high unless ntdp was started quite recently.
Bear in mind that ntpd needs time to beat your clock into submission.
Thirty minutes is a good length of time to wait before taking offset and
dispersion figures seriously.

Richard B. Gilbert wrote:
> Karl Denninger wrote:
>> I'm hacking a copy of the NMEA driver to work with the CDMA modems
>> (which provide a clock signal even if not subscribed - kinda
>> interesting) and have it talking to the device.
>>
>> But - even though the dispersion looks reasonable and so does jitter,
>> the application refuses to consider it "synced".
>>
>> I have the following.....
>>
>> ntpdc> sysi
>> system peer: CDMA(0)
>> system peer mode: client
>> leap indicator: 11
>> stratum: 16
>> precision: -19
>> root distance: 0.00000 s
>> root dispersion: 0.00165 s
>> reference ID: [67.68.77.0]
>> reference time: 00000000.00000000 Thu, Feb 7 2036 0:28:16.000
>> system flags: auth monitor ntp kernel stats
>> jitter: 0.001129 s
>> stability: 0.000 ppm
>> broadcastdelay: 0.003998 s
>> authdelay: 0.000000 s
>> ntpdc> peer
>> remote local st poll reach delay offset disp
>> ================================================== =====================
>> *CDMA(0) 127.0.0.1 0 16 377 0.00000 0.241065 0.00697
>> ntpdc>
>>
>> Obviously, I'm missing SOMETHING....... the dispersion looks
>> reasonable, but it will not lock up on the clock. Any idea where I
>> start?
>
> I think you may be missing the "*" in column one above. That indicates
> that ntpd has your CDMA(0) clock as the synchronization source.
>
> The offset looks a little high unless ntdp was started quite recently.
> Bear in mind that ntpd needs time to beat your clock into submission.
> Thirty minutes is a good length of time to wait before taking offset and
> dispersion figures seriously.
>

Ok... I'll wait a good long while (several hours)

This thing isn't the BEST time source ever invented, but I've got a few
folks who would like it as a solution, and of course I'll contribute the
driver back to the codebase - if I can get it to work!

The other problem - that the driver's "start" routine is never called
unless ntpd is not running as a daemon - is puzzling. Not quite sure
why that would happen.... but the routine is definitely not being
entered, although the base code IS running (the startup message gets
logged to the syslog and there are no errors.)

Its almost like the config file switch is ignored if its not in debug
mode and thus didn't attempt to start the clock. I can get a sysi but a
peer shows no data (as expected with no clocks or peers attached)

I built this from source of the current RC2 source - I'm a long-time
NTPD user (and have a Stratum 1 server running here with a GPS+PPS
source), but haven't (yet) attempted to integrate a "new" clock into the
codebase.

--
Karl Denninger (karl@denninger.net)
http://www.denninger.net

What OS are you running, and what CDMA modem are you using? (Just curious)

Also from the info you gave it looks like it is using your CDMA source, but
seeing the stratum at 16 I don't think you have had NTP run long enough to
adjust the clock into sync.

Jason

_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Jason Rabel wrote:
> What OS are you running, and what CDMA modem are you using? (Just curious)
>
> Also from the info you gave it looks like it is using your CDMA source, but
> seeing the stratum at 16 I don't think you have had NTP run long enough to
> adjust the clock into sync.
>
> Jason


FreeBSD 6 (and 7; I have both here); the modem is a Multitech MTCBA.

--
Karl Denninger (karl@denninger.net)
http://www.denninger.net

Karl Denninger wrote:
> Jason Rabel wrote:
>> What OS are you running, and what CDMA modem are you using? (Just
>> curious)
>>
>> Also from the info you gave it looks like it is using your CDMA
>> source, but
>> seeing the stratum at 16 I don't think you have had NTP run long
>> enough to
>> adjust the clock into sync.
>>
>> Jason
>
>
> FreeBSD 6 (and 7; I have both here); the modem is a Multitech MTCBA.
>

Quick update on this.... it appears that while the timecode is being
stuffed appropriately, the underlying NTPD daemon doesn't like it -
after a half-hour or so (running with debug turned up) and watching it
log things, it fails to lock on and resets the time source, dropping and
restarting the clock.

I assume this means it is unable to get "happy enough" with the
stability of the timestamps to formulate a "solution", declares the
clock "broken", and then restarts....... yes?

The obvious question is "can a time source that outputs only with 1
second resolution and only when polled generate
sufficiently-high-quality reference time for the system to use it?"

If the answer is "no", then the curtain needs to be drawn on this
attempt. If the answer is "yes", then I need to figure out how to
accomplish getting better input resolution I suspect - perhaps with a
helper application that polls at a higher rate of speed (e.g. several
times per second) and "stuffs" timecode events into the receive buffer
(e.g. via a named pipe or similar)

--
Karl Denninger (karl@denninger.net)
http://www.denninger.net

>>> In article , Karl Denninger writes:

ntpdc> peer
>>> remote local st poll reach delay offset disp
>>> ================================================== =====================
>>> *CDMA(0) 127.0.0.1 0 16 377 0.00000 0.241065 0.00697

I would not expect to see 127.0.0.1 in that field, but it may be because you
are using ntpdc and not ntpq. What does the output of 'ntpq -p' look like?

Karl> I built this from source of the current RC2 source

I'd recommend using ntp-dev instead. We're effectively at a feature freeze
for ntp-4.2.6 now, as I'm expecting to release 4.2.6 as soon as the current
set of blocking bugs are fixed. I expect this will take another couple of
months' time.

H

Karl Denninger wrote:
> Karl Denninger wrote:
>
>> Jason Rabel wrote:
>>
>>> What OS are you running, and what CDMA modem are you using? (Just
>>> curious)
>>>
>>> Also from the info you gave it looks like it is using your CDMA
>>> source, but
>>> seeing the stratum at 16 I don't think you have had NTP run long
>>> enough to
>>> adjust the clock into sync.
>>>
>>> Jason
>>
>>
>>
>> FreeBSD 6 (and 7; I have both here); the modem is a Multitech MTCBA.
>>
>
> Quick update on this.... it appears that while the timecode is being
> stuffed appropriately, the underlying NTPD daemon doesn't like it -
> after a half-hour or so (running with debug turned up) and watching it
> log things, it fails to lock on and resets the time source, dropping and
> restarting the clock.
>
> I assume this means it is unable to get "happy enough" with the
> stability of the timestamps to formulate a "solution", declares the
> clock "broken", and then restarts....... yes?
>
> The obvious question is "can a time source that outputs only with 1
> second resolution and only when polled generate
> sufficiently-high-quality reference time for the system to use it?"
>
> If the answer is "no", then the curtain needs to be drawn on this
> attempt. If the answer is "yes", then I need to figure out how to
> accomplish getting better input resolution I suspect - perhaps with a
> helper application that polls at a higher rate of speed (e.g. several
> times per second) and "stuffs" timecode events into the receive buffer
> (e.g. via a named pipe or similar)
>

Subject to correction by someone who knows what he's talking about the
answer is not just "no" but "HELL NO"!

The resolution of 1 second is a killer. This is going to make the
jitter a function of exactly when each poll is received. I doubt that
ntpd cares very much exactly when a poll is sent. If this device has a
PPS output, it might be useable. . . .

Richard B. Gilbert wrote:
> Karl Denninger wrote:
>> Karl Denninger wrote:
>>
>>> Jason Rabel wrote:
>>>
>>>> What OS are you running, and what CDMA modem are you using? (Just
>>>> curious)
>>>>
>>>> Also from the info you gave it looks like it is using your CDMA
>>>> source, but
>>>> seeing the stratum at 16 I don't think you have had NTP run long
>>>> enough to
>>>> adjust the clock into sync.
>>>>
>>>> Jason
>>>
>>>
>>>
>>> FreeBSD 6 (and 7; I have both here); the modem is a Multitech MTCBA.
>>>
>>
>> Quick update on this.... it appears that while the timecode is being
>> stuffed appropriately, the underlying NTPD daemon doesn't like it -
>> after a half-hour or so (running with debug turned up) and watching it
>> log things, it fails to lock on and resets the time source, dropping
>> and restarting the clock.
>>
>> I assume this means it is unable to get "happy enough" with the
>> stability of the timestamps to formulate a "solution", declares the
>> clock "broken", and then restarts....... yes?
>>
>> The obvious question is "can a time source that outputs only with 1
>> second resolution and only when polled generate
>> sufficiently-high-quality reference time for the system to use it?"
>>
>> If the answer is "no", then the curtain needs to be drawn on this
>> attempt. If the answer is "yes", then I need to figure out how to
>> accomplish getting better input resolution I suspect - perhaps with a
>> helper application that polls at a higher rate of speed (e.g. several
>> times per second) and "stuffs" timecode events into the receive buffer
>> (e.g. via a named pipe or similar)
>>
>
> Subject to correction by someone who knows what he's talking about the
> answer is not just "no" but "HELL NO"!
>
> The resolution of 1 second is a killer. This is going to make the
> jitter a function of exactly when each poll is received. I doubt that
> ntpd cares very much exactly when a poll is sent. If this device has a
> PPS output, it might be useable. . . .

It doesn't, which sucks. Severely.

I will contact Multitech and see if there's a solution to this (either
in the form of better resolution or a PPS output option somehow.) If
not, well, it was a nice try :->

--
Karl Denninger (karl@denninger.net)
http://www.denninger.net

Well I guess I should speak up with a correction... :P

Actually more of just an addendum, what you are saying isn't incorrect.

I know from some experience with the TrueTime driver that the sysplex output
only has second resolution, *however* it outputs the time and the trailing
is supposed to be within X milliseconds of "on time". When you go into
polling mode, then it gives you three digits past the decimal when it
returns the time.

So the issue here is, you either need a way for the device to go into an
auto-output mode where it gives the time on the second, or give better
resolution when polled. Also helpful would be if it followed the sysplex
flags to know if the time was actually in sync or not with the radio source.

Jason

_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

"Karl Denninger" wrote in message
news:sVJbi.122151$NK5.94621@newsfe23.lga...
[...]
> The obvious question is "can a time source that outputs only with 1
> second resolution and only when polled generate
> sufficiently-high-quality reference time for the system to use it?"

Perhaps not on its own, but I can imagine a scheme where you look
for its top-of-second point, by polling at random intervals or
intervals of slightly more or less than one second.

If its internal clock is good enough, then given time it could be
made acceptable. It's not unlike TSC interpolation.

Groetjes,
Maarten Wiltink

Maarten Wiltink wrote:
> "Karl Denninger" wrote in message
> news:sVJbi.122151$NK5.94621@newsfe23.lga...
> [...]
>> The obvious question is "can a time source that outputs only with 1
>> second resolution and only when polled generate
>> sufficiently-high-quality reference time for the system to use it?"
>
> Perhaps not on its own, but I can imagine a scheme where you look
> for its top-of-second point, by polling at random intervals or
> intervals of slightly more or less than one second.
>
> If its internal clock is good enough, then given time it could be
> made acceptable. It's not unlike TSC interpolation.
>
> Groetjes,
> Maarten Wiltink
>
>

That's kinda what I'm thinking.

If Multitech can't get me something better than what I have I may try to
synthesize it with a daemon that attempts to "find" the change and then
stuffs NTPD via a named pipe or something similar.

--
Karl Denninger (karl@denninger.net)
http://www.denninger.net

On 2007-06-13, Karl Denninger wrote:

> If Multitech can't get me something better than what I have I may try
> to synthesize it with a daemon that attempts to "find" the change and
> then stuffs NTPD via a named pipe or something similar.

This what the SHM driver is for.

--
Steve Kostecke
NTP Public Services Project - http://support.ntp.org/

Steve Kostecke wrote:
> On 2007-06-13, Karl Denninger wrote:
>
>> If Multitech can't get me something better than what I have I may try
>> to synthesize it with a daemon that attempts to "find" the change and
>> then stuffs NTPD via a named pipe or something similar.
>
> This what the SHM driver is for.
>

Yep.

But I'm going to try to get something from Multitech first. If no
response or nothing constructive, then I'll start writing code.

--
Karl Denninger (karl@denninger.net)
http://www.denninger.net

>The resolution of 1 second is a killer. This is going to make the
>jitter a function of exactly when each poll is received. I doubt that
>ntpd cares very much exactly when a poll is sent. If this device has a
>PPS output, it might be useable. . . .

Some GPS units can be put into a mode where they send a report
on each second tick. So although the resolution in their
data format is only one second, you get the message close
to that second tick.

There might be an option in the polling mode where it
waits until the second ticks before answering.

You might be able to fake it by polling every few ms until you
see the answer change. Then you know that the second ticked
between two polls so your time resolution is the poll interval.
Skipping the useless polls is left as an exercise ....

--
These are my opinions, not necessarily my employer's. I hate spam.

> From: Karl Denninger
> Date: Wed, 13 Jun 2007 12:07:22 -0500
> Sender: questions-bounces+oberman=es.net@lists.ntp.isc.org
>
> Steve Kostecke wrote:
> > On 2007-06-13, Karl Denninger wrote:
> >
> >> If Multitech can't get me something better than what I have I may try
> >> to synthesize it with a daemon that attempts to "find" the change and
> >> then stuffs NTPD via a named pipe or something similar.
> >
> > This what the SHM driver is for.
> >
>
> Yep.
>
> But I'm going to try to get something from Multitech first. If no
> response or nothing constructive, then I'll start writing code.

Carl,

We use CDMA and can keep time within a couple of microseconds. I am using
an EndRun Technologies CDMA clock which provides PPS, but the jitter on
the raw (TrueTime emulated) once a second update is about 4 ms at
worst. This sucks compared to the PPS, but should be good for most cases
where high precision is not an issue.

By the way, the external CDMA clock from EndRun is pretty well hidden on
the web pages under "Other Products". It is found at:
http://www.endruntechnologies.com/ne...ime-source.htm
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman@es.net Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751

_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)
Comment: Exmh version 2.5 06/03/2002

iD8DBQFGcDPJkn3rs5h7N1ERAmyFAJ96zEYOdQD6s3afGcb3jH OrIDhe1gCeNji/
7rk8+b5N5L0VEe5xyId6AbE=
=1c+W
-----END PGP SIGNATURE-----

Kevin Oberman wrote:
>>From: Karl Denninger
>>Date: Wed, 13 Jun 2007 12:07:22 -0500
>>Sender: questions-bounces+oberman=es.net@lists.ntp.isc.org
>>
>>Steve Kostecke wrote:
>>
>>>On 2007-06-13, Karl Denninger wrote:
>>>
>>>
>>>>If Multitech can't get me something better than what I have I may try

>
> Carl,
>
> We use CDMA and can keep time within a couple of microseconds. I am using
> an EndRun Technologies CDMA clock which provides PPS, but the jitter on
> the raw (TrueTime emulated) once a second update is about 4 ms at
> worst. This sucks compared to the PPS, but should be good for most cases
> where high precision is not an issue.
>
> By the way, the external CDMA clock from EndRun is pretty well hidden on
> the web pages under "Other Products". It is found at:
> http://www.endruntechnologies.com/ne...ime-source.htm
>

They say "Email or call us for a competitive price quote...."
Why do I always get nervous when someone says that? It generally means
"all the traffic will bear and then some!" I much prefer to deal with
someone who says, up front, "it's $1253.99 plus shipping from. . . ."
It saves us both a bit of time because there's no way I'm going to pay
that much. It might be different if I had a corporate sponsor but
nowadays it's strictly out of my pocket!

Richard B. Gilbert wrote:

>
> They say "Email or call us for a competitive price quote...."
> Why do I always get nervous when someone says that? It generally means
> "all the traffic will bear and then some!" I much prefer to deal with
> someone who says, up front, "it's $1253.99 plus shipping from. . . ." It
> saves us both a bit of time because there's no way I'm going to pay that
> much. It might be different if I had a corporate sponsor but nowadays
> it's strictly out of my pocket!
>

You got that right. Its over $1,000 (I DID email them.)

Give me a break. A GPS receiver is a hell of a lot less expensive.

Competitive my tailfeathers.

--
Karl Denninger (karl@denninger.net)
http://www.denninger.net

On 2007-06-13, Richard B. Gilbert wrote:

> They say "Email or call us for a competitive price quote..."
> Why do I always get nervous when someone says that? It generally means
> "all the traffic will bear and then some!" I much prefer to deal with
> someone who says, up front, "it's $1253.99 plus shipping from. . . ."
> It saves us both a bit of time because there's no way I'm going to pay
> that much. It might be different if I had a corporate sponsor but
> nowadays it's strictly out of my pocket!

Based on a quote I received 2 years ago I'd guess the current base price
is in the ball park of $1200. An OCXO is extra...

--
Steve Kostecke
NTP Public Services Project - http://support.ntp.org/

On 2007-06-13, Karl Denninger wrote:

> Give me a break. A GPS receiver is a hell of a lot less expensive.
>
> Competitive my tailfeathers.

There are some applications where GPS won't work (due to antenna siting
restrictions); CDMA may be the best solution in those cases.

--
Steve Kostecke
NTP Public Services Project - http://support.ntp.org/