> From that point forward (and we hope the devices will have an operational > life of at least ten years) they'll be dependent on their internal clock and > NTP, but we really need them to stay synchronized to within 100 > microseconds. 10 microseconds would be ideal, but 100 would be acceptable. > And in order to be useful, they need to stay synchronized at that level of > precision essentially forever.
It's going to be "interesting". I suggest you start experimenting. How good a crystal do you need if you run without NTP? Note that you don't need accuracy, just stability. Software can correct for a frequency that is slightly off. NTP calls it drift. Let's play with some numbers. Let's talk about 3 years. That's 94608000 seconds, or 1E8, a handy round number. So if your clock is off by 1 part in 1E8, it will drift 1 second in 3 years. You need 100 microseconds, or 1E-4, so you need a clock good for 1E-12. Here is a typical high end OCXO. (It may blow your budget, but we can use it as an example.) http://www.mti-milliren.com/ocxo_270_ocxo.html The typical 5 MHz aging performance is 5E-10 per day and 5E-08 per year. That's not in the right ballpark. So, can you do it in software? After the typical NTP packet exchange, you have 4 time stamps. The (local) time the request left the client, the time it arrived at the server, the time the response left the server, and the time it got back to the client. You have 3 unknowns: transit time out, transit time back, and clock offset. >From the timestamps, you get two equations: the transit times fudged by the clock offset. NTP assumes that the network is symmetric. That's the 3rd equation that lets it compute the clock offset which it uses to correct the local clock. If you assume the local clock is accurate, you can compute the network delays. There is a chicken-egg problem. You can't do both at the same time. If you have a lot of NTP data and everything goes right, you get a picture like the one here: http://www.eecis.udel.edu/~mills/ntp/html/huffpuff.html You need to know how sharp the point on the left is. That depends on the network path between your box and the NTP servers you are using. The traffic pattern on the last hop (from your site to your ISP) is likely to be the nasty part. In my experience, getting to 100 microseconds is going to be hard. I wouldn't call it impossible, but it sure won't be easy. Suppose you can find good NTP servers with a stable network path. If you collect a bunch of data the packets with the minimum total network delay will be the ones that didn't encounter any queuing delays in the network. If you cross your fingers and assume the network path is symmetric, you now have a good measure of the clock offset. If you remember that transit time and only use packets with similar transit times, you should be able to get good results. There are a lot of loose ends in there. The reference version of ntpd used by most Unix like OSes is setup to run on typical PCs and servers. Their crystals are actually a pretty good thermometers. :) http://www.ijs.si/time/temp-compensation/ If you have a good crystal (good, not great) it should be possible to ride over busy periods when you don't get any packets with short delays. > That would be nice, of course, and we'll get the best GPS antenna we can > afford and fit, but we can't have an externally-cabled antenna, or require > that people put these on windowsills, or anything like that⦠There will be > too many of them, and the level of clue of the people plugging them in out > in the field is likely to be too low. How are you going to find good NTP servers for all your boxes? Are you targeting homes, offices, or machine rooms? GPS works inside my house. (Not great, but good enough.) Are you trying to measure arrival times of packets you control, or get accurate times from tcpdump/wireshark on arbitrary traffic? Can you post-process the data? I'm thinking of something like get a reasonably good crystal and let your system run off that crystal without trying to get time from the network. The idea is to keep NTP from doing something stupid. You can poke it occasionally from a central server to track the long term drift. Or setup nearby servers in noselect mode, turn on logging, and get the info out of the log files. -- These are my opinions, not necessarily my employer's. I hate spam.
_______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
