NameDateSize

..10-Sep-201996

aclocal.m407-Mar-201949.2 KiB

adjtimed/07-Mar-20196

bincheck.mf21-Apr-2015605

bootstrap13-Jul-20154.7 KiB

build07-Mar-20194.2 KiB

ChangeLog07-Mar-2019248.2 KiB

check-libopts.mf21-Apr-2015374

clockstuff/07-Mar-20197

CommitLog07-Mar-20195.2 MiB

CommitLog-4.1.006-Nov-2012190.6 KiB

conf/21-Apr-20159

config.h.in07-Mar-201942.4 KiB

configure07-Mar-2019921.9 KiB

configure.ac07-Mar-201991.9 KiB

COPYRIGHT07-Mar-201911.7 KiB

deps-ver21-Apr-201529

depsver.mf21-Apr-20152.2 KiB

dot.emacs21-Apr-2015521

flock-build21-Apr-20153.3 KiB

html/21-Aug-201869

include/07-Mar-201980

includes.mf21-Apr-2015238

INSTALL06-Nov-20127.4 KiB

kernel/07-Mar-20195

lib/21-Apr-20153

libjsmn/13-Jul-20159

libntp/07-Mar-201976

libparse/07-Mar-201930

Makefile.am01-Mar-20183.7 KiB

Makefile.in07-Mar-201935 KiB

NEWS07-Mar-2019161 KiB

NOTES.y2kfixes06-Nov-20122.6 KiB

ntpd/15-Nov-2019111

ntpdate/07-Mar-20197

ntpdc/07-Mar-201924

ntpq/07-Mar-201922

ntpsnmpd/07-Mar-201922

packageinfo.sh07-Mar-20193 KiB

parseutil/07-Mar-20197

README06-Nov-20125.4 KiB

README.bk06-Nov-2012219

README.hackers21-Apr-2015348

README.leapsmear13-Jul-201512.8 KiB

README.patches06-Nov-20121.6 KiB

README.pullrequests27-Apr-20163.7 KiB

README.refclocks06-Nov-20122 KiB

README.versions06-Nov-2012817

readme.y2kfixes21-Apr-20154.8 KiB

results.y2kfixes06-Nov-20122.9 KiB

scripts/07-Mar-201939

sntp/07-Mar-201953

TODO06-Nov-20122.8 KiB

util/07-Mar-201932

WHERE-TO-START21-Apr-20152.3 KiB

README

1
2Submit patches, bug reports, and enhancement requests via
3
4			http://bugs.ntp.org
5
6		  The ntp Distribution Base Directory
7
8This directory and its subdirectories contain the Network Time Protocol
9Version 4 (NTP) distribution for Unix and Windows/NT systems.  This release
10may still work on VxWorks, too.
11
12The contents of the base directory are given in this file. The contents of
13subdirectories are given in the README files in each subdirectory.
14
15A complete explanation of the configure, compile and install process, as
16well as setting up an NTP subnet, is in the HTML pages in the ./html/
17directory. For more information on NTP and how to get a working setup,
18read WHERE-TO-START.
19
20For Windows/NT, visit html/build/hints/winnt.html .
21
22The base directory ./ contains the autoconfiguration files, source
23directories and related stuff:
24
25COPYRIGHT	Excerpt from the HTML file ./html/copyright.html. This file
26		specifies copyright conditions, together with a list of
27		major authors and electric addresses.
28
29INSTALL		Generic installation instructions for autoconf-based programs.
30		Unless you really know what you are doing, you should read the
31		directions in the HTML pages, starting with ./html/index.html.
32
33NEWS		What's new in this release.
34
35README		This file.
36
37README.bk	Instructions for folks who use the BitKeeper-repository
38		version of NTP.
39
40README.hackers	Notes to folks who want to hack on the code.
41
42TODO            List of items the NTP developers are working on.
43
44WHERE-TO-START	Hints on what to read in order to get a working
45		configuration.
46
47Makefile.am	Automake file configuration file. Edit only if you have the
48		GNU automake and autoconf utilities installed.
49
50Makefile.in	Autoconf make file template for Unix.
51
52adjtimed        Directory containing the sources for the adjtime daemon
53		for HP/UX systems prior to HP-UX 10.0.
54
55authstuff       Directory containing sources for miscellaneous programs
56		to test, calibrate and certify the cryptographic
57		mechanisms for DES and MD5 based authentication. These
58		programs do not include the cryptographic routines
59		themselves, so are free of U.S. export restrictions.
60
61build		A script to build the distribution in A.`config.guess`
62		subdirectory (more or less).
63
64clockstuff	Directory containing sources for miscellaneous programs
65		to test certain auxiliary programs used with some kernel
66		configurations, together with a program to calculate
67		propagation delays for use with radio clocks and
68		national time dissemination services such as WWV/WWVH,
69		WWVB and CHU.
70
71conf            Directory containing a motley collection of
72		configuration files for various systems. For example only.
73
74config.guess	Script used to identify the machine architecture and
75		operating system.
76
77config.h.in	Configuration file generated automatically from
78		configure.in. Do not edit.
79
80configure	Script used to configure the distribution. See the HTML pages
81		(./html/index.html) for a complete description of the options
82		available.
83
84configure.in	Master configuration template. Edit only if you have the
85		GNU automake and autoconf utilities installed.
86
87dot.emacs	C-mode indentation rules for code "Just the way Dave likes it".
88
89flock_build	(UDel only) Build the distribution on a number of
90		different platforms.
91
92html            Directory containing a complete set of documentation on
93		building and configuring a NTP server or client. The
94		documentation is in the form of HTML files suitable for
95		browsing and contains links to additional documentation
96		at various web sites. If a browser is unavailable, an
97		ordinary text editor can be used.
98
99include		Directory containing include header files used by most
100		programs in the distribution.
101
102install-sh	Script to install a program, script or data file.
103
104kernel		Directory containing sources for kernel programs such as
105		line disciplines and STREAMS modules used with the CHU
106		decoder and precision PPS signals.
107
108libntp		Directory containing library source code used by most
109		programs in the distribution.
110
111ntpdate		Directory containing sources for a program to set the
112		local machine time from one or more remote machines
113		running NTP.  Operates like rdate, but much more accurate.
114
115ntpq            Directory containing sources for a utility program to
116		query local and remote NTP peers for state variables and
117		related timekeeping information. This program conforms
118		to Appendix A of the NTP Version 3 Specification RFC 1305.
119
120ntptrace        Directory containing sources for a utility program that
121		can be used to reveal the chain of NTP peers from a
122		designated peer to the primary server at the root of the
123		timekeeping subnet.
124
125parse		Directory containing files belonging to the generic
126		parse reference clock driver. For reasonably simple
127		clocks it is possible to get away with about 3-4Kb of
128		code. additionally the SunOS 4.x/Solaris 5.3 streams
129		module for parse squats here.
130
131patches		Directory containing patches already applied to this
132		distribution. These are included for record and to help
133		in possible porting problems.
134
135scripts		Directory containing scripts to build the configuration
136		files in this directory and then the makefiles used in
137		various dependent directories. the subdirectories
138		monitoring and support hold various perl and shell
139		scripts for visualizing synchronization and daemon startup.
140
141stamp.h.in	Configuration file generated automatically from configure.in.
142		Do not edit.
143
144util            Directory containing sources for various utility and
145		testing programs.
146
147David L. Mills (mills@udel.edu)
14821 June 1998
149

README.bk

1In order to use the BitKeeper repository version of NTP you should visit
2
3 http://support.ntp.org/Main/SoftwareDevelopment
4
5for important information.
6
7If you want to submit patches, please see the README.hackers file.
8

README.hackers

1Notes to hackers.
2
3See README.patches for information about submitting patches.
4
5---
6
7Dave likes this code indented formatted in a consistent way.
8The file "dot.emacs" has the emacs C-mode indentation style that Dave likes.
9
10---
11
12We'd like to see *all* system function declarations live in include/l_stdlib.h
13and NEVER appear in the .c files.
14
15---
16

README.leapsmear

1Leap Second Smearing with NTP
2-----------------------------
3
4By Martin Burnicki
5with some edits by Harlan Stenn
6
7The NTP software protocol and its reference implementation, ntpd, were
8originally designed to distribute UTC time over a network as accurately as
9possible.
10
11Unfortunately, leap seconds are scheduled to be inserted into or deleted
12from the UTC time scale in irregular intervals to keep the UTC time scale
13synchronized with the Earth rotation.  Deletions haven't happened, yet, but
14insertions have happened over 30 times.
15
16The problem is that POSIX requires 86400 seconds in a day, and there is no
17prescribed way to handle leap seconds in POSIX.
18
19Whenever a leap second is to be handled ntpd either:
20
21- passes the leap second announcement down to the OS kernel (if the OS
22supports this) and the kernel handles the leap second automatically, or
23
24- applies the leap second correction itself.
25
26NTP servers also pass a leap second warning flag down to their clients via
27the normal NTP packet exchange, so clients also become aware of an
28approaching leap second, and can handle the leap second appropriately.
29
30
31The Problem on Unix-like Systems
32--------------------------------
33If a leap second is to be inserted then in most Unix-like systems the OS
34kernel just steps the time back by 1 second at the beginning of the leap
35second, so the last second of the UTC day is repeated and thus duplicate
36timestamps can occur.
37
38Unfortunately there are lots of applications which get confused it the
39system time is stepped back, e.g. due to a leap second insertion.  Thus,
40many users have been looking for ways to avoid this, and tried to introduce
41workarounds which may work properly, or not.
42
43So even though these Unix kernels normally can handle leap seconds, the way
44they do this is not optimal for applications.
45
46One good way to handle the leap second is to use ntp_gettime() instead of
47the usual calls, because ntp_gettime() includes a "clock state" variable
48that will actually tell you if the time you are receiving is OK or not, and
49if it is OK, if the current second is an in-progress leap second.  But even
50though this mechanism has been available for about 20 years' time, almost
51nobody uses it.
52
53
54NTP Client for Windows Contains a Workaround
55--------------------------------------------
56The Windows system time knows nothing about leap seconds, so for many years
57the Windows port of ntpd provides a workaround where the system time is
58slewed by the client to compensate the leap second.
59
60Thus it is not required to use a smearing NTP server for Windows clients,
61but of course the smearing server approach also works.
62
63
64The Leap Smear Approach
65-----------------------
66Due to the reasons mentioned above some support for leap smearing has
67recently been implemented in ntpd.  This means that to insert a leap second
68an NTP server adds a certain increasing "smear" offset to the real UTC time
69sent to its clients, so that after some predefined interval the leap second
70offset is compensated.  The smear interval should be long enough,
71e.g. several hours, so that NTP clients can easily follow the clock drift
72caused by the smeared time.
73
74During the period while the leap smear is being performed, ntpd will include
75a specially-formatted 'refid' in time packets that contain "smeared" time.
76This refid is of the form 254.x.y.z, where x.y.z are 24 encoded bits of the
77smear value.
78
79With this approach the time an NTP server sends to its clients still matches
80UTC before the leap second, up to the beginning of the smear interval, and
81again corresponds to UTC after the insertion of the leap second has
82finished, at the end of the smear interval.  By examining the first byte of
83the refid, one can also determine if the server is offering smeared time or
84not.
85
86Of course, clients which receive the "smeared" time from an NTP server don't
87have to (and even must not) care about the leap second anymore.  Smearing is
88just transparent to the clients, and the clients don't even notice there's a
89leap second.
90
91
92Pros and Cons of the Smearing Approach
93--------------------------------------
94The disadvantages of this approach are:
95
96- During the smear interval the time provided by smearing NTP servers
97differs significantly from UTC, and thus from the time provided by normal,
98non-smearing NTP servers.  The difference can be up to 1 second, depending
99on the smear algorithm.
100
101- Since smeared time differs from true UTC, and many applications require
102correct legal time (UTC), there may be legal consequences to using smeared
103time.  Make sure you check to see if this requirement affects you.
104
105However, for applications where it's only important that all computers have
106the same time and a temporary offset of up to 1 s to UTC is acceptable, a
107better approach may be to slew the time in a well defined way, over a
108certain interval, which is what we call smearing the leap second.
109
110
111The Motivation to Implement Leap Smearing
112-----------------------------------------
113Here is some historical background for ntpd, related to smearing/slewing
114time.
115
116Up to ntpd 4.2.4, if kernel support for leap seconds was either not
117available or was not enabled, ntpd didn't care about the leap second at all.
118So if ntpd was run with -x and thus kernel support wasn't used, ntpd saw a
119sudden 1 s offset after the leap second and normally would have stepped the
120time by -1 s a few minutes later.  However, 'ntpd -x' does not step the time
121but "slews" the 1-second correction, which takes 33 minutes and 20 seconds
122to complete.  This could be considered a bug, but certainly this was only an
123accidental behavior.
124
125However, as we learned in the discussion in http://bugs.ntp.org/2745, this
126behavior was very much appreciated since indeed the time was never stepped
127back, and even though the start of the slewing was somewhat undefined and
128depended on the poll interval.  The system time was off by 1 second for
129several minutes before slewing even started.
130
131In ntpd 4.2.6 some code was added which let ntpd step the time at UTC
132midnight to insert a leap second, if kernel support was not used.
133Unfortunately this also happened if ntpd was started with -x, so the folks
134who expected that the time was never stepped when ntpd was run with -x found
135this wasn't true anymore, and again from the discussion in NTP bug 2745 we
136learn that there were even some folks who patched ntpd to get the 4.2.4
137behavior back.
138
139In 4.2.8 the leap second code was rewritten and some enhancements were
140introduced, but the resulting code still showed the behavior of 4.2.6,
141i.e. ntpd with -x would still step the time.  This has only recently been
142fixed in the current ntpd stable code, but this fix is only available with a
143certain patch level of ntpd 4.2.8.
144
145So a possible solution for users who were looking for a way to come over the
146leap second without the time being stepped could have been to check the
147version of ntpd installed on each of their systems.  If it's still 4.2.4 be
148sure to start the client ntpd with -x.  If it's 4.2.6 or 4.2.8 it won't work
149anyway except if you had a patched ntpd version instead of the original
150version.  So you'd need to upgrade to the current -stable code to be able to
151run ntpd with -x and get the desired result, so you'd still have the
152requirement to check/update/configure every single machine in your network
153that runs ntpd.
154
155Google's leap smear approach is a very efficient solution for this, for
156sites that do not require correct timestamps for legal purposes.  You just
157have to take care that your NTP servers support leap smearing and configure
158those few servers accordingly.  If the smear interval is long enough so that
159NTP clients can follow the smeared time it doesn't matter at all which
160version of ntpd is installed on a client machine, it just works, and it even
161works around kernel bugs due to the leap second.
162
163Since all clients follow the same smeared time the time difference between
164the clients during the smear interval is as small as possible, compared to
165the -x approach.  The current leap second code in ntpd determines the point
166in system time when the leap second is to be inserted, and given a
167particular smear interval it's easy to determine the start point of the
168smearing, and the smearing is finished when the leap second ends, i.e. the
169next UTC day begins.
170
171The maximum error doesn't exceed what you'd get with the old smearing caused
172by -x in ntpd 4.2.4, so if users could accept the old behavior they would
173even accept the smearing at the server side.
174
175In order to affect the local timekeeping as little as possible the leap
176smear support currently implemented in ntpd does not affect the internal
177system time at all.  Only the timestamps and refid in outgoing reply packets
178*to clients* are modified by the smear offset, so this makes sure the basic
179functionality of ntpd is not accidentally broken.  Also peer packets
180exchanged with other NTP servers are based on the real UTC system time and
181the normal refid, as usual.
182
183The leap smear implementation is optionally available in ntp-4.2.8p3 and
184later, and the changes can be tracked via http://bugs.ntp.org/2855.
185
186
187Using NTP's Leap Second Smearing
188--------------------------------
189- Leap Second Smearing MUST NOT be used for public servers, e.g. servers
190provided by metrology institutes, or servers participating in the NTP pool
191project.  There would be a high risk that NTP clients get the time from a
192mixture of smearing and non-smearing NTP servers which could result in
193undefined client behavior.  Instead, leap second smearing should only be
194configured on time servers providing dedicated clients with time, if all
195those clients can accept smeared time.
196
197- Leap Second Smearing is NOT configured by default.  The only way to get
198this behavior is to invoke the ./configure script from the NTP source code
199package with the --enable-leap-smear parameter before the executables are
200built.
201
202- Even if ntpd has been compiled to enable leap smearing support, leap
203smearing is only done if explicitly configured.
204
205- The leap smear interval should be at least several hours' long, and up to
2061 day (86400s).  If the interval is too short then the applied smear offset
207is applied too quickly for clients to follow.  86400s (1 day) is a good
208choice.
209
210- If several NTP servers are set up for leap smearing then the *same* smear
211interval should be configured on each server.
212
213- Smearing NTP servers DO NOT send a leap second warning flag to client time
214requests.  Since the leap second is applied gradually the clients don't even
215notice there's a leap second being inserted, and thus there will be no log
216message or similar related to the leap second be visible on the clients.
217
218- Since clients don't (and must not) become aware of the leap second at all,
219clients getting the time from a smearing NTP server MUST NOT be configured
220to use a leap second file.  If they had a leap second file they would apply
221the leap second twice: the smeared one from the server, plus another one
222inserted by themselves due to the leap second file.  As a result, the
223additional correction would soon be detected and corrected/adjusted.
224
225- Clients MUST NOT be configured to poll both smearing and non-smearing NTP
226servers at the same time.  During the smear interval they would get
227different times from different servers and wouldn't know which server(s) to
228accept.
229
230
231Setting Up A Smearing NTP Server
232--------------------------------
233If an NTP server should perform leap smearing then the leap smear interval
234(in seconds) needs to be specified in the NTP configuration file ntp.conf,
235e.g.:
236
237 leapsmearinterval 86400
238
239Please keep in mind the leap smear interval should be between several and 24
240hours' long.  With shorter values clients may not be able to follow the
241drift caused by the smeared time, and with longer values the discrepancy
242between system time and UTC will cause more problems when reconciling
243timestamp differences.
244
245When ntpd starts and a smear interval has been specified then a log message
246is generated, e.g.:
247
248 ntpd[31120]: config: leap smear interval 86400 s
249
250While ntpd is running with a leap smear interval specified the command:
251
252 ntpq -c rv
253
254reports the smear status, e.g.:
255
256# ntpq -c rv
257associd=0 status=4419 leap_add_sec, sync_uhf_radio, 1 event, leap_armed,
258version="ntpd 4.2.8p3-RC1@1.3349-o Mon Jun 22 14:24:09 UTC 2015 (26)",
259processor="i586", system="Linux/3.7.1", leap=01, stratum=1,
260precision=-18, rootdelay=0.000, rootdisp=1.075, refid=MRS,
261reftime=d93dab96.09666671 Tue, Jun 30 2015 23:58:14.036,
262clock=d93dab9b.3386a8d5 Tue, Jun 30 2015 23:58:19.201, peer=2335,
263tc=3, mintc=3, offset=-0.097015, frequency=44.627, sys_jitter=0.003815,
264clk_jitter=0.451, clk_wander=0.035, tai=35, leapsec=201507010000,
265expire=201512280000, leapsmearinterval=86400, leapsmearoffset=-932.087
266
267In the example above 'leapsmearinterval' reports the configured leap smear
268interval all the time, while the 'leapsmearoffset' value is 0 outside the
269interval and increases from 0 to -1000 ms over the interval.  So this can be
270used to monitor if and how the time sent to clients is smeared.  With a
271leapsmearoffset of -.932087, the refid reported in smeared packets would be
272254.196.88.176.
273

README.patches

1See README.hackers for notes on coding styles.
2
3The master copy of this information can be found at:
4
5 http://support.ntp.org/Dev/MaintainerIssues#How_to_work_on_a_bug_using_BitKe
6
7If you are going to patch both ntp-stable and ntp-dev
8please do it this way:
9
10 > cd ntp-stable
11 > (make and test your changes to ntp-stable first)
12 > (commit your changes to ntp-stable)
13 > cd ../ntp-dev
14 > bk pull ../ntp-stable	(get your changes from ntp-stable)
15 > (resolve any problems and test your changes)
16 > (commit your changes to ntp-dev)
17
18With the current release of bitkeeper it is *much* easier to move changes
19from ntp-stable to ntp-dev than it is to move changes from ntp-dev to
20ntp-stable.
21
22If you make your changes in the above order and then submit them,
23it will be trivial to apply your patches.
24
25Otherwise, it will be much more difficult to apply your patches.
26
27You are pretty much done now if your repos are on pogo.udel.edu.
28
29If these patches are for a bugzilla issue, mark the issue as Resolved/READY
30with a comment of "Please pick up the patches in pogo:/wherever"
31
32---
33
34Please read (and follow) the previous section if you want to submit
35patches for both ntp-stable and ntp-dev.
36
37If you cannot easily get your patches to pogo, you may submit patches
38via the 'bk send' command:
39
40 > cd REPO
41 > bk citool	(or bk ci ... ;  bk commit ... )
42 > bk pull	# make sure your repo is up-to-date
43 > bk send -d -ubk://www.ntp.org/home/bk/REPO - > file-containing-the-patch
44 > bk receive -vv -a < file-containing-the-patch
45		# Sanity check.
46
47 # Open a bugzilla item at <http://bugzilla.ntp.org>
48
49 # After the bug is opened, visit the bug and attach file-containing-the-patch
50

README.pullrequests

1See README.hackers for notes on coding styles.
2
3The NTP project's github repository is at https://github.com/ntp-project/ntp.
4
5There are two branches, master and stable.
6
7The stable branch is the current supported production code branch, the
8ntp-stable code (even 2nd number).
9
10The master branch is for new development, also known as ntp-dev (which
11has an odd 2nd number).
12
13If you have some work you'd like to add, then if there is any interest
14in seeing that work in the current production release then base your work
15on the stable branch, and pull your work into a master copy to allow for
16publishing your changes in the ntp-dev or master branch.
17
18If there is no expectation that your work will be included in the
19current stable release (the ntp-stable code) then it's better to do your
20work on a copy of the master branch.
21
22Make sure that any changes you make to stable pull cleanly into master.
23
24It's possible that after pulling your changes from stable to master that
25some additional cleanup will be required in master.  Please do this.
26
27If you follow this method, then if you submit a pull request for either
28master or for master+stable, it will be easy for us to evaluate and
29incorporate your work.
30
31Please also note that your submissions will be able to be evaluated and
32handled sooner if the repo that contains your pull requests also includes
33test cases.
34
35The general workflow is as follows:
36
371) If you haven't, create a fork of ntp-project/ntp with your github account.
38   i) Log on to github.com with your github account.
39       - If you don't have one, create one first. (read: https://help.github.com/articles/signing-up-for-a-new-github-account)
40       - Make sure you also have a SSH key associated with your github account.
41         (read: https://help.github.com/articles/generating-ssh-keys/)
42   ii) Go to https://github.com/ntp-project/ntp
43   iii) On the top right corner, right below the header bar, there is
44        a button labeled "Fork".  Click on it.  This will fork the current
45	ntp master to your own account. Once done, it will go to your account's
46	version of the ntp repository. (Your fork of ntp source)
47   iv) Clone a local version of your fork. 
48        - git clone git@github.com:<your_username>/ntp
49
502) Look through the bugs listed in the bug tracker: http://bugs.ntp.org/
51
523) Once you've found a bug to work on:
53
54   i) Create a branch off your own master branch of your local fork.
55      (the <branchname> can be any valid short string that will tell you
56       what you're working on)
57      - git checkout -b <branchname>
58        
59   ii) Start working on the bug.
60   iii) When you create changes in the source, it would help you to 
61        keep track of your changes by committing to your local repo.
62	(This way, every small change is tracked and when you've
63	 made a mistake, you can always go back.)
64	 - git commit -a -m "description of change"
65   iv) Once you are satisfied, you can push to your github account's
66       repository.
67         - git push origin <branchname>
68    v) (go to step iii).
69
704) Once you feel you've fixed the bug (and tested it), you need to 
71   create a pull request on your branch on github.  (Read up on
72   pull requests @ https://help.github.com/articles/using-pull-requests)
73
74    i) Create your pullrequest by following the instructions @
75       https://help.github.com/articles/creating-a-pull-request/
76
775) Your pull request will be reviewed by committers and when it
78   passes review, it will be merged by the reviewer/allowed committer.
79
806) You have fixed a bug.  Goto step #2.
81
82If these patches are for a bugzilla issue, mark the issue as Resolved/READY
83with a comment of "Please pick up the patches from XXX" where XXX is
84something like:
85
86 hostname:~user/path	if it's a machine the reviewers have access to, or
87 github-pull-request-URI
88
89---
90
91

README.refclocks

1This is a list of the #define REFCLK_* stuff.
2
3If you want to add a new refclock let us know and we'll assign you a number.
4
5Should this list also include the name of the party responsible for the
6refclock?
7
8LOCALCLOCK	1	/* external (e.g., lockclock) */
9GPS_TRAK	2	/* TRAK 8810 GPS Receiver */
10WWV_PST		3	/* PST/Traconex 1020 WWV/H */
11SPECTRACOM	4	/* Spectracom (generic) Receivers */
12TRUETIME	5	/* TrueTime (generic) Receivers */
13IRIG_AUDIO	6	/* IRIG-B/W audio decoder */
14CHU_AUDIO	7	/* CHU audio demodulator/decoder */
15PARSE		8	/* generic driver (usually DCF77,GPS,MSF) */
16GPS_MX4200	9	/* Magnavox MX4200 GPS */
17GPS_AS2201	10	/* Austron 2201A GPS */
18GPS_ARBITER	11	/* Arbiter 1088A/B/ GPS */
19IRIG_TPRO	12	/* KSI/Odetics TPRO-S IRIG */
20ATOM_LEITCH	13	/* Leitch CSD 5300 Master Clock */
21MSF_EES		14	/* EES M201 MSF Receiver */
22GPSTM_TRUE	15	/* OLD TrueTime GPS/TM-TMD Receiver */
23IRIG_BANCOMM	16	/* Bancomm GPS/IRIG Interface */
24GPS_DATUM	17	/* Datum Programmable Time System */
25NIST_ACTS	18	/* NIST Auto Computer Time Service */
26WWV_HEATH	19	/* Heath GC1000 WWV/WWVH Receiver */
27GPS_NMEA	20	/* NMEA based GPS clock */
28GPS_VME		21	/* TrueTime GPS-VME Interface */
29ATOM_PPS	22	/* 1-PPS Clock Discipline */
30PTB_ACTS	NIST_ACTS
31USNO		NIST_ACTS
32GPS_HP		26	/* HP 58503A Time/Frequency Receiver */
33ARCRON_MSF	27	/* ARCRON MSF radio clock. */
34SHM		28	/* clock attached thru shared memory */
35PALISADE	29	/* Trimble Navigation Palisade GPS */
36ONCORE		30	/* Motorola UT Oncore GPS */
37GPS_JUPITER	31	/* Rockwell Jupiter GPS receiver */
38CHRONOLOG	32	/* Chrono-log K WWVB receiver */
39DUMBCLOCK	33	/* Dumb localtime clock */
40ULINK		34	/* Ultralink M320 WWVB receiver */
41PCF		35	/* Conrad parallel port radio clock */
42WWV_AUDIO	36	/* WWV/H audio demodulator/decoder */
43FG		37	/* Forum Graphic GPS */
44HOPF_SERIAL	38	/* hopf DCF77/GPS serial line receiver */
45HOPF_PCI	39	/* hopf DCF77/GPS PCI receiver */
46JJY		40	/* JJY receiver */
47TT560		41	/* TrueTime 560 IRIG-B decoder */
48ZYFER		42	/* Zyfer GPStarplus receiver */
49RIPENCC		43	/* RIPE NCC Trimble driver */
50???????		44	Claas Hilbrecht (20020711)
51

README.versions

1
2NTP uses A.B.C - style release numbers.
3
4At the moment:
5
6 A is 4, for ntp V4.
7 B is the major release number.
8 C is the minor release number.  Even numbers are 'stable' releases and
9 odd numbers are "development" releases.
10
11Following the release number may be the letter 'p' followed by a number.
12This indicates a point (or patch) release.
13
14Release candidates have -RC in the release number.
15
16Here are some recent versions numbers as an example:
17
18 4.2.2		A production release (from the ntp-stable repository)
19 4.2.2p2	A production release (from the ntp-stable repository)
20 4.2.3p12	A development release
21 4.2.3p15-rc1	A release candidate for 4.2.4
22
23Note that after the ntp-dev repo produces a production release it will
24be copied into the ntp-stable and the cycle will repeat.
25
26Feel free to suggest improvements...
27
28

readme.y2kfixes

1
2AT&T Freeware Year 2000 Certification
3====================================
4
5This is the "readme" file for the freeware application which has 
6been certified by AT&T Labs as part of the "Freeware Y2K 
7Certification Project".
8
9DISCLAIMER
10----------
11    For its own internal business purposes AT&T Labs has
12    assessed various programs obtained from the Internet for
13    Year-2000 (Y2K) readiness that were not sufficiently certified
14    for AT&T's needs.  As a service to the computing community
15    AT&T Labs is freely releasing this information to the
16    public as a series of "Y2K Application Updates", one update
17    for what AT&T Labs considers an "application".
18
19    For use outside of AT&T, AT&T Labs is not certifying this
20    information is correct, that any software, including repairs
21    and tests, will help others in any way, survive the year
22    2000, nor work with current applications. Nor is AT&T
23    taking any responsibility for repairing any Y2K problems
24    that were overlooked nor repairing any bugs in any
25    "Y2K Application Update". All risk of using this Y2K
26    Application Update remains with the user who is expected
27    to test that this update meets their needs.
28
29    LICENSE TO USE
30    AT&T's intent is to ensure these Y2K patches are freely
31    available to the public but will not maintain a public web site
32    for their distribution. Any copyright claims only only apply to 
33    the specific changes made by Y2K to the code. Any original 
34    copyright holders retain rights to unchanged code. Wherever 
35    possible patches will be returned to the current owner(s) of the code.
36
37    Owners and publishers are free to incorporate appropriate patches,
38    upgrades, and tests within legal future distributions as long as
39    they include the credit:
40
41      Various Y2K updates and tests provided by AT&T Labs.
42      Copyright 1999 AT&T.
43
44    and any AT&T "comments" on the changed code remain intact.
45
46    Any distributions of the updates must keep the entire update
47    intact, without any change, including copyright and disclaimer
48    information.  If integrated with the original application items
49    not needed for an integrated release may be omitted. When
50    distributed on the same media as the original application there
51    must be no charge for this "Y2k Application Update".
52
53    CONTACTS
54    If you find any overlooked Y2K problems, or have other strictly Y2K
55    repairs for the software, please E-mail:
56
57            y2k@y2k.labs.att.com
58
59    This address is strictly reserved for the topic at hand.
60    AT&T makes no commitments to answer any E-mail
61    to this address.  AT&T is free to use any submissions,
62    including publishing in future Y2K related release notes,
63    without payment or advance notice to the submitting person or
64    persons... appropriate credit will be given in any future
65    publications to the first person submitting something that
66    AT&T uses.
67
68
69======================================================================
70
71Perl  ver - 4.036 
72No. of Repairs: 2 Repairs
73Compilation of Patches Required: No
74OS Tested: Solaris 2.6
75
76======================================================================
77
78ORGANIZATION OF THE "Y2KFixes" DIRECTORY
79
80The "Y2KFixes" directory has been included in the archive to give
81you information about the Y2K testing that was conducted and their
82results.
83
84The Y2KFixes directory contains at least the following three files:
85|----> NOTES.y2kfixes    -- Technical details about the Y2K Testing
86|----> Readme.y2kfixes   -- this Readme file
87|----> Results.y2kfixes  -- The results of Y2K Environment Tests
88
89The directory may contain additional files and/or directories, as 
90appropriate to the application, to provide the exact snapshots.
91
92
93======================================================================
94
95INSTALLING THE "PATCHES"
96
97If you have downloaded a "patch", then you may install it as follows:
98
99    At the same level as the source directory, invoke:
100
101	patch -p < *.patches 
102
103The patch file contains a header which has a manifest of changed files.
104
105======================================================================
106
107ADDITIONAL INSTRUCTIONS:
108
109
1101) Extract the patches into perl-4.036 directory which is top level directory
111   for the perl4 source.
112
1132) cd to Y2KFixes.
114
1153) It will have y2k directory which contains regression tests for Y2K testing.
116
1174) now cd to ../t which contains TEST file for running this regression tests.
118
1195) run TEST, see the results  & apply patches.
120
1216) Once you apply the patch, you need to run a shell script in x2p/find2perl.SH
122   which will generate find2perl.
123
124
125======================================================================
126
127SUPPORT
128
129See http://y2k.labs.att.com/freeware.  There will be no ongoing 
130support for the project. But if you have some very important issue, 
131you may email us at: y2k@y2k.labs.att.com
132