Re: NTP issues with 5.4 (SOLVED) (fwd)
On Sat, 21 May 2005, Christian Hiris wrote: On Saturday 21 May 2005 15:56:15, Darrel wrote: On Fri, 20 May 2005, Christian Hiris wrote: On Friday 20 May 2005 01:01:01, Darrel wrote: [...] Thanks, Christian! I am comparing to a NetBSD computer with older hardware, that seems to always have PLL enabled: May 14 18:26:10 ntpd[343]: ntpd 4.2.0-r Wed Mar 23 08:12:50 UTC 2005 (1) May 14 18:26:11 ntpd[343]: precision = 2.000 usec May 14 18:26:11 ntpd[343]: kernel time sync status 0040 May 14 18:26:12 ntpd[343]: frequency initialized 74.725 PPM from /var/db/ntp.drift May 14 18:29:29 ntpd[343]: time reset -1.128987 s May 14 18:29:29 ntpd[343]: kernel time sync disabled 0041 May 14 18:35:49 ntpd[343]: kernel time sync enabled 0001 Probably the 4 indicates that the clock had drifted too far for the program to permit syncing to- perhaps the battery should be replaced. No, that's ok. The synchronization takes some minutes. The '1' indicates that PLL updates enabled, but it doesn't tell you much about the actual PLL/FFL mode. About weak batteries - I run ntpd on a i386 machine that had no battery inserted w/o any problems. I am still not sure why we do not see the new NTP4 mode shift to FLL, as with the FreeBSD computer. Maybe the /var/log/messages are just implemented differently on NetBSD 2.02. I will watch it occasionally with 'ntpdc -c kerninfo | grep status'. This NetBSD clock is also set to UTC and it seems that I recall that UTC can be improperly implemented when the computer previously had Microsoft Windows installed. The answer to your question is quite simple. The status bit STA_MODE hasn't been implemented in netBSD. I run a diff on FreeBSD's and netBSD's timex.h to point out the status bits differences: $ diff -u timex.h-freebsd timex.h-netbsd | grep STA_ - * format in use is determined by the STA_NANO bit of the status - * STA_NANO bit in the status word. See the description below for - * STA_FLL bit in the status word. #define STA_PLL0x0001 /* enable PLL updates (rw) */ #define STA_PPSFREQ0x0002 /* enable PPS freq discipline (rw) */ #define STA_PPSTIME0x0004 /* enable PPS time discipline (rw) */ -#define STA_FLL0x0008 /* enable FLL mode (rw) */ +#define STA_FLL0x0008 /* select frequency-lock mode (rw) */ #define STA_INS0x0010 /* insert leap (rw) */ #define STA_DEL0x0020 /* delete leap (rw) */ #define STA_UNSYNC 0x0040 /* clock unsynchronized (rw) */ #define STA_FREQHOLD 0x0080 /* hold frequency (rw) */ #define STA_PPSSIGNAL 0x0100 /* PPS signal present (ro) */ #define STA_PPSJITTER 0x0200 /* PPS signal jitter exceeded (ro) */ #define STA_PPSWANDER 0x0400 /* PPS signal wander exceeded (ro) */ #define STA_PPSERROR 0x0800 /* PPS signal calibration error (ro) */ #define STA_CLOCKERR 0x1000 /* clock hardware fault (ro) */ -#define STA_NANO 0x2000 /* resolution (0 = us, 1 = ns) (ro) */ -#define STA_MODE 0x4000 /* mode (0 = PLL, 1 = FLL) (ro) */ -#define STA_CLK0x8000 /* clock source (0 = A, 1 = B) (ro) */ #define STA_RONLY (STA_PPSSIGNAL | STA_PPSJITTER | STA_PPSWANDER | \ -STA_PPSERROR | STA_CLOCKERR | STA_NANO | STA_MODE | STA_CLK) +STA_PPSERROR | STA_CLOCKERR) /* read-only bits */ - * Note: The time member is in microseconds if STA_NANO is zero and - * STA_NANO is zero and nanoseconds if not. The complete sources are available via cvsweb: http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/sys/sys/timex.h http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/dist/ntp/kernel/sys/timex.h Cheers, ch -- Christian Hiris <[EMAIL PROTECTED]> | OpenPGP KeyID 0x3BCA53BE OpenPGP-Key at hkp://wwwkeys.eu.pgp.net and http://pgp.mit.edu Thanks, Christian! And the FreeBSD computer has resolution to nanoseconds. Also, I upgraded the netBSD to 2.02_STABLE and compiled the kernel with RTC_OFFSET=0. Cheers, Darrel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NTP issues with 5.4 (SOLVED) (fwd)
On Saturday 21 May 2005 15:56:15, Darrel wrote: > On Fri, 20 May 2005, Christian Hiris wrote: > > On Friday 20 May 2005 01:01:01, Darrel wrote: [...] > Thanks, Christian! > > I am comparing to a NetBSD computer with older hardware, that seems to > always have PLL enabled: > > May 14 18:26:10 ntpd[343]: ntpd 4.2.0-r Wed Mar 23 08:12:50 UTC > 2005 (1) > May 14 18:26:11 ntpd[343]: precision = 2.000 usec > May 14 18:26:11 ntpd[343]: kernel time sync status 0040 > May 14 18:26:12 ntpd[343]: frequency initialized 74.725 PPM > from /var/db/ntp.drift > May 14 18:29:29 ntpd[343]: time reset -1.128987 s > May 14 18:29:29 ntpd[343]: kernel time sync disabled 0041 > May 14 18:35:49 ntpd[343]: kernel time sync enabled 0001 > > Probably the 4 indicates that the clock had drifted too far for the > program to permit syncing to- perhaps the battery should be replaced. No, that's ok. The synchronization takes some minutes. The '1' indicates that PLL updates enabled, but it doesn't tell you much about the actual PLL/FFL mode. About weak batteries - I run ntpd on a i386 machine that had no battery inserted w/o any problems. > I > am still not sure why we do not see the new NTP4 mode shift to FLL, as > with the FreeBSD computer. > > Maybe the /var/log/messages are just implemented differently on NetBSD > 2.02. I will watch it occasionally with 'ntpdc -c kerninfo | grep > status'. This NetBSD clock is also set to UTC and it seems that I > recall that UTC can be improperly implemented when the computer > previously had Microsoft Windows installed. The answer to your question is quite simple. The status bit STA_MODE hasn't been implemented in netBSD. I run a diff on FreeBSD's and netBSD's timex.h to point out the status bits differences: $ diff -u timex.h-freebsd timex.h-netbsd | grep STA_ - * format in use is determined by the STA_NANO bit of the status - * STA_NANO bit in the status word. See the description below for - * STA_FLL bit in the status word. #define STA_PLL0x0001 /* enable PLL updates (rw) */ #define STA_PPSFREQ0x0002 /* enable PPS freq discipline (rw) */ #define STA_PPSTIME0x0004 /* enable PPS time discipline (rw) */ -#define STA_FLL0x0008 /* enable FLL mode (rw) */ +#define STA_FLL0x0008 /* select frequency-lock mode (rw) */ #define STA_INS0x0010 /* insert leap (rw) */ #define STA_DEL0x0020 /* delete leap (rw) */ #define STA_UNSYNC 0x0040 /* clock unsynchronized (rw) */ #define STA_FREQHOLD 0x0080 /* hold frequency (rw) */ #define STA_PPSSIGNAL 0x0100 /* PPS signal present (ro) */ #define STA_PPSJITTER 0x0200 /* PPS signal jitter exceeded (ro) */ #define STA_PPSWANDER 0x0400 /* PPS signal wander exceeded (ro) */ #define STA_PPSERROR 0x0800 /* PPS signal calibration error (ro) */ #define STA_CLOCKERR 0x1000 /* clock hardware fault (ro) */ -#define STA_NANO 0x2000 /* resolution (0 = us, 1 = ns) (ro) */ -#define STA_MODE 0x4000 /* mode (0 = PLL, 1 = FLL) (ro) */ -#define STA_CLK0x8000 /* clock source (0 = A, 1 = B) (ro) */ #define STA_RONLY (STA_PPSSIGNAL | STA_PPSJITTER | STA_PPSWANDER | \ -STA_PPSERROR | STA_CLOCKERR | STA_NANO | STA_MODE | STA_CLK) +STA_PPSERROR | STA_CLOCKERR) /* read-only bits */ - * Note: The time member is in microseconds if STA_NANO is zero and - * STA_NANO is zero and nanoseconds if not. The complete sources are available via cvsweb: http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/sys/sys/timex.h http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/dist/ntp/kernel/sys/timex.h Cheers, ch -- Christian Hiris <[EMAIL PROTECTED]> | OpenPGP KeyID 0x3BCA53BE OpenPGP-Key at hkp://wwwkeys.eu.pgp.net and http://pgp.mit.edu pgpODeW512gM1.pgp Description: PGP signature
Re: NTP issues with 5.4 (SOLVED) (fwd)
On Fri, 20 May 2005, Christian Hiris wrote: On Friday 20 May 2005 01:01:01, Darrel wrote: I installed openntpd considering that it should run with reduced privileges. The Workgroup did not sync up right away and I reinstalled NTP4. Currently, I can sync Window XP and Windows 98. My /var/log/messages: May 19 12:25:37 ntpd[379]: kernel time sync enabled 6001 May 19 12:42:40 ntpd[379]: kernel time sync enabled 2001 May 19 14:59:14 ntpd[379]: kernel time sync enabled 6001 May 19 15:16:19 ntpd[379]: kernel time sync enabled 2001 May 19 18:24:09 ntpd[379]: kernel time sync enabled 6001 May 19 18:41:14 ntpd[379]: kernel time sync enabled 2001 I am not sure, but this could be normal phase-lock-loop of the kernel. I think this is normal, the above status codes are in hex. Bit 0 of the 1st byte tells about clock source (0=A 1=B), bit 1 of 1st byte stands for mode status (0=PLL 1=FLL), bit 2 of 1st byte represents resolution status (0=us 1=ns) and bit 7 of the 2nd byte indicates that PLL updates are enabled. status 0x2001 = source A, mode PLL, resolution ns, PLL updates enabled status 0x6001 = source A, mode FLL, resolution ns, PLL updates enabled The command 'ntpdc -c kerninfo | grep status' displays some of this status information in human-readable format. You can find a document that describes the Adaptive Hybrid Clock Discipline Algorithm at http://www.eecis.udel.edu/~mills/database/papers/allan.pdf Cheers, ch -- Christian Hiris <[EMAIL PROTECTED]> | OpenPGP KeyID 0x3BCA53BE OpenPGP-Key at hkp://wwwkeys.eu.pgp.net and http://pgp.mit.edu Thanks, Christian! I am comparing to a NetBSD computer with older hardware, that seems to always have PLL enabled: May 14 18:26:10 ntpd[343]: ntpd 4.2.0-r Wed Mar 23 08:12:50 UTC 2005 (1) May 14 18:26:11 ntpd[343]: precision = 2.000 usec May 14 18:26:11 ntpd[343]: kernel time sync status 0040 May 14 18:26:12 ntpd[343]: frequency initialized 74.725 PPM from /var/db/ntp.drift May 14 18:29:29 ntpd[343]: time reset -1.128987 s May 14 18:29:29 ntpd[343]: kernel time sync disabled 0041 May 14 18:35:49 ntpd[343]: kernel time sync enabled 0001 Probably the 4 indicates that the clock had drifted too far for the program to permit syncing to- perhaps the battery should be replaced. I am still not sure why we do not see the new NTP4 mode shift to FLL, as with the FreeBSD computer. Maybe the /var/log/messages are just implemented differently on NetBSD 2.02. I will watch it occasionally with 'ntpdc -c kerninfo | grep status'. This NetBSD clock is also set to UTC and it seems that I recall that UTC can be improperly implemented when the computer previously had Microsoft Windows installed. Cheers, Darrel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NTP issues with 5.4 (SOLVED) (fwd)
On Friday 20 May 2005 01:01:01, Darrel wrote: > I installed openntpd considering that it should run with reduced > privileges. The Workgroup did not sync up right away and I reinstalled > NTP4. > > Currently, I can sync Window XP and Windows 98. My /var/log/messages: > > May 19 12:25:37 ntpd[379]: kernel time sync enabled 6001 > May 19 12:42:40 ntpd[379]: kernel time sync enabled 2001 > May 19 14:59:14 ntpd[379]: kernel time sync enabled 6001 > May 19 15:16:19 ntpd[379]: kernel time sync enabled 2001 > May 19 18:24:09 ntpd[379]: kernel time sync enabled 6001 > May 19 18:41:14 ntpd[379]: kernel time sync enabled 2001 > > I am not sure, but this could be normal phase-lock-loop of the > kernel. I think this is normal, the above status codes are in hex. Bit 0 of the 1st byte tells about clock source (0=A 1=B), bit 1 of 1st byte stands for mode status (0=PLL 1=FLL), bit 2 of 1st byte represents resolution status (0=us 1=ns) and bit 7 of the 2nd byte indicates that PLL updates are enabled. status 0x2001 = source A, mode PLL, resolution ns, PLL updates enabled status 0x6001 = source A, mode FLL, resolution ns, PLL updates enabled The command 'ntpdc -c kerninfo | grep status' displays some of this status information in human-readable format. You can find a document that describes the Adaptive Hybrid Clock Discipline Algorithm at http://www.eecis.udel.edu/~mills/database/papers/allan.pdf Cheers, ch -- Christian Hiris <[EMAIL PROTECTED]> | OpenPGP KeyID 0x3BCA53BE OpenPGP-Key at hkp://wwwkeys.eu.pgp.net and http://pgp.mit.edu pgpL7BNSORxZr.pgp Description: PGP signature
Re: NTP issues with 5.4 (SOLVED) (fwd)
I wrote: Hello, I run ntpd in daemon mode on several FreeBSD computers and synchronize with 'ntpd -q' all others. I've just updated one machine to 5.4 (from 5.3) and noticed the daemon was unhappy, often logging 'time reset' and resynchronizing with peers. On other machines I also only recently (after the upgrade to 5.4) see ntp problems - 'ntpd -q' gets stuck and time goes off. The machines were all fine before. I searched the web and archives and found some more people complaining about similar issues but I haven't found any good answer. At first I thought it was happening only on SMP computers but it isn't the case. The machines have all kinds of timecounters - ACPI-fast, ACPI-safe and i8254. I'd like to let you all know that I don't think the problem is as widespread as I originally thought. After tens of restarts of ntpd processes I've never experienced any problem synchronizing. No more hung 'ntpd -q' processes either. I suspect the latter was a consequence of my server having problems synchronizing. Michal - I installed openntpd considering that it should run with reduced privileges. The Workgroup did not sync up right away and I reinstalled NTP4. Currently, I can sync Window XP and Windows 98. My /var/log/messages: May 19 12:25:37 ntpd[379]: kernel time sync enabled 6001 May 19 12:42:40 ntpd[379]: kernel time sync enabled 2001 May 19 14:59:14 ntpd[379]: kernel time sync enabled 6001 May 19 15:16:19 ntpd[379]: kernel time sync enabled 2001 May 19 18:24:09 ntpd[379]: kernel time sync enabled 6001 May 19 18:41:14 ntpd[379]: kernel time sync enabled 2001 I am not sure, but this could be normal phase-lock-loop of the kernel. Darrel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
