From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 06 Apr 1998 11:11:05 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: kernel pll status change 1? [-/+]
X-Keywords: FLL [-/+] jitter [-/+]
In article <3525260a.14227720@news.earthlink.net> rowl@earthlink.net (Michael St. Laurent) writes:
> I've seen two different lines in the xntpd log files that I don't
> understand. They are:
>
> 31 Mar 09:29:15 xntpd[20991]: kernel pll status change 89
Kernel is doing FREQHOLD and FLL at the same time. This indicates that
the kernel clock is not stable at the moment.
> 31 Mar 10:03:23 xntpd[20991]: kernel pll status change 1
Never seen before. I guess you just had a huge jitter, or your maximum
error is really huge.
>
> Can anyone explain what these mean? This is from a Linux system
> (kernel 2.0.33).
(I had posted a longer explanation in the past)
Ulrich
From: per@erix.ericsson.se (Per Hedeland) [-/+]
Date: 5 Apr 1998 11:07:14 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: [++] Re: NTP: Automatic time/date propagation ? [-/+]
In article <3521FED2.45AE941E@hda.hydro.com> Terje Mathisen
<Terje.Mathisen@hda.hydro.com> writes:
>The maximum time step that ntp will correct is a #define in the source
>code, I believe it is 900 secs (15 mins).
>
>Anyway, it should be possible to increase this to whatever you need,
>which would then make it possible to step all systems to the new
>reference time.
Or use the undocumented -g option to xntpd, which disables the limit.
--Per Hedeland
per@erix.ericsson.se
From: Marc Brett <mbrett@rgs0.london.waii.com> [-/+]
Date: 5 Apr 1998 11:17:46 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Timezones (again) [-/+]
X-Keywords: daylight [-/+] DST [-/+] timezone [-/+]
Armando Reis <asr@mail.telepac.pt> wrote:
> Hi y'all
> I've recently installed xntpd on one of my machines, and I'm still not
> very familiar with it.
> My installation was running fine up till last weekend, when we changed
> to daylight savings time. I was curious to see what would happen.
> Well, nothing did.... I saw no change in the time my machine reported.
> I stopped xntpd and set the time myself.
> Later I went back to the docs and tried to figure out what had
> happened. I now know that my problem is probably related to the
> timezone I'm using (GMT)
> Finally the question: Where can I find some info on the influence of
> the TZ on ntp servers? I mean, in my case everything _seemed_ OK,
> until DST came into play. Should I have changed my TZ? In that case
> what should I use? GMT-DST??? and also _WHEN_ should I make that
> change?
> Hoping to hear from someone real soon
> ASR
NTP has nothing to do with timezones. It merely steers the system
clock towards UTC. The operating system is responsible for converting
this time to the local time.
In keeping with the pervasive pattern of American cultural imperialism
in computing technologies, the default switchover dates for daylight
savings time will reflect US laws (02:00 the first Sunday of April and
02:00 the last Sunday in October). Users in most countries will have
to customize the TZ variable (or whatever mechanism their OS uses) to
reflect local conditions.
Check the environment(4) or environ(4) man pages for the TZ syntax
rules. Here in Britain, we use:
TZ=GMT0BST,M3.5.0/1,M10.5.0/2
--
Marc Brett +44 181 560 3160 Western Geophysical
Marc.Brett@waii.com 455 London Road, Isleworth
FAX: +44 181 847 5711 Middlesex TW7 5AB UK
From: per@erix.ericsson.se (Per Hedeland) [-/+]
Date: 5 Apr 1998 11:21:30 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntpd: authentication and restrict secretly coupled?
X-Keywords: restrict [-/+]
In article <ubtumhsu0.fsf@astsun.fujitsu.com.au> Milan Durovic
<ip103@astsun.fujitsu.com.au> writes:
>restrict default notrust nomodify
>restrict timeserver1
>restrict timeserver2
>restrict timeserver3
Unfortunately, "restrict" cannot take a hostname as argument - from the
docs:
restrict numeric_address [ mask numeric_mask ] [ flag ] [ ... ]
The numeric_address argument, expressed in dotted-quad form, is
the address of an host or network. The mask argument, also
expressed in dotted-quad form, defaults to 255.255.255.255,
meaning that the numeric_address is treated as the address of an
individual host. A default entry (address 0.0.0.0, mask 0.0.0.0)
is always included and, given the sort algorithm, is always the
first entry in the list. Note that, while numeric_address is
normally given in dotted-quad format, the text string default,
with no mask option, may be used to indicate the default entry.
I.e. use the IP addresses and you should be fine.
--Per Hedeland
per@erix.ericsson.se
From: Tom.Horsley@worldnet.att.net (Thomas A. Horsley) [-/+]
Date: 03 Apr 1998 17:13:31 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Simple NTP client
X-Keywords: Windows [-/+]
> Is there simple NTP client source code for Linux and/or Windows NT
>anywhere?
My NTPTime program has the source code available and works on NT or 95
(but better on NT :-).
Follow the pointers from my web page (below) to find it.
--
>>==>> The *Best* political site <URL:http://www.vote-smart.org/> >>==+
email: Tom.Horsley@worldnet.att.net icbm: Delray Beach, FL |
<URL:http://home.att.net/~Tom.Horsley> Free Software and Politics <<==+
From: Urs Thuermann <urs@isnogud.escape.de> [-/+]
Date: 05 Apr 1998 23:15:12 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Timezones (again) [-/+]
X-Keywords: daylight [-/+] timezone [-/+]
Marc Brett <mbrett@rgs0.london.waii.com> writes:
> In keeping with the pervasive pattern of American cultural imperialism
> in computing technologies, the default switchover dates for daylight
> savings time will reflect US laws (02:00 the first Sunday of April and
> 02:00 the last Sunday in October). Users in most countries will have
> to customize the TZ variable (or whatever mechanism their OS uses) to
> reflect local conditions.
>
> Check the environment(4) or environ(4) man pages for the TZ syntax
> rules. Here in Britain, we use:
>
> TZ=GMT0BST,M3.5.0/1,M10.5.0/2
That method of converting times to local timezone is broken anyway.
It won't work for years somewhat in the past or future, especially in
Britain where timezone rules seem to change more often than anywhere
else:
# 1954 to 1980, starting rules
Rule GB-Eire 1954 only - Apr 11 2:00s 1:00 BST
Rule GB-Eire 1955 1956 - Apr Sun>=16 2:00s 1:00 BST
Rule GB-Eire 1957 only - Apr 14 2:00s 1:00 BST
Rule GB-Eire 1958 1959 - Apr Sun>=16 2:00s 1:00 BST
Rule GB-Eire 1960 only - Apr 10 2:00s 1:00 BST
Rule GB-Eire 1961 1963 - Mar lastSun 2:00s 1:00 BST
Rule GB-Eire 1964 1967 - Mar Sun>=19 2:00s 1:00 BST
Rule GB-Eire 1968 only - Feb 18 2:00s 1:00 BST
Rule GB-Eire 1972 1980 - Mar Sun>=16 2:00s 1:00 BST
# 1953 to 1980, ending rules
Rule GB-Eire 1953 1960 - Oct Sun>=1 2:00s 0 GMT
Rule GB-Eire 1961 1968 - Oct Sun>=23 2:00s 0 GMT
Rule GB-Eire 1972 1980 - Oct Sun>=23 2:00s 0 GMT
# 1981 on
Rule GB-Eire 1981 1995 - Mar lastSun 1:00u 1:00 BST
Rule GB-Eire 1981 1989 - Oct Sun>=23 1:00u 0 GMT
Rule GB-Eire 1990 1995 - Oct Sun>=22 1:00u 0 GMT
That is, if you have file created before 1990, 'ls' might very well
display a wrong local modification time.
Instead, the timezone code from Arthur David Olson, also found in
newer glibc, will work much better.
There you would set
TZ=Europe/London
and /usr/share/zoneinfo/Europe/London contains all those crazy
timezone rules.
But timezone related discussions probably don't belong in this group,
since NTP doesn't deal with those. Is there group more appropriate
for this?
urs
From: dehxprr9@ibmmail.com [-/+]
Date: Tue, 07 Apr 1998 09:09:41 -0600 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP for Windows NT [-/+]
X-Keywords: DCF77 [-/+] MSF [-/+] Windows [-/+]
In article <3520C6AF.C1F2FF77@hda.hydro.com>,
Terje Mathisen <Terje.Mathisen@hda.hydro.com> wrote:
>
> Alan Reid wrote:
> >
> > Is there a version of NTP available which will support the ARCRON MSF
> > receiver under Windows NT?
>
> The NT port does not support any ref clocks, not because it would be
> impossible (rather the opposite), but most probably because serial port
> interfacing is so dissimilar from Unix, that you would require a major
> rewrite of the relevant interface code.
>
> Do you volunteer to do the porting?
>
> Terje
>
Hi,
PMJI -- I'm living/working in germany. The company I'm working for uses xntp.
In those days (one year ago) when I helped introducing xntp we found
that there exist two german manufacturers building hardware to receive the
german radio-signal DCF77 (the official german time-signal at 77kHz).
Both manufacturers were also working on integrating their DCF77 hardware
into xntp for WinNT. Unfortunatelly I do not know if they also integrated
their GPS-receivers ...
See also:
http://www.hopf-time.com
http://www.meinberg.de
I know this is of interest only to german ntp-users. But I just wanted to
indicate that there are activities on xntp-refclock-drivers for WinNT ...
BTW: As far as I have heard it was planned to make those clock-drivers (for
WinNT)part of the ntp-distribution. I do not know the actual state ...
Bye for now
Obige Aussagen sind meine persoenliche Meinung
Opinions are my own and not necessarily shared by my employer
Roland Fiedler
RFiedler@GeoCities.com
101,144234@germanynet.com
dehxprr9@ibmmail.com (preferred)
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
From: dehxprr9@ibmmail.com [-/+]
Date: Tue, 07 Apr 1998 10:17:47 -0600 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Timezones (again) [-/+]
X-Keywords: daylight [-/+]
Hi Marc,
I'm Roland ... I think we already had some email contact concerning ntp for
OS/2 isn't it?
Here are some annotations to your statements:
In article <6g7p8q$1cqs$1@mail1.wg.waii.com>,
Marc Brett <mbrett@rgs0.london.waii.com> wrote:
> ...
>
> NTP has nothing to do with timezones. It merely steers the system
> clock towards UTC. The operating system is responsible for converting
> this time to the local time.
>
Well you're "d..." right :-) but ...
> In keeping with the pervasive pattern of American cultural imperialism
> in computing technologies, the default switchover dates for daylight
> savings time will reflect US laws (02:00 the first Sunday of April and
> 02:00 the last Sunday in October). Users in most countries will have
> to customize the TZ variable (or whatever mechanism their OS uses) to
> reflect local conditions.
>
> Check the environment(4) or environ(4) man pages for the TZ syntax
> rules. Here in Britain, we use:
>
> TZ=GMT0BST,M3.5.0/1,M10.5.0/2
is UK the center of the World? 7;)
In our company (I'm in the German Headquarter at Frankfurt) I'm using:
TZ=MEZ-1MESZ,M3.5.0,M10.5.0/03:00
(Whatch the time of switching forth and back!)
>
> --
> Marc Brett +44 181 560 3160 Western Geophysical
> Marc.Brett@waii.com 455 London Road, Isleworth
> FAX: +44 181 847 5711 Middlesex TW7 5AB UK
>
Cheers,
Roland
--
Obige Aussagen sind meine persoenliche Meinung
Opinions are my own and not necessarily shared by my employer
--
dehxprr9@ibmmail.com
101,144234@GermanyNet.de
RFiedler@GeoCities.com
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
From: "Alan J. Wylie" <alanw@cyrano.com>
Date: Tue, 07 Apr 1998 11:02:13 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Timezones (again) [-/+]
X-Keywords: DST [-/+]
Armando Reis wrote:
>
> pausch@electra.saaf.se (Paul Schlyter) wrote:
>
> >This British tradition of changing DST rules at a whim is less likely
> >to continue in the future, since Britain and continental Europe recently
> >agreed to use the same DST rules, so that the European Union will go back
> >and forth from DST at the same time.
> >
> Hi, do you know if there's an online source for this agreement?
> I've also heard about it, but I can't seem to find any online docs.
> ASR
try
its is done with Active Server Pages/CGI/some such technology,
so I can't give a URL, but search for the following:
summer time order Statutory Instrument
also
leap second NPL
may be of interest
--
Alan J. Wylie (Cyrano UK Ltd.) | mailto:alanw@cyrano.com
http://www.cyrano.com |
http://www.zen.co.uk/home/page/alan.wylie
From: "M.C. van den Bovenkamp" <bovenkamp@lucent.com>
Date: Tue, 07 Apr 1998 17:05:19 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP for Windows NT [-/+]
X-Keywords: DCF [-/+] dispersion [-/+]
dehxprr9@ibmmail.com wrote:
> I know this is of interest only to german ntp-users.
Well, and countries close by. I'm in the Netherlands, and my 16 DM
Conrad DCF clock module (the 'WT100 Seriell', in case you're interested)
works well enough. A bit inaccurate for a true Stratum 1 NTP server, as
it syncs itself only once an hour to the DCF transmitter, and it gives
no date info. And xntpd does not directly support it, so I had to use
the small program 'dcf77time' I found to control the local clock and
tell xntpd to believe that. Gives a rather high dispersion, but it
works.
As does my DCF77-controlled watch, by the way :-).
Regards,
--
Marco van den Bovenkamp.
CIO EMEA Network Design Engineer,
Lucent Technologies Nederland.
Room: HVS BZK 38
Tel.: (+31-35-687)2724
Mail: bovenkamp@lucent.com
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 08 Apr 1998 06:54:57 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP for Windows NT [-/+]
X-Keywords: DCF [-/+] DCF77 [-/+]
In article <352A40AF.DC1CFC88@lucent.com> "M.C. van den Bovenkamp" <bovenkamp@lucent.com> writes:
> dehxprr9@ibmmail.com wrote:
>
> > I know this is of interest only to german ntp-users.
>
> Well, and countries close by. I'm in the Netherlands, and my 16 DM
> Conrad DCF clock module (the 'WT100 Seriell', in case you're interested)
> works well enough. A bit inaccurate for a true Stratum 1 NTP server, as
As the topic came up: The recent DCF77 receiver modules from "Conrad
Electronic" seem to be less suitable than the old ones. The new ones
have a serial output and an internal clock chip, while the old type
has just a DCF77-bit output (DCFRAW). Unfortunately the new module
needs an external clock for serial timing, and you never know when or
whether the time was received.
For NTP purposes, please do not put up a stratum-1 server with these
modules! (It seems to be impossible to get the raw DCF77 timing out
from the module)
Ulrich
From: dalton@cup.hp.deletethis.com (David Dalton) [-/+]
Date: 7 Apr 1998 20:11:51 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntp on non-symmetric lines
X-Keywords: ATOM [-/+] configuration [-/+] delay [-/+] dispersion [-/+] Garmin [-/+] nanosecond NMEA [-/+] poll [-/+] PPS [-/+] precision [-/+] prefer [-/+] WWVB [-/+]
Ole Streicher (ole@hpbai1.ifh.de) wrote:
remote refid st t when poll reach delay offset disp
==============================================================================
xGPS_NMEA(0) .GPS. 0 l 5 16 377 0.00 853.702 91.63
LOCAL(1) LOCAL(1) 10 l 37 64 377 0.00 0.000 10.01
+faui46a.informa .GPS. 1 u 15 64 377 588.59 58.455 0.82
*maelaren.cs.tu- .GPS. 1 u 45 64 277 588.36 58.597 6.06
+unios.rz.Uni-Os otc1.psu.edu 2 u 60 64 337 590.03 54.370 6.45
:>My questions are now:
:>- how can I avoid the switctch to the internet servers if the local
:> GPS works? ("prefer" did not help)
It appears that "prefer" did not help because your GPS clock is
"designated falseticker". Getting to the bottom of this will likely solve
all of your problems.
It looks to me as though you have run into a common problem with low-cost
GPS clocks (lots of the NMEA clocks have this): terrible dispersion. I
think this is why it is designated falseticker when there are network
sources available with much lower dispersion. Any GPS clock worth its salt
will have dispersion in the sub-ten millisecond range, and yours is ninety!
OTOH it could simply be the difference in offsets that causes your GPS clock
to lose. NTP sees three stratum-1 sources with offset around 50 milliseconds,
and your clock with offset above 800. The lone outlier loses. This is of
course due to the large and assymetric delay to the stratum-1 sources.
Is there any way you can use the Pulse-Per-Second signal from your GPS clock?
That would completely solve your problem. Configure the ATOM driver for this.
This would get the dispersion into the microsecond range.
If it makes you feel any better, I have a home-built GPS based on Garmin
GPS-20 and TAPR TAC-2 that has dispersion swings up to 200 milliseconds all
the time. The only thing it is good for is an isolated location with no other
timeservers available. But it was cheap. It would be great if I could
use the PPS signal.
You also mention that your GPS clock fails frequently. The obvious solution
is to get one that doesn't fail. You get what you pay for.
:>- Is there a possibility to add a certain non-symmetric delay (which
:> can be measured) to the configuration?
No. Most people have no ability to measure the difference between outbound
and inbound delays, so NTP has no provision for this. Are you actually able
to measure this difference? I believe that you can measure the total
delay, but measuring the difference is hard. It usually requires that you
have another communication channel for the measurement that is both very high
speed and very low latency. Hard to do in real-time. Are you familiar with
the way pulsars are observed at widely separated locations? The astronomers
can get nanosecond precision, but only when the data is correlated months
afterwards. It's too hard to do it in real-time.
NTP does quite well when the delays are reasonably symmetrical.
--
-> My $.02 only Not an official statement from HP {They make me say that}
--
As far as we know, our computer has never had an undetected error.
---------------------------------------------------------------------------
David Dalton dalton@cup.hp.deletethis.com 408/447-3016
remote refid st t when poll reach delay offset disp
==============================================================================
*WWVB_SPEC(1) .WWVB. 0 l 76 64 377 0.00 0.309 13.79
+GPS_HP(1) .GPS. 0 l 10 64 377 0.00 0.669 4.33
cosl4.cup.hp.co listo.hp.com 2 u 432 1024 377 5.95 -3.353 0.92
cupertino.cns.h listo.hp.com 2 u 428 1024 177 249.66 -40.517 37.69
From: dalton@cup.hp.deletethis.com (David Dalton) [-/+]
Date: 7 Apr 1998 20:54:14 GMT [-/+]
Newsgroups: comp.protocols.time.ntp,comp.sys.hp.hpux
Subject: NTP Primer Available [-/+]
X-Keywords: configuration [-/+] HP-UX [-/+]
My primer for NTP on HP-UX is now available to the public:
ftp://contrib:9unsupp8@hprc.external.hp.com/sysadmin/ntp.9x/
Along with "ntp_primer.txt" and "ntp.conf.example" you will find
executables for NTP on HP-UX 9.x systems.
The text is oriented towards HP-UX right now because that is what I am most
familiar with, but much of the configuration and troubleshooting advice is
quite general and applies to any NTP setup. All comments and feedback are
welcome, I am hoping to turn it into a whole book in the not-too-distant
future.
This will also be presented as a paper at the InterWorks conferences, along
with lab exercises and Q&A:
April 26 Santa Clara CA
Aug 6? San Diego CA
--
-> My $.02 only Not an official statement from HP {They make me say that}
--
As far as we know, our computer has never had an undetected error.
---------------------------------------------------------------------------
David Dalton dalton@cup.hp.deletethis.com 408/447-3016
From: Casper.Dik@Holland.Sun.Com (Casper H.S. Dik - Network Security Engineer) [-/+]
Date: 10 Apr 1998 12:46:49 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntp on Solaris 2.6: FINALLY [-/+]
[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]
Brad Giaccio <bgiaccio@psrw.com> writes:
>Forgive me for sounding foolish, but unless I am misunderstanding the
>problem I don't quite see what the big deal is. It seems that most people
>who have run into a problem with solaris 2.6 are alos running 2.5, well if
>the problem is as you said below, then wouldn't using a binary from 2.5
>work just as well. We run a network of 2.5 2.51 and 2.6 all using one
>binary for xntp, and in the last six months I have not noticed any
>problems with the time sync on any of them.
If you configure and compile the binary on 2.5, the new system calls added
to 2.6 won't be found (obviously) and the old, standard, code will be
used.
So, yes, a 2.5 configrued binary will most likely work just as well.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
From: per@erix.ericsson.se (Per Hedeland) [-/+]
Date: 12 Apr 1998 01:17:09 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntp on Solaris 2.6: FINALLY [-/+]
X-Keywords: KERNEL_PLL [-/+]
In article <6glbm2$b64$1@ncar.ucar.edu> woods@ncar.ucar.edu (Greg Woods)
writes:
>In article <Pine.SOL.3.96.980410072552.7377A-100000@finnegan>,
>Brad Giaccio <bgiaccio@psrw.com> wrote:
>>wouldn't using a binary from 2.5
>>work just as well.
>
>Just FYI, I'm not a complete bonehead. This is the *first* thing I tried.
>It didn't work. Same symptoms: very large offsets. Identical binary
>that worked fine on 2.5.1.
I don't think anyone suggested that you're a bonehead:-), but xntp on
2.6 can be rather confusing... - was a 2.5.1 binary the *absolutely*
first thing you tried, or did you try a 2.6 binary before that? Because
if you did, you have to reboot before you can get the system to run
sanely with *any* binary. In any case, my 2.5.1-compiled (default
configure) 3-5.91 runs perfectly when started on a freshly booted 2.6
system.
>Given the nature of what the problem is (that the kernel support for
>the ntp_* calls is incompatible with XNTP), we shouldn't be surprised
>that this didn't work. The configure script enables this stuff by
>default under 2.5.1 as well.
No, as those system calls don't exist on 2.5.1, configure won't enable
the deadly KERNEL_PLL.
>There are a number of binaries from 2.5.1 that don't work on 2.6.
Certainly, and of course using a 2.5.1-compiled xntpd isn't a viable
long-term solution even if it works - sooner or later you have a new
xntp version that you want to compile and no pre-2.6 system to do it
on...
Perhaps more interesting: Has anyone figured out exactly *what* the
incompatibility is - i.e. is it xntp or Solaris that is broken? And if
(as I'd suspect:-) the latter, what about 2.7, I gather there are quite
a few people beta-testing it - is this fixed there?
--Per Hedeland
per@erix.ericsson.se
From: ajs@nospam.cs.nott.ac.uk (Al Smith)
Date: 8 Apr 1998 11:38:17 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Timezones (again) [-/+]
X-Keywords: timezone [-/+]
Urs Thuermann (urs@isnogud.escape.de) wrote:
: Instead, the timezone code from Arthur David Olson, also found in
: newer glibc, will work much better.
:
: There you would set
:
: TZ=Europe/London
IRIX has [undocumented] support for this, too. put the zone files in
/usr/lib/locale/TZ and set TZ=:Europe/London in /etc/TIMEZONE. i've used
this in 5.3 and 6.[23] - it probably works in 6.4, too, and the only thing
i found that doesn't like it is java. it's far easier than having to
calculate the day-number of each change.
From: woods@ncar.ucar.edu (Greg Woods)
Date: 9 Apr 1998 09:29:53 -0600 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: xntp on Solaris 2.6: FINALLY [-/+]
X-Keywords: ACTS [-/+] AIX [-/+] Arbiter [-/+] ATOM [-/+] authentication [-/+] Bancomm [-/+] broadcast [-/+] Datum [-/+] DCF77 [-/+] DES [-/+] dosynctodr [-/+] HPUX [-/+] IRIG [-/+] KERNEL_PLL [-/+] Meinberg [-/+] MSF [-/+] NMEA [-/+] nsec_per_tick [-/+] PARSE [-/+] PLL [-/+] poll [-/+] PPS [-/+] precision [-/+] sched_setscheduler [-/+] SLEWALWAYS [-/+] Spectracom [-/+] syslog [-/+] Trimble [-/+] TrueTime [-/+] UDP [-/+] USNO [-/+] VAX WWVB [-/+]
Since I've beaten my head against the wall for several weeks now trying
to get xntp to work on Solaris 2.6, and have finally done it, and I see
that people are *still* asking about this, I thought I would share my
experiences. First a quick disclaimer: I am not an expert on the inner
workings of NTP nor on the Solaris kernel. I'm just a system administrator
who wanted to run a decent time server for our organization on a system
that has Solaris 2.6 installed on it. I extend thanks to those who responded
to my earlier query on this subject.
The problem, as I understand it, has to do with the fact that there
are some system calls available under Solaris 2.6, and the configure
script will detect this and use them, but they do not work correctly
with xntp. It is therefore necessary to modify the config.h file
that is produced by the configure script in order to compile XNTP
for Solaris 2.6. The version I successfully used is xntp3-5.92d.
One person told me not to use xntp3-5.92c because his own patch
broke it. I did not verify this, I just took his advice and went
to xntp3-5.92d. I append the config.h file I used. The code was compiled
on a Sparc 5 running Solaris 2.6 using "gcc version 2.8.1".
--Greg
/* config.h. Generated automatically by configure. */
/* Modified for Solaris 2.6 by Greg Woods 4/9/98 */
/* config.h.in. Generated automatically from configure.in by autoheader. */
/* Define if on AIX 3.
System headers sometimes define this.
We just want to avoid a redefinition error message. */
#ifndef _ALL_SOURCE
/* #undef _ALL_SOURCE */
#endif
/* Define if type char is unsigned and you are not using gcc. */
#ifndef __CHAR_UNSIGNED__
/* #undef __CHAR_UNSIGNED__ */
#endif
/* Define to empty if the keyword does not work. */
/* #undef const */
/* Define to `int' if <sys/types.h> doesn't define. */
/* #undef gid_t */
/* Define if on MINIX. */
/* #undef _MINIX */
/* Define if your struct nlist has an n_un member. */
/* #undef NLIST_NAME_UNION */
/* Define if you have <nlist.h>. */
#define NLIST_STRUCT 1
/* Define if the system does not provide POSIX.1 features except
with this defined. */
/* #undef _POSIX_1_SOURCE */
/* Define if you need to in order for stat and other things to work. */
/* #undef _POSIX_SOURCE */
/* Define as the return type of signal handlers (int or void). */
#define RETSIGTYPE void
/* Define if you have the ANSI C header files. */
#define STDC_HEADERS 1
/* Define if you can safely include both <sys/time.h> and <time.h>. */
#define TIME_WITH_SYS_TIME 1
/* Define if your <sys/time.h> declares struct tm. */
/* #undef TM_IN_SYS_TIME */
/* Define to `int' if <sys/types.h> doesn't define. */
/* #undef uid_t */
/* Define if your processor stores words with the most significant
byte first (like Motorola and SPARC, unlike Intel and VAX). */
#define WORDS_BIGENDIAN 1
/* Package */
#define PACKAGE "xntp3"
/* Version */
#define VERSION "5.92d"
/* debugging code */
#define DEBUG 1
/* MD5 authentication */
#define MD5 1
/* DFS authentication (COCOM only) */
#define DES 1
/* reference clock interface */
#define REFCLOCK 1
/* ACTS modem service */
#define ACTS 1
/* Arbiter 1088A/B GPS receiver */
#define ARBITER 1
/* DHD19970505: ARCRON support. */
#define ARCRON_MSF 1
/* Austron 2200A/2201A GPS receiver */
#define AS2201 1
/* PPS interface */
#define ATOM 1
/* Datum/Bancomm bc635/VME interface */
/* #undef BANC */
/* ELV/DCF7000 clock */
/* #undef CLOCK_DCF7000 */
/* HOPF 6021 clock */
/* #undef CLOCK_HOPF6021 */
/* Meinberg clocks */
/* #undef CLOCK_MEINBERG */
/* DCF77 raw time code */
/* #undef CLOCK_RAWDCF */
/* RCC 8000 clock */
/* #undef CLOCK_RCC8000 */
/* Schmid DCF77 clock */
/* #undef CLOCK_SCHMID */
/* Trimble GPS receiver/TAIP protocol */
/* #undef CLOCK_TRIMTAIP */
/* Trimble GPS receiver/TSIP protocol */
/* #undef CLOCK_TRIMTSIP */
/* Diems Computime Radio Clock */
/* #undef CLOCK_COMPUTIME */
/* Datum Programmable Time System */
#define DATUM 1
/* TrueTime GPS receiver/VME interface */
/* #undef GPSVME */
/* Heath GC-1000 WWV/WWVH receiver */
#define HEATH 1
/* HP 58503A GPS receiver */
#define HPGPS 1
/* Sun IRIG audio decoder */
/* #undef IRIG */
/* Leitch CSD 5300 Master Clock System Driver */
#define LEITCH 1
/* local clock reference */
#define LOCAL_CLOCK 1
/* EES M201 MSF receiver */
#define MSFEES 1
/* Magnavox MX4200 GPS receiver */
/* #undef MX4200 */
/* Rockwell Jupiter based GPS receiver */
/* #undef JUPITER */
/* NMEA GPS receiver */
#define NMEA 1
/* PARSE driver interface */
/* #undef PARSE */
/* PARSE kernel PLL PPS support */
#undef PPS_SYNC
/* PCL 720 clock support */
/* #undef PPS720 */
/* PST/Traconex 1020 WWV/WWVH receiver */
#define PST 1
/* PTB modem service */
#define PTBACTS 1
/* clock thru shared memory */
/* #undef SHM_CLOCK */
/* KSI/Odetics TPRO/S GPS receiver/IRIG interface */
/* #undef TPRO */
/* TRAK 8810 GPS receiver */
#define TRAK 1
/* Kinemetrics/TrueTime receivers */
#define TRUETIME 1
/* USNO modem service */
#define USNO 1
/* Spectracom 8170/Netclock/2 WWVB receiver */
#define WWVB 1
/* define if it's OK to declare char *sys_errlist[]; */
#define CHAR_SYS_ERRLIST 1
/* define if it's OK to declare int syscall P((int, struct timeval *, struct timeval *)); */
#define DECL_SYSCALL 1
/* define if we have syscall is buggy (Solaris 2.4) */
/* #undef SYSCALL_BUG */
/* Do we need extra room for SO_RCVBUF? (HPUX <8) */
/* #undef NEED_RCVBUF_SLOP */
/* Should we open the broadcast socket? */
#define OPEN_BCAST_SOCKET 1
/* Do we want the HPUX FindConfig()? */
/* #undef NEED_HPUX_FINDCONFIG */
/* canonical system (cpu-vendor-os) string */
#define STR_SYSTEM "sparc-sun-solaris2.6"
/* define if [gs]ettimeofday() only takes 1 argument */
/* #undef SYSV_TIMEOFDAY */
/* define if struct sockaddr has sa_len */
/* #undef HAVE_SA_LEN_IN_STRUCT_SOCKADDR */
/* define if struct clockinfo has hz */
/* #undef HAVE_HZ_IN_STRUCT_CLOCKINFO */
/* define if struct clockinfo has tickadj */
/* #undef HAVE_TICKADJ_IN_STRUCT_CLOCKINFO */
/* define if function prototypes are OK */
#define HAVE_PROTOTYPES 1
/* define if setpgrp takes 0 arguments */
#define HAVE_SETPGRP_0 1
/* hardwire a value for tick? */
#define PRESET_TICK 1000000L/hz
/* hardwire a value for tickadj? */
#define PRESET_TICKADJ 500/hz
/* is adjtime() accurate? */
#define ADJTIME_IS_ACCURATE 1
/* should we NOT read /dev/kmem? */
/* #undef NOKMEM */
/* use UDP Wildcard Delivery? */
#define UDP_WILDCARD_DELIVERY 1
/* always slew the clock? */
/* #undef SLEWALWAYS */
/* step, then slew the clock? */
/* #undef STEP_SLEW */
/* force ntpdate to step the clock if !defined(STEP_SLEW) ? */
/* #undef FORCE_NTPDATE_STEP */
/* synch TODR hourly? */
/* #undef DOSYNCTODR */
/* do we set process groups with -pid? */
/* #undef UDP_BACKWARDS_SETOWN */
/* must we have a CTTY for fsetown? */
/* #undef USE_FSETOWNCTTY */
/* can we use SIGIO for tcp and udp IO? */
#define HAVE_SIGNALED_IO 1
/* can we use SIGPOLL for UDP? */
#define USE_UDP_SIGPOLL 1
/* can we use SIGPOLL for tty IO? */
#define USE_TTY_SIGPOLL 1
/* do we have the chu_clk line discipline/streams module? */
/* #undef CHUCLK */
/* do we have the ppsclock streams module? */
/* #undef PPS */
/* do we have the tty_clk line discipline/streams module? */
/* #undef TTYCLK */
/* does the kernel support precision time discipline? */
#undef KERNEL_PLL
/* does the kernel support multicasting IP? */
#define MCAST 1
/* do we have ntp_{adj,get}time in libc? */
#define NTP_SYSCALLS_LIBC 1
/* do we have ntp_{adj,get}time in the kernel? */
#undef NTP_SYSCALLS_STD
/* do we have STREAMS/TLI? (Can we replace this with HAVE_SYS_STROPTS_H? */
/* #undef STREAMS_TLI */
/* do we need an s_char typedef? */
#define NEED_S_CHAR_TYPEDEF 1
/* include the GDT Surveying code? */
/* #undef GDT_SURVEYING */
/* does SIOCGIFCONF return size in the buffer? */
/* #undef SIZE_RETURNED_IN_BUFFER */
/* what is the name of TICK in the kernel? */
#define K_TICK_NAME "nsec_per_tick"
/* Is K_TICK_NAME (nsec_per_tick, for example) in nanoseconds? */
#define TICK_NANO 1
/* what is the name of TICKADJ in the kernel? */
/* #undef K_TICKADJ_NAME */
/* Is K_TICKADJ_NAME (hrestime_adj, for example) in nanoseconds? */
#define TICKADJ_NANO 1
/* what is (probably) the name of DOSYNCTODR in the kernel? */
#define K_DOSYNCTODR_NAME "dosynctodr"
/* what is (probably) the name of NOPRINTF in the kernel? */
#define K_NOPRINTF_NAME "noprintf"
/* do we need HPUX adjtime() library support? */
/* #undef NEED_HPUX_ADJTIME */
/* Might nlist() values require an extra level of indirection (AIX)? */
/* #undef NLIST_EXTRA_INDIRECTION */
/* Should we recommend a minimum value for tickadj? */
/* #undef MIN_REC_TICKADJ */
/* Is there a problem using PARENB and IGNPAR (IRIX)? */
/* #undef NO_PARENB_IGNPAR */
/* Should we not IGNPAR (Linux)? */
/* #undef RAWDCF_NO_IGNPAR */
/* Does DTR power the DCF77 (Linux)? */
/* #undef RAWDCF_SETDTR */
/* Does the compiler like "volatile"? */
/* #undef volatile */
/* Does qsort expect to work on "void *" stuff? */
#define QSORT_USES_VOID_P 1
/* What is the fallback value for HZ? */
#define DEFAULT_HZ 100
/* Do we need to override the system's idea of HZ? */
/* #undef OVERRIDE_HZ */
/* Do we want the SCO3 tickadj hacks? */
/* #undef SCO3_TICKADJ */
/* Do we want the SCO5 tickadj hacks? */
/* #undef SCO5_TICKADJ */
/* adjtime()? */
/* #undef DECL_ADJTIME_0 */
/* bcopy()? */
/* #undef DECL_BCOPY_0 */
/* bzero()? */
/* #undef DECL_BZERO_0 */
/* ioctl()? */
/* #undef DECL_IOCTL_0 */
/* IPC? (bind, connect, recvfrom, sendto, setsockopt, socket) */
/* #undef DECL_IPC_0 */
/* memmove()? */
/* #undef DECL_MEMMOVE_0 */
/* mkstemp()? */
#define DECL_MKSTEMP_0 1
/* mktemp()? */
/* #undef DECL_MKTEMP_0 */
/* plock()? */
/* #undef DECL_PLOCK_0 */
/* rename()? */
/* #undef DECL_RENAME_0 */
/* select()? */
/* #undef DECL_SELECT_0 */
/* setitimer()? */
/* #undef DECL_SETITIMER_0 */
/* setpriority()? */
/* #undef DECL_SETPRIORITY_0 */
#define DECL_SETPRIORITY_1 1
/* sigvec()? */
/* #undef DECL_SIGVEC_0 */
/* stdio stuff? */
/* #undef DECL_STDIO_0 */
/* strtol()? */
/* #undef DECL_STRTOL_0 */
/* syslog() stuff? */
/* #undef DECL_SYSLOG_0 */
/* time()? */
/* #undef DECL_TIME_0 */
/* [gs]ettimeofday()? */
/* #undef DECL_TIMEOFDAY_0 */
/* tolower()? */
/* #undef DECL_TOLOWER_0 */
/* The number of bytes in a int. */
#define SIZEOF_INT 4
/* The number of bytes in a long. */
#define SIZEOF_LONG 4
/* The number of bytes in a signed char. */
#define SIZEOF_SIGNED_CHAR 1
/* Define if you have the K_open function. */
/* #undef HAVE_K_OPEN */
/* Define if you have the __adjtimex function. */
/* #undef HAVE___ADJTIMEX */
/* Define if you have the __ntp_gettime function. */
/* #undef HAVE___NTP_GETTIME */
/* Define if you have the clock_settime function. */
#define HAVE_CLOCK_SETTIME 1
/* Define if you have the daemon function. */
/* #undef HAVE_DAEMON */
/* Define if you have the getbootfile function. */
/* #undef HAVE_GETBOOTFILE */
/* Define if you have the getdtablesize function. */
#define HAVE_GETDTABLESIZE 1
/* Define if you have the getrusage function. */
#define HAVE_GETRUSAGE 1
/* Define if you have the gettimeofday function. */
#define HAVE_GETTIMEOFDAY 1
/* Define if you have the getuid function. */
#define HAVE_GETUID 1
/* Define if you have the kvm_open function. */
#define HAVE_KVM_OPEN 1
/* Define if you have the memcpy function. */
#define HAVE_MEMCPY 1
/* Define if you have the memmove function. */
#define HAVE_MEMMOVE 1
/* Define if you have the memset function. */
#define HAVE_MEMSET 1
/* Define if you have the mkstemp function. */
#define HAVE_MKSTEMP 1
/* Define if you have the mlockall function. */
#define HAVE_MLOCKALL 1
/* Define if you have the nice function. */
#define HAVE_NICE 1
/* Define if you have the nlist function. */
#define HAVE_NLIST 1
/* Define if you have the ntp_adjtime function. */
#undef HAVE_NTP_ADJTIME
/* Define if you have the ntp_gettime function. */
#undef HAVE_NTP_GETTIME
/* Define if you have the plock function. */
#define HAVE_PLOCK 1
/* Define if you have the pututline function. */
#define HAVE_PUTUTLINE 1
/* Define if you have the pututxline function. */
#define HAVE_PUTUTXLINE 1
/* Define if you have the rtprio function. */
/* #undef HAVE_RTPRIO */
/* Define if you have the sched_setscheduler function. */
#define HAVE_SCHED_SETSCHEDULER 1
/* Define if you have the setlinebuf function. */
#define HAVE_SETLINEBUF 1
/* Define if you have the setpgid function. */
#define HAVE_SETPGID 1
/* Define if you have the setpriority function. */
#define HAVE_SETPRIORITY 1
/* Define if you have the setsid function. */
#define HAVE_SETSID 1
/* Define if you have the settimeofday function. */
#define HAVE_SETTIMEOFDAY 1
/* Define if you have the setvbuf function. */
#define HAVE_SETVBUF 1
/* Define if you have the sigaction function. */
#define HAVE_SIGACTION 1
/* Define if you have the sigset function. */
#define HAVE_SIGSET 1
/* Define if you have the sigsuspend function. */
#define HAVE_SIGSUSPEND 1
/* Define if you have the sigvec function. */
/* #undef HAVE_SIGVEC */
/* Define if you have the stime function. */
#define HAVE_STIME 1
/* Define if you have the strchr function. */
#define HAVE_STRCHR 1
/* Define if you have the strerror function. */
/* #undef HAVE_STRERROR */
/* Define if you have the sysconf function. */
#define HAVE_SYSCONF 1
/* Define if you have the sysctl function. */
/* #undef HAVE_SYSCTL */
/* Define if you have the timer_create function. */
#define HAVE_TIMER_CREATE 1
/* Define if you have the timer_settime function. */
#define HAVE_TIMER_SETTIME 1
/* Define if you have the umask function. */
#define HAVE_UMASK 1
/* Define if you have the uname function. */
#define HAVE_UNAME 1
/* Define if you have the updwtmp function. */
#define HAVE_UPDWTMP 1
/* Define if you have the updwtmpx function. */
#define HAVE_UPDWTMPX 1
/* Define if you have the vsprintf function. */
#define HAVE_VSPRINTF 1
/* Define if you have the </sys/sync/queue.h> header file. */
/* #undef HAVE__SYS_SYNC_QUEUE_H */
/* Define if you have the </sys/sync/sema.h> header file. */
/* #undef HAVE__SYS_SYNC_SEMA_H */
/* Define if you have the <errno.h> header file. */
#define HAVE_ERRNO_H 1
/* Define if you have the <fcntl.h> header file. */
#define HAVE_FCNTL_H 1
/* Define if you have the <machine/inline.h> header file. */
/* #undef HAVE_MACHINE_INLINE_H */
/* Define if you have the <memory.h> header file. */
#define HAVE_MEMORY_H 1
/* Define if you have the <net/if.h> header file. */
#define HAVE_NET_IF_H 1
/* Define if you have the <netinet/in.h> header file. */
#define HAVE_NETINET_IN_H 1
/* Define if you have the <netinet/ip.h> header file. */
#define HAVE_NETINET_IP_H 1
/* Define if you have the <poll.h> header file. */
#define HAVE_POLL_H 1
/* Define if you have the <sched.h> header file. */
#define HAVE_SCHED_H 1
/* Define if you have the <sgtty.h> header file. */
#define HAVE_SGTTY_H 1
/* Define if you have the <stdlib.h> header file. */
#define HAVE_STDLIB_H 1
/* Define if you have the <string.h> header file. */
#define HAVE_STRING_H 1
/* Define if you have the <sys/bsd_audioirig.h> header file. */
/* #undef HAVE_SYS_BSD_AUDIOIRIG_H */
/* Define if you have the <sys/chudefs.h> header file. */
/* #undef HAVE_SYS_CHUDEFS_H */
/* Define if you have the <sys/clkdefs.h> header file. */
/* #undef HAVE_SYS_CLKDEFS_H */
/* Define if you have the <sys/file.h> header file. */
#define HAVE_SYS_FILE_H 1
/* Define if you have the <sys/i8253.h> header file. */
/* #undef HAVE_SYS_I8253_H */
/* Define if you have the <sys/ioctl.h> header file. */
#define HAVE_SYS_IOCTL_H 1
/* Define if you have the <sys/lock.h> header file. */
#define HAVE_SYS_LOCK_H 1
/* Define if you have the <sys/mman.h> header file. */
#define HAVE_SYS_MMAN_H 1
/* Define if you have the <sys/modem.h> header file. */
/* #undef HAVE_SYS_MODEM_H */
/* Define if you have the <sys/param.h> header file. */
#define HAVE_SYS_PARAM_H 1
/* Define if you have the <sys/pcl720.h> header file. */
/* #undef HAVE_SYS_PCL720_H */
/* Define if you have the <sys/ppsclock.h> header file. */
/* #undef HAVE_SYS_PPSCLOCK_H */
/* Define if you have the <sys/proc.h> header file. */
#define HAVE_SYS_PROC_H 1
/* Define if you have the <sys/resource.h> header file. */
#define HAVE_SYS_RESOURCE_H 1
/* Define if you have the <sys/select.h> header file. */
#define HAVE_SYS_SELECT_H 1
/* Define if you have the <sys/sockio.h> header file. */
#define HAVE_SYS_SOCKIO_H 1
/* Define if you have the <sys/stat.h> header file. */
#define HAVE_SYS_STAT_H 1
/* Define if you have the <sys/stream.h> header file. */
#define HAVE_SYS_STREAM_H 1
/* Define if you have the <sys/stropts.h> header file. */
#define HAVE_SYS_STROPTS_H 1
/* Define if you have the <sys/sysctl.h> header file. */
/* #undef HAVE_SYS_SYSCTL_H */
/* Define if you have the <sys/time.h> header file. */
#define HAVE_SYS_TIME_H 1
/* Define if you have the <sys/timers.h> header file. */
/* #undef HAVE_SYS_TIMERS_H */
/* Define if you have the <sys/timex.h> header file. */
#define HAVE_SYS_TIMEX_H 1
/* Define if you have the <sys/tpro.h> header file. */
/* #undef HAVE_SYS_TPRO_H */
/* Define if you have the <sys/types.h> header file. */
#define HAVE_SYS_TYPES_H 1
/* Define if you have the <termio.h> header file. */
#define HAVE_TERMIO_H 1
/* Define if you have the <termios.h> header file. */
#define HAVE_TERMIOS_H 1
/* Define if you have the <unistd.h> header file. */
#define HAVE_UNISTD_H 1
/* Define if you have the <utmp.h> header file. */
#define HAVE_UTMP_H 1
/* Define if you have the <utmpx.h> header file. */
#define HAVE_UTMPX_H 1
/* Define if you have the elf library (-lelf). */
#define HAVE_LIBELF 1
/* Define if you have the gen library (-lgen). */
/* #undef HAVE_LIBGEN */
/* Define if you have the kvm library (-lkvm). */
#define HAVE_LIBKVM 1
/* Define if you have the ld library (-lld). */
/* #undef HAVE_LIBLD */
/* Define if you have the mld library (-lmld). */
/* #undef HAVE_LIBMLD */
/* Define if you have the nsl library (-lnsl). */
#define HAVE_LIBNSL 1
/* Define if you have the posix4 library (-lposix4). */
#define HAVE_LIBPOSIX4 1
/* Define if you have the socket library (-lsocket). */
#define HAVE_LIBSOCKET 1
From: Brian Morris <brian@mvhs.fuhsd.org>
Date: Thu, 9 Apr 1998 21:17:46 -0700 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: solaris 5.6 wisdom repost request [-/+]
I don't know why his message to me didn't how up here, even though there
is a header saying it was posted to this newsgroup. Here is the excerpt
from his message to me regarding "solaris 5.6 wisdom".
---------- Forwarded message ----------
~Date: Sat, 4 Apr 1998 23:09:50 -0700
~From: Bruce Bartram 303-497-6217 <bwb@etl.noaa.gov>
From: Unknown Author <none> (auto-inserted) [-/+]
Subject: none (auto-inserted) [-/+]
To: Brian Morris <brian@mvhs.fuhsd.org>
~Subject: Re: ntp client problems
~Newsgroups: comp.protocols.time.ntp
X-Keywords: bug [-/+] calendar [-/+] dosynctodr [-/+] nsec_per_tick [-/+] PLL [-/+] syslog [-/+]
--- SNIP First part of message ---
----- newgroup wisdom about Solaris 5.6
WARNING: this isn't based on real experience or details !!!
The newsgroup wisdom is that the Solaris 5.6 kernel ntp_adjtime
and ntp_gettime calls "don't play well" with xntpd (at least so far).
To create usable xntpd with new versions like 3-5.92, after
./configure and before make, edit the config.h file to make
certain that HAVE_NTP_ADJTIME and HAVE_NTP_GETTIME are undef'ed.
This blocks compiling the PLL stuff and the old fashioned adjtime()
hooks gets used.
It is reported that a reboot is needed to clean up after running
xntpd in PLL mode on a 5.6 system.
The distribution version is 3.4y and is reported to use only adjtime()
(via a look with truss). This is a fairly old version but it should
work fine. There is one important bug that was fixed in 3-5.87 that
can lead to the daemon quitting with a syslog message "step too large"
with a time value like 2^31 seconds. (AVOID versions 3-5.86 to 3-5.89.7).
There is only one report of a public server ever providing the unique
broken packets that trigger this Q/A bug.
I don't think the kernel variables:
dosynctodr 0 disables OS adjtime() to keep OS clock with CMOS
nsec_per_tick amount of time added each interrupt
usec_per_tick "
work (or at least in the same way). I don't think tickadj -s is needed
to clear dosynctodr, since it isn't supplied in the 5.6 distribution.
When a server upstairs jumped from 5.4 to 5.6, the basic freq seems to
have changed. Before it was trimmed within a couple ppm by a line in
/etc/system "set nsec_per_tick = 10001200". With the line still present,
under 5.6 the drift is about 19 ppm instead of about 126. I suspect
Solaris now does a callibration of the interrupt rate based on the
CMOS clock/calendar chip during boot, but this is pure guesswork.
I hope these rumors help.
From: "J. Buck Caldwell" <buck_c@polygon.com>
Date: Mon, 13 Apr 1998 13:55:22 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Cadence for NT v3.00 BETA Now Available.
X-Keywords: Windows [-/+]
Polygon is proud to announce that a public BETA program is now available for Cadence Time Services
v3.00 for Windows NT. Anyone wishing any further information, please check out:
http://www.polygon.com/beta.html
Engineer - Technical Support - Webmaster
Polygon, Inc. email:buck_c@polygon.com phone: (314) 432-4142
PO Box 8470 http://www.polygon.com/ fax: (314) 997-9696
St. Louis, MO 63132 ftp://ftp.polygon.com/ bbs: (314) 997-9682
From: Ian G Batten <I.G.Batten@batten.eu.org>
Date: 15 Apr 1998 06:38:29 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: solaris 5.6 wisdom repost request [-/+]
X-Keywords: delay [-/+] dispersion [-/+] jitter [-/+] NMEA [-/+] PLL [-/+] poll [-/+] PPS [-/+]
-----BEGIN PGP SIGNED MESSAGE-----
In article <Pine.GSO.3.95q.980409211423.2495D-100000@quantum>,
Brian Morris <brian@mvhs.fuhsd.org> wrote:
> It is reported that a reboot is needed to clean up after running
> xntpd in PLL mode on a 5.6 system.
This is true, I've found. I'm working with a Motorola OnCore module via
NMEA and some hacked hardware to bring the PPS input into the serial
port. I wanted to use two features:
* Kernel PLL
* DCD Edge detection
The problem I hit most obviously was that the DCD detection in 2.6
appears to log both the falling and the rising edge, so I had to write
code to take the incoming NMEA message, get the serial number of the
current DCD event, add 1 second to the message and spin reading the DCD
event until the serial went up by exactly one. I'm seeing this problem
that others might not because my edge-acquisition hardware has dropped
DCD before the NMEA message has actually arrived.
However, with this stuff in I was seeing offsets and dispersions in the
20ms range.
I then, following the wisdom of this group, built an xntpd binary with
the kernel PLL stuff disabled. That would hold sync to a millisecond or
two, but went off into hyperspace once in a while.
Then, following Brian's posting, I rebooted the machine in question.
Within 12 hours it had settled to an offset of a microsecond or two,
with a claimed dispersion of a few tens of microseconds. My driver has
PRECISION set to -20, so I think there is some source of jitter over and
above the claimed accuracy, but it's still pretty good I think.
$ ntpq -p sugar
remote refid st t when poll reach delay offset disp
==============================================================================
*GPS_NMEA(1) .GPS. 0 l 4 16 377 0.00 -0.001 0.02
border-cisco.ft noc.rl.ja.net 2 u 463 512 376 3.85 0.189 6.35
kevin.ftel.co.u korat.ukerna.ac 2 u 1618 1024 376 4.20 -0.316 0.53
ian
--
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv
iQB1AwUBNTRHz8oy0yij3IvtAQFtwgMAo0lRQv+RKEwvmF/EaMVvfurZ8p81iQFu
z+cW+PDYmBVJ5okG1/G8LGN9Vt72cIijEgtCEd9e2SZy6VgVQZG75h94rorVlNfu
WqYad6o3f9AlMivLzWtqPkKtM6cCU1gg
=5tAz
-----END PGP SIGNATURE-----
From: Steve Dunlop <dunlops@hotmail.com>
Date: Tue, 14 Apr 1998 13:49:29 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Netware time sync to a NTP server?? [-/+]
X-Keywords: firewall [-/+] Novell [-/+]
There is at least one public-domain .NLM on Novell's web site that
does this. We did some testing with it once. It's kinda klunky but it
worked for us.
Gary L. Zeiger wrote:
> Does anyone know of a Netware .NLM that will sync the server time to a
> NTP
> server that is running on my NT firewall? I have been using RDATE.NLM,
> but that will only sync to a Unix server, and my Unix server kind of bit
>
> the big one. Thanks in advance.
>
----------------------------------------------------------------------
Steve Dunlop
letters: "dunlop" at "bitstream" dot "net"
http://www2.bitstream.net/~dunlop
From: dalton@cup.hp.deletethis.com (David Dalton) [-/+]
Date: 15 Apr 1998 19:18:54 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Advice about TAC-2 & xntp3 please?
X-Keywords: Garmin [-/+] NMEA [-/+] PPS [-/+]
Michael St. Laurent (rowl@earthlink.net) wrote:
:>I've almost completed construction on our TAC-2/Garmin GPS-20 clock
:>and am almost ready to set it up to work with our Linux Timeserver and
:>xntp. Before I dive into doing that I hope to get some advice on what
:>the best (most accurate) way to accomplish this might be. There are
:>kernel patches available for Linux permitting it to use the PPS
:>signal. Since the consensus here seems to be that this is the only
:>way to get accuracy out of the GPS-20 I figure I'll be using them.
:>Does anyone know if these patches train the local clock by themselves
:>or are they just glue code that permits xntp to use the PPS signal?
Surely they are just the glue. NTP does the training.
:>Do I also need to set up xntp to pull the rough time out of the NMEA
:>data or is the PPS signal enough?
You must pull the rough time out of the NMEA data. There is no data at all
in the PPS, it is just a pulse with a well-defined rising edge.
Also pay attention to what the NMEA data is telling you. For example, the
GPRMC message tells you where the last fix was. If you are not currently
locked on to at leat one bird, the time reported could be weeks old. The
current NTP NMEA driver (#20) is not very smart about this. You should (at
least try to) be smarter if you write your own.
--
-> My $.02 only Not an official statement from HP {They make me say that}
--
As far as we know, our computer has never had an undetected error.
---------------------------------------------------------------------------
David Dalton dalton@cup.hp.deletethis.com 408/447-3016
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 17 Apr 1998 05:59:48 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Clock Resolution
X-Keywords: resolution [-/+]
In article <353565ab.4745207@news.doc.ca> l.dandurand@ieee.org (Luc Dandurand) writes:
> I'm trying to find out the clock resolution and accuracy on some
> machines I'm using in an experiment. The computers are all running
> Linux 2.0.30. I've got 486's and 1 Pentium. All systems have the
> CLOCKS_PER_SEC set to 100, so I assume that I have a 10 ms clock
> resolution. I am hoping for a lot more, and I have a feeling I'm
First, Linux got some essential fixes for the time code in 2.0.32, so
you should go for that version. Secondly, the resolution of the clock
is much higher than 10ms: For the i[34]86 the counter in the timer
chip is used to get close to 1us in resolution. For the Pentium and
above the CPU cycle counter is used for a theoretical (1/CPU-MHz)
resolution. For a Pentium at 100MHz the resolution you can experience
from user land is about 5us.
> getting a higher resolution. But I don't know how to find out...
> Anybody can help? And while you're at it, is there a better way of
> measuring small time intervals than gettimeofday()? I'm not interested
What architecture are you using Linux on? I suspect you have a non
i386 conformant platform...
> in obtaining truely accurate global time, but rather in measuring the
> time between two events up to microsecond resolution...
That should work.
> Thanks in advance...
> Luc Dandurand.
Ulrich
From: Terje Mathisen <Terje.Mathisen@hda.hydro.com> [-/+]
Date: Thu, 16 Apr 1998 21:00:37 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: [++] Re: Adjusting time on mission critical systems [-/+]
X-Keywords: adjustment [-/+] HP-UX [-/+] SNTP [-/+] TrueTime [-/+]
Philippe Kipfer wrote:
>
> Rodney J. Jenkins wrote:
> > The constraints:
> > I need to adjust the time back 00:02:56. (HH:MM:SS)
> > All servers need to have the same time. (Accurate to the same second)
> > The applications cannot have the time adjusted backwards by any amount.
> > I cannot shut the applicaitons down.
> >
> > The Solution (?):
> > I think I would like to have a way that would slow the time down on the NTP
> > server. This adjustment would then be replicated down to the other NTP
> > clients. What I don't know is how the NTP protocol would react to this. If
> > this is the way to do it, what is the HP-UX command to slow down the clock?
>
> The NTP protocol (not to be confused with SNTP = Simple NTP) is a protocolusing
> a kind of (sampled) regulation algorithm. A particular node located at a
> particular
> NTP stratum compare permanently its local time with a reference time (in your
> case, the primary time = GPS). Once the "error" is computed, the NTP daemon
> will (very) slowly correct the local clock to reach a null time difference
This is (by default) only true if you're quite close to the correct
time:
Since the current offset (given as 2 min 56 sec) is greater than the
128ms which is the maximum NTP will adjust gradually, starting NTP would
result in a big backwards step after about 5 minutes.
It shouldn't be too hard to do this gracefully, if you first load NTP on
all servers, with the local clock on the master designated as the single
source.
If you then use adjtickx() or something similar to slow down the master
local clock, the other servers will follow along (just do the adjustment
very slowly!), until you get to where you can connect a GPS or similar
reference.
> compared
> to its time reference. You won't see any time step from the application. NTP
> never
> do a time step, but only slight corrections.
>
> If I can suggest a trick to enhance your (time service) availability, connect
> the GPS on
> machines located on different subnets. If routers or network fail somewhere,
> other
> are still available.
I have a TrueTime NTP/GPS Stratum 1 clock, and have ordered two more
Stratum 1 sources, which I will locate in different locations to handle
this problem.
I am going to have two GPS and one radio clock, so that even if the US
should for some strange reason turn off the GPS system, my radio clock
should keep working.
>
> I observed a typicall time difference of +/- 100 ms with 4 NTP stratums over
> big networks impliing more than 50 nodes to distribute the time in a big
> organization.
This is a quite large time spread, you're close to time stepping this
way.
Terje
--
- <Terje.Mathisen@hda.hydro.com>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
From: john.ackermann@daytonOH.ncr.com (John Ackermann) [-/+]
Date: Wed, 15 Apr 1998 15:12:30 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Advice for TAC-2 & xntp newbie please?
X-Keywords: Garmin [-/+] NMEA [-/+] PPS [-/+] precision [-/+]
In article <352e95f6.104041496@news.earthlink.net>, rowl@earthlink.net (Michael St. Laurent) wrote:
>I've almost completed construction on our TAC-2/Garmin GPS-20 clock
>and by the time anyone is able to respond to this I will be ready to
>set it up to work with our Linux Timeserver and xntp. Before I dove
>into doing that I hoped to get some advice on what the best (most
>accurate) way to accomplish this might be. There are kernel patches
>available for Linux permitting it to use the PPS signal. Since the
>consensus here seems to be that this is the only way to get accuracy
>out of the GPS-20 I figure I'll be using them. Does anyone know if
>these patches train the local clock by themselves or are they just
>glue code that permits xntp to use the PPS signal? Do I also need to
>set up xntp to pull the rough time out of the NMEA data or is the PPS
>signal enough? I'm rather new to the precision time-keeping scene and
>could use some advice from someone who has done this before.
I have some information on the TAC and ntp at http://www.febo.com/ntp/. The
xntpd patch there is for the Oncore, and I don't think it will work with the
GPS-20 (I haven't tried it), but the info should help you get things running.
John Ackermann N8UR
jra@febo.com