What are folks using these days for smaller organizations, that need to dole out time from an internal source?
I use the $300 GPS-based TM1000A from TimeMachinesCorp.com. Gets Stratum-1 time from GPS satellites and distributes it. Usually I relay this through a handful of local time servers to spread out the load, but it can handle hundreds of queries per minute, so it’s reasonable to use as a primary source even in moderate-sized data centers.
I’ve put in a ton of them, and in most installations I buy two for redundancy. The GPS antenna works from a window in most instances .
-mel beckman
I use the $300 GPS-based TM1000A from TimeMachinesCorp.com. Gets Stratum-1 time from GPS satellites and distributes it. Usually I relay this through a handful of local time servers to spread out the load, but it can handle hundreds of queries per minute, so it’s reasonable to use as a primary source even in moderate-sized data centers.
I’ve put in a ton of them, and in most installations I buy two for redundancy. The GPS antenna works from a window in most instances .
I recently fell down the high precision time rabbithole, and now have
3 GPS units (a Truetime, a Symmetricom S250 and a LeoNTP), 3 Cesuim
Primary Reference sources (an FTS4060, and 2 PRS-50s), and an
assortment rubidium units.
One of the "standard" solutions is one of the Microsemi (Symmetricom)
SyncServer's, but these can be expensive -- I've been much happies
with the LeoNTP (
http://www.leobodnar.com/shop/index.php?main_page=product_info&products_id=272
) -- they are small, they are cheap, and they fast, they are "accurate
enough", and they just work. I've got one on my desk, with a cheap
(car) GPS antenna dangling out the window, and it syncs and runs
happily. A friend of mine has stuffed one in an IP68 box and it's
hanging happily on the side of a TV tower in the elements with no
issues...
I get mine from airspy.us - $349 + antenna.
W
Warren,
I like the cheap price of the LeoNTP. The only reason I prefer the Tm1000a is that it has an embedded web server, which lets me monitor the satellite constellation visibility. Otherwise, except for oven-controller time clocks, it seems obvious that the $2000+ GPS NTP servers are overpriced overkill 
-mel via cell
Warren,
I like the cheap price of the LeoNTP. The only reason I prefer the Tm1000a is that it has an embedded web server, which lets me monitor the satellite constellation visibility. Otherwise, except for oven-controller time clocks, it seems obvious that the $2000+ GPS NTP servers are overpriced overkill
Yup, that is a very good point -- the LeoNTP has a small LED interface
and a rotary encoder for configuration and monitoring, but it doesn't
have a web UI.
From the FAQ:
"Q/ Can I configure it via HTTP/Telnet ?
A/ No. Running a web server on this device although entirely possible
would reduce the performance of the unit. Therefore we took the
decision to just do configuration via the front panel."
This is indeed a really annoying limitation - in the past I've ended
up pointing a webcam at the LCD, but that is (obviously) suboptimal.
I also forgot to mention that it doesn't (yet) do v6, but that might
be added in future firmware versions...
W
If you want to go really cheap and don't value your time, but do value knowing the correct time, a GPS receiver with a USB interface and a Raspberry Pi would do the trick.
https://www.ntpsec.org/white-papers/stratum-1-microserver-howto/
RPi + GPS Hat because time across USB has much jitter.
Patrick
Not sure how accurate you need, but I just use a Raspberry Pi as a pool.ntp.org node. I thought about going the GPS route with it but didn’t want to mess with it.
-Andy
* jay@west.net (Jay Hennigan) [Fri 21 Jun 2019, 05:19 CEST]:
What are folks using these days for smaller organizations, that need to dole out time from an internal source?
If you want to go really cheap and don't value your time, but do value knowing the correct time, a GPS receiver with a USB interface and a Raspberry Pi would do the trick.
Have you tried this? Because I have, and it's absolutely terrible.
GPS doesn't give you the correct time, it's supposed to give you a good 1pps clock discipline against which you can measure your device's internal clock and adjust accordingly for drift due to it not being Cesium-based, influenced by room temperature etc.
You're unlikely to get the 1pps signal across USB, and even then there'll likely be significant latencies in the USB stack compared to the serial interface that these setups traditionally use.
-- Niels.
I think it depends on recipe you are using.
Raspberry have low latency GPIO, and some receivers have 1pps output.
https://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html
And there are tricks for avoiding temperature-related deviations
https://blog.ntpsec.org/2017/02/01/heat-it-up.html
Tony.
Yep, went through the same route until I figured out that GPS time is a bit ahead of UTC. We simply use a windows NTP server for internal use at work, and I won't recommend doing so, because it went off the rails once for a while despite of having several upstream servers pointed to.
Also there's a community out there dedicated for atomic clocks for civil use, it'd be fun to have one, set it up, and watch it ticking.
If "internal" means a local NTP server independent of external network
resources, the other responses are apposite.
If "internal" means a stratum 2 NTP server dependent upon other servers on
the network, and if you don't need accuracy in single-digit millisecond or
better range, we've done well with an older ex-Windows machine that now
runs FreeBSD and vanilla NTPD, and is now a pool server at ntp.org. � six
milliseconds, cost approaches the cube root of zero.
mdr
This.
I’ve had some timing issues ( unrelated to NTP ) with certain combinations of FlightAware RTLSDR USB sticks and Pi models. IIRC USB and Ethernet share the same bus on the Pis, and that can cause bumps.
GPIOs run right off the SOC, avoiding that.
The clocks on the GPS satellites are set to GPST which I think (I'm not a time geek so this is going to make someone cringe) is UTC without leap seconds or other corrections relating to rotation of the earth.
However, the messages sent to GPS receivers include the offset between GPST and UTC as well as the GPST timestamp. The receivers can use both together to obtain a measure of UTC accurate to about 100 nanoseconds.
Seems to me (again, not time geek, stop throwing things) that the use of GPST is an internal implementation detail chosen because it's easier to adjust an offset that rarely changes than it is to adjust atomic clocks floating in space. The system (including the system-internal adjustment of GPST with the offset) still produces a reasonably accurate measure of UTC. Also I imagine occasional leap seconds causing GPS navigators to jump spontaneously to the left which is probably more amusing in my imagination than in real life.
Joe
Patrick <nanog@haller.ws>:
The data from GPS includes the offset value from UTC for leap-second correction. This should be easily included in your time calculation. It's presently 18 seconds.
Once upon a time, Jay Hennigan <jay@west.net> said:
The data from GPS includes the offset value from UTC for leap-second
correction. This should be easily included in your time calculation.
Not only that, but at least some GPS receivers/protocols notify of
pending leap seconds, so software can properly distribute the
notification in advance.
I would submit that the proper use of a GPS receiver is for alignment
of the start of the second to a more precise value than can be
distributed across an asymmetric network like the Internet. The
actual 'time label' for that second doesn't necessarily need to come
from GPS at all. For security reasons, it's probably a good thing to
make sure you validate the data received from GPS in any case.
Once upon a time, Forrest Christian (List Account) <lists@packetflux.com> said:
I would submit that the proper use of a GPS receiver is for alignment
of the start of the second to a more precise value than can be
distributed across an asymmetric network like the Internet. The
actual 'time label' for that second doesn't necessarily need to come
from GPS at all. For security reasons, it's probably a good thing to
make sure you validate the data received from GPS in any case.
If you don't trust the GPS receiver's idea of the time, why do you trust
its start of the second? It seems really odd to trust one and not the
other.