NTP "FAQ" #2 (6/96 - 10/97) - Articles (part 15)

Previous part

From: eggert@twinsun.com (Paul Eggert) [-/+]Date: 23 May 1997 14:18:25 -0700 [-/+]Newsgroups: comp.protocols.time.ntp,uk.comp.misc Subject: Re: What is the UK's current summer time rule? [-/+]

Paul Black <paul@darwin.demon.co.uk> writes: > "Marc Brett" <Marc.Brett@waii.com> wrote: > > Spring forward to British Summer Time at 0100 on the Last Sunday of March. > > Fall back to Greenwich Mean Time at 0200 on the Last Sunday of October. > Has this changed? I thought clocks always changed at 2am.

Not always. According to <ftp://elsie.nci.nih.gov/pub/>, British clocks have changed at the following times:

from through time of change (UT) 1916 1940 2am 1941 1945 1am 1945 1947 2am 1947 1947 1am (1947 was a wild year, with 4 clock-changes.) 1947 1980 2am 1981 now 1am

(The EU requires that clocks change at 1am UT; this is probably not coincidental.)

By comparison the USA is a model of consistency: we've changed our clocks at 2am local time ever since standard time was introduced.

From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]Date: 23 May 1997 23:07:33 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: What is the UK's current summer time rule? [-/+]X-Keywords: compatible [-/+] daylight [-/+] timezone [-/+]

Nick Maclaren (nmm1@cus.cam.ac.uk) wrote:

: I am sorry for an inappropriate posting, but there aren't any better : groups! I need to know the actual rule that we currently use for : changing between the daylight saving and normal parts of BST. Can : anyone help?

: Nick Maclaren, : University of Cambridge Computer Laboratory, : New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. : Email: nmm1@cam.ac.uk : Tel.: +44 1223 334761 Fax: +44 1223 334679

Howdy, The home of the timezone workers seems to be ftp://elsie.nci.nih.gov/pub and the tzdata1997f.tar.gz file (or newer) has the europe data in it. I just grabbed a copy and as I read it (WARNING: don't trust me !!!), the time changes now follow the EU rules == the last Sundays of March and October. I'm not quite sure how to read the time-of-day for the switch, but I'd guess the switch occurs at 01 UTC, so the spring switch would be 0:59:59 to 2:00:00 and the fall would be 1:59:59 to 1:00:00. (Again: WARNING !!)

There are many pages of notes on the vagaries of Parliament and BST over many years.

I think that most UNIX systems can directly swallow the data file with the "zic" program to produce the needed /usr/share/lib/zoneinfo/... files and you could just set the default TZ=Europe/London to get all the history. I know Solaris uses a "zic" and "localtime()" that are different than the elsie.nci.nih.gov flavors, but I think the europe file can be swallowed by the Solaris "zic" to create the .../zoneinfo/Europe/... files. I wouldn't be as sure that the zic output format is compatible.

Since timezones (especially daylight savings time) are political creations, I suggest using the fancy TZ=Europe/London form of the un*x time system.

Bruce Bartram bbartram@etl.noaa.gov just another chimehead

From: WhiskerP@logica.com (Peter Whisker) [-/+]Date: Tue, 27 May 1997 09:03:00 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: What is the UK's current summer time rule? [-/+]X-Keywords: compatible [-/+] daylight [-/+] timezone [-/+]

In article <5m57vl$h1m$1@mwrns.boulder.noaa.gov>, bwb@etl.noaa.gov (Bruce Bartram) wrote: >Nick Maclaren (nmm1@cus.cam.ac.uk) wrote: > >: I am sorry for an inappropriate posting, but there aren't any better >: groups! I need to know the actual rule that we currently use for >: changing between the daylight saving and normal parts of BST. Can >: anyone help? > >: Nick Maclaren, >: University of Cambridge Computer Laboratory, >: New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. >: Email: nmm1@cam.ac.uk >: Tel.: +44 1223 334761 Fax: +44 1223 334679 > >Howdy, > The home of the timezone workers seems to be > ftp://elsie.nci.nih.gov/pub >and the tzdata1997f.tar.gz file (or newer) has the europe >data in it. I just grabbed a copy and as I read it >(WARNING: don't trust me !!!), the time changes now >follow the EU rules == the last Sundays of March and October. >I'm not quite sure how to read the time-of-day for the >switch, but I'd guess the switch occurs at 01 UTC, so >the spring switch would be 0:59:59 to 2:00:00 and the >fall would be 1:59:59 to 1:00:00. (Again: WARNING !!) > >There are many pages of notes on the vagaries of >Parliament and BST over many years. > >I think that most UNIX systems can directly swallow the >data file with the "zic" program to produce the needed >/usr/share/lib/zoneinfo/... files and you could just >set the default TZ=Europe/London to get all the history. >I know Solaris uses a "zic" and "localtime()" that are >different than the elsie.nci.nih.gov flavors, but I think the >europe file can be swallowed by the Solaris "zic" to create >the .../zoneinfo/Europe/... files. I wouldn't be as >sure that the zic output format is compatible. > >Since timezones (especially daylight savings time) are >political creations, I suggest using the fancy TZ=Europe/London >form of the un*x time system. > >Bruce Bartram bbartram@etl.noaa.gov just another chimehead

Yes, the timezone table (and your interpretation) are correct. The changes is at 0100 UTC on the last Sunday of March & October for all of the EU. (However, it now looks like France want to break this.)

Peter Whisker Cobham, Surrey, England.

************************************************************ * Peter Whisker * Logica UK Ltd, Cobham, Surrey, UK *Any opinions are mine!* http://www.logica.com/ for theirs ! * whiskerp@logica.com * http://public.logica.com/~whiskerp/

For PGP key:Send e-mail to pgp_peter@reepicheep.logica.co.uk Fingerprint:FD 97 98 9A F4 1E 9C 89 8B 8D FF 73 65 A0 E1 99

From: wiu09524@rrzc4 (Ulrich Windl) [-/+]Date: 26 May 1997 08:11:07 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: Xntp time offset swinging wildly X-Keywords: Linux [-/+] loopstats [-/+]

Maybe you should also watch the loopstats file. Some sanity checks might ignore bad timestamps from your reference clock.

One think known to disturb xntpd on Linux (at least) are short select()s, just when playing MIDI files (or running Java (I've heard)). Xntpd is delayed when reading reference time stamps and thinks he/she/it is late...

-- Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>

From: helm@fionn.es.net (Michael Helm) Date: 25 May 1997 21:46:35 GMT [-/+]Newsgroups: comp.protocols.time.ntp,comp.sys.hp.hpux Subject: PHKL_4413 & ntp [-/+]X-Keywords: synchronized [-/+]

Don't apply patch PHKL_4413 to systems where time is synchronized with ntp. This patch makes external synchronization impossible.

If you find this patch installed, uninstall it with rmfn & then have sam build you a new kernel. Thanks to the people who answered my question about uninstalling patches; it came in handy.

(This should be added to the hpux hints, I think.)

From: alek@mail1.ast.lmco.com (Alek O. Komarnitsky) Date: 26 May 1997 11:24:22 -0600 [-/+]Newsgroups: comp.protocols.time.ntp,comp.sys.hp.hpux Subject: Re: PHKL_4413 & ntp [-/+]X-Keywords: FAQ [-/+] synchronized [-/+]

In article <5mabvr$9ir@overload.lbl.gov>, Michael Helm <helm@fionn.es.net> wrote: >Don't apply patch PHKL_4413 to systems where time is synchronized >with ntp. This patch makes external synchronization impossible. > >If you find this patch installed, uninstall it >with rmfn & then have sam build you a new kernel. Thanks to the >people who answered my question about uninstalling patches; it >came in handy. > >(This should be added to the hpux hints, I think.)

OK ... but before I add something like this to the FAQ, I kinda need to know a few more details on exactly why this causes the problem you describe.

Thanx, alek

From: dsiebert@icaen.uiowa.edu (Doug Siebert) Date: 26 May 1997 19:19:27 GMT [-/+]Newsgroups: comp.protocols.time.ntp,comp.sys.hp.hpux Subject: Re: PHKL_4413 & ntp [-/+]X-Keywords: FAQ [-/+] HP-UX [-/+] synchronized [-/+]

alek@mail1.ast.lmco.com (Alek O. Komarnitsky) writes:

>In article <5mabvr$9ir@overload.lbl.gov>, >Michael Helm <helm@fionn.es.net> wrote: >>Don't apply patch PHKL_4413 to systems where time is synchronized >>with ntp. This patch makes external synchronization impossible. >> >>If you find this patch installed, uninstall it >>with rmfn & then have sam build you a new kernel. Thanks to the >>people who answered my question about uninstalling patches; it >>came in handy. >> >>(This should be added to the hpux hints, I think.)

>OK ... but before I add something like this to the FAQ, >I kinda need to know a few more details on exactly why >this causes the problem you describe.

I ran into this about three years ago running timed on 9.x systems. The PHKL_4413 patch is a patch that correct "hardware clock drift" if I remember correctly. What it did to my systems running timed was to start massive clock drifting between a minute or two fast and a minute or two slow, cycling so fast that the clock ran probably 50% fast for a few minutes then 50% slow! I assume there was some sort of interaction between what timed was doing to correct the clock and what this patch did, and that interaction may also affect ntp.

I remember this well since this is the only time I have ever had to back out a patch on HP-UX, despite always just taking every patch there is when I'm doing a system load.

-- Douglas Siebert Director of Computing Facilities douglas-siebert@uiowa.edu Division of Mathematical Sciences, U of Iowa

He who lives in a glass house should not invite in he who is without sin.

From: "Marc Brett" <Marc.Brett@waii.com> [-/+]Date: 29 May 1997 07:59:09 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: simple question [-/+]X-Keywords: SGI [-/+]

tatsuya kawasaki <tatsuya@thongvilay.giganet.net> wrote: > I use solaris 2.5 and I would like to run xntpd when the system booted > up.

> what kind of file do I need to put into initd and rc2.d etc..

This script was posted by R. Bernstein, and is what is used here to start up SGI machines.

>From airgun.wg.waii.com!uunet!in1.uu.net!newsfeed.internetmci.com!panix!panix2.panix.com!rocky Mon Jan 15 09:48:37 1996

From: Unknown Author <none> (auto-inserted) [-/+]Subject: none (auto-inserted) [-/+]~From: rocky@panix.com (R. Bernstein) ~Newsgroups: comp.protocols.time.ntp ~Subject: Some simple NTP scripts ~Date: 14 Jan 1996 01:42:34 -0500 Organization: PANIX Public Access Unix, NYC ~Lines: 146 Distribution: inet Message-ID: <ROCKY.96Jan14014230@panix2.panix.com> NNTP-Posting-Host: panix2.panix.com cc: mills@udel.edu X-Keywords: AIX [-/+] configuration [-/+] peer [-/+]

Many thanks to all the folks that have worked on NTP and made it such a great piece of software.

In humble appreciation, here are the scripts I've been using for a while to start/stop xntpd and to force setting the date---I do this before running xntpd. Perhaps these may be of use.

I've used these scripts (ntphosts.sh, setdate, rc.ntp) on SunOS, Solaris, AIX, and an old RT/PC run BSD 4.3. First a short description of each:

ntphosts.sh merely lists all of the time servers listed in a particular ntp.conf file. It's used by setdate and rc.ntp. It takes an argument which is the configuration file.

setdate uses ntphosts.sh and ntpdate to set the date/time. I use this in rc.ntp before starting xntpd.

rc.ntp starts and stops xntpd. On Solaris this could be symbolically linked in /etc/rc.2d. Other platforms it's just called from another rc.file such as rc.local (on BSD-ish boxes) or rc.tcpip (on AIX).

----- setdate ---- #!/bin/sh # Time-stamp: <95/11/02 15:17:08 rocky> # The incantation used to force setting the date using ntpdate. Assumes xntpd # installation and /etc/ntp.conf has been installed. /var/adm/bin/ntpdate `/var/adm/bin/ntphosts.sh /etc/ntp.conf` exit $?

---- ntphosts.sh ----

#!/bin/sh ntp_conf=$1 [ -z "$ntp_conf" ] || [ ! -f $ntp_conf ] && echo " Usage: $0 *ntp.conf*

Lists the non-local NTP peers and servers in the NTP configuration file *ntp.conf*. " && exit 1 awk ' /^(peer|server)[ \t]/ { host = $2 if ( host !~ /127.127.1.0/) print host } ' $ntp_conf

--- rc.ntp ------ #!/bin/sh # NTP time synchronization start up and stop script. # # Ideas borrowed from the script by 1.11 1993/07/09 13:17:00 kardel Exp # and scripts/xntp by rocky. # This script follows the Solaris convention that a single parameter # is passed and it is either "start" or "stop". # This script also is intended to be used on lots of different architecures. # Therefore the least common-denominator features are used. Like sh instead # of ksh.

# locations of various things. NTPBIN=/var/adm/bin NTPDATE=$NTPBIN/ntpdate NTPHOSTS=$NTPBIN/ntphosts.sh XNTPD=$NTPBIN/xntpd XNTPDLOG=/var/adm/ntpstats/xntpd.log NTPCONF=/etc/ntp.conf

# return the process id for the process given as the argument. getpid() { #set -x if [ -f /vmunix ] ; then pid=`/usr/bin/ps -ax | /usr/bin/grep $1 | /usr/bin/grep -v grep | /usr/bin/sed -e 's/^ *//' -e 's/ .*//'` else pid=`/usr/bin/ps -e | /usr/bin/grep $1 | /usr/bin/sed -e 's/^ *//' -e 's/ .*//'` fi if [ -z "$pid" ] ; then echo 0; else echo $pid fi }

# Return a list of peers and servers listed in the NTP configuration file. getservers() { #set -x if [ -r $NTPCONF ] && [ -x $NTPHOSTS ]; then SERVERS=`$NTPHOSTS $NTPCONF` else SERVERS='' fi }

# Set the date via ntpdate setdate() { #set -x if [ -x $NTPDATE ] ; then getservers if [ -n "$SERVERS" ] ; then $NTPDATE -s $SERVERS sleep 3 # wait till it settles down? fi fi }

# # Main line code... # case "$1" in 'start') # Is xntpd already running? More than once? pids=`getpid xntpd` for pid in $pids ; do [ $pid -ne 0 ] && exit 1 done setdate if [ -x $XNTPD ] ; then # Now start xntpd --- and you thought I'd never get around to it! if [ -w $XNTPDLOG ] ; then $XNTPD >> $XNTPDLOG 2>&1 else $XNTPD fi exit $? else echo "${0}: xntpd (in ${XNTPD}) not found or not executable." fi ;; 'stop') # Is xntpd already running? More than once? pids=`getpid xntpd` for pid in $pids ; do [ $pid -ne 0 ] && kill $pid done exit $? ;; *) echo "Usage: $0 { start | stop }" exit 1 ;; esac exit 0

-- Marc Brett +44 181 560 3160 Western Atlas Marc.Brett@waii.com 455 London Road, Isleworth FAX: +44 181 847 5711 Middlesex TW7 5AB England

From: Carl Brewer <carl@abm.com.au> [-/+]Date: Fri, 30 May 1997 13:53:51 +1100 [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: NTP server for MVS? [-/+]X-Keywords: implementation [-/+] mainframe [-/+] MVS [-/+] Stenn [-/+]

Harlan Stenn wrote: > > At one site I know the folks have their MVS box call Boulder every week > during the reboot and set its clock. They say the clock in the box is > "very stable" and that the clock requires very little change when the > sync to Boulder happens. > > They'd like to run NTP as a *server* on this box, using the local clock > as the refclock. > > Since there are a lot of other machines that interface to the mainframe, > the other machines sync their clocks to the mainframe. > > Does anybody know of an implementation of an NTP server that runs under > MVS that could be used for this purpose? > > If it means anything, I also hear the word "sysplex" mentioned (I > started forgetting what little I knew about IBM mainframe gear nearly 20 > years ago).

This is a similar question to one I asked here a few months ago, at the time, there was no NTP implementation for any of the mainframes that anyone could tell me about (I didn't ask about UNIX on a mainframe, that may be a possibility)

The Sysplex timers are supposedly very accurate (although at the site I was at they were set twice a year by an operator calling the local telephone time service and pressing a key "on the third stroke"!)

You may be able to run an NTP daemon from one of the other machines that pulls its time from the big iron, but AFAIK there's no NTP at all for MVS (not according to the IBM people I spoke to, or anyone on this newsgroup at the time).

From: "Marc Brett" <Marc.Brett@waii.com> [-/+]Date: 29 May 1997 07:56:50 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: simple question [-/+]

tatsuya kawasaki <tatsuya@thongvilay.giganet.net> wrote: > I use solaris 2.5 and I would like to run xntpd when the system booted > up.

> what kind of file do I need to put into initd and rc2.d etc..

This was posted by Edward J. Huff to c.p.t.n a while ago.

>From diamond.waii.com!uunet!in1.uu.net!166.84.0.219!panix!cmcl2.nyu.edu!news.nyu.edu!not-for-mail Fri Feb 7 15:35:20 1997

From: Unknown Author <none> (auto-inserted) [-/+]Subject: none (auto-inserted) [-/+]~From: "Edward J. Huff" <huffe@carbon.chem.nyu.edu> ~Newsgroups: comp.protocols.time.ntp ~Subject: Solaris 2.5 xntpd startup/shutdown: /etc/init.d/ntp.server ~Date: Thu, 06 Feb 1997 23:38:00 -0500 Organization: New York University Chemistry Dept ~Lines: 160 Message-ID: <32FAB1A8.122E@carbon.chem.nyu.edu> NNTP-Posting-Host: carbon.chem.nyu.edu X-Keywords: configuration [-/+] dosynctodr [-/+]

Here is my idea of the ideal startup/shutdown for xntpd on Solaris 2.5.

In addition to the usual "start" and "stop" the script supports "restart" (stop/sleep/start) and "truss" which writes 100 lines of truss output to /etc/ntp.truss for the currently running ntpd process.

Given that /etc/do_rcps copies one file from the main file server to the other workstations and /etc/do_rshs runs rsh on only the other workstations, here are my scripts. The first installs the second, which is assumed to live in /usr/local/src/ntp/init.d.ntp.server.

I guess the installation could be done using pkgadd etc. but I don't know how to set that up.

Unfortunately it looks like this mailer added some newlines, be careful...

xenon% wc /usr/local/src/ntp/install_init.d 18 61 906 /usr/local/src/ntp/install_init.d xenon% wc /usr/local/src/ntp/init.d.ntp.server 104 510 3346 /usr/local/src/ntp/init.d.ntp.server

---------- #!/bin/sh

# remove existing files rm -f /etc/init.d/ntp.server /etc/rc2.d/S99ntp.server /etc/rc1.d/K00ntp.server /etc/rc0.d/K00ntp.server /etc/do_rshs 'rm -f /etc/init.d/ntp.server /etc/rc2.d/S99ntp.server /etc/rc1.d/K00ntp.server /etc/rc0.d/K00ntp.server'

# install /etc/init.d/ntp.server and /etc/rc2.d/S99ntp.server hard link. cp /usr/local/src/ntp/init.d.ntp.server /etc/init.d/ntp.server chmod 544 /etc/init.d/ntp.server chown root:sys /etc/init.d/ntp.server ln /etc/init.d/ntp.server /etc/rc2.d/S99ntp.server ln /etc/init.d/ntp.server /etc/rc1.d/K00ntp.server ln /etc/init.d/ntp.server /etc/rc0.d/K00ntp.server /etc/do_rcps /etc/init.d/ntp.server /etc/do_rshs 'chown root:sys /etc/init.d/ntp.server' /etc/do_rshs 'ln /etc/init.d/ntp.server /etc/rc2.d/S99ntp.server' /etc/do_rshs 'ln /etc/init.d/ntp.server /etc/rc1.d/K00ntp.server' /etc/do_rshs 'ln /etc/init.d/ntp.server /etc/rc0.d/K00ntp.server'

----------- #!/bin/sh # Start/stop/restart/truss Network Time Protocol Daemon xntpd # /etc/init.d/ntp.server # ln /etc/init.d/ntp.server /etc/rc2.d/S99ntp.server # ln /etc/init.d/ntp.server /etc/rc1.d/K00ntp.server # ln /etc/init.d/ntp.server /etc/rc0.d/K00ntp.server

# All scripts starting with Snn in rc2.d are executed on # transition to state 2 (multiuser mode) with $1 = start. # Do not edit these scripts in place with emacs. # All scripts starting with Knn in rc1.d or rc0.d are # executed on shutdown with $1 = stop. See /etc/rc2.d/README

# # Derived from suggestions by # Denny Gentry denny@eng.sun.com # Bruce Bartram bbartram@etl.noaa.gov bwb@etl.noaa.gov # and others on comp.protocols.time.ntp

# The use of "grep -w" is lifted from /etc/init.d/nfs.server # -w Search for the expression as a word as if # surrounded by \< and \>. # 3.1 \< constrains a RE to match the beginning of a string # or to follow a character that is not a digit, under- # score, or letter. The first character matching the RE # must be a digit, underscore, or letter. # 3.2 \> constrains a RE to match the end of a string or to # precede a character that is not a digit, underscore, or # letter.

if [ ! -d /usr/bin ] ; then # /usr not mounted exit fi

# Find process id's of all processes named exactly 'xntpd' # The -p option of xntpd is not used. What if the file # fails to be deleted on shutdown, the pid happens to # be in use on startup, etc.? Does not work if this # script is itself named xntpd. pid=`/usr/bin/ps -e | /usr/bin/grep -w xntpd | /usr/bin/sed -e 's/^ *//' -e 's/ .*//'`

# the name of the xntpd configuration file ntpconf=/etc/ntp.conf

# check in /etc/system for the dosynctodr = 0 statement pat='^[ ]*set[ ][ ]*dosynctodr[ ]*=[ ]*0\>' /usr/bin/grep "$pat" /etc/system > /dev/null 2>&1 if [ $? -ne 0 ] ; then echo "Network Time Protocol needs dosynctodr=0 in /etc/system" fi

# the first three servers in the configuration file # which are not actual clocks (127 network). # Each [ ] is blank or tab. servers=` /usr/bin/sed -n 's/^[ ]*server[ ]*$[^ ]*$.*/\1/p' $ntpconf | /usr/bin/grep -v "^127\." | /usr/bin/head -3`

case "$1" in 'start')

if [ -f $ntpconf -a -x /usr/local/bin/xntpd -a -x /usr/local/bin/ntpdate ]; then if [ "${pid}" != "" ]; then echo "Network Time Protocol daemon is running, pid = $pid." else echo Network Time Protocol: set clock from $servers /usr/local/bin/ntpdate -v $servers sleep 5 echo "Starting Network Time Protocol daemon xntpd" /usr/local/bin/xntpd -c $ntpconf fi fi ;;

'stop') if [ $1 = "stop" ]; then if [ "${pid}" != "" ]; then echo "Stopping Network Time Protocol daemon pid ${pid}" /usr/bin/kill ${pid} fi fi ;;

'restart') /etc/init.d/ntp.server stop sleep 5 /etc/init.d/ntp.server start ;;

'truss') echo "This is for debugging hung xntpd server" echo "(/usr/bin/truss -p ${pid} 2>&1) | head -100 > /etc/ntp.truss &" (/usr/bin/truss -p ${pid} 2>&1 & trusspid=$!; sleep 60; kill $trusspid ) | head -100 > /etc/ntp.truss & ;;

*) echo "Usage: /etc/init.d/ntp.server { start | stop | restart | truss }" ;; esac

-- huffe@carbon.chem.nyu.edu (Edward J. Huff) 212-998-8465

-- Marc Brett +44 181 560 3160 Western Atlas Marc.Brett@waii.com 455 London Road, Isleworth FAX: +44 181 847 5711 Middlesex TW7 5AB England

From: Tom.Horsley@worldnet.att.net (Thomas A. Horsley) [-/+]Date: 29 May 1997 18:31:24 -0400 [-/+]Newsgroups: comp.protocols.time.ntp Subject: Yet another NTP client available... X-Keywords: Windows [-/+]

The NTP client I wrote as a learning exercise has now been documented, cleaned up, and placed on my web page for anyone who wants to fool with it.

Runs on Windows NT as a service and Windows 95 as a console app.

Source code and x86 executable available.

You can read all about it at http://home.att.net/~Tom.Horsley/ntptime.html -- See <URL:http://home.att.net/~Tom.Horsley> for information on Government by Performance

From: "Marc Brett" <Marc.Brett@waii.com> [-/+]Date: 30 May 1997 09:17:01 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: NTP server for MVS? [-/+]X-Keywords: implementation [-/+] mainframe [-/+] MVS [-/+] Stenn [-/+]

Harlan Stenn <stenn@whimsy.udel.edu> wrote: > At one site I know the folks have their MVS box call Boulder every week ~~~~~~~~~~ > during the reboot and set its clock. They say the clock in the box is ~~~~~~~~~~~~~~~~~ > "very stable" and that the clock requires very little change when the > sync to Boulder happens.

They're rebooting MVS every week!?!? They've got bigger problems than time synchronization...

> They'd like to run NTP as a *server* on this box, using the local clock > as the refclock.

> Since there are a lot of other machines that interface to the mainframe, > the other machines sync their clocks to the mainframe.

> Does anybody know of an implementation of an NTP server that runs under > MVS that could be used for this purpose?

> If it means anything, I also hear the word "sysplex" mentioned (I > started forgetting what little I knew about IBM mainframe gear nearly 20 > years ago).

[This is all from memory of other posts to this newsgroup, and so may be completely out in left field. Caveat Emptor.]

The Sysplex Timer is (rather expensive) hardware which controls the clock(s) on the (cluster of) MVS machine(s). The Sysplex Timer is in turn controlled by a PC running OS/2. This PC can alter the clock of the Sysplex Timer by sending messages via its RS/232 interface.

The controller PC can get its time via NTP, then transmit the time info to the Sysplex Timer. The MVS box will then be in effect a slave of an NTP client. The remaining machines on the network can then be rigged as NTP clients and/or servers.

You would have to dig up an OS/2 NTP client (do they exist?) and write a simple daemon to transmit the time info to the Sysplex Timer.

-- Marc Brett +44 181 560 3160 Western Atlas Marc.Brett@waii.com 455 London Road, Isleworth FAX: +44 181 847 5711 Middlesex TW7 5AB England

From: nmm1@cus.cam.ac.uk (Nick Maclaren) [-/+]Date: 4 Jun 1997 12:08:12 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: NTP server for MVS? [-/+]X-Keywords: implementation [-/+] MVS [-/+] precision [-/+]

In article <3392fe1c.257949354@news.pl.unisys.com>, "Don.[NO SPAM]Payette"@unisys.com (Don Payette) writes: |> nmm1@cus.cam.ac.uk (Nick Maclaren) wrote: |> |> > . . . NTP is seriously incompatible with MVS. |> |> This statement piqued my curiosity. Would you care to |> expand on this a bit? Thanks.

NTP is based around the concept that the system timing is done by reference to a single, high-precision, real-time system clock and that all other time-related values are taken from that. It also assumes that the clock value can be changed safely while the system is running.

MVT (MVS's predecessor) was originally designed for hardware that need not have ANY real-time clock and, if one was provided, it was assumed would be used primarily for displaying human-readable times. This changed over time, and I believe that MVS now always uses the TOD (high-precision, real-time) clock as the master.

At least in MVS/XA, with some models, the only hardware instruction to set the TOD clock consistently across all CPUs caused the clock to stop until it picked up from the clock of some other CPU. This could occur only at a 'long second' (1.048576 second) boundary.

There are also a lot of places where the software assumes that the system will be stopped to change time (i.e. much like Unix). This probably means that gradual changes are feasible while MVS is running, but larger ones are a bad idea.

As I have never used MVS/ESA, it is possible that the time model has been extended enough to make NTP implementable. I am quite certain that the conceptual differences are large enough to make such an implementation extremely tricky, and to justify my first statement.

Nick Maclaren, University of Cambridge Computer Laboratory, New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. Email: nmm1@cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679

From: "Don.[NO SPAM]Payette"@unisys.com (Don Payette) Date: Wed, 04 Jun 1997 17:28:57 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: NTP server for MVS? [-/+]X-Keywords: implementation [-/+] mainframe [-/+] MVS [-/+] precision [-/+]

Thanks, Nick. I was curious since I'm a systems programmer for Unisys (formerly Burroughs) and I'm implementing clock drift and slewing code in our mainframe (A Series). Application visible negative clock adjustments are unacceptable, of course. In our operating system (the MCP) we have a mechanism to cause all but one of the CPUs to go idle. I then set the time back and spin until it catches up to what the time was before the setback, then let the CPUs run again. This way no application will ever see the time go backwards.

nmm1@cus.cam.ac.uk (Nick Maclaren) wrote:

>In article <3392fe1c.257949354@news.pl.unisys.com>, "Don.[NO SPAM]Payette"@unisys.com (Don Payette) writes: >|> nmm1@cus.cam.ac.uk (Nick Maclaren) wrote: >|> >|> > . . . NTP is seriously incompatible with MVS. >|> >|> This statement piqued my curiosity. Would you care to >|> expand on this a bit? Thanks. > >NTP is based around the concept that the system timing is done >by reference to a single, high-precision, real-time system clock >and that all other time-related values are taken from that. It >also assumes that the clock value can be changed safely while >the system is running. > >MVT (MVS's predecessor) was originally designed for hardware that >need not have ANY real-time clock and, if one was provided, it >was assumed would be used primarily for displaying human-readable >times. This changed over time, and I believe that MVS now always >uses the TOD (high-precision, real-time) clock as the master. > >At least in MVS/XA, with some models, the only hardware instruction >to set the TOD clock consistently across all CPUs caused the clock >to stop until it picked up from the clock of some other CPU. This >could occur only at a 'long second' (1.048576 second) boundary. > >There are also a lot of places where the software assumes that the >system will be stopped to change time (i.e. much like Unix). This >probably means that gradual changes are feasible while MVS is >running, but larger ones are a bad idea. > >As I have never used MVS/ESA, it is possible that the time model >has been extended enough to make NTP implementable. I am quite >certain that the conceptual differences are large enough to make >such an implementation extremely tricky, and to justify my first >statement. > > >Nick Maclaren, >University of Cambridge Computer Laboratory, >New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. >Email: nmm1@cam.ac.uk >Tel.: +44 1223 334761 Fax: +44 1223 334679

Don.[NO SPAM]Payette@unisys.com I speak only for myself; not my employer To reply via email, remove the [NO SPAM] from my email address

From: "Reynir Siik" <reynir.siik@lsc.mil.se> Date: 29 May 97 18:56:28 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: Is NTP year2000 compliant? [-/+]

Yes indeed, NTP version 3 will be able to operate untill sometime in the year 2036. Then the timestampformat will overflow unless actions are taken. Currently, work are beeing done on NTP version 4 that will be operational after 2036.

The following text is a quote from RFC-2030: "As the NTP timestamp format has been in use for the last 17 years, it remains a possibility that it will be in use 40 years from now when the seconds field overflows. As it is probably inappropriate to archive NTP timestamps before bit 0 was set in 1968, a convenient way to extend the useful life of NTP timestamps is the following convention: If bit 0 is set, the UTC time is in the range 1968-2036 and UTC time is reckoned from 0h 0m 0s UTC on 1 January 1900. If bit 0 is not set, the time is in the range 2036- 2104 and UTC time is reckoned from 6h 28m 16s UTC on 7 February 2036. Note that when calculating the correspondence, 2000 is not a leap year. Note also that leap seconds are not counted in the reckoning."

Reynir Siik reynir.siik@lsc.mil.se

John A. Gesualdi <jgesuald@projo.com> skrev i inl�gg <5mg4b6$mlh$1@pnn.projo.com>... > > > > We have ntp version 3.4h running on our Sun Sparc systems, can someone > tell me if ntp is year2000 compliant? > > Thanks > > >

From: richw@webcom.com (Rich Wales) [-/+]Date: 2 Jun 1997 11:10:58 -0400 [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: Is NTP year2000 compliant? [-/+]X-Keywords: calendar [-/+]

"Reynir Siik" <reynir.siik@lsc.mil.se> wrote:

The following text is a quote from RFC-2030: ". . . a convenient way to extend the useful life of NTP timestamps is the following convention: If bit 0 is set, the UTC time is in the range 1968-2036 and UTC time is reckoned from 0h 0m 0s UTC on 1 January 1900. If bit 0 is not set, the time is in the range 2036-2104 and UTC time is reckoned from 6h 28m 16s UTC on 7 February 2036."

06:28:16 UTC on 7 Feb. 2036, BTW, happens to be the exact time when the 32-bit "seconds" part of the 64-bit NTP timestamp overflows. So the above convention is simply another way of saying that time marches on without a hitch when an overflow occurs.

"Note that when calculating the correspondence, 2000 is not a leap year."

Since 2000 =is= a leap year, I would assume that the above is a typo and that it should really say "1900 is not a leap year".

I redid the calculations myself just now -- assuming correct Gregorian calendar leap year rules, under which 1900 was not a leap year, but 2000 will be -- and confirmed that the timestamp does indeed overflow at the above-stated moment in 2036.

Rich Wales richw@webcom.com http://www.webcom.com/richw/

From: Peter Silva <Peter.Silva@ec.gc.ca> Date: Wed, 04 Jun 1997 11:56:49 -0400 [-/+]Newsgroups: comp.protocols.time.ntp Subject: Daylight Savings bug in 3-5.90 on NT [-/+]

I have a problem with xntp on NT which is fairly gruesome. What to do about the Time zones. People want to use local time on their NT hosts, and NT doesn't seem to have a clue about having the time zone as a "user registry entry" (forgive my NT illiteracy, I'm lamentably unix-oriented) or some such.

So we have to have the whole system on local time, so when Daylight savings kick in or out, the xntpd says the clock suddenly changed by an hour, and dies. That's fine if you beside you NT box, but I'm trying to have other people (whom I don't know) run it on machines at hundreds of places remotely, getting them all to restart the daemon after is (to put it mildly) inconvenient.

Has anyone else seen this problem, work-around it?

-- Peter.Silva@ec.gc.ca - Supercomputing, Environment Canada

From: Tom.Horsley@worldnet.att.net (Thomas A. Horsley) [-/+]Date: 04 Jun 1997 19:40:58 -0400 [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: Daylight Savings bug in 3-5.90 on NT [-/+]X-Keywords: timezone [-/+]

>I have a problem with xntp on NT which is fairly gruesome. >What to do about the Time zones. People want to use local time >on their NT hosts, and NT doesn't seem to have a clue about >having the time zone as a "user registry entry" (forgive >my NT illiteracy, I'm lamentably unix-oriented) or some such.

I'm not sure if this is exactly what you are asking, but NT does have the GetSystemTime() and SetSystemTime() functions which operate with the UTC time, not local time, so it must keep timezone info somewhere.

If you want to know how different users on the same machine can have different timezones, then you got me :-).

From: Matt Park <mattpark@transend.com.tw> Date: Fri, 06 Jun 1997 07:33:17 +0800 [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: Daylight Savings bug in 3-5.90 on NT [-/+]

Peter Silva wrote: > > I have a problem with xntp on NT which is fairly gruesome. > What to do about the Time zones. People want to use local time > on their NT hosts, and NT doesn't seem to have a clue about > having the time zone as a "user registry entry" (forgive > my NT illiteracy, I'm lamentably unix-oriented) or some such. > > -- > Peter.Silva@ec.gc.ca - Supercomputing, Environment Canada

NT Registry does have a clue about time zones. Like 95 it is easily set by the date/time function under the control panel or even easier by double clicking on the clock in the toolbar (For NT4.0). There is also an option for automatically adjusting dofr Daylight savings time.

I have recently been experimenting with the GetSystemTime and SetSystemTime() functions and they do return UCT time. They work fine. I did find that they messed up when I set my time zone to Taiwan time, it acted like I was in PST. By switching to Beijing time zone (CHT), which is the same GMT-8 as Taiepi, it worked fine.

Good luck,

Matt

From: Greg Schueman <schueman@ix.netcom.com> [-/+]Date: Sun, 08 Jun 1997 14:56:01 -0700 [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: Daylight Savings bug in 3-5.90 on NT [-/+]

I have heard several reports of this problem. I have not yet found the solution in the code base. I'm not sure where in NTP the problem is being introduced.

I am actively looking into it, but it might be a month as I only have snippets of time available.

-Greg

Peter Silva wrote:

> I have a problem with xntp on NT which is fairly gruesome. > What to do about the Time zones. People want to use local time > on their NT hosts, and NT doesn't seem to have a clue about > having the time zone as a "user registry entry" (forgive > my NT illiteracy, I'm lamentably unix-oriented) or some such. > > So we have to have the whole system on local time, so when > Daylight savings kick in or out, the xntpd says the clock > suddenly changed by an hour, and dies. That's fine if > you beside you NT box, but I'm trying to have other people > (whom I don't know) run it on machines at hundreds of places > remotely, getting them all to restart the daemon after is > (to put it mildly) inconvenient. > > Has anyone else seen this problem, work-around it? > > -- > Peter.Silva@ec.gc.ca - Supercomputing, Environment Canada

From: Viraj Bais <viraj_bais@ccm.fm.intel.com> Date: Mon, 09 Jun 1997 00:51:31 -0700 [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: Daylight Savings bug in 3-5.90 on NT [-/+]X-Keywords: bug [-/+] daylight [-/+] timezone [-/+]

Greg Schueman wrote: > > I have heard several reports of this problem. I have not yet found the > solution > in the code base. I'm not sure where in NTP the problem is being > introduced. > > I am actively looking into it, but it might be a month as I only have > snippets > of time available. > > -Greg

There is a bug in the NT _ftime() system call (actually in one of the Win32 API's that the _ftime() calls, I forget which one but one can find out by stepping the code through the debugger) that returns incorrect values if your timezone is one that does not adjust for daylight's savings. In the xntp3.5f version, we have made some changes to the winnt_gettimeofday() routine in lib/machines.c file to fix this bug. I have not looked at 3.5-90, it would need something similar.

OLD CODE: int winnt_gettimeofday(tv) struct timeval *tv; { struct _timeb timebuffer;

_ftime(timebuffer); tv->tv_sec = (long)timebuffer.time; tv->tv_usec = (long) (1000 * timebuffer.millitm)); return 0; }

CORRECTED CODE:

// 100ns intervals between 1/1/1601 and 1/1/1970 as reported by // SystemTimeToFileTime() #define FILETIME_1970 0x019db1ded53e8000 const BYTE DWLEN = sizeof(DWORD) * 8; //number of bits in DWORD

int winnt_gettimeofday(tv) struct timeval *tv; { FILETIME ft; __int64 msec;

GetSystemTimeAsFileTime(&ft); // 100ns intervals since 1/1/1601 msec = (__int64)ft.dwHighDateTime << DWLEN | ft.dwLowDateTime; msec = (msec - FILETIME_1970) / 10; tv->tv_sec = (long) (msec / 1000000); tv->tv_usec = (long) (msec % 1000000); return 0; }

From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]Date: 5 Jun 1997 04:13:10 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: novice questions X-Keywords: adjustment [-/+] calendar [-/+] configuration [-/+] controlkey [-/+] dosynctodr [-/+] driftfile [-/+] fudge [-/+] implementation [-/+] loopfilter [-/+] Mills [-/+] nsec_per_tick [-/+] peer [-/+] precision [-/+] requestkey [-/+] resolution [-/+] synchronized [-/+] syslog [-/+] TCP [-/+] UDP [-/+]

Bjoern Haake (bxh@dsc.com) wrote: : Hello,

: I have a couple of questions concerning installing : ntp on a Solaris machine, and I guess I didn't get : the whole point of NTP yet.

Yes, a general understanding of what NTP is about is a required starting point. NTP is a protocol to distribute "good time" in UTC. "Good time" comes from some authority, a radio clock, a series of phone calls, or perhaps just the sysadm checking the time regularly against a wristwatch. There are many details that come into play to make it work. Each host has a daemon program running that asks, listens and responds to time packets on the ntp/udp port. This daemon must be "root" to be able to attach to the privledged port and to change the OS clock.

In a small LAN, systems can usually keep within a few milliseconds (or a bit worse) if the LAN is lightly loaded. Over long network connections and in the presense of network conjestion, the accuracy gets worse, to perhaps several 10s of milliseconds and with occasional large hits. 0.128 seconds is considered so bad that the xntpd daemon steps the time and resets. An occasional step happens in response to very bad network delays or flakey time sources. A step occurs at the leap second (23:59:60 June 30, 1997 will be a leap) if the daemon is warned.

NTP has lots of checking and testing to try to identify and ignore broken, insane or missing hosts. The primary implementation of NTP is the xntpd program, and it can be both server and client.

: Machine: Solaris 2.5.1 : NTP: xntp3-5.90 Good choice. I'm a bit lazy and am still on 3-5.89.8.

: I have installed it without problems. For testing : purposes, there are only two machines right now. : My first question is:

: Can't I just install ntp on machine A, then call : ntpdate with the address from machine B and get : the same time on both machines?

: Well, obviously not, otherwise I wouldn't ask, I : guess I am missing the point. Shouldn't it be : possible to get the time from another UNIX machine : without all the fancy Radio clock stuff?

For Solaris, the xntpd launcher script should be in /etc/init.d/xntp with a symbolic link in /etc/rc2.d/S99xntp (in my humble opinion). When the host reboots, the multi-user start up code executes "/etc/rc2.d/S* start" so the xntpd daemon will wake up. To manually start, stop or restart xntpd, execute the /etc/init.d/xntp with the desired argument. By using the scripts, simple errors and lots of typing can be avoided. My overly complicated startup script is attached below.

For Solaris, the tickadj program needs to be run before the xntpd starts to tweak a kernel variable "dosynctodr" and thereby prevent the OS from adjusting the OS clock to match the hardware clock/calendar chip that is built into the computer. There must only be one time adjusting program running on the host at once. For sparc-Solaris 2.5.x the tickadj program can also trim the basic clock rate at very high precision (0.1 ppm resolution) by using "tickadj -s -t <nsec_per_tick value, nominal 10^7>". tickadj option -A is recommended by Dave Mills to set yet another kernel variable "tickadj" to a good value for xntpd. (The default is much larger than needed. The smaller value should improve smoothness, as far as my limited understanding of the loopfilter goes.) Summary: the startup script should have tickadj -s -A -t <trimmed nsec_per_tick on sparc>. For Ultra-Solaris-2.5.x, a trimming technique was discussed at the end of April.

Some kind of ntp.conf file is needed unless you can make it work by the command line switches. I recommend using xntpd -c /usr/local/etc/ntp.conf in the startup script, so the ntp.conf and other files aren't destroyed by an OS upgrade, patch or reload (yes, my disk bombed once when I was using /etc/ntp.conf).

The ntp.conf and ntp.keys files can be shared between many similar clients, but each host needs its own ntp.drift file. ntp.drift remembers that host's frequency error so the daemon doesn't need to relearn it when waking up later.

A very simple ntp.conf for your primary host could be server 127.127.1.0 # local refclock fallback fudge 127.127.1.0 stratum 9 # show poor quality driftfile /usr/local/etc/ntp.drift # freq memory keyfile /usr/local/etc/ntp.keys # passwd controlkey 1 requestkey 1 # allow live config and this host might have a DNS CNAME of "tick". Only the first line is required, the rest of the lines add features. I don't know how to declare a server or refclock from the command line. I could enable live configuration and then add the server via xntpdc, but that is harder than ntp.conf. Simple -cast clients can be launched without an ntp.conf.

Your client ntp.conf could be server tick driftfile /usr/local/etc/ntp.drift

Once tick wakes up, it will respond to any client requests for time packets (chimes) and it will send its OS clock as the "good time". You can read .../html/driver0.html to learn about the techniques to trim tick to keep fairly decent time (I think +/- 10 ppm should be doable in a week of eyeball and wrist-watch with xntpdc fudge...)

When the client wakes up, it will probe tick once a minute (actually 2^6 seconds) until it has about 5 or 6 samples. The client will then declare tick to be its sync peer and will start adjtime()'ing its clock to match tick's time. If the client finds itself more than 0.128 seconds off, it will step its time and then spend another 6 minutes watching before starting to track. In my system, even with a bunch of network failures, the client hasn't stepped in several months.

In a client's startup script, calling ntpdate tick will get the clock very close before xntpd starts, so the daemon can start up faster.

The xntpd won't answer, or will answer that it isn't giving "good time", unless the daemon is synchronized to a server or a refclock. The 127.127.1.0 is a simulated refclock that just looks at the host's own clock as "good time". If the xntpd has a frequency offset value, from either ntp.drift or from contact with a lower stratum server in the past, the daemon will call adjtime() with the drift value. By tweaking or learning the drift, tick's OS clock can be very good (a few ppm). xntpd shows stratum 16 and/or LEAP 11 to mean that it isn't giving good time.

: When I do a ntpdate -d <IP-Addr> I get: : # ntpdate -d 199.181.240.50 : 4 Jun 14:46:22 ntpdate[479]: ntpdate 3-5.90 Mon : Jun 2 13:30:42 PDT 1997 (1) : transmit(199.181.240.50) : transmit(199.181.240.50) ... : 4 Jun 14:46:26 ntpdate[479]: no server suitable : for synchronization found : What does this mean?

Looks like the server wasn't running xntpd or couldn't be reached.

: I know that the clocks are less than 1000secs : apart and that I have a ntp.conf file (which I : don't need in this case, do I?). One thing that : worries me is that I read it is using UDP, not : TCP, my /etc/services file shows both, however: : ntp 123/tcp # : Network Time Protocol : ntp 123/udp # : Network Time Protocol : Is that causing problem?

The Solaris /etc/services has the needed ntp/udp. This is OK.

: One last question: : When I run any command in ntpd or xntpdc (for : example peers), I get: : xntpdc> peers : xntpdc: read: Connection refused : xntpdc>

The local host isn't running xntpd. Look in syslog. I think your xntpd quit and it probably left a message as to why.

: If you have answers to some of the above question, : I'd really appreciate. Email me if I am not : specific enough.

: Thanks a lot, Bjoern : bxh@dsc.com

----- my overly complicated startup script sparc-solaris 2.5 WARNING: I just edited this beast and haven't test it !!!

#!/bin/sh # /etc/init.d/xntp (intended, not tested in this exact form) # BBartram 19970603 thru 19970604 # # To stop running xntpd and to go back to original: # 1) remove /etc/rc2.d/S99xntp to something not S* or K* # 2) reboot # This is needed to get the system to restart the adjustment of # the system time to the clock-calendar onboard chip. # # original may be found .../html/hints/solaris # The script should be in /etc/init.d/xntp and there should be # ln -s /etc/init.d/xntp /etc/rc2.d/S99xntp # so things get started during reboot to multiuser. # I once had a bit of trouble cranking while nis+ was coming # up and intres didn't return. I avoid it now by nsswitch.conf # hosts DNS. I could have chagned to IP#s or actually tried to # find out what was going on but I just did "hack and run"

if [ a$1 = a ]; then echo $0 "needs an argument choices: stop or start or restart" else if [ $1 = "stop" -o $1 = "restart" ]; then # Assumes ps -e gives <space possible>PID<space>stuff<space>xntpd # Ignores S99xntp process because the S99, and the grep by the [x] # I haven't got a trick to allow /etc/init.d/xntpd stop to ignore # itself, so I have to name that program without the ending d # I should convert grep sed to a just sed, but I'm lazy psline=`/usr/bin/ps -e | /usr/bin/grep ' [x]ntpd$'` # sed skips intial white, then removes next white and after pid=`echo $psline | /usr/bin/sed -e 's/^ *//' -e 's/ .*//'` if [ "${pid}" != "" ]; then echo "Stopping Network Time Protocol daemon pid = " $pid /usr/bin/kill ${pid} fi fi

if [ $1 = "restart" ]; then # make sure it has time to die sleep 5 fi

if [ $1 = "start" -o $1 = "restart" ]; then if [ -x /usr/local/bin/xntpd ]; then ntpconf=/usr/local/etc/ntp.conf echo "Starting NTP, takes a minute... using" $ntpconf # # I used to use /etc/system addon lines set dosynctodr=0 # and set nsec_per_tick=10001264. tickadj 3-5.90 can # do this now /usr/local/bin/tickadj -s -A -t 10001264 # Note: the -t for sparc-Solaris 2.5 adjusts nsec # Take drift value average after a few days, # and the new value is : # new := current * ( 1 + drift/2^20 ) # default nsec_per_tick is 10^7, so my drift of # +132.5 makes the target value 10001264. # # find 3 servers in ntp.conf, ignore ref_clocks # each of the [ ] or [^ ] have a space and a tab # I hope the line wrap v below is ok. servers=`/usr/bin/sed -n \ 's/^[ ]*server[ ]*$[^ ]*$.*/\1/p' $ntpconf | /usr/bin/grep -v "^127\." | /usr/bin/head -3` echo ntpdate polling servers $servers /usr/local/bin/ntpdate -sv $servers # let ntpdate's adjtime settle down sleep 3 /usr/local/bin/xntpd -c $ntpconf echo "xntpd needs tickadj -s or /etc/system set dosynctodr = 0" fi fi fi

# from original .../html/hints/solaris by Denny Gentry denny@eng.sun.com # end

From: John Hay <jhay@zibbi.mikom.csir.co.za> [-/+]Date: 8 Jun 1997 18:44:06 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: Delorme anticipation [-/+]X-Keywords: Garmin [-/+] NMEA [-/+]

Todd Graham Lewis <tlewis@mindspring.net> wrote: : The Travelmate is that cute little yellow GPS receiver; I've seen it : reviewed recently in several PC magazines. It outputs NMEA-0183 over : RS-232; for those unfamiliar with NMEA-0183, I found the following two : sites particularly helpful: ... : Anyway, my question is, does xntpd support NMEA directly? I am somewhat : discouraged by the lack of mention of NMEA in the xntpd docs and also by : the noticeable lack of several fields from the NMEA format, esp. leap : second indication. Also, NMEA seems to be sort of gratuitous in its : message generation; the docs abound with sentences such as "anywhere : between two and eight seconds between messages" and what not.

There is a nmea driver in xntpd, look in html/driver20.html and xntpd/refclock_nmea.c

The quality of the output time on GPS's vary a lot, because it is not its main use. I use a Garmin GPS 25XL, which is an OEM unit (it doesn't have a LCD screen or power supply) and with NMEA output and 1PPS signal it makes a very nice stratum 0 clock. Garmin says the 1PPS signal is accurate +-1us. It costs about $180.

John -- John Hay -- John.Hay@mikom.csir.co.za

From: hpa@transmeta.com (H. Peter Anvin) [-/+]Date: 8 Jun 1997 18:45:56 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: Delorme anticipation [-/+]X-Keywords: Linux [-/+] NMEA [-/+] PPS [-/+]

Followup to: <Pine.LNX.3.96.970608043719.11666A-100000@reflections.eng.mindspring.net> By author: Todd Graham Lewis <tlewis@mindspring.net> In newsgroup: comp.protocols.time.ntp > > The temptation was too great. For $140 I can have a stratum-1 server in > my apartment, and I am merely human. > > Anyway, a Delorme Travelmate is supposedly in the hands of the USPS, on > its way to Atlanta. In the interim, I decided to read up on the thing to > see what I'm getting. > > The Travelmate is that cute little yellow GPS receiver; I've seen it > reviewed recently in several PC magazines. It outputs NMEA-0183 over > RS-232; for those unfamiliar with NMEA-0183, I found the following two > sites particularly helpful: > > http://www.marinesoft.com/htm/mse4.htm > > ftp://sundae.triunf.ca/pub/peter/nmeafaq.txt > > Anyway, my question is, does xntpd support NMEA directly? I am somewhat > discouraged by the lack of mention of NMEA in the xntpd docs and also by > the noticeable lack of several fields from the NMEA format, esp. leap > second indication. Also, NMEA seems to be sort of gratuitous in its > message generation; the docs abound with sentences such as "anywhere > between two and eight seconds between messages" and what not. > > Anyway, I'm sure I can hack something up even if it's not directly > supported, the message format is straightforward enough. I'm just curious > if it's a case of crappy technology. I'm not embarassed to pay $140 for > crappy technology, just curious as to what I'm getting. > > TIA for anyone who can shed light on this. >

xntp *does* support NMEA, but NMEA alone is not very good. The problem is that NMEA gives a time indication, but doesn't have a "beep" saying exactly WHEN the time indication is valid. The TAPR TAC people, I believe, are using an NMEA GPS module, *but* are adding a PPS output so you have the firm synchronization point that NMEA lacks.

Don't expect xntp driven by an NMEA-only source to remain accurate to more than +- a few seconds, since it typically will never be able to achieve a lockdown.

-hpa -- PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD 1E DF FE 69 EE 35 BD 74 See http://www.zytor.com/~hpa/ for web page and full PGP public key Always looking for a few good BOsFH. ** Linux - the OS of global cooperation I am Baha'i -- ask me about it or see http://www.bahai.org/

Next part