# NTP-disciplined Rubidium?

**URL:** <https://community.ntppool.org/t/ntp-disciplined-rubidium/2768>\
**Category:** Server operators\
**Created:** [March 16, 2023, 9:26pm UTC](https://community.ntppool.org/t/ntp-disciplined-rubidium/2768 "2023-03-16T21:26:46Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![n1zyy](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/n1zyy/32/338_2.png) [@n1zyy](https://community.ntppool.org/u/n1zyy)\
**Post date:** [March 16, 2023, 9:26pm UTC](https://community.ntppool.org/t/ntp-disciplined-rubidium/2768/1 "2023-03-16T21:26:46Z")

</div>

I recently picked up a Symmetricom SyncServer S350 with a Rubidium oscillator and PTP option, thinking I’d gotten a steal. It turns out that the GPS is affected by a week number rollover bug, and will take some hacking to get it to sync.

I have noticed that, set up to just run as a stratum 2 NTP server for now, the Rubidium oscillator went into lock. It’s not immediately clear to me if it’s free-running, or if it’s actually being driven by NTP. If the latter, it got me curious how well this would work. Would I benefit from the short- (and even medium-term) stability of Rubidium, while NTP keeps it long-term accurate? Or is the ~1ms ballpark accuracy of NTP going to forever limit absolute accuracy? I’m wondering if there could be any value in putting this into a colo facility where it wouldn’t have a view of the sky, to forever run at stratum 2, or if it’d be no better than a regular PC.

---

<div class="post-metadata">

**Author:** ![Kets\_One](https://avatars.discourse-cdn.com/v4/letter/k/46a35a/32.png) [@Kets\_One](https://community.ntppool.org/u/Kets_One)\
**Post date:** [March 17, 2023, 8:28am UTC](https://community.ntppool.org/t/ntp-disciplined-rubidium/2768/2 "2023-03-17T08:28:33Z")

</div>

Dear n1zyy,

I have a Symmetricom S200 that suffers from the same week rollover problem and cannot lock onto sattelites and therefore cannot obtain its time from them.

With a replacement GPS module (Furuno GT-8736) i can get a satellite lock. However, the hardware clock never seems to synchronize with GPS for some reason.  
Please check experiences of other people on upgrading/updating symmetricom units on [this forum](https://www.eevblog.com/forum/metrology/symmetricom-s200-teardownupgrade-to-s250/msg1316816/#msg1316816).

To answer your question, stability will be better than regular PC. However, the timing source of the S350 is a source with an error larger than the GPS module has. Surely it makes sense to find a replacement GPS module that doesnt suffer from the week rollover problem.

Kets

---

<div class="post-metadata">

**Author:** ![ddrown](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/ddrown/32/11_2.png) [@ddrown](https://community.ntppool.org/u/ddrown)\
**Post date:** [March 17, 2023, 6:13pm UTC](https://community.ntppool.org/t/ntp-disciplined-rubidium/2768/3 "2023-03-17T18:13:29Z")

</div>

chrony recently added the “local” option to a PPS input. Documentation is under the refclock section [https://chrony.tuxfamily.org/doc/4.3/chrony.conf.html#refclock](https://chrony.tuxfamily.org/doc/4.3/chrony.conf.html#refclock)

It’s designed for your use case - you have a PPS that has a decent frequency but no connection to the proper offset. I have a blog post about it: [NTP server frequency stability](https://blog.dan.drown.org/strat-2-tcxo/)

---

<div class="post-metadata">

**Author:** ![n1zyy](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/n1zyy/32/338_2.png) [@n1zyy](https://community.ntppool.org/u/n1zyy)\
**Post date:** [March 17, 2023, 7:01pm UTC](https://community.ntppool.org/t/ntp-disciplined-rubidium/2768/4 "2023-03-17T19:01:10Z")

</div>

Thanks to both of you!

I had come across [this PDF](https://furuno.ent.box.com/s/fva29wqbcioqvd6mqxn5rt976dkaxudj) from Furuno which mentions that the GT-8031 can keep working if the date is manually set, but it’s light on details. Only last night did I realize that the GPS board is actually a Pentar SA101, with a chip on the underside. It look like the Pentar sits in front of the GT-8031 and makes it look like a Motorola GPS. So I’m guessing that’s why there’s not an easy fix to extend the life of these GPS units.

It’s also unclear to me if the Rubidium oscillator is actually being steered by NTP or is just free-running. This doesn’t inspire a lot of confidence:

```auto
ntpdc> loopinfo
offset: 0.000703 s
frequency: -105.277 ppm
poll adjust: 18
watchdog timer: 398 s

```

It would be interesting to get the GPS set up again while it’s doing NTP and see if things stabilize.

Where did you get the GT-8736? I’m having a hard time finding anywhere selling them. I’d also love a multi-constellation receiver, but I’m not sure anyone is making them with what I’m inferring is Motorola Oncore compatibility.

---

<div class="post-metadata">

**Author:** ![Kets\_One](https://avatars.discourse-cdn.com/v4/letter/k/46a35a/32.png) [@Kets\_One](https://community.ntppool.org/u/Kets_One)\
**Post date:** [March 18, 2023, 9:31am UTC](https://community.ntppool.org/t/ntp-disciplined-rubidium/2768/5 "2023-03-18T09:31:08Z")

</div>

@n1zyy  
I Managed to get hold of a few of GT-8736’s a month ago directly from Furuno.  
They told me these were “the last on the planet”, lol.

I am willing to sell you one if you require. PM me if you are interested.

Kets

---

<div class="post-metadata">

**Author:** ![ask](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/ask/32/907_2.png) [@ask](https://community.ntppool.org/u/ask)\
**Post date:** [March 29, 2023, 5:44am UTC](https://community.ntppool.org/t/ntp-disciplined-rubidium/2768/6 "2023-03-29T05:44:22Z")

</div>

I believe the Meinberg LANTIME systems has a mode where they do an NTP query every second (always) to get more accurate time and then use that to steer the local oscillator.

It seems plausible that you can get “better than 1ms” with enough NTP queries and math…

---

<div class="post-metadata">

**Author:** ![Bas](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/bas/32/465_2.png) [@Bas](https://community.ntppool.org/u/Bas)\
**Post date:** [April 2, 2023, 9:32pm UTC](https://community.ntppool.org/t/ntp-disciplined-rubidium/2768/7 "2023-04-02T21:32:27Z")

</div>

I use time-stamped hardware NIC’s an then poll 2 servers for their PPS signals on the local lan, that is the best accuracy I can get.

```auto
root@server:~# chronyc sourcestats 
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
==============================================================================
GPS 7 5 95 -102.126 344.847 -31ms 4158us
PPS 32 14 124 -0.000 0.028 -1ns 1615ns
raspberrypi.fritz.box 14 9 101 +0.404 0.421 +583us 11us
ntp-main-1.oma.be 15 7 20m -0.583 0.749 -2159us 268us
ntp0.nl.uu.net 12 4 1034 -0.529 0.716 -2087us 225us
ptbtime1.ptb.de 13 7 1099 -0.509 0.487 -1704us 157us

```

```auto
root@server:~# chronyc sources
MS Name/IP address Stratum Poll Reach LastRx Last sample               
===============================================================================
#? GPS 0 4 377 17 -26ms[-26ms] +/- 6474us
#* PPS 0 2 377 6 -640ns[-719ns] +/- 7434ns
^- raspberrypi.fritz.box 1 2 377 4 +630us[+630us] +/- 351us
^- ntp-main-1.oma.be 1 6 377 49 -2169us[-2169us] +/- 8604us
^- ntp0.nl.uu.net 1 6 377 11 -1638us[-1637us] +/- 10ms
^- ptbtime1.ptb.de 1 6 377 22 -2164us[-2163us] +/- 19ms

```

```auto
root@server:~# chronyc tracking 
Reference ID : 50505300 (PPS)
Stratum : 1
Ref time (UTC) : Sun Apr 02 21:30:57 2023
System time : 0.000000168 seconds slow of NTP time
Last offset : -0.000000172 seconds
RMS offset : 0.000000571 seconds
Frequency : 11.784 ppm fast
Residual freq : -0.000 ppm
Skew : 0.016 ppm
Root delay : 0.000000001 seconds
Root dispersion : 0.000010524 seconds
Update interval : 8.0 seconds
Leap status : Normal

```

Seems to work well as this is a pretty bussy server 🙂

---

<div class="post-metadata">

**Author:** ![n1zyy](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/n1zyy/32/338_2.png) [@n1zyy](https://community.ntppool.org/u/n1zyy)\
**Post date:** [April 2, 2023, 11:07pm UTC](https://community.ntppool.org/t/ntp-disciplined-rubidium/2768/8 "2023-04-02T23:07:05Z")

</div>

Nice, that PPS source looks really good!

I ultimately took Kets\_One up on his offer and have a replacement GPS coming my way. I like the idea of PPS from GPS + NTP for time of day, but if I can get the thing doing native GPS, that’s even better.

In the current “NTP appliance with an onboard rubidium oscillator claiming it’s locked, but getting time from the Internet” state, I’m unclear what it’s using for system time, but it’s not looking great:

```auto
bash-2.05b$ ntpq -c rv | grep frequency
offset=1.161, frequency=-69.664, jitter=0.234, noise=1.587,

```

My understanding is that a free-running rubidium oscillator should have way, way less than 70ppm of frequency error.

I had wondered what would happen if I put this in a data center, where GPS would be unavailable (or at least unaffordable). What I _hoped_ would happen is that rubidium would give me excellent short-term stability, and NTP would guard against long-term drift. In actuality, it doesn’t look any better than a commodity PC.

---

<div class="post-metadata">

**Author:** ![Bas](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/bas/32/465_2.png) [@Bas](https://community.ntppool.org/u/Bas)\
**Post date:** [May 20, 2023, 2:27pm UTC](https://community.ntppool.org/t/ntp-disciplined-rubidium/2768/9 "2023-05-20T14:27:35Z")

</div>

I’m using the Garmin on 1 server here at home, totally RS-232 connected.  
And a Ublox with PPS on another server.

Both GPS’ses are located at different places of my house.

As for the Garmin, I use this one:

[https://www.lammertbies.nl/comm/info/gps-time](https://www.lammertbies.nl/comm/info/gps-time)

It’s not that expensive but terribly good. Bit hard to find on the Garmin website.
