Home | History | Annotate | only in /src/external/bsd/ntp/dist
Up to higher level directory
NameDateSize
aclocal.m418-Aug-202444.7K
adjtimed/Today
bincheck.mf27-Dec-2013605
bootstrap10-Jul-20154.7K
build25-May-20204.2K
ChangeLog18-Aug-2024269.6K
check-libntp.mf18-Aug-2024282
check-libntpd.mf18-Aug-2024179
check-libopts.mf27-Dec-2013374
check-libunity.mf18-Aug-2024373
check-scm-rev.mf18-Aug-2024234
clockstuff/Today
CommitLog18-Aug-20245.6M
CommitLog-4.1.013-Dec-2009190.6K
conf/Today
config.h.in18-Aug-202445.4K
configure18-Aug-2024973.7K
configure.ac18-Aug-202492.6K
COPYRIGHT18-Aug-202411.9K
deps-ver18-Aug-202429
depsver.mf18-Aug-20242.2K
dot.emacs13-Dec-2009521
flock-build18-Aug-20243K
html/Today
include/Today
includes.mf18-Aug-2024259
INSTALL13-Dec-20097.4K
kernel/Today
libjsmn/Today
libntp/Today
libparse/Today
Makefile.am18-Aug-20243.8K
Makefile.in18-Aug-202435.4K
NEWS18-Aug-2024360.9K
NOTES.y2kfixes13-Dec-20092.6K
ntpd/Today
ntpdate/Today
ntpdc/Today
ntpq/Today
ntpsnmpd/Today
packageinfo.sh18-Aug-20243.1K
parseutil/Today
README13-Dec-20095.4K
README.bk13-Dec-2009219
README.hackers13-Dec-2009348
README.leapsmear10-Jul-201512.8K
README.patches13-Dec-20091.6K
README.pullrequests01-May-20163.7K
README.refclocks13-Dec-20092K
README.versions13-Dec-2009817
readme.y2kfixes19-Dec-20144.8K
results.y2kfixes13-Dec-20092.9K
scripts/Today
sntp/Today
tests/Today
TODO13-Dec-20092.8K
util/Today
WHERE-TO-START27-Dec-20132.3K

README

      1 
      2 Submit patches, bug reports, and enhancement requests via
      3 
      4 			http://bugs.ntp.org
      5 
      6 		  The ntp Distribution Base Directory
      7 
      8 This directory and its subdirectories contain the Network Time Protocol
      9 Version 4 (NTP) distribution for Unix and Windows/NT systems.  This release
     10 may still work on VxWorks, too.
     11 
     12 The contents of the base directory are given in this file. The contents of
     13 subdirectories are given in the README files in each subdirectory.
     14 
     15 A complete explanation of the configure, compile and install process, as
     16 well as setting up an NTP subnet, is in the HTML pages in the ./html/
     17 directory. For more information on NTP and how to get a working setup,
     18 read WHERE-TO-START.
     19 
     20 For Windows/NT, visit html/build/hints/winnt.html .
     21 
     22 The base directory ./ contains the autoconfiguration files, source
     23 directories and related stuff:
     24 
     25 COPYRIGHT	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 
     29 INSTALL		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 
     33 NEWS		What's new in this release.
     34 
     35 README		This file.
     36 
     37 README.bk	Instructions for folks who use the BitKeeper-repository
     38 		version of NTP.
     39 
     40 README.hackers	Notes to folks who want to hack on the code.
     41 
     42 TODO            List of items the NTP developers are working on.
     43 
     44 WHERE-TO-START	Hints on what to read in order to get a working
     45 		configuration.
     46 
     47 Makefile.am	Automake file configuration file. Edit only if you have the
     48 		GNU automake and autoconf utilities installed.
     49 
     50 Makefile.in	Autoconf make file template for Unix.
     51 
     52 adjtimed        Directory containing the sources for the adjtime daemon
     53 		for HP/UX systems prior to HP-UX 10.0.
     54 
     55 authstuff       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 
     61 build		A script to build the distribution in A.`config.guess`
     62 		subdirectory (more or less).
     63 
     64 clockstuff	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 
     71 conf            Directory containing a motley collection of
     72 		configuration files for various systems. For example only.
     73 
     74 config.guess	Script used to identify the machine architecture and
     75 		operating system.
     76 
     77 config.h.in	Configuration file generated automatically from
     78 		configure.in. Do not edit.
     79 
     80 configure	Script used to configure the distribution. See the HTML pages
     81 		(./html/index.html) for a complete description of the options
     82 		available.
     83 
     84 configure.in	Master configuration template. Edit only if you have the
     85 		GNU automake and autoconf utilities installed.
     86 
     87 dot.emacs	C-mode indentation rules for code "Just the way Dave likes it".
     88 
     89 flock_build	(UDel only) Build the distribution on a number of
     90 		different platforms.
     91 
     92 html            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 
     99 include		Directory containing include header files used by most
    100 		programs in the distribution.
    101 
    102 install-sh	Script to install a program, script or data file.
    103 
    104 kernel		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 
    108 libntp		Directory containing library source code used by most
    109 		programs in the distribution.
    110 
    111 ntpdate		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 
    115 ntpq            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 
    120 ntptrace        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 
    125 parse		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 
    131 patches		Directory containing patches already applied to this
    132 		distribution. These are included for record and to help
    133 		in possible porting problems.
    134 
    135 scripts		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 
    141 stamp.h.in	Configuration file generated automatically from configure.in.
    142 		Do not edit.
    143 
    144 util            Directory containing sources for various utility and
    145 		testing programs.
    146 
    147 David L. Mills (mills (a] udel.edu)
    148 21 June 1998
    149 

README.bk

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

README.hackers

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

README.leapsmear

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

README.patches

      1 See README.hackers for notes on coding styles.
      2 
      3 The 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 
      7 If you are going to patch both ntp-stable and ntp-dev
      8 please 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 
     18 With the current release of bitkeeper it is *much* easier to move changes
     19 from ntp-stable to ntp-dev than it is to move changes from ntp-dev to
     20 ntp-stable.
     21 
     22 If you make your changes in the above order and then submit them,
     23 it will be trivial to apply your patches.
     24 
     25 Otherwise, it will be much more difficult to apply your patches.
     26 
     27 You are pretty much done now if your repos are on pogo.udel.edu.
     28 
     29 If these patches are for a bugzilla issue, mark the issue as Resolved/READY
     30 with a comment of "Please pick up the patches in pogo:/wherever"
     31 
     32 ---
     33 
     34 Please read (and follow) the previous section if you want to submit
     35 patches for both ntp-stable and ntp-dev.
     36 
     37 If you cannot easily get your patches to pogo, you may submit patches
     38 via 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

      1 See README.hackers for notes on coding styles.
      2 
      3 The NTP project's github repository is at https://github.com/ntp-project/ntp.
      4 
      5 There are two branches, master and stable.
      6 
      7 The stable branch is the current supported production code branch, the
      8 ntp-stable code (even 2nd number).
      9 
     10 The master branch is for new development, also known as ntp-dev (which
     11 has an odd 2nd number).
     12 
     13 If you have some work you'd like to add, then if there is any interest
     14 in seeing that work in the current production release then base your work
     15 on the stable branch, and pull your work into a master copy to allow for
     16 publishing your changes in the ntp-dev or master branch.
     17 
     18 If there is no expectation that your work will be included in the
     19 current stable release (the ntp-stable code) then it's better to do your
     20 work on a copy of the master branch.
     21 
     22 Make sure that any changes you make to stable pull cleanly into master.
     23 
     24 It's possible that after pulling your changes from stable to master that
     25 some additional cleanup will be required in master.  Please do this.
     26 
     27 If you follow this method, then if you submit a pull request for either
     28 master or for master+stable, it will be easy for us to evaluate and
     29 incorporate your work.
     30 
     31 Please also note that your submissions will be able to be evaluated and
     32 handled sooner if the repo that contains your pull requests also includes
     33 test cases.
     34 
     35 The general workflow is as follows:
     36 
     37 1) 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 (a] github.com:<your_username>/ntp
     49 
     50 2) Look through the bugs listed in the bug tracker: http://bugs.ntp.org/
     51 
     52 3) 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 
     70 4) 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 
     77 5) Your pull request will be reviewed by committers and when it
     78    passes review, it will be merged by the reviewer/allowed committer.
     79 
     80 6) You have fixed a bug.  Goto step #2.
     81 
     82 If these patches are for a bugzilla issue, mark the issue as Resolved/READY
     83 with a comment of "Please pick up the patches from XXX" where XXX is
     84 something 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

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

README.versions

      1 
      2 NTP uses A.B.C - style release numbers.
      3 
      4 At 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 
     11 Following the release number may be the letter 'p' followed by a number.
     12 This indicates a point (or patch) release.
     13 
     14 Release candidates have -RC in the release number.
     15 
     16 Here 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 
     23 Note that after the ntp-dev repo produces a production release it will
     24 be copied into the ntp-stable and the cycle will repeat.
     25 
     26 Feel free to suggest improvements...
     27 
     28 

readme.y2kfixes

      1 
      2 AT&T Freeware Year 2000 Certification
      3 ====================================
      4 
      5 This is the "readme" file for the freeware application which has 
      6 been certified by AT&T Labs as part of the "Freeware Y2K 
      7 Certification Project".
      8 
      9 DISCLAIMER
     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 (a] 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 
     71 Perl  ver - 4.036 
     72 No. of Repairs: 2 Repairs
     73 Compilation of Patches Required: No
     74 OS Tested: Solaris 2.6
     75 
     76 ======================================================================
     77 
     78 ORGANIZATION OF THE "Y2KFixes" DIRECTORY
     79 
     80 The "Y2KFixes" directory has been included in the archive to give
     81 you information about the Y2K testing that was conducted and their
     82 results.
     83 
     84 The 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 
     89 The directory may contain additional files and/or directories, as 
     90 appropriate to the application, to provide the exact snapshots.
     91 
     92 
     93 ======================================================================
     94 
     95 INSTALLING THE "PATCHES"
     96 
     97 If 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 
    103 The patch file contains a header which has a manifest of changed files.
    104 
    105 ======================================================================
    106 
    107 ADDITIONAL INSTRUCTIONS:
    108 
    109 
    110 1) Extract the patches into perl-4.036 directory which is top level directory
    111    for the perl4 source.
    112 
    113 2) cd to Y2KFixes.
    114 
    115 3) It will have y2k directory which contains regression tests for Y2K testing.
    116 
    117 4) now cd to ../t which contains TEST file for running this regression tests.
    118 
    119 5) run TEST, see the results  & apply patches.
    120 
    121 6) 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 
    127 SUPPORT
    128 
    129 See http://y2k.labs.att.com/freeware.  There will be no ongoing 
    130 support for the project. But if you have some very important issue, 
    131 you may email us at: y2k (a] y2k.labs.att.com
    132