Eric S. Raymond writes: > Achim Gratz <strom...@nexgo.de>: >> Forget about GPS outages. If you want to connect these time servers to >> the net, they should have some form of sanity checking that's >> independent from their primary time source and take them off the net as >> soon as something looks fishy. > > What kind of sanity checking do you recommend?
I'd think that keeping two or three known good servers as noselect would go a long way in that scenario. Could even be a pool statement, although personally I'd opt for at least five servers in that case. If more than one of those servers are more than 10ms either way from your time, something is going on that shouldn't be. If it's other stratum-1 sources then you should likely see below 1ms (2ms tops) unless the network totally flakes out. Since ntpd doesn't do anything with noselect sources the actual logic of taking the stratum-1 offline in case of problems would need to be delegated to some monitor process. The message offset relative to the PPS is recorded somewhere in ntpd (you can set up the extended statistics to spit it out), so if that starts drifting from the expected value (fudge2) the clock should become suspect. The same goes for sudden changes in the local frequency offset. Again would need to be an external process that does the health monitoring. Another thing would be to have more than one refclock, but ntpd currently doesn't support that very well. Part of that is that you seemingly can't have more than one pps-gpio for whatever reason. The other part is that you can't tell ntpd which clock you expect to be more accurate and how to switch from one to the other. That would need new code to support it from within ntpd I think. As I said before, I'm planning to use a microcontroller to integrate GPS, DCF77 and maybe an OCXO into a time box. I'm currently looking at a controller that has Ethernet w/ PTP support (hardware timestamps), so it could be a completely autonomous dual-protocol timeserver. But a less capable controller might just produce PPS and a serial stream and connect to a rasPi or other server for a resilient stratum-1. That would use the Uni Erlangen format, like the Meinberg clocks. > My recipe/HOWTO does emphasize that you need 1PPS for Stratum 1 service. > Beyond that I don't know there's much I can do to head off operator error. There's no way to prevent stupidity and malice, yes. But since the goal is (IIUC) to get more stratum-1 servers onto the net, some education how not to shoot yourself into the foot is in order. > How do you fudge a 1PPS source? What do you have that you consider > more accurate? You are only talking about an aligned PPS source, not frequency PPS, right? The NMEA driver in PPS mode has noth a PPS offset (fudge1) as well as an NMEA message offset (fudge2) parameter. I haven't used the ATOM/prefer combination in a while, but IIRC, ATOM can be fudged as well. If the PPS is done via pps-gpio the offset should be below a few milliseconds. I can't be sure of my own offset better than about 2…4ms due to the asymmetry of the DSL line, but to get the same time as the PTB servers I need to fudge about 1.7ms with the navSpark mini. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
