On Thu, Nov 10, 2011 at 15:14, Charles Elliott <[email protected]> wrote: > I don't understand why you are not recommending some sort of GPS device as > the primary time source for Marongiu's system.
You seem to be assuming goals of Marco's design which he didn't specify. There are a number of questions that could inform better advice: 1) How much offset is acceptable between his systems and UTC? 2) How much offset is acceptable between any given pair of systems in a single data center? 3) How much offset is acceptable between any given pair of systems in different data centers? The lack of such requirements is part of why I didn't respond initially. When I did respond, I responded only to the issue he raised, which was "what you think about how I _currently_ organize my synchronization subnets?" You seem to be assuming goals he didn't state. I did not advise against using a local reference clock, and you are correct that he can achieve tighter sync both to UTC and between machines by placing one or more quality reference clocks in each data center. > When the WAN becomes busy, > usually during the daylight hours, the offset becomes highly and negatively > correlated with the network delay. Also, the jitter can easily rise to the > 500s. I am not sure of the source of this error; it may be that the > algorithm for computing the round-trip transit delay is in error, or the > to-server and from-server transit times may not be symmetric, but in any > case the error in the computer time can, and often is, in the 100s of > milliseconds. A continuously saturated link can cause hundreds of milliseconds or even seconds of error in the apparent offset to a remote source reached across the saturated link. This is inherent in the NTP protocol and is not due to asymmetry of forward and return paths, it is due to the increased variability in round trip times (jitter) compared to a path transiting no congested links. > I own three GPS devices now, and I don't yet have PPS > installed, but nevertheless the GPS seems never to vary more than about ±40 > ms from true time, although without accessing the true time over the > telephone or by radio it is impossible to tell for sure. Performance of GPS without PPS is highly dependent on the specific receiver/firmware combination as well as the method of interface to the PC. The same GPS puck connected via USB will typically have much higher jitter than one connected via a traditional serial port (usually RS-232, sometimes RS-442). I would not assume your experience is applicable to other GPSes and/or connections. Imagine how far off a navigation GPS's position reports would be if the receiver internally could not do better than 40 msec. Basically useless for navigation -- so the issue is not the GPS receiver so much as its output timing performance. Garmin GPS 18x LVC pucks replaced the earlier GPS 18 LVC with a more sensitive receiver that aquires faster and in more marginal situations (like inside a window facing north), a great improvement for navigation use, but the 18x output timing jitter is worse than the earlier 18, providing poorer time service in absence of PPS. This archives of this list provide a wealth of information on these workhorse affordable receivers (which do support PPS in the LVC variety, but also require custom wiring). > With inexpensive > GPS devices, which I have, time does appear to vary about ±40 ms over the > day as satellites come into and go out of view. But with stratum 1 network > time sources over the WAN, time accuracy appears to vary wildly in the > interval ±100 ms or more. There are inexpensive options such as the Sure evaluation board (around $30) and the GPS 18x LVC (around $60) for those willing and able to solder the required connections, which is trickier with the Sure due to the need to solder on the board as opposed to simply mess with a cord terminated in bare wires for the LVC). Personally, I've bought two GPS 18x LVCs from the same fellow who provides a nice packaged solution with USB and DB-9 serial connectors, with the USB cable providing power while serial and PPS are wired to the DB-9, for less than $120 delivered in the US last I checked. See the list archives for his web and email addresses. > We should find out what Marongiu's time accuracy requirements are. If they > are severe, then he should think about using WWV over the radio, PPS over > the telephone, or an expensive GPS device as his primary time source, IMHO. Expensive is relative. $50 to $120 in the US is expensive for some, and that gets you PPS and small fractions of a millisecond offset to UTC. > See Meinberg Radio Clocks, Bad Pyrmont, Germany, http://www.meinberg.de. These are somewhat more expensive, from what I gather. Cursed be all vendors who provide no hint of their prices until you submit yourself to their sales, uh, people. I've never heard anything but praise regarding the quality of Meinberg solutions, but like practically every other vendor of time synchronization hardware, their prices are invisible to those who choose not to ask for pricing. Make me an offer, please, or I'll find someone who does, on ornery principle that I don't care to spend my time contacting N vendors about M options when I can throw something together with a junked PC and $120 or less that gets me way under 1 msec. I'd rather do the integration work myself than play pricing peek-a-boo, but then I'm doing this as a hobby, not to solve a business problem. It's probably true that if I have to ask the price, it will be higher than I'd be willing to pay. Cheers, Dave Hart _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
