Re: [ntp:questions] Local clock - sync issue

On 2010-11-09, David Woolley wrote: > unruh wrote: > >> If I recall correctly his problem was that he had 4 outside sources plus >> the local time. Then something disconnected him from those outside >> sources for a long time ( hours) After that was fixed, the system never >> again went back to th

Re: [ntp:questions] Local clock - sync issue

Connectivity is fine to the ntp servers, if I restart ntpd it starts syncing with an external clock immediately. This article could be the fix: http://www.novell.com/coolsolutions/feature/15345.html Cheers, Stephen Thanks, Stephen. I don't like that solution, as it imposes more load than n

Re: [ntp:questions] Local clock - sync issue

I'm talking about weeks at a time. Network connectivity goes down, ntp reverts to LOCAL clock, then if you look at the logs and check ntpq, it remains bound to the LOCAL clock, several weeks after the connectivity went down. A simple restart of ntpd brings the external clocks back online. Chee

Re: [ntp:questions] Local clock - sync issue

On 11/8/2010 8:35 PM, Stephen Vaughan wrote: Alright, I'll give it a miss then. We'll look into removing the locl clock. Cheers, Stephen -Original Message- From: questions-bounces+stephen.vaughan=blackboard@lists.ntp.org [mailto:questions-bounces+stephen.vaughan=blackboard@lis

Re: [ntp:questions] Will AutoKey setup work on a NAT host behind a firewall?

Harry, Autokey is not designed to work behind NAT boxes. The Autokey server and client must have the same (reversed) IP addresses. The intended model is using two interfaces, one for the Internet side running Autokey, the other for the inside net on the other side of the NAT box. Dave Harry

Re: [ntp:questions] Local clock - sync issue

Stephen Vaughan wrote: I'm talking about weeks at a time. Network connectivity goes down, ntp reverts to LOCAL clock, then if you look at the logs and check ntpq, it remains bound to the LOCAL clock, several weeks after the connectivity went down. A simple restart of ntpd brings the external

Re: [ntp:questions] Local clock - sync issue

Richard B. Gilbert wrote: Perhaps he meant "IBURST"? That's certain allowable, particularly if he does restarts at long (weeks or months) intervals. Given that NTPD needs up to ten hours to get a tight lock on the correct time, most users will want to minimize restarts. If you read the art

Re: [ntp:questions] What level of timesynch error is typical onWinXP?

Dave, Thanks for the test. I verified the same thing. Note that the measured offset at the end of the frequency measurement phase was very small, so the net frequency measurement should be the same as Solaris. Obviously, FreeBSD is doing something very different than Solaris. I suspect Linux

[ntp:questions] help needed for ntpd ipv6 setup

I have two linux PCs, both running fedora 11 with NTP ver. 4.2.4p7. PC1 has 192.168.1.1 and 2002::c0a9:0101 addresses PC2 has 192.168.1.2 and 2002::c0a9:0102 addresses ntpd is running on PC1. on PC2 ntpdate 192.168.1.1 returned good timing from PC1 But ntpdate 2002::c0a9:0101 did not work Wiresh

Re: [ntp:questions] Local clock - sync issue

On 11/9/2010 5:10 PM, David Woolley wrote: Richard B. Gilbert wrote: Perhaps he meant "IBURST"? That's certain allowable, particularly if he does restarts at long (weeks or months) intervals. Given that NTPD needs up to ten hours to get a tight lock on the correct time, most users will want to

Re: [ntp:questions] Local clock - sync issue

Richard B. Gilbert wrote: > What "article" are you talking about? If it was posted here, > could you tell me the date/time stamp on the message? (Shrug) From: Stephen Vaughan Newsgroups: comp.protocols.time.ntp Subjec

Re: [ntp:questions] help needed for ntpd ipv6 setup

joan lee wrote: Wireshark runs on PC1 shows NTP client messages from 2002::c0a9:0102 + are received properly, but instead of replying with NTP server messages, + PC1 is sending ICMPV6 unreachable (administratively prohibited) messages. Could anybody gives me some hint on why NTPD ignores the