> some insights for people using GPS for very critical server time keeping > http://www.dw.de/dw/article/0,,15817272,00.html
This misses the point in a rather large way. Most of this jamming makes the true GPS signal hard to receive. When the signal cannot be received, the existing free-running clocks in various parts of the "system" keep working. Since the subsystem as a whole has learned the 1st, 2nd, and hopefully 3rd and further derivatives to tune itself and predicively pace, everything works out. Until the GPS signal or whatever else comes back. Oh my god, sometimes we use net, and we can't talk to remote Internet-based ntp services. Except that's the point -- we only pay attention to the remote services (ntp or gps) to learn how to tune various adjustments to the free-running clocks. Furthermore, some GPS receivers will keep feeding their own free-running clocks but say the service is "degraded". It is not like that free-running clock on the GPS is going to go wonky immediately. It is being jammed. It is not being spoofed. The end result is that the clock does not go crazy. It remains stable and the best effort result is good enough. So enough of this "oh my god, it is all going to go wrong" balony.
