In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Bert Gøtterup_Petersen) wrote:
> I am trying to use NTP to synchronize embedded audio-video products > (running Linux). Are these in a single broadcast area? If so, your application appears to require timed, not ntpd. Use of ntpd without a source of true time (now commonly called an isolated time island) is considered a secondary use, and ntpd is not optimised for that use, and doesn't have parameters to tell it that it needs to operate any differently from when used for its intended use. > peer 192.168.1.80 iburst burst prefer minpoll 4 maxpoll 4 prefer > peer 192.168.1.98 iburst burst prefer minpoll 4 maxpoll 4 prefer > peer 192.168.1.162 iburst burst prefer minpoll 4 maxpoll 4 > server 127.127.1.0 iburst # local clock (LCL) If this is typical of all of the machines, you have a potentially unstable configuration. The preferred method, these days, for running an isolated time island, is to use orphan mode, with no local clocks defined at all. If you do define local clocks, you should use a strict hierarchy, using server, not peer, and set the stratum to differ by at least two between hierarchy levels. > fudge 127.127.1.0 stratum 6 # LCL is unsynchronized flag1 0 flag2 0 flag3 Unless you have a five (four?) level hierarchy, you should not set the local clock stratum this low. The reason you might want to set it this low is that you have something other than ntpd disciplining the system software clock. You don't use zero in this case, because ntpd doesn't know when that something has failed, so clients need to have a chance to use a server where ntpd directly accesses the reference clock, in preference. The reason for setting high stratum numbers is to prevent your bogus time accidentally being used by a machine that has access to traceable time. One other thing to be aware of with this sort of configuration is that the maximum safe static frequency error is halved, to somewhat under 250ms, because you may end up synchronising to something which is at the maximum static error in the opposite sense to your static error. You don't have a drift file. Without a drift file, ntpd will do a full time and frequency calibration whenever it starts. That normally takes 15 minutes or more. It doesn't recognize the use of the local clock as special, because using the local clock as source is considered abnormal. If you do have a drift file, the standard ntpd configuration will accept initial errors up to 128ms, so you will have to wait for those to be removed from the system using the normal control loop (which has rather a large time constant). I think the very latest versions may have had some changes in this area, for initial startup. > As can be seen I use the local crystal as fall back, and this is were the > problem arises. If this is the configuration file on all the servers, you are not using the local clock as the fallback, you are using the local clock as the primary reference. > When the first of the peers is started it takes about 4 minutes before is > has synchronized with to its local crystal and further 3 minutes before a The way the local clock is defined, it is *always* synchronised with its local crystal! What takes some time is for ntpd to believe the time well enough for it to pass it on to clients and downstream servers. ntpd doesn't know you are running an isolated time island, so doesn't make a special case of the local clock. In the intended usage, it would be very bad for ntpd to start serving time from the local clock before having got reliable times from peers and servers, as it could end up serving a completely bogus time to the rest of the network, and then, suddenly jumping to the correct time. To get the master server to serve its local clock instantly, you would need a strict hiearchy, so that there was a clear master, and new option to tell the server that its software clock was the definite time source for the local time island. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
