In article <[EMAIL PROTECTED]>, Anders <[EMAIL PROTECTED]> wrote:
> I tried fartein.ifi.uio.no and it reads like this: I would avoid that server. > swisstime.ee.et LOCAL(0) 13 u 976 1024 377 63.230 -1998.8 16.680 It is using a well known, long standing, broken server. Indicating that it is not being properly managed. In turn, that broken server has a local clock configured, which is something you should not do if you are a low stratum public server, or a source for one. > *chronos.cru.fr .GPS. 1 u 217 512 377 64.610 1.839 1.570 Even the delay for its current upstream server is rather high. > *LOCAL(1) LOCAL(1) 12 l 1 64 17 0.000 0.000 0.008 You should only consider configuring a local clock if you serve time to other machines (and only do so locally). As you are using Windows, and Windows is a poor choice for an NTP server, you shouldn't really expect to have local clocks configured on Windows. Note that the frequency correction will be maintained without this being configured. Others have said that the problem is a known bug. If they hadn't, I would have suggested that DNS wasn't up at the time ntpd tried to resolve the server addresses. _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
