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
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
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
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
:
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
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
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
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
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.
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
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
: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
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
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
: ==
:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
* 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.
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
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
32 matches
Mail list logo