Re: clock problem

2007-05-12 Thread Oliver Fromme
M. Warner Losh wrote: Oliver Fromme wrote: : M. Warner Losh wrote: : Peter Jeremy wrote: : : There seems to be a bug in ntpd where the PLL can saturate at : : +/-500ppm and will not recover. This problem seems too occur mostly : : where the reference servers have lots of

Re: clock problem

2007-05-12 Thread Ian Smith
On Fri, 11 May 2007, M. Warner Losh wrote: : Yes, but Martin already showed it was using the i8254, not TSC; would : you expect the same effect using powerd with the i8254 clock? It seems : so, unless it's some problem with est and/or p4tcc under APM (canoworms) No. I would not have

Re: clock problem

2007-05-11 Thread Oliver Fromme
M. Warner Losh wrote: Peter Jeremy wrote: : There seems to be a bug in ntpd where the PLL can saturate at : +/-500ppm and will not recover. This problem seems too occur mostly : where the reference servers have lots of jitter (ie a fairly congested : link to them). Yes. This is a

Re: clock problem

2007-05-11 Thread Martin Dieringer
On Thu, 10 May 2007, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Martin Dieringer [EMAIL PROTECTED] writes: : well now it works without restrict: : # ntpq -p : remote refid st t when poll reach delay offset jitter :

Re: clock problem

2007-05-11 Thread M. Warner Losh
In message: [EMAIL PROTECTED] Martin Dieringer [EMAIL PROTECTED] writes: : This is NOT a hardware problem. 1. I have this on 2 machines, 2. the : problem is solved by switching to ACPI instead of APM It is a hardware problem. APM + powerd changes the frequency of the TSC. If the TSC

Re: clock problem

2007-05-11 Thread M. Warner Losh
In message: [EMAIL PROTECTED] Oliver Fromme [EMAIL PROTECTED] writes: : M. Warner Losh wrote: : Peter Jeremy wrote: : : There seems to be a bug in ntpd where the PLL can saturate at : : +/-500ppm and will not recover. This problem seems too occur mostly : : where the reference

Re: clock problem

2007-05-11 Thread Tom Evans
On Fri, 2007-05-11 at 08:53 -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Martin Dieringer [EMAIL PROTECTED] writes: : This is NOT a hardware problem. 1. I have this on 2 machines, 2. the : problem is solved by switching to ACPI instead of APM It is a hardware

Re: clock problem

2007-05-11 Thread Ian Smith
On Fri, 11 May 2007, Tom Evans wrote: On Fri, 2007-05-11 at 08:53 -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Martin Dieringer [EMAIL PROTECTED] writes: : This is NOT a hardware problem. 1. I have this on 2 machines, 2. the : problem is solved by switching

Re: clock problem

2007-05-11 Thread M. Warner Losh
In message: [EMAIL PROTECTED] Tom Evans [EMAIL PROTECTED] writes: : On Fri, 2007-05-11 at 08:53 -0600, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Martin Dieringer [EMAIL PROTECTED] writes: : : This is NOT a hardware problem. 1. I have this on 2 machines, 2.

Re: clock problem

2007-05-11 Thread M. Warner Losh
In message: [EMAIL PROTECTED] Ian Smith [EMAIL PROTECTED] writes: : On Fri, 11 May 2007, Tom Evans wrote: : On Fri, 2007-05-11 at 08:53 -0600, M. Warner Losh wrote: :In message: [EMAIL PROTECTED] :Martin Dieringer [EMAIL PROTECTED] writes: :: This is NOT a

Re: clock problem

2007-05-11 Thread Peter Jeremy
On 2007-May-11 12:11:29 +0200, Oliver Fromme [EMAIL PROTECTED] wrote: Of course, the best solution is to buy a GPS or DCF radio receiver and set up a startum-1 yourself. One of our customers has 6 GPS-locked NTP servers. Only problem is that two of them are reporting a time that is exactly one

Re: clock problem

2007-05-11 Thread Matthew Dillon
:One of our customers has 6 GPS-locked NTP servers. Only problem is :that two of them are reporting a time that is exactly one second :different to the other four. You shouldn't rely solely on your :GPS or DCF receiver - use it as the primary source but have some :secondary sources for sanity

Re: clock problem

2007-05-11 Thread Matthew Dillon
Another idea to help track down timebase problems. Port dntpd to FreeBSD. You need like three sysctls (because the ntp API and the original sysctl API are both insufficient). Alternatively you could probably hack dntpd to run in debug mode without having to implement any new

Re: clock problem

2007-05-10 Thread M. Warner Losh
In message: [EMAIL PROTECTED] Martin Dieringer [EMAIL PROTECTED] writes: : well now it works without restrict: : # ntpq -p : remote refid st t when poll reach delay offset jitter : == :

Re: clock problem

2007-05-10 Thread M. Warner Losh
In message: [EMAIL PROTECTED] Peter Jeremy [EMAIL PROTECTED] writes: : There seems to be a bug in ntpd where the PLL can saturate at : +/-500ppm and will not recover. This problem seems too occur mostly : where the reference servers have lots of jitter (ie a fairly congested : link to

Re: clock problem

2007-05-10 Thread M. Warner Losh
In message: [EMAIL PROTECTED] Oliver Fromme [EMAIL PROTECTED] writes: : Martin's Problem with ntpd is not a precision problem. : His problem is that his ntpd does not synchronize at all. : Adding more servers certainly won't solve that problem. There are two causes to not

Re: clock problem

2007-05-09 Thread Oliver Fromme
Jeffrey Goldberg wrote: Oliver Fromme wrote: Martin Dieringer wrote: Oliver Fromme wrote: Are you sure that your /etc/ntp.conf ist correct? # cat /etc/ntp.conf server time.fu-berlin.de iburst maxpoll 9 driftfile /var/db/ntp.drift logfile /var/log/ntpd

Re: clock problem

2007-05-09 Thread Oliver Fromme
Martin Dieringer wrote: # ntpq -p remote refid st t when poll reach delay offset jitter == *time192.53.103.108 2 u 19 64 77 91.454 301.926 860.104 and the clock is

clock problem

2007-05-08 Thread Martin Dieringer
My clock is now _15 minutes_ late, after about 1 day with powerd running. ntpd is running also. Can nobody tell where the problem is here? m. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To

Re: clock problem

2007-05-08 Thread Oliver Fromme
Martin Dieringer wrote: My clock is now _15 minutes_ late, after about 1 day with powerd running. ntpd is running also. Can nobody tell where the problem is here? Are you sure that your /etc/ntp.conf ist correct? Are there any messages from ntpd in /var/log/messages? What's the output

Re: clock problem

2007-05-08 Thread Javier Henderson
On Tue, 8 May 2007 14:03:58 +0200 (CEST), Martin Dieringer wrote: My clock is now _15 minutes_ late, after about 1 day with powerd running. ntpd is running also. Can nobody tell where the problem is here? You say that ntpd is running, but what does the output of 'ntpq -p' show? Is

Re: clock problem

2007-05-08 Thread Martin Dieringer
On Tue, 8 May 2007, Oliver Fromme wrote: Martin Dieringer wrote: My clock is now _15 minutes_ late, after about 1 day with powerd running. ntpd is running also. Can nobody tell where the problem is here? Are you sure that your /etc/ntp.conf ist correct? # cat /etc/ntp.conf server

Re: clock problem

2007-05-08 Thread Javier Henderson
On Tue, 8 May 2007 15:33:51 +0200 (CEST), Martin Dieringer wrote: On Tue, 8 May 2007, Oliver Fromme wrote: Martin Dieringer wrote: My clock is now _15 minutes_ late, after about 1 day with powerd running. ntpd is running also. Can nobody tell where the problem is here? Are you sure that

Re: clock problem

2007-05-08 Thread Oliver Fromme
Martin Dieringer wrote: Oliver Fromme wrote: Are you sure that your /etc/ntp.conf ist correct? # cat /etc/ntp.conf server time.fu-berlin.de iburst maxpoll 9 driftfile /var/db/ntp.drift logfile /var/log/ntpd You must add restrict lines for every server and for localhost, like

Re: clock problem

2007-05-08 Thread Jeffrey Goldberg
On May 8, 2007, at 8:33 AM, Martin Dieringer wrote: On Tue, 8 May 2007, Oliver Fromme wrote: Martin Dieringer wrote: My clock is now _15 minutes_ late, after about 1 day with powerd running. ntpd is running also. Can nobody tell where the problem is here? Are you sure that your

Re: clock problem

2007-05-08 Thread Martin Dieringer
On Tue, 8 May 2007, Oliver Fromme wrote: Martin Dieringer wrote: Oliver Fromme wrote: Are you sure that your /etc/ntp.conf ist correct? # cat /etc/ntp.conf server time.fu-berlin.de iburst maxpoll 9 driftfile /var/db/ntp.drift logfile /var/log/ntpd You must add restrict lines for every

Re: clock problem

2007-05-08 Thread Martin Dieringer
On Tue, 8 May 2007, Jeffrey Goldberg wrote: On May 8, 2007, at 8:33 AM, Martin Dieringer wrote: On Tue, 8 May 2007, Oliver Fromme wrote: Martin Dieringer wrote: My clock is now _15 minutes_ late, after about 1 day with powerd running. ntpd is running also. Can nobody tell where the problem

Re: clock problem

2007-05-08 Thread Martin Dieringer
On Tue, 8 May 2007, Richard Coleman wrote: Martin Dieringer wrote: What's the output from ntpq -p? # ntpq -p No association ID's returned # Are you using pf? sorry for the short answer: no m. ___ freebsd-stable@freebsd.org mailing list

Re: clock problem

2007-05-08 Thread Richard Coleman
Martin Dieringer wrote: What's the output from ntpq -p? # ntpq -p No association ID's returned # Are you using pf? I think there is some kind of boot time race condition between pf and ntpd. On my firewall (uses FreeBSD 6.2 with pf), I always have to restart ntpd after boot, otherwise it

Re: clock problem

2007-05-08 Thread Nicolas Rachinsky
* Oliver Fromme [EMAIL PROTECTED] [2007-05-08 16:29 +0200]: How are you redialling? If you get a new dynamic IP address, it might be necessary to restart ntpd. For example, if you use ppp(8) for dial-up, you can write a linkup script that performs the restart. I use the attached patch.

Re: clock problem

2007-05-08 Thread Jeffrey Goldberg
On May 8, 2007, at 9:29 AM, Oliver Fromme wrote: Martin Dieringer wrote: Oliver Fromme wrote: Are you sure that your /etc/ntp.conf ist correct? # cat /etc/ntp.conf server time.fu-berlin.de iburst maxpoll 9 driftfile /var/db/ntp.drift logfile /var/log/ntpd You must add restrict lines for

Re: clock problem

2007-05-08 Thread Peter Jeremy
On 2007-May-08 15:33:51 +0200, Martin Dieringer [EMAIL PROTECTED] wrote: # cat /var/db/ntp.drift 500.000 # There seems to be a bug in ntpd where the PLL can saturate at +/-500ppm and will not recover. This problem seems too occur mostly where the reference servers have lots of jitter (ie a