On 2008-12-03, Jeremy Leibs <[EMAIL PROTECTED]> wrote: > Our configuration is 4 machines connected on a local gigabit network > located on a mobile robotic base. These machines are subject to > frequently being powered down or restarted.
Warm restarting a stable ntpd is not generally a problem. But cold starts are a challenge. The problem is that the behavior of the clock circuitry changes as it heats up. And, the drift correct calculated by ntpd for a warm clock is likely not the same as what is required for a cold clock. If short synchronization times are imporant then you need to be willing to pay for better clock circuitry. You may want to look at using PTP (IEEE 1588) between the clocks on your LAN (see http://ieee1588.nist.gov/) instead of NTP. > In order to use the robot, the clocks on these machines must be > self-synchronized to less than 1 millisecond. And, further on, you state that you need this in the time span of a few minutes. > Ping times between machines on this local network vary between 100 > microseconds, and 1ms depending on saturation of the network by sensor > data streams. That latency is not a problem for NTP. > The 4 machines are connected to the rest of the world through a > wireless link. The delay time on the wireless link is much more > variable: in the range of 2ms to 300ms depending on the quality of the > link and the amount of data going over the wire. We don't care nearly > as much about synchronization between the robot and the outside world, > though it would be nice to avoid unbounded drift. A synchronization in > the range of 10's of ms would be acceptable. Synchronization to UTC is a side effect of using UTC as the time-base for NTP. In reality, any sufficiently stable time-base could be used. Most people want to be synchronized to "the one true" time and UTC over a network (i.e. from a remote time server) or via GPS is cheap and ubiquitous. > Our present configuration is made up of 1 machine syncing to an external > server over the wireless link and acting as a local server for the robot. > The remaining 3 machines then sync to this local server. The key here is that the local server must be configured to continue serving time to the robot LAN even when the real time sources are unreachable. > Operating under "stable" conditions, this configuration seems to work well > and eventually converges to our sub-millisecond criteria. However, we have > 2 large problems. > > 1) When the operating conditions suddenly change, the system diverges > dramatically, and sometimes becomes unstable/divergent. In particular, a > pathological case we have seen is when the wireless link is near saturation > for an extended period of time such as when copying over multi-gigabyte log > files over the course of several hours. Once the transfer completes and the > wireless link opens up again, the delay time across the wireless link > plummets, the local server immediately diverges from the external server by > around 30 ms. You should employ traffic shaping to insure that less than 100% of the bandwidth is used by these log transfers. > After this initial divergence, the local server stops qualifying as a > good source of time, and the remaining 3 machines start drifting apart > in independent directions. 30ms of drift should not be enough to cause the robot LAN server to be rejected. Unless the robot LAN clients have been misconfigured to use the Undisciplined Local Clock (127.127.1.x) as an alleged "backup". > 2) When the system is in a non-converged state, such as after > diverging in case 1, or on boot, the time it takes for the system to > converge is unacceptably long. If I disable NTP, and run ntpdate on > each of the client machines, I can synchronize them to within 1 ms, > but as soon as I start NTP again, all of the clocks begin to diverge, > often taking hours to re-converge back to to steady state. Have these ntpds ever been allowed to run long enough to populate their drift file? -- Steve Kostecke <[EMAIL PROTECTED]> NTP Public Services Project - http://support.ntp.org/ _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
