tlaronde%polynum.com@localhost writes: > On Tue, Jun 04, 2013 at 11:20:21AM +0000, Michael van Elst wrote: >> >> NTP doesn't use ICMP but UDP and client and servers exchange time >> information directly within the NTP protocol. The gateway is >> nothing more than a router in the path that causes some delay, >> with NAT or without. >> > > OK. But do you know if the offset is taken as the mean of the time (in > client's time) for the round-trip, and if the out-going translation > (allocation of port) on the gateway is more time consuming than the > translation when the packet returns i.e. the mean is inaccurate due to > some asymetry between going and returning? (Or more generally because > the NAT gateway can take a variable amount of time treating the > packets.) Basically, NTP (ntpd and ntpdate) assume that the mean of the outgoing and incoming local timestamps (in the local machine's time) is the same time as the mean of the remote machines incoming and outgoing timestamps (in the remote machine's time). Equating those leads to an estimated offset. So if there is asymetric delay where there is extra delay D in one direction, the estimated offset will be biased by D/2. If this delay is always present, there's no way to tell without another time path. > The question arised because I have bad values (more than 2 seconds > offset) for a node on which I have made a "ntpdate -b" (so no adjtime) a > day before: the (new, dual-core x86_64, NetBSD 6.1) PC clock is not an > atomic clock, but when the system is running it does not shift by > several seconds a day, or is it? 2 seconds in a day does not sound unusual. My machine's clock has a drift value of 26, which if I am doing math right is 2.2s/day slow. You should be able to use verbose options and see what the delay and offset are. If the delay is on the order of 50ms, then your error is bounded at 25ms. And probably it's far less. Also, ntpdate sends several packets. If the NAT is slow on outbound setup, then the subsequent packets should be faster. You should be able to look at the verbose logs to see if that's true. I would be really surprised if NAT were a factor at timescales of 500 us or more; 100 us extra delay on setup wouldn't surprise me much. > (It is more to understand what is going on, since this network I have a > node into is intermittently connected to the Internet, so ntpd is not an > option; and as long as all the LAN nodes have the same time, it does not > matter if it is not exactly in sync with external. But there was an > appliance---NAS---whether taking time from some Windows node serving > Active Directory (? I'm not a Windows administrator...) if it was > not using ntpd, or using ntpd and going insane when left without a > connection for 2 days. So I'm trying to see with the NetBSD the accuracy > of ntpdate/ntpd in this topology.) Try a cron job to run ntpdate without setting the clock, just logging, and do that every hour and see if you can see any patterns. Why do you say ntpd is not an option because of intermittent connectivity? Did you try it? I'd expect it to, with some difficulty, estimate the drift and correct for it when it can't reach any servers. You could hand-measure a drift rate and jam that into /var/db/ntp.drift (IIRC as a rate * 2^20, so ppm is pretty close) to start up.
Attachment:
pgpWd27roR6Px.pgp
Description: PGP signature