In article <[EMAIL PROTECTED]>, jjxjjx <[EMAIL PROTECTED]> wrote:
> Subject: Peer's stratum is less than Host's stratum Peers are not the same as clients, and you shouldn't be configuring them unless you really know what you are doing. > i got this message when trying to sync system clocks on win 2003. In any case, I can't find this message anywhere in version 4.2.0 of the reference implemntation. Which implementations and versions are you using. Note that the service pack level of Windows 2003 is important if you are using W32Time. (Although, as the source code and detailed documentation for W32Time are not available outside Microsoft, they are the best people to ask about that implementation.) > Using ethereal i see packets between client and server. > Client is intruducing itself as Client but has Stratum 1 That should only be true if it has a directly attached and working references clock, in which case it doesn't need an external server. Even the early versions of W32Time didn't start reporting a synchronised stratum until they had been synchronised once, and, even then, reported stratum 2 (regardless of the source!!!). Remove the reference clock from the configuration, or replace the client with a working NTP implementation. > Server is intruducing itself as Server bu has Stratum 15 I think this is correctly synchronised to a stratum 14 reference clock, which is the most paranoid setting for the local clock driver. Assuming the network is only two levels, there is no valid reason for configuring the local clock with any better a stratum. > We configured server with some NTP server tool that has reference to > Local System time on server. What tool? What parameters did you use? Normally people configure the local clock by directly editing the configuration file, and are able to quote its contents here. > Is it possible to force stratum on machine? No, it is only possible to force the stratum on a reference clock, but you should never need to force the local clock to anything numerically lower than 15 minus the largest number of NTP network hops to a client. As has already been noted, many of the assumptions in NTP are based on the idea that time is eventually traceable to Universal Coordinated Time, rather than the random measure of time produced by some PC's clock. As such, using the local clock as a first choice source is never the best solution. _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
