Currently om running one server on GPS and one on DCF77 / PZF reference time source.
Im currently looking into making this more robust (from denial or spoofing) by either adding time servers that use other time sources, or servers that can add more ‘robustness’ to my current setup.
For example by using PPS or 10 MHz as an alternative frequency source.
Does anyone use the eLoran system as an alternative time source?
DCF77 isn’t a good source to keep time.
The reason is that it’s path thru the air is far from stable, for that reason it will not be very precise.
It’s nice for a clock on the wall, but not for NTP.
GPS with PPS is the most exact time you can get.
To make it robust, just add servers from good sources on the internet.
Because they will prevent wrong time if they spoof the GPS or PPS time.
PPS will only make it more precise, it’s an extra signal that GPS produces to be more accurate.
A very good GPS with PPS is the Garmin 18x LVC, see this article:
https://www.lammertbies.nl/comm/info/gps-time
I use it for my main server.
Add additonal NTP Server as source and you will be fine.
Both of your appliance receiver have a either a TCXO or OCXO which will be synched and regulated.
If you want to add additonal PPS / 10MHz those muste be synched / regulated too.
thanks for the info.
My DCF77 appliance (Meinberg M200) seems to run very nicely (between -8 and +8 ms compared to monitor time over the past 10 days). It also uses the PZF, which also uses the phase modulation of the signal.
Accuracy of my server is comparable to my current GPS-setup (Meinberg M300).
I think there’s a misunderstanding in this thread, and this is at the heart of it. If you define accuracy as nanoseconds deviation from the US Naval Observatory’s clock ensemble, GPS is your best bet for accuracy. But UTC is a global effort coordinated by BIPM, and the USNO is just one contributor.
I think this thread isn’t about absolute accuracy to USNO, but about overall resilience of global time. The US Cybersecurity and Infrastructure Security Agency considers timing a cybersecurity concern and says:
[T]he use of the Global Positioning Navigation (GPS) as the primary, and in many cases, the sole source of PNT data makes these sectors vulnerable to the intentional or unintentional disruption of the GPS signal.
I can only assume non-US sources are even less keen to rely solely on GPS. (See, e.g., India’s mandate that corporations use its own NTP servers.)
If only your GPS receiver is jammed or spoofed, sure, a good implementation will fail over to stratum 2 or go into holdover on the local oscillator. But in a widespread disruption of GPS, relying on other servers won’t help. We need other stratum 1 sources for resilience. (Admittedly, a widespread GPS outage would cause more problems than the time shown on your computer being wrong, but that’s not a reason to ignore it.)
Both of the VMs I have in the pool in Brazil get time from the national observatory’s Cesium references. Their observatory is one of the contributors to defining UTC. (However, I’m on a garbage network there, so I’m not realizing great accuracy. But it means I’m not solely dependent on upstream GPS as a source.)
Is eLoran operational? All of my Googling is only turning up old Loran stuff. My inner radio nerd would be thrilled to see it remain in use.
ntp.time.nl (which is a pool consisting of ntp1.time.nl and ntp2.time.nl) also uses the European Galileo GNSS as a reference. Perhaps that is an option?
See https://time.nl/ for further details.
Thanks for the suggestion!
Discussions of UTC versus GPS versus USNO etc are good fodder for the time-nuts mailing list. UTC is not available in real time. UTC(NIST), UTC(USNO), UTC(PTB), UTC(NPL), etc are maintained by the major laboratories, but may be difficult to access with high precision. E.g., NPL offers fiber optic time transfer at a price.
DCF77 avoids GPS, but there are caveats. The leap second indicator is not protected by a checksum. I’ve observed spurious leap seconds decoded a few times. Meinberg NTP servers have additional logic to minimize the problem.
The use of multiple, diverse time sources is often recommended.
Hello Kets_One
Does anyone use the eLoran system as an alternative time source?
I have 3 physical servers in one location with 2 internet connections,
e.g. poor mans dual homed internet. They are all peers to each other,
and do have (or had) some Stratum 0 sources (GPS and DCF77) and also
some other external servers as source.
The Garmin GPS 18x LVC I had to place outside of the window, else it
looses sync. The DCF77 mouseCLOCK is placed inside (cable to short), but
it helps if there is kind of an open visibility into the direction of
the source with a window (avoid letting down some metal shades) instead
of a brick or concrete wall. My Location is in Zürich, around 300km
south of Mainflingen, where the DCF77 sender in Germany is located.
During bad weather somewhere in the path, e.g. snow or thunder storms,
the signal reception is bad and the local ntpd kicks the DCF out as the
primary source.
Some (partly outdated) details are documented here:
https://www.home4u.ch/ntp.html
The DCF77 on FreeBSD does not work any more since a few years. 
Some output from each server (sorry for a potential line wraps):
ntp1.home4u.ch # ntpq -p
remote refid st t when poll reach delay offset
jitter
As I use the forum through email, it has kind of cropped the last part, so here it continues (now submitted through the community website):
ntp1.home4u.ch # ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
oGPS_NMEA(1) .PPS. 0 l 6 16 377 0.000 +0.002 0.001
+ntp2.home4u.ch .DCFa. 1 u 27 64 377 0.159 +1.475 0.119
+ntp3.home4u.ch 251.4.108.178 2 u 42 64 377 0.216 +0.529 0.044
+time1.ethz.ch .PPS. 1 u 48 64 377 1.736 -0.152 0.076
-ptbtime2.ptb.de .PTB. 1 u 35 64 377 14.769 -0.967 0.045
ntp2.home4u.ch # ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*GENERIC(0) .DCFa. 0 l 48 64 377 0.000 +5.920 4.202
+ntp1.home4u.ch .PPS. 1 u 59 64 377 0.143 -1.408 0.115
-ntp3.home4u.ch 251.4.108.178 2 u 39 64 377 0.127 -0.856 0.147
+ntps1-1.eecsit. 130.149.17.21 2 u 22 64 377 20.825 -1.998 0.165
ntp3.home4u.ch # ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*ntp1.home4u.ch .PPS. 1 u 105 512 377 0.210 -0.535 0.965
+ntp2.home4u.ch .DCFa. 1 u 469 512 377 0.265 +0.753 1.078
-ntp12.metas.ch .MRS. 1 u 59 512 377 9.255 +1.236 3.892
+time2.ethz.ch .PPS. 1 u 78 512 377 6.362 +0.540 2.462
Best regards,
Fabian
Sorry mate, DCF is a signal that is broadcasted via VLF Radio bands, 77KHz, the problem is that it’s not very accurate compered to PPS from GPS.
We also can use other satellites.
Yes you can spoof of jam a GPS, so what? There are other internet sources you compare it too.
If you do not compare your time-source to other timeservers then you have a point.
We have a lot of sources here, we do not depend on GPS only. BTW, you do not need to poll servers near you, you can easily use sources at the other side of the planet to compare, they will be accurate too, enough to check your own sources,
I have a DCF77 receiver also, but it doesn’t work well as I’m 1000km away from Munich. I should have bought the device with external antenna connector as I have very big wire aerials here that pick up the signal just fine.
In case you want to know what DCF77 looks like, you can hear it on my websdr during the day:
http://websdr.heppen.be/?tune=77.2cw
It’s just a bunch of tones 
Sorry, I just re-read my reply and it came across as confrontational in a way I totally didn’t intend. My apologies for that!
My point was just that I think there’s value in non-GPS sources, even if they’re not the very best accuracy available. Like you say, they can always be compared with other Internet sources. I’m sure many can do better, but my home connection struggles to get more than +/- several milliseconds to even nearby Internet sources, so lacking the nanosecond-level accuracy of GPS isn’t a huge shortcoming.
BTW, from your websdr link, I gather you’re a fellow ham! US-based N1ZYY here. I’m in a city here with a really nasty noise floor so I’m rarely even on HF, though.
ON5HB here and my wife is ON3MS.
Luckily our location is very quiet, so I’m mostly on 160/80/40.
You can also make phone-calls to get the time, but I think that will become very expensive 