From: Tom Lane <tgl@netcom.com> [-/+]
Date: Wed, 18 Mar 1998 07:10:36 GMT [-/+]
Newsgroups: comp.os.linux.networking,comp.protocols.time.ntp
Subject: Re: Is jumpstarting Xntpd with ntpdate necesarry Yes/No [-/+]
X-Keywords: documentation [-/+]
jbessels <j.bessels@g-bank.nl> writes:
> For testing purposes I've deliberately set my clock 5 minutes earlier
> to see if xntpd would correct it. Nothing seems to happen. I've
> changed the gap to only 1 minute, but still nothing happens. I've also
> waited about 10-15 minutes to give xntpd "some time".
xntpd is fairly conservative. There is some maximum offset beyond
which it will not believe the outside clock sources --- I forget whether
this is measured in seconds or minutes, but it is certainly not hours.
Check the documentation.
Even if your five-minute test offset is within the window of
believability, it will take xntpd some time to become sufficiently
confident of the measurement to decide to step the system clock to
meet it. My experience is about 15 minutes. In short, you set the
local clock too far wrong, or didn't wait long enough to see what
xntpd would do, or both.
ntpdate is, by design, considerably more willing to step the system
clock on the basis of a few measurements. xntpd is designed to
maintain the clock within milliseconds/microseconds of an outside
reference. Getting within hailing distance of that reference in the
first place is not xntpd's task.
regards, tom lane
From: dalton@cup.hp.deletethis.com (David Dalton) [-/+]
Date: 20 Mar 1998 00:52:29 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Setting up xntpd on Solaris clients [-/+]
X-Keywords: broadcast [-/+] Cisco [-/+] configuration [-/+] driftfile [-/+]
Allen Patenaude (allenp@otis.com) wrote:
:>I have set up a Soalris server with the following ntp.conf file:
:>server dominator.eecs.harvard.edu
:>server ntp.ctr.columbia.edu
:>server ntp0.cornell.edu
:>broadcast 192.250.15.255
:>driftfile /etc/ntp.drift
This looks OK
:>The question is how do I set up my Solaris workstations to pick up their
:>time from the NTP broadcast on my network?
The clients don't need any ntp.conf file when you are using broadcast.
Just start the daemon on the client with the "-b" option:
xntpd -b
:>Do I even need to broadcast on my network?
Broadcast works OK if you don't need accuracy below about 100 milliseconds.
People use it because it simplifies the client configuration. Very helpful
if you have thousands of clients. But you must have a server connected to
each subnet making the broadcasts. Cisco routers (and possibly some
others) can be configured as NTP broadcast servers.
:>Should I just use ntpdate in a cron job?
This is an alternative if your accuracy needs are modest and you don't care
about small jumps in time. It is certainly easier to configure than the
full-blown daemon. Just have all of your clients run ntpdate maybe once a
day (late at night would be good) or maybe once an hour. Simple.
I have customers who run database applications that are absolutely allergic
to any jumps in time (especially backward jumps). They cannot use ntpdate
from a cronjob.
--
-> My $.02 only Not an official statement from HP {They make me say that}
--
As far as we know, our computer has never had an undetected error.
---------------------------------------------------------------------------
David Dalton dalton@cup.hp.deletethis.com 408/447-3016
From: steveb@netcom.com (Steve Bochinski)
Date: Thu, 19 Mar 1998 20:04:57 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntpd info
X-Keywords: implementation [-/+] RFC [-/+]
I would suggest reading the various RFC's, like 1305 and I think there
are a couple of newer ones relating to updated standards like RFC 2030
(assuming that you like reading - I read them from front to back when I
started with NTP and it really helped to understand the design, algorithms
and also I read most of the current source at the time to learn about
implementation details, etc)
This should be enough to bring you up to speed to maintain, install, and
understand NTP.
Good Luck!
Steve
From: dalton@cup.hp.deletethis.com (David Dalton) [-/+]
Date: 20 Mar 1998 00:52:29 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Setting up xntpd on Solaris clients [-/+]
X-Keywords: broadcast [-/+] Cisco [-/+] configuration [-/+] driftfile [-/+]
Allen Patenaude (allenp@otis.com) wrote:
:>I have set up a Soalris server with the following ntp.conf file:
:>server dominator.eecs.harvard.edu
:>server ntp.ctr.columbia.edu
:>server ntp0.cornell.edu
:>broadcast 192.250.15.255
:>driftfile /etc/ntp.drift
This looks OK
:>The question is how do I set up my Solaris workstations to pick up their
:>time from the NTP broadcast on my network?
The clients don't need any ntp.conf file when you are using broadcast.
Just start the daemon on the client with the "-b" option:
xntpd -b
:>Do I even need to broadcast on my network?
Broadcast works OK if you don't need accuracy below about 100 milliseconds.
People use it because it simplifies the client configuration. Very helpful
if you have thousands of clients. But you must have a server connected to
each subnet making the broadcasts. Cisco routers (and possibly some
others) can be configured as NTP broadcast servers.
:>Should I just use ntpdate in a cron job?
This is an alternative if your accuracy needs are modest and you don't care
about small jumps in time. It is certainly easier to configure than the
full-blown daemon. Just have all of your clients run ntpdate maybe once a
day (late at night would be good) or maybe once an hour. Simple.
I have customers who run database applications that are absolutely allergic
to any jumps in time (especially backward jumps). They cannot use ntpdate
from a cronjob.
--
-> My $.02 only Not an official statement from HP {They make me say that}
--
As far as we know, our computer has never had an undetected error.
---------------------------------------------------------------------------
David Dalton dalton@cup.hp.deletethis.com 408/447-3016
From: dalton@cup.hp.deletethis.com (David Dalton) [-/+]
Date: 20 Mar 1998 19:25:20 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: TAC-2/GPS and xnptd [-/+]
X-Keywords: dispersion [-/+] Garmin [-/+] HP-UX [-/+] NMEA [-/+] PPS [-/+]
Tom Dunigan (dunigan@thistle.epm.ornl.gov) wrote:
:>Anyone have an ntp driver for the GPS clock kit TAC-2 ?
:>(Totally Accurate Clock) under $1000, see
:>http://www.tapr.org/tapr/html/tac2.html
It works fine with driver #20, the (somewhat undocumented) NMEA driver.
My experience with the Garmin GPS20 + TAC-2 was that the dispersion wasn't
very good because the board is "lazy" about putting out the NMEA data. I
had dispersion in the 100-200 milliseconds range, good enough for home use
but lousy in the general NTP world. You can sidestep all of this if you
have PPS support on your NTP/unix platform (sadly HP-UX does not support
PPS right now).
There is some possibility that other OEM boards will do better than the
Garmin in this regard, and I am building another one based on Motorola
Oncore right now, and another from Funai lined up after that. Does anyone
else have dispersion data to share on NMEA GPS devices?
Some GPS boards support Zero-D High Accuracy Timing mode, in which the
location is fixed (determined in advance) and the GPS board puts all
effort into determing time. This requires a modification to driver #20 so
it can decode the GPZDA message, and at least one person around here has
made this modification and has the revised driver code available. Sorry I
don't have the reference handy. Of course the Zero-D High Accuracy Timing
mode is meaningless if you don't have PPS.
--
-> My $.02 only Not an official statement from HP {They make me say that}
--
As far as we know, our computer has never had an undetected error.
---------------------------------------------------------------------------
David Dalton dalton@cup.hp.deletethis.com 408/447-3016
From: John Hay <jhay@zibbi.mikom.csir.co.za>
Date: 20 Mar 1998 20:10:12 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: TAC-2/GPS and xnptd [-/+]
X-Keywords: delay [-/+] dispersion [-/+] FreeBSD [-/+] Garmin [-/+] HP-UX [-/+] NMEA [-/+] peer [-/+] poll [-/+] PPS [-/+]
: :>Anyone have an ntp driver for the GPS clock kit TAC-2 ?
: :>(Totally Accurate Clock) under $1000, see
: :>http://www.tapr.org/tapr/html/tac2.html
: It works fine with driver #20, the (somewhat undocumented) NMEA driver.
: My experience with the Garmin GPS20 + TAC-2 was that the dispersion wasn't
: very good because the board is "lazy" about putting out the NMEA data. I
: had dispersion in the 100-200 milliseconds range, good enough for home use
: but lousy in the general NTP world. You can sidestep all of this if you
: have PPS support on your NTP/unix platform (sadly HP-UX does not support
: PPS right now).
So get a PC (486/Pentium/whatever) and run FreeBSD (or Linux) on it,
with their PPS support and then sync the rest from that one.
: There is some possibility that other OEM boards will do better than the
: Garmin in this regard, and I am building another one based on Motorola
: Oncore right now, and another from Funai lined up after that. Does anyone
I doubt if you will have much better luck. For most of the GPSes
transmition on the serial port is the lowest priority task. That is
why you should use the PPS signal (which Garmin claim is accurate to
+-1us).
: else have dispersion data to share on NMEA GPS devices?
You mean something like these two? The first is running xntp3-5.92c
(FreeBSD on a dual Pentium 100MHz) and the second ntp-4.0.72c (FreeBSD
on a 486DX2-66).
xntpdc> peer
remote local st poll reach delay offset disp
=======================================================================
*GPS_NMEA(0) 127.0.0.1 0 64 377 0.00000 0.000004 0.00002
ntpdc> peer
remote local st poll reach delay offset disp
=======================================================================
*GPS_NMEA(0) 127.0.0.1 0 64 377 0.00000 -0.000001 0.00092
John
--
John Hay -- John.Hay@mikom.csir.co.za
From: dalton@cup.hp.deletethis.com (David Dalton) [-/+]
Date: 21 Mar 1998 01:40:58 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: TAC-2/GPS and xnptd [-/+]
X-Keywords: delay [-/+] dispersion [-/+] FreeBSD [-/+] NMEA [-/+] peer [-/+] poll [-/+] PPS [-/+]
John Hay (jhay@zibbi.mikom.csir.co.za) wrote:
:>: else have dispersion data to share on NMEA GPS devices?
:>You mean something like these two? The first is running xntp3-5.92c
:>(FreeBSD on a dual Pentium 100MHz) and the second ntp-4.0.72c (FreeBSD
:>on a 486DX2-66).
:>xntpdc> peer
:> remote local st poll reach delay offset disp
:>=======================================================================
:>*GPS_NMEA(0) 127.0.0.1 0 64 377 0.00000 0.000004 0.00002
:>ntpdc> peer
:> remote local st poll reach delay offset disp
:>=======================================================================
:>*GPS_NMEA(0) 127.0.0.1 0 64 377 0.00000 -0.000001 0.00092
Those look great, but I meant WITHOUT using PPS.... There are rumours of
some GPS units that put out the serial data with good timing. I know that
the HP58503A GPS clock does this (within 5 milliseconds ALL the time), but
it costs $5k.
It is generally true that you get what you pay for. I am looking for an
exception and haven't found any (yet).
--
-> My $.02 only Not an official statement from HP {They make me say that}
--
As far as we know, our computer has never had an undetected error.
---------------------------------------------------------------------------
David Dalton dalton@cup.hp.deletethis.com 408/447-3016
From: Marc Brett <mbrett@rgs0.london.waii.com> [-/+]
Date: 23 Mar 1998 18:32:32 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntp port [-/+]
X-Keywords: TCP [-/+] UDP [-/+]
tibor sujan <tibor@ku-trnava.sk> wrote:
> My proxy server can use only mapped links TCP port.
> Can I use xntpd with TCP port 123 ? How ?
Nope. NTP must use an "unreliable" protocol: UDP. The reliability of
TCP means that incorrect packets get retransmitted, which introduces
unpredictable time delays. This means death for any time
synchronization product.
(Aside: Some Unix products get shipped with "ntp 123/tcp" in
/etc/services. This is incorrect. It must always be "ntp 123/udp".)
Have a word with the administrator of the proxy server. Perhaps she can
configure NTP to run on it. Then UDP packets would never have to pass
*through* the server, but you could still get time from it.
--
Marc Brett +44 181 560 3160 Western Geophysical
Marc.Brett@waii.com 455 London Road, Isleworth
FAX: +44 181 847 5711 Middlesex TW7 5AB UK
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 24 Mar 1998 09:36:10 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: update of NTP FAQ (to come soon)
X-Keywords: adjustment [-/+] bug [-/+] clockstats [-/+] documentation [-/+] FAQ [-/+] loopstats [-/+] ntptime [-/+] peer [-/+] peerstats [-/+] precision [-/+] release [-/+] Trimble [-/+] update [-/+]
> From: "Mark Watts" <mwatts@HiWAAY.net>
> Newsgroups: comp.protocols.time.ntp
> Subject: Re: update of NTP FAQ (to come soon)
> Date: Fri, 20 Mar 1998 08:50:25 -0600
> Organization: http://www.msfc.nasa.gov/
> Distribution: inet
> NNTP-Posting-Host: 128.158.97.32
> X-Trace: news.msfc.nasa.gov 890405430 9118 (none) 128.158.97.32
> X-Complaints-To: abuse@news.msfc.nasa.gov
> X-Newsreader: Microsoft Outlook Express 4.72.2106.4
> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
> Xcanpos: shelf.01/199804011801!0031916720
I hope Microsoft will learn some day how to make proper user-defined
headers correctly...
>
> Ulrich,
> I tried responding to you email but it bounced. Thought you might see
> it here! Here's the y2k scans you asked for.
>
> Thanks,
> Mark
> ------start------
> Script started on Thu Mar 19 04:24:28 1998
> Building list of files to scan...
>
> Scanning for potentially problematical Y2K source constructs...
>
> Any reported here ARE PROBABLY problems ...
>
> /home/systems/wattsms/make.inc:627:UPDATE_PARAM_DB=@[ %$(EHS_DEFER_PARAM) =
> %yes ] || (cd $(EHS_CONFIG); make -f parameter.mkf)
>
> /home/systems/wattsms/Source/sscs/ntp/libparse/clk_trimtsip.c:273:
> printf("sv6+ software: %d.%d (19%d/%d/%d)\n",
This looks as if it displays the date of the firmware
revision. Possibly Trimble has to make some new equipment in Y2000
first. Anyway if you add the numer to 1900 everybody will be happy.
>
> /home/systems/wattsms/Source/sscs/ntp/scripts/stats/summary.sh:9:DATE=`date
> +19%y%m%d`
That shell script is rather obsolete. I don't know how the daily
statistic files will be named in Y2000.
>
> Any reported here MAY BE problems ...
>
> /home/systems/wattsms/Source/sscs/ntp/libparse/parse.c:616: * convert a
> struct clock to UTC since Jan, 1st 1970 0:00 (the UNIX EPOCH)
The fun with automatic tools is that the even complain about
comments. Using a time base of 1970 is non-critical for Y2K IMHO.
>
> /home/systems/wattsms/Source/sscs/ntp/libparse/parse.c:637: clock->year
> += 1900;
ditto.
>
> /home/systems/wattsms/Source/sscs/ntp/libparse/parse.c:651: t =
> (clock->year - 1970) * 365;
ditto.
>
> /home/systems/wattsms/Source/sscs/ntp/libparse/parse.c:652: t +=
> (clock->year >> 2) - (1970 >> 2);
ditto.
>
> /home/systems/wattsms/Source/sscs/ntp/libparse/parse.c:653: t -=
> clock->year / 100 - 1970 / 100;
>
ditto.
> /home/systems/wattsms/Source/sscs/ntp/libparse/parse.c:654: t +=
> clock->year / 400 - 1970 / 400;
ditto.
>
> /home/systems/wattsms/Source/sscs/ntp/libparse/parse.c:803: usecoff += (t -
> parseio->parse_dtime.parse_stime.fp.l_ui + JAN_1970) * 1000000
ditto. (hey, Frank Kardel is a clever man!)
>
> /home/systems/wattsms/Source/sscs/ntp/libparse/parse.c:986:
> parseio->parse_dtime.parse_time.fp.l_ui = t + JAN_1970;
ditto.
>
> /home/systems/wattsms/Source/sscs/ntp/libparse/clk_trimtsip.c:368:
> clock->utctime = gpstime.l_ui - JAN_1970;
ditto.
>
> /home/systems/wattsms/Source/sscs/ntp/libparse/clk_trimtsip.c:416:
> now = clock->utctime + JAN_1970; /* now in GPS seconds */
ditto.
>
> /home/systems/wattsms/Source/sscs/ntp/libparse/clk_rawdcf.c:526:
> parseio->parse_dtime.parse_time.fp.l_ui = t + JAN_1970;
ditto.
>
> /home/systems/wattsms/Source/sscs/ntp/html/parsenew.html:75: since Jan
> 1st 1970, 0:00:00. The useconds field gives the respective
>
ditto. (despite of the fact that HTML documentation won't have a Y2K
problem)
> /home/systems/wattsms/Source/sscs/ntp/html/driver6.html:55:words, the first
> of which is the seconds since 1970 and the second is
>
> /home/systems/wattsms/Source/sscs/ntp/html/irig.html:156:number of seconds
> since 1 January 1970, while the second is the number
>
> /home/systems/wattsms/Source/sscs/ntp/html/release.html:149:S2000
> Sequent PTX 1.4 cc LOCAL_CLOCK (kd 93/11/10)
ditto. (I guess it should be clear for the next 95 years; after that
the HTML has to be rewritten anyway)
>
> /home/systems/wattsms/Source/sscs/ntp/html/release.html:150:S2000
> Sequent PTX 1.4 gcc LOCAL_CLOCK (kd 93/11/10)
ditto.
>
> /home/systems/wattsms/Source/sscs/ntp/html/hints/winnt:101:TimeServe2000 GPS
> receiver clock that acts as a strata 1 NTP server with no
ditto. (I don't know if the brandmark has any Y2K problems...)
>
> /home/systems/wattsms/Source/sscs/ntp/ntpq/ntpq.c:1690: cal.year += 1900;
>
ditto. (If year has the correct value (>= 100), there's no problem)
> /home/systems/wattsms/Source/sscs/ntp/util/testrs6000.c:25:
> adjustment.tv_usec = -2000;
ditto. (That is commonly named a "constant")
>
> /home/systems/wattsms/Source/sscs/ntp/util/ntptime.c:271: ts.l_ui +=
> JAN_1970;
>
> /home/systems/wattsms/Source/sscs/ntp/scripts/monitoring/ntploopwatch:60:$MJ
> D_1970 = 40587; # from ntp.h (V3)
ditto. (1970 won't change much after Y2K)
>
> /home/systems/wattsms/Source/sscs/ntp/scripts/monitoring/ntploopwatch:663:
> $t = ($F[$[] - $MJD_1970) * 24 * 60 * 60;
>
> /home/systems/wattsms/Source/sscs/ntp/scripts/monitoring/ntploopwatch:678:
> $t = ($F[$[] - $MJD_1970) * 24 * 60 * 60;
>
> /home/systems/wattsms/Source/sscs/ntp/scripts/monitoring/ntploopwatch:1000:
> $t = ($F[$[] - $MJD_1970) * 24 * 60 * 60;
ditto.
>
> /home/systems/wattsms/Source/sscs/ntp/scripts/monitoring/ntploopwatch:1475:
> if ($1 < 1970)
ditto. (Who else wrote code in the 80's that runs in pre-UNIX time?)
>
> /home/systems/wattsms/Source/sscs/ntp/scripts/monitoring/ntploopwatch:1477:
> warn("$0: can not handle years before 1970 - year $1 ignored\n");
ditto. (Obviously nobody)
>
> /home/systems/wattsms/Source/sscs/ntp/scripts/monitoring/README:143:
> config files to unix epoch values (seconds since 1970-01-01_00:00_00 UTC)
>
> /home/systems/wattsms/Source/sscs/ntp/scripts/monitoring/README:146: it
> has a bug related to dates crossing 1970, causing endless loops..
>
> /home/systems/wattsms/Source/sscs/ntp/scripts/monitoring/ntploopstat:114:$MJ
> D_1970 = 40587;
ditto. (Getting tired of 1970...)
>
> /home/systems/wattsms/Source/sscs/ntp/scripts/monitoring/ntploopstat:405:
> $suff = sprintf("%04d%02d%02d",$y+1900,$m+1,$d);
ditto. (No problem)
>
> /home/systems/wattsms/Source/sscs/ntp/scripts/monitoring/ntploopstat:418:
> int($time/86400)+$MJD_1970,
>
> /home/systems/wattsms/Source/sscs/ntp/scripts/plot_summary.pl:123:
> $line = timegm (59, 59, 23, $3, $2, $1 - 1900, 0, 0, 0);
>
ditto. (These automatic report generators make me feel more smart than
ever before)
> /home/systems/wattsms/Source/sscs/ntp/scripts/plot_summary.pl:191: print
> "set xlabel \"Days relative to 1970\"\n";
>
> /home/systems/wattsms/Source/sscs/ntp/scripts/plot_summary.pl:230: print
> "set xlabel \"Days relative to 1970\"\n";
ditto. (I guess I won't change it after Y2K)
>
> /home/systems/wattsms/Source/sscs/ntp/scripts/plot_summary.pl:264:
> $line = timegm (59, 59, 23, $3, $2, $1 - 1900, 0, 0, 0);
>
> /home/systems/wattsms/Source/sscs/ntp/scripts/plot_summary.pl:313: print
> "set xlabel \"Days relative to 1970\"\n";
>
> /home/systems/wattsms/Source/sscs/ntp/parseutil/dcfd.c:718: * since 1.1.
> 1970 UTC)
>
> /home/systems/wattsms/Source/sscs/ntp/parseutil/dcfd.c:737: clock->year
> += 1900;
ditto. (That's simply correct)
>
> /home/systems/wattsms/Source/sscs/ntp/parseutil/dcfd.c:760: * calculate
> days since 1970 (watching leap years)
>
> /home/systems/wattsms/Source/sscs/ntp/parseutil/dcfd.c:762: t =
> (clock->year - 1970) * 365;
>
> /home/systems/wattsms/Source/sscs/ntp/parseutil/dcfd.c:763: t +=
> (clock->year >> 2) - (1970 >> 2);
>
> /home/systems/wattsms/Source/sscs/ntp/parseutil/dcfd.c:764: t -=
> clock->year / 100 - 1970 / 100;
>
> /home/systems/wattsms/Source/sscs/ntp/parseutil/dcfd.c:765: t +=
> clock->year / 400 - 1970 / 400;
ditto. (The same "in green")
>
> /home/systems/wattsms/Source/sscs/ntp/include/ntp_unixtime.h:28: * Time of
> day conversion constant. Ntp's time scale starts in 1900,
>
> /home/systems/wattsms/Source/sscs/ntp/include/ntp_unixtime.h:29: * Unix in
> 1970.
>
> /home/systems/wattsms/Source/sscs/ntp/include/ntp_unixtime.h:31:#define
> JAN_1970 0x83aa7e80 /* 2208988800 1970 - 1900 in seconds */
>
> /home/systems/wattsms/Source/sscs/ntp/include/ntp_calendar.h:37: * We deal
> in a 4 year cycle starting at March 1, 1900. We assume
>
> /home/systems/wattsms/Source/sscs/ntp/include/ntp_calendar.h:50:#define
> MAR1900 ((JAN+FEB) * SECSPERDAY) /* no leap year in 1900 */
>
> /home/systems/wattsms/Source/sscs/ntp/include/ntp_calendar.h:72:#define
> MAR1988 (u_long)(STARTCYCLE22 + (u_long)MAR1900)
>
> /home/systems/wattsms/Source/sscs/ntp/include/ntp.h:674:#define MJD_1970
> 40587 /* MJD for 1 Jan 1970 */
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/ntp_util.c:460: day =
> tv.tv_sec / 86400 + MJD_1970;
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/ntp_util.c:464:
> filegen_setup(&peerstats, (u_long)(tv.tv_sec + JAN_1970));
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/ntp_util.c:503: day =
> tv.tv_sec / 86400 + MJD_1970;
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/ntp_util.c:507:
> filegen_setup(&loopstats, (u_long)(tv.tv_sec + JAN_1970));
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/ntp_util.c:545: day =
> tv.tv_sec / 86400 + MJD_1970;
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/ntp_util.c:549:
> filegen_setup(&clockstats, (u_long)(tv.tv_sec + JAN_1970));
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/ntp_util.c:587: day =
> tv.tv_sec / 86400 + MJD_1970;
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/ntp_util.c:591:
> filegen_setup(&rawstats, (u_long)(tv.tv_sec + JAN_1970));
ditto. (The only thing to worry about is an overflow within the next
decades, but I guess we'll have 64bit until then. That should give us
a few more thousand years)
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/refclock_bancomm.c:404:
> tptr->year = (unsigned short)(tadr->tm_year + 1900);
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/refclock_atom.c:283:
> pp->lastrec.l_ui = time(0) - 2 + JAN_1970;
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/refclock_atom.c:333:
> pp->lastrec.l_ui = up->ev.tv.tv_sec + JAN_1970;
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/refclock_leitch.c:691: if
> ((days_per_year((leitch->year>90?1900:2000)+leitch->year)==365) &&
ditto. (Isn't that we code we are proud of (at least until 2090)?)
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/refclock_hpgps.c:459: *
> Exception noted for year 2000.
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/refclock_hpgps.c:465: if
> ((pp->year % 4) || (pp->year == 2000)) {
OK, this looks like a sloppy leap-year detection!
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/refclock_gpsvme.c:390:
> tptr->year = (unsigned short)(tadr->tm_year + 1900);
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/refclock_gpsvme.c:574:
> time_t mktime(),time();
If that is a declaration and not a comment, it should go away.
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/refclock_heath.c:168: if
> (a->tm_year < b->tm_year ) return -1;
ditto. (Should be fine)
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/refclock_heath.c:169: if
> (a->tm_year > b->tm_year ) return 1;
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/refclock_heath.c:365:
> t.tm_year = pp->year;
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/refclock_heath.c:374:
> pp->year = q->tm_year;
>
ditto.
> /home/systems/wattsms/Source/sscs/ntp/xntpd/refclock_heath.c:396: *
> Yes, I know this code incorrectly thinks that 2000 is a leap
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/refclock_chu.c:503: tmp
> = chuc->codetimes[i].tv_sec + JAN_1970;
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/refclock_irig.c:45: * words, the
> first of which is the seconds since 1970 and the second is
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/refclock_irig.c:215:
> buf.stamp.tv_sec += JAN_1970;
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/refclock_trak.c:324:
> ppsev.tv.tv_sec += (u_int32) JAN_1970;
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/refclock_mx4200.c:1944:
> up->ppsev.tv.tv_sec += (u_int32) JAN_1970;
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/refclock_arc.c:197: 9) We would
> appear to have a year-2000 problem with this clock since
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/refclock_arc.c:1108: /*
> Year-2000 alert! */
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/refclock_arc.c:1111:
> if(pp->year < 97) { pp->year += 2000; }
Another Y2K fix until 2096...
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/refclock_arc.c:1112: else
> /* if(pp->year < 100) */ { pp->year += 1900; }
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/ntp_refclock.c:706:
> tstmp.l_ui += JAN_1970;
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/refclock_acts.c:703: *
> Yes, I know this code incorrectly thinks that 2000 is a leap
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/refclock_parse.c:1154:static
> char * l_mktime P((u_long));
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/refclock_parse.c:1214:
> CLK_UNIT(parse->peer), l_mktime(err->err_stage->err_delay));
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/refclock_parse.c:1225:
> l_mktime(current_time - err->err_started));
Subtracting time stamps is Y2K unrelated, but it may overflow
eventually.
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/refclock_parse.c:2475: *
> l_mktime - make representation of a relative time
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/refclock_parse.c:2478:l_mktime(d
> elta)
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/refclock_parse.c:2517:
> l_mktime(current_time - parse->generic->timestarted));
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/refclock_parse.c:2545:
> l_mktime(stime),
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/refclock_parse.c:3029:
> l_mktime(parse->parse_type->cl_maxunsync), parse->peer->precision);
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/refclock_parse.c:3227: tim
> = parse->time.parse_time.fp.l_ui - JAN_1970;
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/refclock_parse.c:3341:
> l_mktime(stime),
>
> /home/systems/wattsms/Source/sscs/ntp/xntpd/refclock_parse.c:3352:
> sprintf(tt, "; running time: %s\"", l_mktime(sum));
Maybe you'll need a new C library in Y2K.
>
> /home/systems/wattsms/Source/sscs/ntp/libntp/machines.c:170:/* 100ns
> intervals between 1/1/1601 and 1/1/1970 as reported by
>
> /home/systems/wattsms/Source/sscs/ntp/libntp/machines.c:174:#define
> FILETIME_1970 0x019db1ded53e8000
>
> /home/systems/wattsms/Source/sscs/ntp/libntp/machines.c:186: msec =
> (msec - FILETIME_1970) / 10;
>
> /home/systems/wattsms/Source/sscs/ntp/libntp/machines.c:208: st.wYear
> = (WORD) (gmtm->tm_year + 1900);
>
> /home/systems/wattsms/Source/sscs/ntp/libntp/caltontp.c:30: * Subtract
> out 1/1/1900, the beginning of the NTP epoch
>
> /home/systems/wattsms/Source/sscs/ntp/libntp/buftvtots.c:58: ts->l_ui =
> sec + (u_long)JAN_1970;
>
> /home/systems/wattsms/Source/sscs/ntp/libntp/caljulian.c:59: * Find the
> day past 1900/01/01 00:00 UTC
>
> /home/systems/wattsms/Source/sscs/ntp/libntp/caljulian.c:74: jt->yearday
> = 1 + d4%DAYSPERYEAR;
>
> /home/systems/wattsms/Source/sscs/ntp/libntp/calyearstart.c:35:
> cyclestart = MAR1900;
>
> /home/systems/wattsms/Source/sscs/ntp/libntp/prettydate.c:33: sec =
> ts->l_ui - JAN_1970;
>
> /home/systems/wattsms/Source/sscs/ntp/libntp/prettydate.c:40:
> months[tm->tm_mon], tm->tm_mday, 1900 + tm->tm_year,
>
> /home/systems/wattsms/Source/sscs/ntp/libntp/systime.c:112: now->l_ui +=
> JAN_1970;
>
> /home/systems/wattsms/Source/sscs/ntp/libntp/calleapwhen.c:44:
> dateincycle -= MAR1900;
>
> /home/systems/wattsms/Source/sscs/ntp/libntp/humandate.c:33: sec =
> ntptime - JAN_1970;
>
> /home/systems/wattsms/Source/sscs/ntp/libntp/humandate.c:38:
> 1900+tm->tm_year, tm->tm_hour, tm->tm_min, tm->tm_sec);
>
> /home/systems/wattsms/Source/sscs/ntp/libntp/uglydate.c:28: sec =
> ts->l_ui - JAN_1970;
>
> /home/systems/wattsms/Source/sscs/ntp/libntp/uglydate.c:41: year
> = tm->tm_year;
>
> /home/systems/wattsms/Source/sscs/ntp/clockstuff/chutest.c:299:
> ts.l_ui += JAN_1970;
>
> /home/systems/wattsms/Source/sscs/ntp/clockstuff/chutest.c:341:
> ts.l_ui += JAN_1970;
>
> /home/systems/wattsms/Source/sscs/ntp/clockstuff/chutest.c:683: tmp
> = chuc->codetimes[i].tv_sec + JAN_1970;
>
> /home/systems/wattsms/Source/sscs/ntp/xntpdc/ntpdc.c:220:#define
> JAN_1970 2208988800 /* 1970 - 1900 in seconds */
>
> script done on Thu Mar 19 04:25:47 1998
Now if your program did a good job, I do not see any severe problem
for Y2K. Completely unrelated is the fact that several manufacturers
supply old versions like 3.4. These may have problems with Y2K...
Regards,
Ulrich
From: Wolfgang Rupprecht <wolfgang@dailyplanet.wsrcc.com> [-/+]
Date: 24 Mar 1998 13:05:09 -0800 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntp port [-/+]
X-Keywords: delay [-/+] dispersion [-/+] TCP [-/+] UDP [-/+]
wiu09524@rrzc4 (Ulrich Windl) writes:
> In article <6f69s0$34m6$1@mail1.wg.waii.com> Marc Brett <mbrett@rgs0.london.waii.com> writes:
> I thought UDP was chosen because
> 1) There is less packet processing delay (dispersion)
> 2) You don't need to keep up or re-establish persistent TCP connections
> 3) Less packets are exchanged
> 4) Less resources in a server are consumed (imagine serving a few hundred
> clients)
There is probably another more important reason; you really don't want
an ntp response to get out that just suffered a 3-second TCP
retransmit timeout. ;-)
Its much better to drop a delayed ntp packet then to send it out at a
much later time.
-wolfgang
From: "P. Allen Jensen" <Allen_Jensen-SC082C@email.mot.com>
Date: Tue, 24 Mar 1998 14:14:35 -0700 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntp port [-/+]
X-Keywords: delay [-/+] dispersion [-/+] TCP [-/+] UDP [-/+]
UDP is not "unreliable" - U is User - User Datagram Protocol - it's a datagram, meaning
that you do not have an "ack" - no connection, so no round-trip delay for the ack - besides,
you don't need the ack anyway - if you get the datagram - you have it all.....
The point about TCP is true - you don't know what errors do to the delay (how many
times did it send the packet....)
Also, most likely, the best thing to do with a bad NTP packet is to throw it away anyhow,
since "fixing" it (retransmission) makes no sense - so why use TCP.
Lots of reasons to NOT use a connection oriented protocol (note - connectionless = datagram,
connection = TCP in the above).
Ulrich Windl wrote:
> In article <6f69s0$34m6$1@mail1.wg.waii.com> Marc Brett <mbrett@rgs0.london.waii.com> writes:
>
> > tibor sujan <tibor@ku-trnava.sk> wrote:
> > > My proxy server can use only mapped links TCP port.
> > > Can I use xntpd with TCP port 123 ? How ?
> >
> > Nope. NTP must use an "unreliable" protocol: UDP. The reliability of
> > TCP means that incorrect packets get retransmitted, which introduces
> > unpredictable time delays. This means death for any time
> > synchronization product.
>
> I thought UDP was chosen because
>
> 1) There is less packet processing delay (dispersion)
> 2) You don't need to keep up or re-establish persistent TCP connections
> 3) Less packets are exchanged
> 4) Less resources in a server are consumed (imagine serving a few hundred
> clients)
>
> Ulrich
From: dalton@cup.hp.deletethis.com (David Dalton) [-/+]
Date: 25 Mar 1998 04:40:50 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntp4.0.72c and "Lost Sync" Messages?
X-Keywords: synchronized [-/+]
Mark Watts (mwatts@HiWAAY.net) wrote:
:> Why is stepping the clock considered a lost sync situation?
Because all of the buffers are cleared, and all data pertaining to any
synchronization is intentionally purged. This is the design of NTP.
How far away can you be and still consider yourself "synchronized"? For
NTP the answer is 128 milliseconds. Once you are outside this range, you
make a step AND clear the buffers and try to regain your senses.
--
-> My $.02 only Not an official statement from HP {They make me say that}
--
As far as we know, our computer has never had an undetected error.
---------------------------------------------------------------------------
David Dalton dalton@cup.hp.deletethis.com 408/447-3016
From: "Christopher Spry" <cspry@sghms.ac.uk>
Date: Wed, 25 Mar 1998 10:02:56 -0000 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Problem starting IRIX xntpd 3-5.92c
X-Keywords: SGI [-/+]
My little guide to installing 'xntpd' date/time services on a SGI Indy under
IRIX 6.2 is at
http://sprysgi.sghms.ac.uk/~cspry/computing/Indy_admin/xntpd_time.html
I hope there is something there to help you start xntpd 3-5.92c.
Best wishes,
From: dalton@cup.hp.deletethis.com (David Dalton) [-/+]
Date: 25 Mar 1998 22:44:51 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Stratum time accuracy numbers
X-Keywords: firewall [-/+]
Connect Computer (Brian.Teravskis@connects.com) wrote:
:>The company that I currently work at has a firewall that provides stratum3
:>ntp services. If I set up a time server off of the firewall I would be
:>starting my NTP network at stratum4 with core devices at stratum5 and
:>workstations at stratum6.
:>The supervisor of this group has asked me to give him a number of
:>approximate time variance between taking time from a stratum3 source versus
:>a stratum6 source. I cannot find any easy refence to these numbers.
:>Does anyone have an aproximate number of time variance as you cross a
:>stratum?
There is no fixed answer to this question. The timing accuracy depends on
the networking between the strata much more than the total number of
strata. For example, I could easily set up a stratum-10 source with 100
millisecond variance, and another stratum-4 source (with lousy networking)
with 200 milliseconds variance (both fed from the same stratum-1).
You can probably operate just fine with the firewall machine at stratum-3
and all your internal machines at stratum-4 with no problems. I wouldn't
bother setting up any more layers unless you have well over one thousand
clients or very complex topology. You do need to think about redundancy a
little bit...
If you really care about sub-200 millisecond variance (which I doubt), you
should buy a GPS receiver and set up your own stratum-1 server inside the
firewall. Better yet, but three for redundancy. That's what I do.
--
-> My $.02 only Not an official statement from HP {They make me say that}
--
As far as we know, our computer has never had an undetected error.
---------------------------------------------------------------------------
David Dalton dalton@cup.hp.deletethis.com 408/447-3016
From: Richard Curnow <richard@curnow.demon.co.uk> [-/+]
Date: 27 Mar 1998 07:22:15 +0000 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Why was UDP chosen over TCP? (was Re: xntp port)
X-Keywords: broadcast [-/+] delay [-/+] dispersion [-/+] RFC1305 [-/+] TCP [-/+] UDP [-/+]
>>>>> "Ulrich" == Ulrich Windl <wiu09524@rrzc4> writes:
>>
>> Nope. NTP must use an "unreliable" protocol: UDP. The
>> reliability of TCP means that incorrect packets get
>> retransmitted, which introduces unpredictable time delays.
>> This means death for any time synchronization product.
Ulrich> I thought UDP was chosen because
Ulrich> 1) There is less packet processing delay (dispersion) 2)
Ulrich> You don't need to keep up or re-establish persistent TCP
Ulrich> connections 3) Less packets are exchanged 4) Less
Ulrich> resources in a server are consumed (imagine serving a few
Ulrich> hundred clients)
In addition to 2) & 4), using persistent connections would mean each
client would take up a file descriptor in the server - a big resource
overhead plus the possibility of a nice denial of service attack.
If you reopen the TCP connection each time, you incur the overhead of
opening and closing the connection - I think at least 5 packets would
have to be sent instead of 2 for every client/server exchange.
[I've found an unrelated but similar problem even with UDP, if the NTP
traffic is all that passes between two machines on a LAN. At long NTP
sampling intervals, the interval becomes similar to the expiry period
on the ARP cache, thus client requests or server replies can incur an
ARP query round-trip before being sent. This puts a noticeable bias
on the measured offsets.]
To the list above I'd also add 5) - the broadcast modes of RFC1305
couldn't be implemented on top of TCP.
Richard
--
Richard P. Curnow
Stevenage, England
From: john.ackermann@daytonOH.ncr.com (John Ackermann) [-/+]
Date: Fri, 27 Mar 1998 22:11:20 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: GPS-20/25 and XNTPD HELP please
X-Keywords: configuration [-/+] FreeBSD [-/+] NMEA [-/+]
>Dave Bloodgood (dabldgd@pacbell.net) wrote:
>:>Im planning to connect my TAPR GPS-20/25 module to my FreeBSD system via the
>:>NMEA driver - Id really appreciate someone sending me their configuration
>:>files and any hints - to ease the process
I have info on configuring the TAPR TAC board with an Oncore receiver at my
web site, including a patched NMEA driver that gives much better performance
than the stock one. I'm not sure if it'll work with the GPS-20 (by the way,
the GPS-25 is a far better timing receiver than the -20), but you might want
to check it out: http://www.febo.com/ntp/
John Ackermann N8UR
jra@febo.com
From: Klaus Kusche <Klaus.Kusche@ooe.gv.at> [-/+]
Date: Mon, 30 Mar 1998 14:36:49 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntp is using to much memory on AIX 4.1.5
X-Keywords: AIX [-/+] monitoring [-/+]
Matt Millard wrote:
> I have recently tried to upgrade the version of ntp that we run on some of our
> R/S 6000 AIX 4.1.5 systems. I have run into a problem that after I run the
> configure, make and make install and run the xntpd demon that it uses an
> enormous amount of the system memory...shown below are two outputs from a
> monitoring utility that shows the top processes by CPU%. The top one is for
> xntp3-5_92d and shows only the xntpd using about 33300K of memory. While the
> lower shows the same system runing 3.4y(comes w/ AIX) and using only about
> 500k of memory. This difference is very detrimental to our system
> performance.
>
> Is there something that I'm doing when I do the configure,make,make install
> process that is causeing the demon to be build improperly? Has anyone else
> experienced this type of memory usage with AIX? Just a note I've tried
> ntp-4.0.70a, xntp3-5.92d, and xntp3.5f with similiar results.
The daemon is properly built.
The problem is known and has been discussed in this newsgroup.
On AIX, the syscall which is used by xntpd to lock its virtual memory
down in physical memory (unpageable) locks down the maximum size allowed
for that process by ulimit, not just the current size.
Starting xntpd with
( ulimit -s 128 ; /usr/local/bin/xntpd )
cures the problem.
--
DI. Dr. Klaus Kusche
Oberoesterreichische Landesregierung / Government of Upper Austria
Rechenzentrum / Computing Centre
Smail: Kaerntnerstrasse 16, A-4020 Linz, Austria (Europe)
Phone: +43 732 7720 - 3394 Fax: +43 732 7720 - 3198
Email: Klaus.Kusche@ooe.gv.at
From: Terje Mathisen <Terje.Mathisen@hda.hydro.com> [-/+]
Date: Tue, 31 Mar 1998 12:34:23 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP for Windows NT [-/+]
X-Keywords: MSF [-/+] Windows [-/+]
Alan Reid wrote:
>
> Is there a version of NTP available which will support the ARCRON MSF
> receiver under Windows NT?
The NT port does not support any ref clocks, not because it would be
impossible (rather the opposite), but most probably because serial port
interfacing is so dissimilar from Unix, that you would require a major
rewrite of the relevant interface code.
Do you volunteer to do the porting?
Terje
--
- <Terje.Mathisen@hda.hydro.com>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
From: Terje Mathisen <Terje.Mathisen@hda.hydro.com> [-/+]
Date: Wed, 01 Apr 1998 10:46:10 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: [++] Re: NTP: Automatic time/date propagation ? [-/+]
Rick Thomas wrote:
>
> The xntp program is designed to make sub-milisecond tweeks to a
> system's clock which is within a few hundred miliseconds (at most!) of
> the reference. When you change the date on the master, you violate
> that assumption.
>
> Gross adjustments of time need to be done with ntpdate.
>
> I realize this isn't what you wanted to hear, but that's the way it
> is.
NTP will indeed tweek the time if the offset error is withing +/- 128
ms, for larger offsets it gives up and just steps the time, up to a
maximum limit.
This max value is compiled in to avoid the situation where an ntp server
is going crazy, and all the clients would follow along.
The maximum time step that ntp will correct is a #define in the source
code, I believe it is 900 secs (15 mins).
Anyway, it should be possible to increase this to whatever you need,
which would then make it possible to step all systems to the new
reference time.
Terje
--
- <Terje.Mathisen@hda.hydro.com>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
From: Matuscak@Rohrer.com (Joe Matuscak) [-/+]
Date: Wed, 01 Apr 1998 15:01:38 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Can't get ntpdate to work from UNIX to NT
X-Keywords: delay [-/+] dispersion [-/+] filter [-/+] Tardis [-/+]
In article <01bd5caf$b7fbb300$af2f79c3@cl0563>, <bakkermX@centocor.com> wrote:
>reference time: 00000000.00000000 Thu, Feb 7 2036 7:28:16.000
>originate timestamp: b8cb77c6.e3d69000 Tue, Mar 31 1998 16:10:14.889
>transmit timestamp: b8cb78c4.0240d000 Tue, Mar 31 1998 16:14:28.008
>filter delay: 0.0349 0.0345 0.0345 0.0345
> 0.0000 0.0000 0.0000 0.0000
>filter offset: -253.121 -253.114 -253.116 -253.119
> 0.00000 0.00000 0.00000 0.00000
>delay 0.0345, dispersion 0.0033
>offset -253.1193404
>
>ntpdate: no server suitable for synchronization found
One thing that ntpdate does to check the sanity of the stuff coming back from
a server is to check that the reference timestamp is less than some delta time
(a day maybe?) of the other timestamps. In the case above,. the reference
timestamp is broke. By any chance is the server here TardisNT? Tardis was
not setting the reference timestamp correctly, which would cause this sort of
problem.
Joe Matuscak
Rohrer Corporation
717 Seville Road
Wadsworth OH 44281
330-335-1541
matuscak@rohrer.com
From: Casper.Dik@Holland.Sun.Com (Casper H.S. Dik - Network Security Engineer) [-/+]
Date: 2 Apr 1998 08:26:15 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntp seems to cause spontaneous rebooting
X-Keywords: adjtimex [-/+]
[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]
Leonard Evens <len@math.nwu.edu> writes:
>We have a Sun Ultra-2 server which is running SunOS 5.6. With xntp
>installed it seems to boot spontaneously several times a day. Has
>anyone else had this problem? Does anyone have any idea if it is more
>likely to be a software problem with the kernel or a hardware problem?
The kernel adjtimex code is broken when it was changed to support
a kernel settable hz value.
You'll see a "divide by 0" trap. This happens when the "constant"
value in the timex structure is > 6.
Bug id is #4095849
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
From: "Henk Uijterwaal (RIPE-NCC)" <henk@ripe.net> [-/+]
Date: Fri, 3 Apr 1998 10:24:33 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: kernel pll status change 1? [-/+]
On Thu, 2 Apr 1998, Michael St. Laurent wrote:
> I've seen two different lines in the xntpd log files that I don't
> understand. They are:
>
> 31 Mar 09:29:15 xntpd[20991]: kernel pll status change 89
> 31 Mar 10:03:23 xntpd[20991]: kernel pll status change 1
>
> Can anyone explain what these mean? This is from a Linux system
> (kernel 2.0.33).
Start by reading xntpd3-5.92/kernel/sys/timex.h, under status code.
Henk
------------------------------------------------------------------------------
Henk Uijterwaal Email: henk.uijterwaal@ripe.net
RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk
Singel 258 Phone: +31.20.535-4414, Fax -4445
1016 AB Amsterdam Home: +31.20.4195305
The Netherlands Pager: +6.57626855
------------------------------------------------------------------------------
%DCL-E-NOCFFE, unable to locate coffee - keyboard input suspended.
From: neufeld@caliban.physics.utoronto.ca (Christopher Neufeld)
Date: Fri, 3 Apr 1998 21:59:33 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Solution for annoying filtering routers (Linux)
X-Keywords: firewall [-/+] UDP [-/+]
For those of us living behind firewalls which refuse to pass incoming
UDP packets on port 123, I now have a working solution, assuming control
of at least one box outside of the firewall.
Requires:
- kernel support of transparent proxying on the NTP master which is on
the wrong side of the firewall, or udprelay to relay the packet to port
123. (I have not tested this with udprelay).
- root access to one machine outside of the firewall.
It does not require recompiling the xntpd sources, if xntpd is
dynamically linked against the C library.
The solution I have used is to create a dynamic link library which
wraps sendto(). It loads a database of IP numbers and ports which the
firewall allows to pass, and rewrites the destination of outgoing packets
which match a certain IP#/netmask pair to the appropriate port. The
receiver, inside the firewall, then uses transparent proxying or udprelay
to put the packet back onto UDP 123. Note that typically only the outside
machine has to rewrite packets, as filtering routers are quite happy to
let most outgoing traffic alone.
I can provide the source code for this kludge to anybody who wants,
and I'm also willing to configure my external stratum 3 NTP server to
send to the new port number of your choice, if you provide an IP and port
number of a machine similarly blocked by an annoying filtering router.
--
Christopher Neufeld - Not a graduate student neufeld@physics.utoronto.ca
Home page: http://caliban.physics.utoronto.ca/neufeld/Intro.html
"Don't edit reality for the sake of simplicity"
From: Richard Curnow <richard@curnow.demon.co.uk> [-/+]
Date: 04 Apr 1998 09:21:53 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: xntpd on dial-up connections (was Re: Simple NTP client) [-/+]
X-Keywords: adjustment [-/+] dial [-/+]
>>>>> "Henk" == Henk Uijterwaal (RIPE-NCC) <henk@ripe.net> writes:
Henk> But... why run it only once a day? The nice thing about NTP
Henk> is that you can simply turn on the xntpd deamon and
Henk> continously let it synchronize your clock as long as your
Henk> machine is on the network. The amount of CPU and memory
Henk> used is so small that you won't even notice it.
Henk> This even works with a dial-up line. At home, the startup
Henk> script turns xntpd on when the machine is booted. When I
Henk> dial out (over PPP), xntpd recognizes this, starts syncing
Henk> the clock until the connection is switched off, then sleeps
Henk> until I dial out again.
But does the machine clock stay reasonably accurate when the network
link is removed? Suppose the machine clock was found to be slow
whilst you were online. Then (as I understand it) xntpd would
increase the frequency so as to gradually pull in the offset. If the
network connection is removed before the pull-in process is complete,
the frequency will be left higher than normal when you disconnect. In
all likelihood this will overshoot true time, leaving your machine
clock significantly fast when you next connect.
Then, the same thing will happen in reverse, as the frequency
adjustment is reversed to pull in the opposite sign of offset to the
first time. Or worse, the machine clock may be stepped (backwards),
and xntpd will take a while to lock the frequency again.
For dial-up links, I think you need a method that looks at the long
term drift of the machine clock (by using readings obtained on
separate dial-up sessions, if necessary). This long term drift
estimate is used to control the machine clock during the disconnected
periods.
Regards,
Richard
--
Richard P. Curnow
Stevenage, England
From: "Henk Uijterwaal (RIPE-NCC)" <henk@ripe.net> [-/+]
Date: Mon, 6 Apr 1998 16:13:41 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntpd on dial-up connections (was Re: Simple NTP client) [-/+]
X-Keywords: dial [-/+] reset [-/+]
On 4 Apr 1998, Richard Curnow wrote:
> >>>>> "Henk" == Henk Uijterwaal (RIPE-NCC) <henk@ripe.net> writes:
>
> Henk> But... why run it only once a day? The nice thing about NTP
> Henk> is that you can simply turn on the xntpd deamon and
> Henk> continously let it synchronize your clock as long as your
> Henk> machine is on the network. The amount of CPU and memory
> Henk> used is so small that you won't even notice it.
>
> Henk> This even works with a dial-up line. At home, the startup
> Henk> script turns xntpd on when the machine is booted. When I
> Henk> dial out (over PPP), xntpd recognizes this, starts syncing
> Henk> the clock until the connection is switched off, then sleeps
> Henk> until I dial out again.
>
> But does the machine clock stay reasonably accurate when the network
> link is removed? Suppose the machine clock was found to be slow
> whilst you were online. Then (as I understand it) xntpd would
> increase the frequency so as to gradually pull in the offset. If the
> network connection is removed before the pull-in process is complete,
> the frequency will be left higher than normal when you disconnect. In
> all likelihood this will overshoot true time, leaving your machine
> clock significantly fast when you next connect.
In theory, you are right, in practice, it turns out fine. This is a home
machine where I want to keep the clock to approximately the right value
without having to worry about it. There are no applications running on
the machine which could be affected by a time-reset.
My usage pattern is such that the network connection is active a couple of
times a week for a few hours. Between logins, the clock drifts like
0.1..0.3 seconds away and while logged in, NTP can easily correct that and
leave the internal clock running at approximately the right speed. Only
when I have been away for more than a couple of days, NTP has to do a
time-reset in order to get the clock to the right value, then needs 15..30
minutes to get the machine in sync.
Henk
------------------------------------------------------------------------------
Henk Uijterwaal Email: henk.uijterwaal@ripe.net
RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk
Singel 258 Phone: +31.20.535-4414, Fax -4445
1016 AB Amsterdam Home: +31.20.4195305
The Netherlands Pager: +6.57626855
------------------------------------------------------------------------------
%DCL-E-NOCFFE, unable to locate coffee - keyboard input suspended.
From: Marc Brett <mbrett@rgs0.london.waii.com> [-/+]
Date: 5 Apr 1998 11:40:06 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: time zones
X-Keywords: AIX [-/+] daylight [-/+]
Jens Erik Taasen <jet@ntb.no> wrote:
> Some days ago Hans Mayer posted a problem concerning time zones.
> I have exactly the same problem myself and, although it seems simple,
> I'm not able to figure it out.
> We're running on AIX 4.2.1 with the xntp that follows the OS.
> The problem appeared when the clock was adjusted for daylight savings
> time.
> Our TZ is NFT-1NFT.
I assume that the problem machine is in Norway. Your TZ variable uses
the default (US) switchover dates for daylight savings time (02:00
first Sunday in April, 02:00 last Sunday in October). You should be
using Norwegian (EU) rules. (01:00 GMT last Sunday in March, 01:00 GMT
last Sunday in October).
Probably something like:
TZ=NFT-1NDT,M3.5.0/02:00:00,M10.5.0/03:00:00
The machine will have to be rebooted for the changes to take effect.
(Of course, now that the US has switched over, the problem will be
(almost) invisible until this time next year.)
--
Marc Brett +44 181 560 3160 Western Geophysical
Marc.Brett@waii.com 455 London Road, Isleworth
FAX: +44 181 847 5711 Middlesex TW7 5AB UK