Hi to all,
in my setup I'm using a pc (Stratum 1) that synchronizes its local
oscillator from a PPS derived by a GPS (Stratum 0).
We known that pc use normally quartz oscillators, that are poor
quality oscilators.
I'm intended to replace this oscillator with an OXCO oscilattor (an
high stability oscillator).

My question is:
an oscillator replacement would create some improvement in my setup?
Consider that my Stratum 1 pc generate a pps derived from its local
time and this PPS is used from other pc (Stratum 2 pc).

What do you think about?
Has someone made some measures about this topic?

Thanks in advance,
Elio Giugliano.

elio.gi@gmail.com wrote:
> Hi to all,
> in my setup I'm using a pc (Stratum 1) that synchronizes its local
> oscillator from a PPS derived by a GPS (Stratum 0).
> We known that pc use normally quartz oscillators, that are poor
> quality oscilators.
> I'm intended to replace this oscillator with an OXCO oscilattor (an
> high stability oscillator).
> 
> My question is:
> an oscillator replacement would create some improvement in my setup?
> Consider that my Stratum 1 pc generate a pps derived from its local
> time and this PPS is used from other pc (Stratum 2 pc).
> 
> What do you think about?
> Has someone made some measures about this topic?
> 

Replacing the crystal oscillator would void the warranty on your PC!
If the replacement is not properly done, the PC may never work again!

If  you feel that you MUST have an OCXO, both Meinberg and Symmetricomm 
offer PCI cards with GPS synchronized OCXOs.  The Meinberg card sells 
for about $1100 US!

The only advantage an OCXO would give you would be a longer "holdover 
time" if the GPS fails.  If your PC is kept in a temperature controlled 
environment I see little or no benefit in replacing the oscillator with 
an OCXO!

<elio.gi@gmail.com> wrote in message
news:1191836018.666680.188700@o80g2000hse.googlegroups.com...

> in my setup I'm using a pc (Stratum 1) that synchronizes its local
> oscillator from a PPS derived by a GPS (Stratum 0).
> We known that pc use normally quartz oscillators, that are poor
> quality oscilators.
> I'm intended to replace this oscillator with an OXCO oscilattor (an
> high stability oscillator).

The poor quality of PC-class quartz oscillators would be evident mostly
in an unpredictable but constant frequency error. Perhaps 'better'
crystals display less aging, but frankly I doubt it.

As a result, a simple PC is not at all bad once it has determined its
'native' drift, and the remaining unpredictability depends very largely
on temperature variations. AC cycles, doors and windows opening,
varying CPU load. A lightly loaded system in a locked closet should be
almost as good as an OCXO-equipped one. Most of the time. And almost.


> My question is:
> an oscillator replacement would create some improvement in my setup?
> Consider that my Stratum 1 pc generate a pps derived from its local
> time and this PPS is used from other pc (Stratum 2 pc).

Obviously, a real OCXO should be more stable than a flimsy crystal in
a garden-variety mostly-stable room temperature environment. I'm not
sure generating a PPS signal would be significantly better than simply
NTP over Ethernet.


> What do you think about?
> Has someone made some measures about this topic?

Replacing the oscillator has been done. What would you like to measure?
What results would change your mind either way?

Groetjes,
Maarten Wiltink

Elio,

Have you seen http://www.febo.com/pages/soekris/ ?

H

Also:

 http://phk.freebsd.dk/soekris/pps/

H

And there are many vendors of excellent products out there if you would
prefer to buy a ready-made S1 solution.

H

Alternatively to Harlan's suggestions, there are a few DIY alternatives 
also if you are so inclined...

TAPR has a nice clock-generator kit with an ICS525 chip that can use an 
external GPS signal rather than a crystal:
  http://www.tapr.org/kits_clock-block.html

And Cypress has evaluation kits using their new CY22180 very low jitter 
clock generator module, if you'd prefer a RYO design instead.
 
http://www.cypress.com/portal/server.pt?space=CommunityPage&control=SetCommunity&CommunityID=209&PageID=259&fid=22&rpn=CY22180&ref=sch


Eric

Guys,

The performance with ntpd running in a rusting Pentium hulk with several 
hundred clients and PPS is surprisingly good. Our rackety.udel.edu runs 
FreeBSD 6.1 with PPS via the parallel port. It usually shows residual 
offset and jitter in the order of a few microseconds. It is good enough 
that the daily variations in the air-conditioned machine room 
temperature can be measured accurately.

Measuring the PPS offset within a few hundred nanoseconds is brilliant; 
however, the measured latency to read the system clock from an 
application is in the order of a microsecond and this polluted by 
context switches, cache misses, timer interrupts, etc.

Dave

Harlan Stenn wrote:
> Also:
> 
>  http://phk.freebsd.dk/soekris/pps/
> 
> H

Eric.Jones wrote:
> Alternatively to Harlan's suggestions, there are a few DIY alternatives 
> also if you are so inclined...
> 
> TAPR has a nice clock-generator kit with an ICS525 chip that can use an 
> external GPS signal rather than a crystal:
>   http://www.tapr.org/kits_clock-block.html

Thanks for the plug (I'm the ClockBlock designer) but this isn't 
accurate.  The Clock-Block requires an input clock signal in the HF 
range and won't work with a PPS signal.

However, a TAPR Reflock II (http://www.tapr.org/kits_reflock_ii.html) 
could sort of do this -- it can steer an oscillator to GPS via PPS 
signals, and that oscillator need not be at something simple like 10 
MHz; it could operate directly at the motherboard's clock frequency.  So 
you would still need to provide a piece of decent-quality quartz in the 
solution.

John

Just had a look around.

The (dead) Asus A7N266 MoBo I have lying around has exactly two Xtals
one with
	14.033MHz ( looks like they derive all other System clocks from this one)
and the other with
	32.768 KHz ( linked to the RTC )

I don't think that this is any different for other recent MoBos
Single xtal boards should be possible too, though you loose
some ability for fault detection that way.


uwe

Hi ,

On 8 Ott, 22:06, "David L. Mills" <mi...@udel.edu> wrote:
> The performance with ntpd running in a rusting Pentium hulk with several
> hundred clients and PPS is surprisingly good. Our rackety.udel.edu runs
> FreeBSD 6.1 with PPS via the parallel port. It usually shows residual
> offset and jitter in the order of a few microseconds. It is good enough
> that the daily variations in the air-conditioned machine room
> temperature can be measured accurately.
>
> Measuring the PPS offset within a few hundred nanoseconds is brilliant;
> however, the measured latency to read the system clock from an
> application is in the order of a microsecond and this polluted by
> context switches, cache misses, timer interrupts, etc.

I work for a big international telecom Company (Number 1 in Mobile)
and I think that I have to give you more details of our Company
project that could use NTP technology.
In this moment we're making our tests with NTP on a test pc, but our
aim is to run NTP on our telecom blades which have onboard their own
processor and an embedded linux OS.
These blades will get a PPS signal derived from a GPS and, thanks to
ntpd daemon, will synchronize their local time.
These "Stratum 1" blades will send to other (Stratum 2) blades NTP
messages, so the question is:

- is the precision of these "messages" (or timestemps) affected by the
stability of the local oscillator ?

The application will run in a MAN corporate network where packet
delays should be small compared to the Internet delays. So it could be
worth to enhance the accuracy of the timestemps provided by the ntp
stratum1 server; than the second question is:

- which kind of accuracy can we reach enhancing the stability of the
oscillator ? (nanoseconds? )
(note that we already use high stability oscillator inside the
equipment, that could also feed the processor clock)

The same question at client side is:

- which accuracy of local clock can we expect using high stability
oscillators? (we have measured around 60 microseconds  peak-to-peak,
using standard crystal in *environment test* configuration- see
below )

****************************************
* Environment Test Configuration *
****************************************

GPS
   ||
   \/
Derived PPS on a cable conneted to the serial port of Stratum 1 pc
   ||
   \/
Stratum 1 PC with ntpd running
   ||
   \/
Ethernet Cable
   ||
   \/
Stratum 2 PC with ntpd running
  ||
  \/
Output PPS signal passing by parallel port pin
  ||
  \/
Measure Instrument with GPS Ref. Clock
**************************************************************

Thanks in advance,
Best Regards,
Elio

elio.gi@gmail.com wrote:
> Hi ,
> 
> On 8 Ott, 22:06, "David L. Mills" <mi...@udel.edu> wrote:
> 
>>The performance with ntpd running in a rusting Pentium hulk with several
>>hundred clients and PPS is surprisingly good. Our rackety.udel.edu runs
>>FreeBSD 6.1 with PPS via the parallel port. It usually shows residual
>>offset and jitter in the order of a few microseconds. It is good enough
>>that the daily variations in the air-conditioned machine room
>>temperature can be measured accurately.
>>
>>Measuring the PPS offset within a few hundred nanoseconds is brilliant;
>>however, the measured latency to read the system clock from an
>>application is in the order of a microsecond and this polluted by
>>context switches, cache misses, timer interrupts, etc.
> 
> 
> I work for a big international telecom Company (Number 1 in Mobile)
> and I think that I have to give you more details of our Company
> project that could use NTP technology.
> In this moment we're making our tests with NTP on a test pc, but our
> aim is to run NTP on our telecom blades which have onboard their own
> processor and an embedded linux OS.
> These blades will get a PPS signal derived from a GPS and, thanks to
> ntpd daemon, will synchronize their local time.
> These "Stratum 1" blades will send to other (Stratum 2) blades NTP
> messages, so the question is:
> 
> - is the precision of these "messages" (or timestemps) affected by the
> stability of the local oscillator ?
> 
> The application will run in a MAN corporate network where packet
> delays should be small compared to the Internet delays. So it could be
> worth to enhance the accuracy of the timestemps provided by the ntp
> stratum1 server; than the second question is:
> 
> - which kind of accuracy can we reach enhancing the stability of the
> oscillator ? (nanoseconds? )
> (note that we already use high stability oscillator inside the
> equipment, that could also feed the processor clock)
> 
> The same question at client side is:
> 
> - which accuracy of local clock can we expect using high stability
> oscillators? (we have measured around 60 microseconds  peak-to-peak,
> using standard crystal in *environment test* configuration- see
> below )
<snip>

The accuracy on the clients depends on, more than anything else, the 
network connection between them and the server.  With a 100 MB LAN the 
delay and, therefore, the uncertainty should be on the order of 1 
millisecond.  The stability of the oscillator has very little to do with 
it; NTP disciplines the local clock and will compensate for any drift in 
the oscillator.

If you really need synchronization to less than 1 millisecond between 
clients, you need to consider something like a PPS signal sent to each 
client and compensating for speed of light delays in each length of cable!

> - is the precision of these "messages" (or timestemps) affected by the
> stability of the local oscillator ?

For all practical purposes, no. As Dr. Mills said, there are many other
factors causing various bits latency in a PC that are independent of the
oscillator. What little you might gain from a Frankenstein oscillator
replacement is still outweighed by the random OS and hardware delays.

> - which kind of accuracy can we reach enhancing the stability of
> the oscillator ? (nanoseconds?)

Let's not forget about the PPS source. You mention "GPS", but no details
there. I would focus more on that end first, ensuring you are doing all that
is necessary and calculating out all your ns delays in cabling, splitters,
etc, so that it can be added to NTP. Accurate antenna position is important
too. Keep in mind GPS is not UTC (even omitting the leap seconds). GPS time
does wander in the double-digit ns range.
http://tf.nist.gov/service/gpscal.htm

As long as you have your PPS signal (and setting the minpoll to 4 doesn't
hurt either), changing the oscillator in your PC isn't going to make much
difference. Same reason as before, there are lots of little things going on
inside a PC that cause random bits of uncompensated delay. I wouldn't say
you could get single digit ns, but more in the order of hundreds of ns
depending on the hardware & OS. Even after you pass this NTP info on via the
network then you are jumping up to the ms range for those clients. Depending
on your OS & BIOS there are certain tweaks you can do to help minimize
delays, check the NTP wiki for more info.

You said you were using Linux, what method are you using to read the PPS
signal? Also does Linux even have nanosecond precision?

> The same question at client side is:
> 
> - which accuracy of local clock can we expect using high stability
> oscillators? (we have measured around 60 microseconds  peak-to-peak,
> using standard crystal in *environment test* configuration- see
> below )

Again, oscillator replacement is not going be the big factor here unless you
have random and sharp environmental changes. NTP over Ethernet is going to
jump you to the tens of ms range. The random unknowns of the source +
network delays all add up so the clients can only assume the time falls
somewhere within a certain range. If you need better than that then you
would need to feed a PPS signal directly to the PC. Maybe even try different
networking hardware (both NICs and switches) and see if that affects your
results any.

A better oscillator in the PC would really only mean better holdover when
all NTP sources are unavailable. But even at that, depending on the OS and
load, time could wander off just as quick even with the oscillator upgrade.
Power regulation could be another factor, not just the AC power coming in,
but the quality of the PC's PSU, or heck even the voltage regulators on the
motherboard. You can pick apart literally a thousand different variables for
a PC that are going to affect time keeping. But the complexities of the
hardware itself and the OS are more your problem than the oscillator.

Jason Rabel said the following on 10/10/2007 02:47 PM:

> A better oscillator in the PC would really only mean better holdover when
> all NTP sources are unavailable. But even at that, depending on the OS and
> load, time could wander off just as quick even with the oscillator upgrade.
> Power regulation could be another factor, not just the AC power coming in,
> but the quality of the PC's PSU, or heck even the voltage regulators on the
> motherboard. You can pick apart literally a thousand different variables for
> a PC that are going to affect time keeping. But the complexities of the
> hardware itself and the OS are more your problem than the oscillator.

I don't think I entirely agree.  A better oscillator in the PC should
also improve short term stability.  When the $0.09 crystal wobbles due
to temperature or voltage changes, it takes NTP some time to adjust; the
loop time constants are quite long.  If you look closely using an
external reference, these wobbles in timekeeping can be quite apparent
even on a PPS-sync'd PC.  A better oscillator will wobble less and
consequently will improve short term stability.

That may or may not be relevant, depending on the design goals of the
server.

And, come to think of it, a good oscillator may make more improvement in
a Stratum 2 machine because the control loop is likely to be much longer
than with a local refclock.

John