NTP-disciplined Rubidium?

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.

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.

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.


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

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

Thanks to both of you!

I had come across this PDF 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:

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.

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.



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…

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.

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
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
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 :slight_smile:

1 Like

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:

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.

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:


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