On Fri, Jul 22, 2011 at 2:27 PM, Jason Rabel
jason@extremeoverclocking.com wrote:

I believe the Symmetricom NTP servers do this, whether or not they
have external access to the oscillator or not I'm not sure. I know
that even their most basic model has OCXO and/or Rubidium upgrade
options. [1] The SyncServer S100 can be disciplined by either NTP via
networking or GPS.

I think all NTP server appliances have this functionality by their
nature, whether or not the oscillator is of particular high quality
(low noise) or not. Many of the low-end ones likely just use a
standard oscillator "in a can" [2] that the embedded processor uses.

[1] http://www.symmetricom.com/products/ntp-servers/ntp-network-appliances/SyncServer-S100/
[2] such as http://www.foxonline.com/thru_hole_oscillators.htm

I must say Jason,

Yes, you are day dreaming, but hey, that is where ideas come from.

I do not play with NTP, but isn't that the same thing ( or similar) as disciplining my local clock when I have it update against a
reference like NIST over the Internet ?  In other words, NTP is used to keep the local computer clock in sync and thus is basically
keeping an oscillator disciplined so to speak.

As to how you would directly make the hardware deal with the oscillator instead of just updating a register dealing with the time, I
do not know.  I am sure it can probably be done.

Bill....WB6BNQ

Jason Rabel wrote:

No exactly. A PPS generator syncrhonized with UTC time, using a GPS ntp
server in the same LAN. Not too bad... but several microseconds jittery
:) enough for my application then. Probably with long time constants it
is doable, but if the ntp server is in the internet, and not in a LAN, I
suspect that to get good results can be a bit difficult :)

Regards,

Javier

El 22/07/2011 20:27, Jason Rabel escribió:

El 22/07/2011 20:39, michael taylor escribió:

No, ntp algorithm does not adjust the oscillator itself.

Regards,

Javier

On 07/22/2011 11:48 AM, Javier Herrero wrote:

Until LightSquared goes online we will have GPS available almost everywhere
high speed internet is available.

NTP disicipline is possible but the necessary time constants might approach
the MTFB of associated systems.

--
Chuck Forsberg WA7KGX N2469R    caf@omen.com  www.omen.com
Developer of Industrial ZMODEM(Tm) for Embedded Applications
Omen Technology Inc      "The High Reliability Software"
10255 NW Old Cornelius Pass Portland OR 97231  503-614-0430

On 7/22/11 11:59 AM, Chuck Forsberg WA7KGX N2469R wrote:

Except that GPS requires a view of the sky (or cabling to a place with a
view of the sky).. There are a quite a lot of applications where you
might have a network connection, but not view of the sky.

The question is whether NTP is decent for disciplining.
(PTP would almost certainly work)

This is exactly what an NTP server does.  It adjusts the rate of a
local clock so that the local clock advances at the same rate is the
set of Internet servers that have passed a clock selection test.  NTP
does this very well considering the uncertainly of the lag over the
internet.  There is a good argument the NTP is optimal but the best
you can get using Internet time servers is "about a milli second" or
0.001 second.

It would be nearly trivial to write software to produce a PPS output
on one of the control line of a serial port.  SO you NTP disciplined
computer can produce PPS with about .001 second error

Send this PPS to the "normal" GPSDXO in place of the GPS' PPS.  The
computer is "only" about 1000 times worse than a GPS and might work OK
if you drastically increase the time constant on the GPSDXO's control
loop.

I think your "NTPDXO might be as good as GPSDXO is measured over a
long enough period, like months.  Short term it might be about as good
as the TTL can oscillator inside the PC.

On Fri, Jul 22, 2011 at 11:27 AM, Jason Rabel
jason@extremeoverclocking.com wrote:

--

Chris Albertson
Redondo Beach, California

On Fri, Jul 22, 2011 at 2:48 PM, Javier Herrero jherrero@hvsistemas.es wrote:

Yes, while the NTP algorithm or protocol does not adjust the
oscillator (or RTC) hardware directly, it does pass trimming or
de-skewing recommendations via software (ntp_adjtime, adjustime, or
hardpps) to OS, allowing the OS to adjust its system's clock.

But in the case of a NTP appliance (or embedded device), having
intimate knowledge of a single design means that the appliance's
Operating System could implement ntp_adjustime or hardpps to a VCO
(voltage controlled oscillator) via a DAC, a DDS or similar, to
actually fine time the device's master oscillator. Which becomes
worthwhile if there is an high quality oscillator driving (or
steering) the computer hardware's system clock, such as an OCXO or
Rubidium oscillator.

I've found a plot of the ntp-synthesized GPS output compared with the
UTC-aligned GPS from a Thunderbolt. The generated PPS output was 1us
wide, and it is represented in infinite persistence to get an idea of
the jitter. The offset was around 50us, and the jitter around 8us, so
not very bad (it was at least one order of magnitude better than my
requirements, so I did not bother to optimize it further).

The ntp source was a M12-based ntp server (a blackfin running uClinux,
not a Soekris :) ).

Driving the PPS output to a serial port from the ntp is not as trivial
as you think. This PPS output is from an "oscillator" disciplined to the
system clock - really a stearable divider from the system clock (it is
an embedded system using uClinux). If you try to drive a digital output
directly from the timer interrupt to get the PPS, you would get far more
jitter and error.

Best regards,

Javier

P.S. not sure if the attachment will show up...

El 22/07/2011 22:19, Chris Albertson escribió:

Hi

The easy way is to take a pps off of your external oscillator and feed that into a port on your NTP server. Let NTP tell you where that pps is. Don't let NTP lock to the pps, just let it report it's position.

After that all you need to do is write some code to read the location of the pulse and implement a long time constant loop. Taking the 1 ms number and a 1x10^-10 goal, the time constant would need to be around 4 months. There are a few minor details about drift of the local reference and how valid 1 ms is over long time periods. A reasonable GPSDO will likely be much more stable and much more accurate.

To get it into the range of being practical, you have to get the NTP setup into single digit microseconds. In the us range you still would not beat the GPSDO, but at least you would have a useful device. 1 us can be done on a LAN with NTP. It's tough to do better than 1 ms over the net. Since PTP suffers the same issues over the net that NTP does, it's not a lot of help in this situation.

Bob

On Jul 22, 2011, at 5:30 PM, Javier Herrero wrote:

"After that all you need to do is write some code to..."

Oh - if I had a nickel for every time I've heard that!

Brent

On Fri, Jul 22, 2011 at 6:07 PM, Bob Camp lists@rtty.us wrote:

On Fri, 22 Jul 2011 13:27:34 -0500
"Jason Rabel" jason@extremeoverclocking.com wrote:

There is something similar. Somewhere on the net, a guy described how
he build a frequency counter using ntp. Unfortunately i'm unable
to find it. AFAIK it worked pretty well with decent results, if the
integration time was in the hours (iirc less than a day).

			Attila Kinali

--
Why does it take years to find the answers to
the questions one should have asked long ago?

On 07/23/2011 12:07 AM, Bob Camp wrote:

There are people already hacking an OCXO into the system clock of their
NTP server.

Now, look at the correction log (frequency and phase) of the system,
low-pass filter that and use it to steer a secondary loop steering the
oscillator. It should be fairly easy and not require much of hacking to
achieve.

Cheers,
Magnus

On Fri, Jul 22, 2011 at 2:30 PM, Javier Herrero jherrero@hvsistemas.es wrote:

The software PPS on the serial port that i suggested would be an
intermediate step.  What you measured was the output of what I called
a NTPDXO decided down.  I think we are talking about the same kind of
design.  I guessed that the jitter on the final PPS would be 1000x
worse than from a GPS and your 8uS measurement is spot on that.  The
M12 has a handful of nS error

Chris Albertson
Redondo Beach, California

On 7/22/11 3:46 PM, brent evers wrote:

When I worked in the physical effects business, we'd get a set of
storyboards from a director, and we'd have to figure out how we were
going to build a rig or arrange the effect as required.  The catch
phrase was always "then, all you gotta do is"...

representing some sort of incredibly difficult, tedious, or impractical
activity. Sure, install 10,000 lightbulb sockets into a frame and wire
them up before tomorrow morning's call time at 6AM.. all you gotta do
is get 50 people to each wire 200 sockets, screw in the bulbs and test them.

Yes but in this case it really is easy;  Below is an outline (don't
try to compile it.).  It has a slight problem because just using
"sleep" is kind of simplistic.  One should wait on the new second and
add some error chacking  Point here is just to show  that this is not
weeks and weeks worth of work".  The below pulse a bit every second
and if the system is running NTP then the length of a second is
controlled by NTP.

Main()
{
int status;
int fd;
int pw = 1000  /* pulse width in uS */
fd=open("dev/tty",O_RDWR);
while(1) {
status = 1;
ioctl(fd, TIOCMSET, &status);
ussleep(pw);
status = 0;
ioctl(fd, TIOCMSET, &status);
ussleep(1000000-pw);
}
}

On Fri, Jul 22, 2011 at 6:08 PM, Jim Lux jimlux@earthlink.net wrote:

--

Chris Albertson
Redondo Beach, California

First, catch your rabbit...

Jim Lux

--
"Neither the voice of authority nor the weight of reason and argument
are as significant as experiment, for thence comes quiet to the mind."
R. Bacon
"If you don't know what it is, don't poke it."
Ghost in the Shell

Dr. Don Latham AJ7LL
Six Mile Systems LLP
17850 Six Mile Road
POB 134
Huson, MT, 59846
VOX 406-626-4304
www.lightningforensics.com
www.sixmilesystems.com

I may be reading way to much into the question.
But the goal discipline the local oscillator as an alternate to GPS or WWVB
etc
Further assumption get the same types of services out of the oscillator
Frequency and time plus pulses.

That said if its one ntp source you look at, potentially far down stream
with many network hops, doesn't that make your reference only as good as
that ntp server as it jitters around?

Would it be better to track say 3 servers hopefully up toward the top of the
ntp service. Analyze their behavior to each other to attempt to account for
network behaviors and the server behaviors.

Essentially compare all three and derive a number to adjust the local
oscillator.

I might add that by adding any 1 pps source from radio or GPS while
available would really let you understand what jitter and path delays you
are getting and then establish the adjustment. (Fully understand that the
path is variable in IP.

Love simple but I suspect, its much tougher then that otherwise why mess
with GPS at all.
;-) Its that darn radio stuff.
Regards
Paul
WB8TSL

On Fri, Jul 22, 2011 at 10:25 PM, Chris Albertson <albertson.chris@gmail.com

Hi

The simple answer is that normal NTP via the net will give you accuracy similar to the "zero beat to WWV" approach. It will take a few days to get to that level. Much faster to fire up the radio and use WWV.

Bob

On Jul 23, 2011, at 12:29 PM, paul swed wrote:

Yes but zero beat by ear is terrible. Are you talking a scope and I think
thats only 1 X 10-7 as I recall.
Regards
Paul.

On Sat, Jul 23, 2011 at 12:42 PM, Bob Camp lists@rtty.us wrote:

Hi

There is a range in what NTP will do, just as there is a range in what you can do via zero beat to WWV. You can get to a ppm or so via zero beat most of the time. Under good conditions you can get to 0.1 ppm. A practial NTP system running to servers over the net has roughly the same accuracy. Time constant of 10,000 seconds, time accuracy / stability of 1 to 10 ms.

Bob

On Jul 23, 2011, at 12:49 PM, paul swed wrote:

On 7/23/11 9:42 AM, Bob Camp wrote:

If you aren't somewhere that has no radio (e.g. underground, in a
electrically noisy EMI environment, underwater, etc.)

Hi

Same issue with NTP. As long as you aren't on a link with nasty asymmetry problems or highly variable delays. There's also the basic "do I trust the server" issue. You can indeed trust WWV as transmitted.

Bob

On Jul 23, 2011, at 1:24 PM, Jim Lux wrote:

On Sat, Jul 23, 2011 at 10:40 AM, Bob Camp lists@rtty.us wrote:

NTP's clock selection algorithm is pretty good.  If you choose a
diverse set of servers then NTP will only use the subset of them that
are self consistent.  "Pool" servers are assigned randomly so even if
there were many bad servers in the world the chance of randomly
picking five that were are "bad" in the exact same way is about zero.
Typically when a server has a problem it does not match another
randomly selected ntp server.

So I think you can trust the consensus time from a set of five
randomly selected pool servers.  It would be far easier to spoof WWV,
just set up a transmitter.

--

Chris Albertson
Redondo Beach, California

Hi

WWV "as transmitted" is massively more accurate than it is as received. There are a lot of NTP servers out there with offsets in the ms to fraction of a ms range. Even if your path was perfect, those issues would keep you from getting to the us level. You could indeed build up some custom servers and take care of the issue. At least  as I understood the original question, random servers on the net were the time source. I assume you would pick them for short path to your location, and then reject any that did really stupid stuff.

Bob

On Jul 23, 2011, at 2:02 PM, Chris Albertson wrote:

Indeed thats why I was saying choose 3 servers.
Now I see in the thread that you can pick pools of servers so thats good.
Then average what they say the time is and drive oscillator.
Wonder if you could look towards the stratum 1 servers.
But that said I could easily believe that it might ot be any better then
wwv.
Good thread. Things to learn as we all seek a backup to GPS I assume.
Regards
Paul
WB8TSL

On Sat, Jul 23, 2011 at 2:17 PM, Bob Camp lists@rtty.us wrote:

I think the original question - "is it possible" has been answered -

yes, it can be (and has been) done.

The real question becomes what specs can one achieve using a

specific feedback loop (and what is the best method to discipline). After
one year of NTP queries, assume you have a 100ms jitter on the network time,
you could at most tweak your oscillator, based on past performance, to 6E-9.
This would be simple for a perfectly stable oscillator just in need of
frequency adjustment. It gets more complicated if it is actually a mere
mortal, aging, drifty oscillator (like most of us). You'd have to start
modeling the drift, drift of the drift, temperature, etc. - similar to what
HP calls 'Smart Clock' to use the NTP only as long interval calibrator and
oscillator drift estimator.
I don't see much use in this exercise, jitter is too high (even
after massaging, averaging, voting, etc.) to get to time-nuts worthiness in
less than weeks or months' time. It is the same as instead of 1 pulse per
second, GPS gave us one pulse per month (but with 10ms uncertainty).

The generic question becomes: given one reference of such Allan

Variance, how can it be combined with another one (of different Allan
Variance spectrum) to generate a device that is better than both (typically
we want the short term stability of one, disciplined by the better long term
of another).

The mathematicians on duty could estimate the best achievable plot

for a sample HP oven osc trained by NTP (with some periodic query,
filtering, etc.)

Same problem as "Can I set my watch by the Rooster's call every

morning?"  (no DST needed here!)

-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On
Behalf Of Bob Camp
Sent: Saturday, July 23, 2011 11:18 AM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Discipline an oscillator with NTP?

Hi

WWV "as transmitted" is massively more accurate than it is as received.
There are a lot of NTP servers out there with offsets in the ms to fraction
of a ms range. Even if your path was perfect, those issues would keep you
from getting to the us level. You could indeed build up some custom servers
and take care of the issue. At least  as I understood the original question,
random servers on the net were the time source. I assume you would pick them
for short path to your location, and then reject any that did really stupid
stuff.

Bob

On Jul 23, 2011, at 2:02 PM, Chris Albertson wrote:

trust WWV as transmitted.

https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

In message CABbxVHuz+Yo+fCH1qb3xSuppFPCNPbghOe1JBQsRDGQL_c+Q9w@mail.gmail.com
, Chris Albertson writes:

That depends a lot on your definition of "good".

If you give the clock selection algoritm more than 5 choices, it
tends to be fickle and change reference server far too often.

The same will happen with fewer really good (=close) servers.

NTPd does build a consensus, it picks a winner.

If you want to do something like this, the one thing you want to
do is hand-pick the NTP server you use, and clamp its minpoll/maxpoll
to the same value.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.