Really good back-end clocks, particularly when you're implementing a redundant system with a cesium clock or two, are a lot more expensive than the front-end servers that clients need to see. Do you have particular technical reasons you want to put the "actual device" on the net? Most of the time, the "actual device" in these cases is merely a linux box or something similar wrapped around a stratum-zero time source. A much easier way to do this, which gives you control over what faces the network, is to run your own front-ends of stratum 1 servers that all talk to the same network of back-end time sources: FE-1 FE-2 FE-3 | | | \--Time Distribution/ \ | / GPS Cesium Clock3 Put cards in the front ends that let them receive PPS or IRIG, and then let them all get a time signal from the back end clocks. The clocks on the FEs will be good to a handfull of microseconds. since the FEs will be synched directly to a stratum zero time source (the PPS signal from the GPS and cesium clocks, for instance), they'll be running at stratum 1. As a nice example of how you can structure this, see the udel NTP page. The added expense here will be purchasing an IRIG board for the front-ends, or you can decode it via the sound input, but if you go with a real irig board, you'll get a high-quality onboard oscillator that'll do a much better job of running free if it loses the backends. This way, you can have as many front ends as you need for (redundancy, scalability, ...) and they'll run a real OS that you control. No need to put an application level forwarder in the middle, since they _are_ your application level gateways to the PPS/IRIG signal. btw, comp.protocols.time.ntp is a good source of information about this kind of thing.. probably better than nanog. -Dave -- work: dga@lcs.mit.edu me: dga@pobox.com MIT Laboratory for Computer Science http://www.angio.net/ I do not accept unsolicited commercial email. Do not spam me.