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

Previous part

From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]Date: 15 Apr 1997 14:49:22 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: What am I missing??? [-/+]X-Keywords: ACTS [-/+] auth [-/+] delay [-/+] dialup [-/+] driftfile [-/+] firewall [-/+] fudge [-/+] prefer [-/+] release [-/+] restrict [-/+] SGI [-/+] syslog [-/+]

Chip Burwell (chip@heffer.rtassoc.com) wrote: : I'm trying to get ntp working on an SGI Indy running Irix5.3. I : successfully compiled and installed release 5.89. I created an : ntp.conf file with the following entries:

: # /etc/ntp.conf (for xntpd) : # ..expecting to run at stratum 2

: server ntp.ucsd.edu prefer : server clepsydra.dec.com : server clock.psu.edu : server delphi.cs.ucla.edu : server heechee.esa.lanl.gov : server time.ucla.edu

: #----- Drift history

: # Save drift information in a file so NTP converges more quickly : # the next time it runs. : driftfile /etc/ntp.drift

: I rebooted my machine, (although I don't think that was neccessary). : When I run ntpq it appears that I am running the ntp daemon, but : that it is not successfully connecting to any of the servers. The : following is the print out from an ntpq session:

[SNIP lines showing a daemon without outside contact]

: I don't have a clue what most of this means, but I'm hoping : that someone out there in net land does, and can spot what : might be wrong with my settup. If I can provide any more info, : please just ask.

: Thanks for any help you can provide.

Howdy, First of all I need to warn you about my LACK of guru-ness in xntp or SGI. I've been running xntp on sparc-Solaris 2.5 for over a year and have been following the newsgroup. I helped a gal fire up xntp on her SGI server and it cooked, once the (perhaps) default timed was removed.

1) Avoid xntp versions 3-5.86 through 3-5.89.7. Before fighting with old bugs, rebuild with the new software ftp://ftp.udel.edu/pub/ntp/xntp3-5.90.tar.gz which, I'm told, has some new stuff for SGI sometime about 89.3. I'm currently on 3-5.89.8 and that is what I saw work on the SGI.

2) If you are a newbie, start slowly and learn the tools. You can make your host declare its own time as a reference (eyeball and wrist-watch-ish) by having an ntp.conf server 127.127.1.0 # local refclock fallback fudge 127.127.1.0 stratum 10 # show poor quality Then you can watch it synch and then answer time packets.

Read your syslog.

3) Play with "ntpdate -d <server>" and watch the packets go. If they don't come back, try "ntptrace <server>". If these work, but "ntpdate <server>" on your host NOT running xntpd at the moment fails with "no servers found", suspect that a firewall near you is blocking your outbound or inbound packets. Send me private email and I can check to see if you are able to reach me. Most of the firewall problems have to do with filters blocking outside packets from privledged ports coming in to inside privledged ports. Solutions range from adjusting the firewall, getting your own radio/GPS clock, using dialup ACTS, or giving up.

4) Avoid banging on the public stratum 1 servers unless you have received permission, since they are busy. See http://www.eecis.udel.edu/~mills/ntp/servers.html

5) Avoid using fancy parts of NTP until you have the simple stuff working. This includes auth, -cast, restrict. Once you have it running, add these in slowly. It is very easy to restrict the responses from your configured servers by "restrict default notrust nomodify" without having each server in its own "restrict <server> nomodify" line. -casting also is a bit complicated, with the keys and trustedkeys...

6) Select your outside servers based on ntpdate or xntpd measured delay time, not physical distance. The internet has some strange lack of connections.

7) I prefer to keep the files in /usr/local/etc and /usr/local/bin since reloading the OS or reving cleans much of /etc.

8) While "prefer" isn't bad, I'd avoid it until I had a working system, and would then add it only if I had serious sync hopping. Occasional bursts of sync changes triggered by network delay are just xntpd working.

(Sorry to preach if you already know all of this!)

>From you evidence, if it came from xntp3-5.89.8 or later, I'd say you were behind a firewall that was blocking any answers. >From 3-5.89, it might be the same answer or it might be one of the troubles in the "dark times".

Happy chiming

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

From: wiu09524@rrzc4 (Ulrich Windl) [-/+]Date: 17 Apr 1997 06:54:59 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: What am I missing??? [-/+]X-Keywords: firewall [-/+]

In article <5j0pqp$4kc@hpindda.cup.hp.com> dalton@cup.hp.com (David Dalton) writes:

> Try running ntpdate with the debug option to see lots of detailed info: > > ntpdate -d newcs.UCSD.EDU clepsydra.DEC.com > > but be aware that "ntpdate -d" uses the unprivileged port and can go > through a firewall, while xntpd cannot do that.

Oops! I did not recognize that yet. Shouldn't "-d" use the very same port than without, just not set or slew the time?

Ulrich P.S. The feature above seems to cause a LOT of confusion, and does not help debugging very much. Maybe the priviledged port should always be used if the (effective?) user is root.

From: roger.foss@oslo.teamco.telenor.no (Roger Foss) [-/+]Date: 15 Apr 1997 17:55:53 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: ntp for Novell Netware 4.x? [-/+]X-Keywords: adjustment [-/+] dial [-/+] dialup [-/+] firewall [-/+] GNU [-/+] NIST [-/+] Novell [-/+] SNTP [-/+] Windows [-/+]

In article <5ii0co$qs$1@caldera.com>, jfree@caldera.com says... > >In article <01bc3932$31ae8440$0100a8c0@chjo2-pc.tdata.no>, >Christer Johansen <christer@sn.no> wrote: >... >>What I would like is a xntpd for Novell Netware 4.x. That way our master >>Netware time server could synchronize to the Unix master time server and >>our whole network would be in sync. Does anyone know of such a product >>(commercial or freeware, it doesn't really matter) ? > >xntp source + GNU binutils/nlmconv ==> xntp NLM ? >-- >Jim Freeman >jfree@caldera.com

Here are a couple of products:

Polygon Inc makes Cadence Time Synchronization for Netware, at http://www.polygon.com/ It is a full-featured product that can dial via modem into NIST, or use NTP etc. Calculates server's slack and will adjust how often it contacts the time server. Cadence can also work as a time *server*, you'll load a cadence client on DOS, Win31x, or 32-bit Windows. The dialin option is nice if your servers are behind a firewall, and you still want the accuracy of an atomic time source. A version I tested was somewhat buggy, but that's supposed to be fixed now..

A. Schild makes SNTP Client for Netware. It's beta and will last two months. The final version will either be donorware or shareware (about 20$). It is simple, command line and only works on NTP (no dialup access). It does seem to work, though. Also, it has an odd feature: it can contact multiple time sources and calculate an average. I guess if 2 time sources are 0.00000003 secs part, it can average this to 0.000000015 secs? Beats me.. Anyway, for the asking price it might be ok? Find it at http://www.neatech.ch/sntpclnt/

A warning: I'm guessing that RDATE.NLM for Netware 3.1x SHOULD NOT be used on Netware 4.x. Although it might run, there's the potential that it could adjust the time *backwards*. With Novell Directory Services - the replicated, loosely consistent and distributed object database, this is a bad thing.

In Netware 3.1x, you'd do a manual time adjustment by setting the server clock on the console with the TIME command. Now ASSUMING that RDATE.NLM uses an API call that does just that - set's a new time, you could have trouble.

With Netware 4.x and NDS, the correct thing to do is do a relative time *adjustment*. Manually, you'd type SET TIMESYNC TIME ADJUSTMENT +00.00.03 AT 16/4/1997 14.00.00 or something similar. The server would then make an adjustment in NDS and convey this to the other NW4.x servers it is talking to.

Again, I'm just assuming this. I just can't imagine that the old NW3.x API calls would do a relative time adjustment...

-- Roger ----------------------------------------------------- Roger Foss, Telenor Bedrift, Division IT-Service Work +47 2313 7249 / Fax 2264 6177 / Pager 965 01 152 E-mail Roger.Foss@oslo.teamco.telenor.no --"Mistake: bridge between inexperience and wisdom"--

Here are a couple of products:

Again, I'm just assuming this. I just can't imagine that the old NW3.x API calls would do a relative time adjustment...

From: dmitchel@kittiwake.sea.adobe.com (David Mitchell) Date: 16 Apr 1997 15:39:16 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: ntp for Novell Netware 4.x? [-/+]X-Keywords: Novell [-/+]

In article <01bc3932$31ae8440$0100a8c0@chjo2-pc.tdata.no>, Christer Johansen <christer@sn.no> wrote: ... >What I would like is a xntpd for Novell Netware 4.x. That way our master >Netware time server could synchronize to the Unix master time server and >our whole network would be in sync. Does anyone know of such a product >(commercial or freeware, it doesn't really matter) ?

William Clark and Associates (http://www.wclark.com) makes a dandy GPS-driven clock with a NetWare 4.1x driver. We've been using it for over a year and are quite satisfied with it.

.david. -- David Mitchell <david.mitchell@adobe.com> | <davidm@bosia.org> Adobe Systems Incorporated | Bainbridge Ometepe Sister Islands Association Fair-traded, Shade-grown, Certified Organic Coffee at http://www.bosia.org

From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]Date: 16 Apr 1997 14:52:50 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: large jumps ??? [-/+]X-Keywords: ACTS [-/+] delay [-/+] dial [-/+] peer [-/+] reset [-/+]

Mark Thomas (mark@Misty.com) wrote: : On several SunOS-4.1.4 hosts running xntp3.5f, my system logs show : what look to me like fairly large "time reset (step)" messages.

: Is this normal, or does this indicate a problem?

: Apr 14 09:57:47 marksys xntpd[2786]: time reset (step) -0.138350 s : Apr 14 10:05:08 leopard xntpd[185]: time reset (step) -0.144241 s : Apr 14 10:10:07 leopard xntpd[185]: time reset (step) 0.154180 s : Apr 14 11:55:18 marksys xntpd[2786]: time reset (step) -0.147544 s : Apr 14 12:12:05 leopard xntpd[185]: time reset (step) -0.206461 s : Apr 14 12:16:49 leopard xntpd[185]: time reset (step) 0.225644 s : Apr 14 12:21:25 leopard xntpd[185]: time reset (step) -0.143447 s : Apr 14 13:35:34 tiger xntpd[19370]: time reset (step) -0.234378 s : Apr 14 13:40:31 marksys xntpd[2786]: time reset (step) -0.289238 s : Apr 14 16:00:42 tiger xntpd[19370]: time reset (step) 0.148951 s : Apr 14 17:46:28 marksys xntpd[2786]: time reset (step) -0.146926 s : Apr 14 17:49:23 tiger xntpd[19370]: time reset (step) -0.175249 s : Apr 14 17:51:27 marksys xntpd[2786]: time reset (step) 0.131291 s : Apr 14 18:55:04 tiger xntpd[19370]: time reset (step) -0.243671 s : Apr 14 19:37:24 tiger xntpd[19370]: time reset (step) -0.411072 s : Apr 14 23:34:38 tiger xntpd[19370]: time reset (step) 0.129574 s : Apr 15 14:13:31 tiger xntpd[19370]: time reset (step) -0.138663 s : Apr 15 19:34:22 marksys xntpd[2786]: time reset (step) -0.136842 s

: On all the hosts I did a "tickadj -s -A" before starting xntpd.

: The ntp.drift files are:

: marksys: -27.276 0 : tiger: 61.380 0 : leopard: 2.643 0

Howdy, Without knowing how the various hosts lie in the NTP sub-net, I'm guessing that you have a problem, possibly excessive network delays or some other process screwing with the clock.

On my systems, the sum of my steps has usually been near zero. When gross network delay knocked me for a step, there was usually a corresponding anti-step of nearly the same size when things cleared up.

It is possible that your "anti-steps" were just small enough to be done as slews, so this might just be an overloaded network segment causing excess delays that skew the xntpd measured time. The threshold for a step, and therefore the message, is 0.128 seconds (CLOCK_MAX_I). Your troubles aren't much larger than this.

leopard does show such +- steps, but marksys has 6 steps - about 1/8 second steps and only one positive step. tiger two + and 5 - and sums about 2/3 seconds off.

To probe further, I turned on the loop and peer stats and watched the details for a while. The newer raw stats gives an even more detailed report of each probe and response. I found that a T1 line near me was saturated for several hours several times a day and some packets were seeing 0.2 second delays in one direction. When the 2nd T1 sent in service, the problems got better, but were still present. Eventually a stratum 1 available over an existing FDDI link has come to the rescue and that is now the primary reference.

I think that the "easy solution" for network delay caused NTP trouble is your own radio clock, ACTS dial or other reference. If your goals are modest and you just want your hosts to keep mostly good time, but the steps cause problems, there are compile switches to "always slew" and smear the steps out.

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

From: dalton@cup.hp.com (David Dalton) [-/+]Date: 18 Apr 1997 19:00:28 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: large jumps ??? [-/+]X-Keywords: delay [-/+] dispersion [-/+] poll [-/+] reset [-/+] synchronized [-/+] WWVB [-/+]

: Mark Thomas (mark@Misty.com) wrote: : : On several SunOS-4.1.4 hosts running xntp3.5f, my system logs show : : what look to me like fairly large "time reset (step)" messages.

: : Is this normal, or does this indicate a problem?

: : Apr 14 09:57:47 marksys xntpd[2786]: time reset (step) -0.138350 s : : Apr 14 10:05:08 leopard xntpd[185]: time reset (step) -0.144241 s : : Apr 14 10:10:07 leopard xntpd[185]: time reset (step) 0.154180 s : : Apr 14 11:55:18 marksys xntpd[2786]: time reset (step) -0.147544 s : : Apr 14 12:12:05 leopard xntpd[185]: time reset (step) -0.206461 s : : Apr 14 12:16:49 leopard xntpd[185]: time reset (step) 0.225644 s : : Apr 14 12:21:25 leopard xntpd[185]: time reset (step) -0.143447 s : : Apr 14 13:35:34 tiger xntpd[19370]: time reset (step) -0.234378 s : : Apr 14 13:40:31 marksys xntpd[2786]: time reset (step) -0.289238 s : : Apr 14 16:00:42 tiger xntpd[19370]: time reset (step) 0.148951 s : : Apr 14 17:46:28 marksys xntpd[2786]: time reset (step) -0.146926 s : : Apr 14 17:49:23 tiger xntpd[19370]: time reset (step) -0.175249 s : : Apr 14 17:51:27 marksys xntpd[2786]: time reset (step) 0.131291 s : : Apr 14 18:55:04 tiger xntpd[19370]: time reset (step) -0.243671 s : : Apr 14 19:37:24 tiger xntpd[19370]: time reset (step) -0.411072 s : : Apr 14 23:34:38 tiger xntpd[19370]: time reset (step) 0.129574 s : : Apr 15 14:13:31 tiger xntpd[19370]: time reset (step) -0.138663 s : : Apr 15 19:34:22 marksys xntpd[2786]: time reset (step) -0.136842 s

This looks like a problem with network delays. Run "ntpq -p" and look at the last column, "dispersion". Run it every 30 minutes with a cron job and see how the dispersion varies during the day. Whenever your dispersion approaches the 128ms threshold for a step you are headed for trouble.

-> My $.02 only. Not an official statement from HP. -- As far as we know, our computer has never had an undetected error. --------------------------------------------------------------------------- David Dalton dalton@cup.hp.com 408/447-3016

disp DISPERSION smaller is better ----

How repeatable is the "delay" measurement? This is very similar to the standard deviation of many "delay" measurements in a row. When this number exceeds 100 (milliseconds) it is very difficult for the daemon to keep the clock synchronized.

This "dispersion" number is a primary measure of network service quality. A slow X25 network not only has a sizeable round trip time, but the round trip time varies a lot from one query to the next. This is very bad for timekeeping purposes, because it makes the "offset" very hard to calculate. The real job of NTP is to manage the "offset" value and minimize it.

EXAMPLE: A system with problems

This machine make step adjustments all the time because the round-trip time of a network packet is highly variable. In this case the network is X.25, a very poor choice for time synchronization.

ntpq> peers remote refid st t when poll reach delay offset disp ============================================================================== XX_XXX 150.50.55.55 2 u 3 512 17 312.87 -249.15 1960.85

EXAMPLE: A system with good ethernet connections and a reference clock

Although some of the delays are high (systems are 5000km apart), the dispersion numbers are pretty good. Low dispersion is necessary for low offset.

ntpq> peers remote refid st t when poll reach delay offset disp ============================================================================== *WWVB_SPEC(1) .WWVB. 0 l 124 64 377 0.00 -0.234 2.01 relay.hp.com listo.hp.com 2 u 875 1024 377 13.84 4.912 4.88 cosl4.cup.hp.co listo.hp.com 2 u 876 1024 377 4.38 -4.468 3.95 paloalto.cns.hp listo.hp.com 2 u 885 1024 377 5.84 0.762 2.18 chelmsford.cns. listo.hp.com 2 u 883 1024 377 89.45 2.160 11.40 atlanta.cns.hp. listo.hp.com 2 u 881 1024 377 63.20 -2.545 0.99 colorado.cns.hp listo.hp.com 2 u 883 1024 377 38.71 -1.110 2.01 boise.cns.hp.co listo.hp.com 2 u 875 1024 377 32.88 -2.015 2.23

From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]Date: 19 Apr 1997 14:14:09 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: Beginner - HELP with local-clock X-Keywords: auth [-/+] FAQ [-/+] firewall [-/+] fudge [-/+] peer [-/+] poll [-/+] prefer [-/+] restrict [-/+] trustedkey [-/+]

Cathy Morison (cathy_morison@mailhost.dpie.gov.au) wrote: : I have read the FAQ and didn't find what I wanted, but maybe that is : because I am looking for the wrong thing (or maybe I just don't know : what I am looking for!)

: We have a system set up that is synchronishing with several Stratum 2 : servers. We then have a hierarchy of internal boxes synchronising with : this box through our firewall. At Stratum 6 the hierarchy fans out and : all our remaining internal boxes (20 or so) synchronise with this one : Stratum 6 box. This box only has access to our Stratum 5 box (which in : turn only has access to our Stratum 4 box, which only has access to our : Stratum 3 box which talks to the external servers mentions above). : Confused?

: Anyway, if for some reason our firewall is not passing time, or one of : these higher Strata boxes fails, we still want our Stratum 6 box to : supply a reasonable time to the other boxes. I have put the lines in : our config which read:

: server xx.x.x.x prefer #(this is our stratum 5 box) : local-clock stratum 10

: Am I barking up the wrong tree or is this how I configure a system to : use its internal clock if the other server(s) is not available?

: As an aside, I don't seem to get any error messages on these systems. : AM I lucky, or am I not looking in the right places. Where would I find : error messages if they existed?

: Looking forward to your help (please!),

: Cathy Morison : Corporate Operations Section : Information Management and Services Branch : DPIE

-----

Howdy, First, my "credentials", consisting mostly of denials of any trustworthyness. I've been running a few hosts with xntp for over a year. (Perhaps my memory is weak, it might be longer.) xntp3.4r through 3-5.89.8 on sparc-Solaris 2.4 and 2.5. I'm certainly no "guru", but I do read the source code when confused (freqeuntly).

Second, avoid versions 3-5.86 through 3-5.89.7. There are nasty bugs. The current version ftp://ftp.udel.edu/pub/ntp/xntp3-5.90.tar.gz is the best choice, although there have been discussions about an integer second error that might effect this and other recent versions in the newsgroup. I don't understand the details and it seems to only effect a fraction of hosts. I've been on ftp://ftp.udel.edu/pub/ntp/testing/xntp3-5.89.8.tar.gz for a couple of months without trouble (but I haven't abused it to see if troubles appear).

I wonder if your setup is more complicated than you really need. Most ntp systems I have the pleasure of meeting have 3 or 4 stratums from the top to bottom. Since handling a client poll on my wimpy sparClassic takes only a few milliseconds, supporting 100 clients (without -casting) would only take 2 ms/poll * 100 clients * (1 poll/64 sec/client) = 3 ms / sec Most of the time, the clients will be polling much slower than 2^6 seconds/poll.

I also suggest that simple ntp.conf are best at the beginning. Add complications after the pieces are working and the tools are familiar. Auth, -cast and restrict are best left until after your system is up and running well in client/server mode. It is very easy to prevent your time packets from being received by restrict default notrust without realizing that this requires that all the servers need restrict lines to let them in. -casting allows lots of low accuracy clients with very little overhead, but it usually involves auth, keyfiles and trustedkey details.

Now to your question. My answer is based on xntp3.4y or later. Sometime before then the format for the refclock numbers was different and the "fudge" of stratum was handled in the "unit #". Declaring a local refclock: server 127.127.1.0 # local refclock fallback fudge 127.127.1.0 stratum 10 # show poor stratum The "127.127" shows the server line refers to a refclock. The type of refclock is ".1.". The final "0" is the refclock unit number. So you don't use any real xx.xx.xx.xx IP#.

The prefer keyword is loaded with special meanings. Unless you really mean it, I suggest that you not include it. I think that a section of code in .../xntpd/ntp_loopfilter.c doesn't make the adjtime() system call to correct for system drift if the local refclock is flagged with "prefer" and is the controlling sync peer. You probably want the continued drift correction. This "little wrinkle" is designed to keep ntp's hands off adjtime() when the host's clock is being controlled by some other disipline. This detail might even cause you to add a level to your stratum count.

Hope this helps.

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

From: nmm1@cus.cam.ac.uk (Nick Maclaren) [-/+]Date: 22 Apr 1997 12:06:28 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: Generic Config [-/+]X-Keywords: implementation [-/+] Mills [-/+] precision [-/+] RFC [-/+] SNTP [-/+] specification [-/+] stability [-/+]

In article <WIU09524.97Apr22132618@rrzc4>, wiu09524@rrzc4 (Ulrich Windl) writes: |> |> First excuse that my RFC horizon is at about RFC1900. Then I knew that |> any NTP server can server SNTP clients, because these clients just |> ignore most of the data received. A SNTP server (the thing I don't |> know), if it serves SNTP clients, should also serve NTP clients unless |> it uses a different protocol. But if it uses that different protocol, |> the SNTP clients could use only SNTP servers.

The relevant RFCs are 1305 (NTP) and 2030 (SNTP) - 2030 supersedes 1769, but the differences are minimal so you can use 1769 for SNTP.

Unfortunately, there is NO specification of the NTP protocol, anywhere. RFC 1305 is a description of the reference implementation, and you have to deduce the protocol by reading between the lines and/or asking David Mills.

The client-side of SNTP is really just a description of some common synchronisation methods that have been used since time immemorial, applied to NTP. You don't HAVE to be as crude as the RFC implies, though you can be.

The server-side of SNTP is really just a description of short cuts that you could take in a dedicated stratum 1 time-server. If it were used at another level, it should be described differently.

|> And I see a big danger that some SNTP servers could be uses a "normal" |> NTP servers, but with less precision. Maybe someone can explain...

No, that is not the danger. The first danger is that RFC 2030 does not require the error estimates to be set correctly, but that is a fairly minor problem and could be fixed easily enough.

The main danger is that the conventional time synchronisation model gets its stability from the fact that the information flow forms a directed acyclic graph. NTP relies on cycles, and its stability comes from entirely different properties. You absolutely MUST NOT mix these!

Hence it is safe to have a SNTP sub-network, provided that it does not BOTH import and export times to a NTP network, and that any exporting provides appropriate NTP information. But it is LETHAL to both networks to have any cycle (however intermittent) that includes both types of segment.

As RFC 2030 is currently written, I don't advise anyone to get involved with a SNTP server. My SNTP server code does its damnedest to ensure that no 'real' NTP client will trust the timestamps it provides :-)

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: hpa@transmeta.com (H. Peter Anvin) [-/+]Date: 23 Apr 1997 00:12:57 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: Generic Config [-/+]X-Keywords: Linux [-/+] precision [-/+] RFC [-/+] SNTP [-/+]

Followup to: <WIU09524.97Apr22132618@rrzc4> By author: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> In newsgroup: comp.protocols.time.ntp > > First excuse that my RFC horizon is at about RFC1900. Then I knew that > any NTP server can server SNTP clients, because these clients just > ignore most of the data received. A SNTP server (the thing I don't > know), if it serves SNTP clients, should also serve NTP clients unless > it uses a different protocol. But if it uses that different protocol, > the SNTP clients could use only SNTP servers. > > And I see a big danger that some SNTP servers could be uses a "normal" > NTP servers, but with less precision. Maybe someone can explain... >

Okay... I drug out my copy of RFC 1769 and it states an SNTP *server* is one which makes no attempt to check the quality of its transmissions against other servers:

The model for a SNTP server operating with either a NTP or SNTP client is an RPC server with no persistent state. Since a SNTP server ordinarily does not implement the full set of NTP algorithms intended to support redundant peers and diverse network paths, it is recommended that a SNTP server be operated only in conjunction with a source of external synchronization, such as a reliable radio clock. In this case the server always operates at stratum 1.

It seems to me that the difference between SNTP and NTP is that SNTP operates in a strictly unidirectional, no-questions-asked mode: an SNTP server receives time data via some "higher source" (that is unquestionable compared with anything on the network) and only forwards it blindly. A radio or atomic clock could incorporate an SNTP server as a standardized way to transmit time signals onto a TCP/IP network -- there is (presumably) no way the radio clock would ever have reason to believe its signals from the air were less than accurate.

Note: this is, indeed, in contradiction with my previous understanding (I presumed an SNTP server would be unable to serve full NTP clients, but that is apparently not the case.)

Similarly, an SNTP client is one which receives time from a server, but makes no independent assessment as to the quality of the data.

-hpa -- Always looking for a few good BOsFH. ** Linux - the OS of global cooperation I am Bah�'� -- ask me about it or see http://www.bahai.org/

From: kees@echelon.nl (Kees Hendrikse) [-/+]Date: Sat, 19 Apr 1997 16:14:43 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: SCO Open Server 5 X-Keywords: Meinberg [-/+] SCO [-/+]

In <5j7a70$pkh$1@news02.btx.dtag.de> Meinberg Funkuhren writes:

> Can anybody tell me whether XNTP runs on SCO Open Server 5 ?

Yes, it does. Get a copy of xntp 3.5.90, which contains SCO specific patches. Also see article <E8B98D.99w@echelon.nl>, posted to this group on Tue Apr 8, for further instructions.

As an additional note: compile with maximum optimalization (-O3 -K pentium) and run xntpd with a low nice-value (nice --15) for best results.

-- Kees Hendrikse | email: kees@echelon.nl | ECHELON consultancy and software development | phone: +31 (0)53 48 36 585 PO Box 545, 7500AM Enschede, The Netherlands | fax: +31 (0)53 43 37 415

From: sean@ugcs.caltech.edu (M. Sean Bennett) Date: 22 Apr 1997 16:48:34 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: Solaris 2.5.1 ntp source [-/+]X-Keywords: cpu_tick_freq [-/+]

Please note that all ultra systems must run 2.5/2.5.1

If anyone has a good soloution to this please E-mail me.

> Bug Id: 4023118 > Category: kernel > Subcategory: other > State: integrated > Synopsis: sun4u doesn't keep accurate time > Description: > > [ bmc, 12/20/96 ] > > The clock on a sun4u drifts unacceptably. On a typical 143 mHz Ultra, > the clock took 1.0001350 seconds to count 1 second. While this may seem > trivial, it adds up quickly. In this case, the TOD chip will have to > pull the clock forward by 2 seconds every 4 hours and 7 minutes. > This drift rate is so high, that the clock is close to being too broken > for NTP to guarantee correctness (in order for NTP's mechanism to work, > it must be assured that the local clock drifts no more than 20 ms in 64 > seconds; this particular 143 mHz Ultra will drift by nearly 9 ms in that > period). This problem has been reproduced on virtually all sun4u > classes. > > The fundamental problem lies in the kernel's perception of ticks per > second. The PROM is responsible for determining this figure exactly, > and the kernel extracts it into the variable cpu_tick_freq. On sun4u's, > this number is disconcertingly round: 143000000, 167000000, 248000000, > etc. Indeed, a simple experiment revealed that these numbers were > quite far from the actual ticks per second. Typical was the 143 mHz > Ultra which was discovered to tick around 142,980,806 (+/- 10) times > per second. > <h3>Work around:</h3> > > Integrated in releases: s297_27 > Duplicate of: > Patch id: > See also: > Summary: >

From: bmc@kiowa.eng.sun.com (Bryan Cantrill) [-/+]Date: 23 Apr 1997 11:51:45 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: Solaris 2.5.1 ntp source [-/+]X-Keywords: bug [-/+] cpu_tick_freq [-/+] dosynctodr [-/+] nsec_per_tick [-/+]

In article <5jiq52$5ah@gap.cco.caltech.edu>, M. Sean Bennett <sean@ugcs.caltech.edu> wrote: > > >Please note that all ultra systems must run 2.5/2.5.1 > >If anyone has a good soloution to this please E-mail me. > >> Bug Id: 4023118 >> Category: kernel >> Subcategory: other >> State: integrated >> Synopsis: sun4u doesn't keep accurate time >> Description: >> >> [ bmc, 12/20/96 ] >> >> The clock on a sun4u drifts unacceptably. On a typical 143 mHz Ultra, >> the clock took 1.0001350 seconds to count 1 second. While this may seem >> trivial, it adds up quickly. In this case, the TOD chip will have to >> pull the clock forward by 2 seconds every 4 hours and 7 minutes. >> This drift rate is so high, that the clock is close to being too broken >> for NTP to guarantee correctness (in order for NTP's mechanism to work, >> it must be assured that the local clock drifts no more than 20 ms in 64 >> seconds; this particular 143 mHz Ultra will drift by nearly 9 ms in that >> period). This problem has been reproduced on virtually all sun4u >> classes. >> >> The fundamental problem lies in the kernel's perception of ticks per >> second. The PROM is responsible for determining this figure exactly, >> and the kernel extracts it into the variable cpu_tick_freq. On sun4u's, >> this number is disconcertingly round: 143000000, 167000000, 248000000, >> etc. Indeed, a simple experiment revealed that these numbers were >> quite far from the actual ticks per second. Typical was the 143 mHz >> Ultra which was discovered to tick around 142,980,806 (+/- 10) times >> per second.

I'm all for open discussion of this problem, but just out of curiosity, where did you get the above bug report? It's from our internal database, and I was unaware that it was released to customers who aren't under NDA. In any case, I'm the "bmc" in the above report; it's important to note that I fixed the bug in 2.6. And, if there's a demand for it, I'll be happy to patch the fix back to 2.5 and 2.5.1.

In terms of a fix, if you use NTP with the appropriate hacks (e.g. dosynctodr set to 0), you _shouldn't_ have any problems. If you don't use NTP but still need more accurate time than 2.5 and 2.5.1 on sun4u provide, you could also look into setting nsec_per_tick to be accurate for your particular box. Let me know if you need more information about how to go about doing this...

- Bryan

---------------------------------------------------------------------- Bryan Cantrill, Solaris Performance. bmc@eng.sun.com (415) 786-3652

- Bryan

---------------------------------------------------------------------- Bryan Cantrill, Solaris Performance. bmc@eng.sun.com (415) 786-3652

From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]Date: 17 Apr 1997 22:18:16 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: ntp master server X-Keywords: bug [-/+] clockstats [-/+] controlkey [-/+] documentation [-/+] driftfile [-/+] fudge [-/+] Garmin [-/+] Mills [-/+] NMEA [-/+] password [-/+] requestkey [-/+]

Sharon Stahl (stahl@poha.soest.hawaii.edu) wrote:

: Hello! : I am wondering if anyone can point me to instructions on how to : set up my computer as a master time server using a GPS clock attached : to a serial port of a SUN SPARC20 running SUNOS 4.1.3? All the : documentation I've been able to find so far explains getting the : time from another server. My system is on a shp and I would like : our main logging computer to be the time server. : Thank you for any help you can give me and I'm sorry if this is : sitting somewhere obvious and I have overlooked it. This is my first : experience with ntp. : If you respond to the newsgroup (which is certainly fine) would you : please also copy my normal email address? : stahl@poha.soest.hawaii.edu

: Aloha,

: Sharon Stahl : Univ of Hawaii - SOEST/STAG : Honolulu, Hi. : email: stahl@poha.soest.hawaii.edu

Howdy, While I haven't run a ref clock and I'm on a sparc-Solaris 2.5 I think I can help some. I'm on .../testing/xntp3-5.89.8

Watch outs: The common cheap handheld GPS units like the Garmin 45 don't output nice timely NMEA messages. The output can be up a second off, which drives xntp nuts.

xntpd has some complications, so start simple and build things more complicated after the simple stuff is working. Before running an external refclock, try the local refclock and learn how to use the xntpdc and ntpq tools. ntp.conf: server 127.127.1.0 # local fallback fudge 127.127.1.0 stratum 11 # showing poor quality driftfile /usr/local/etc/ntp.drift keyfile /usr/locla/etc/ntp.keys controlkey 15 requestkey 15

This will get you a working server you can play with. A client would have a ntp.conf (assuming the master server has a CNAME "tick" so the ntp service can move to another host without having to reconf all the clients, just restart them): server tick driftfile /usr/local/etc/ntp.drift

I put all the files in /usr/local/etc or /usr/local/bin to avoid wiping them out if I have to reload the OS or upgrade to a new OS rev.

I suggest having a ntp.keys file on the server so you can play with the xntpdc fudge controls on the local clock. With some care and a week of watching, the local clock can be brought to nearly perfect ntp.drift, so it will keep time without a reference to about 1 second / week in a stable temperature. Read the .../html/driver1.html and ./xntpd/refclock_local.c files. The key file would read: 15 M password Avoid passwords longer than 8 characters and use the MD5 flavor. You should "chown root ntp.keys" and "chmod 400 ntp.keys".

To add a radio clock that already has an xntpd driver: You need to find the driver and its information. I think some commercial GPS receivers have specific drivers. There is also a NMEA driver, but the doc is only in the source code .../xntpd/refclock_nmea.c. The ntp.conf line might be like: server 127.127.20.0 # GPS nmea refclock

The refclock_nmea.c tries to open a file /dev/gps0 if you use the line above (the last 0 is the unit number and matches the trailing 0 in the gps0 device name. You will need ln -s /dev/ttyb /dev/gps0 to connect the file the code is looking for to the real hardware.

You will need to modify /etc/ttytab to make sure that there is no getty sitting on the intended port, or it will keep grabbing the GPS and trying to run it through login.

Set up the ttytab for the baud rate that the device wants and check that the refclock doesn't try to change it, or at least understand the changes.

When you can "head /dev/gps0" and see the NMEA sentances coming out every second, you are getting close to letting xntpd try.

As xntpd wakes up with the refclock, you should see it fill in the reach field, declare the sync selection and then it will probably step the clock to the gps time. The step kills the sync selection and clears the reach and filters, so it will take another minute to re-sync and start tracking the NMEA.

Things are looking good if xntpdc -p reports the GPS clock line with a * as the first letter showing sync selection, a small offset (a few milliseconds is good, over 25 milliseconds seems a bit too large. The units are seconds).

Launching "xntpd -dddddd" will bury you with debugging info and might be needed to understand where things have failed. There is a lot of output, so pipe it to a file and don't leave it on for many hours.

The "stats" package of ntp.conf can help, such as clockstats.

Since there seems to be a slight bug in 3-5.90, I suggest starting with ftp://ftp.udel.edu/pub/ntp/testing/xntp3-5.89.8.tar.gz or watching the newsgroup for more discussions about the integer seconds off problem in ntp_loopfilter.c in version ftp://ftp.udel.edu/pub/ntp/xntp3-5.90.tar.gz

Again, be warned that I haven't run a refclock yet. I have it in hand, but haven't gotten arround to wiring it up. I have been watching the newsgroup and think I have most of the details.

Yes, the documentation leaves things to be desired. Feel free to spend those long months at sea to write a new set and then send them to Dave Mills. He wants things in html, but it still must be able to read with "cat".

Happy chiming

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

From: "Greg" <schueman@ix.netcom.com> [-/+]Date: 25 Apr 1997 02:38:50 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: NT reread config

Don.[NO SPAM]PayetteDon Payette <@unisys.com> wrote in article <5jlgto$a6d$1@mail.pl.unisys.com>... > With the NT port of xntpd, how do I get > it to reread it's config file and reinitialize. > I assume I just bring it down and start it > up again. Is there a way to do this without > rebooting?

>From the command line type "ndc reload" or to restart XNTPD "ndc restart".

-Greg

From: Jim Reid <jim@pc37.mpn.cp.philips.com> [-/+]Date: 29 Apr 1997 12:03:53 +0200 [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: xntpd[3985]: Can't adjust time: No such file or directory X-Keywords: adjtimed [-/+] HP-UX [-/+] HPUX [-/+]

Ake Mattsson <ama@lm.se> writes:

> I have compiled and installed xntp3 5.90 export on HP-UX 9.04 without > any problems. > > When I run xntpd I get: > xntpd[3985]: Can't adjust time: No such file or directory > > When I run 'ntpdate server' I get: > ntpdate[470]: Can't adjust the time of day: No such file or directory > > I have the same problem in xntp3 5.89 export.

You must compile, install and run adjtimed on HPUX systems prior to HPUX10. This is because HP did not provide the adjtime system call in their kernel until they released HPUX10, 10 years or so after this system call was first added to BSD. The installation procedure for xntpd should take care of compiling and installing adjtimed, but probably don't add something to one of the startup scripts in /etc which would start adtimed at boot time.

On these HPUX systems, adjtimed must start before xntpd. It creates a SysV IPC message queue (horrid!) which xntpd uses to talk to it. For old HPUX systems, adjtime() in xntpd speaks to adjtimed via this message queue and adjtimed patches /dev/kmem to alter the kernel variables used to maintain the time of day. If this message queue does not exist - because adjtimed hadn't been started and therefore didn't create it - xntpd's attempts to use the messsage queue to adjust the clock fail with the error code ENOENT. This causes perror to print the error message "no such file or directory", even though the message queue is not a file or directory. Sigh.

From: wiu09524@rrzc4 (Ulrich Windl) [-/+]Date: 28 Apr 1997 14:08:55 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: drift file exceeds 100 [-/+]X-Keywords: PPM [-/+]

In article <33647547.7353@cellnet.co.uk> Anthony Bowles <abowles@cellnet.co.uk> writes:

> Hi, > > I've got a couple of Solaris 2.x machines who's drift files are > in excess of plus or minus 100. > > Is there anything I can do to improve the drift, within XNTP, > under Solaris or at the hardware level ? > > One machine is an E3000, the other a SPARC 20. > > Thanks, > Anthony

If you divide your value of tick by your value of HZ , you'll get the number of PPM that one tick is worth (e.g. 10000 / 100Hz == 100ppm). If you have a drift of 137.33 with tick == 10000, using tick == 9999 your drift should be 37.33 then.

For a good result stop xntpd, do the tickadj stuff, edit your /etc/ntp.drift and correct the error, then restart xntpd. (If you don't correct the error you could still wait a long time until xntpd catches up...)

Ulrich Windl

From: Gerald Vogt <vogt@isa.de> Date: Tue, 29 Apr 1997 13:53:14 +0200 [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: NTP LOGGING X-Keywords: FAQ [-/+] GNU [-/+] syslog [-/+]

Todd Allen wrote: > Has anyone compiled ntp on a Solaris platform to log messages using the > syslog facility as local? rather than daemon. There is some info in the > FAQ about this, but not enough to get mine to work.

Well, there are several ways to do this. The very quick one is to patch the includes to #define LOG_NTP to e.g. LOG_LOCAL2.

The second way is like this: ./configure ... make cd xntpd ; make clean ; make CPPFLAGS='-DLOG_NTP=LOG_LOCAL2' cd ../ntpdate ; make clean ; make CPPFLAGS='DLOG_NTP=LOG_LOCAL2'

The third way is this: ./configure ... then edit config.status, look for 'CPPFLAGS' and put in the replacement -DLOG_NTP=LOG_LOCAL2. run config.status (like './config.status') to rebuilt the Makefiles. make

The last way is to patch configure to include an option, that allows to configure the used syslog facility with an --with-syslog-facility option. I can send you that patch if you want to. But you'll need the GNU autoconf package to generate the configure script! -- Gerald Vogt E-Mail: vogt@isa.de WWW: <http://www.isa.de/~vogt> PGP pubkey at keyservers or via WWW! PGP Fingerprint = 1A 57 2E B1 9B 39 81 C5 94 D3 FF B4 CC D8 DE 06

From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]Date: 30 Apr 1997 16:39:52 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: "no server suitable" on SunOS 4.1.4 X-Keywords: auth [-/+] delay [-/+] dispersion [-/+] documentation [-/+] filter [-/+] fudge [-/+] peer [-/+] precision [-/+] restrict [-/+] syslog [-/+]

Grant Reaber (greaber@reed.edu) wrote: : I'm getting the "no server suitable for synchronization found" message when : I run ntpdate. I tried installing the new version of xntpd, and it didn't : help. It fails with IP numbers as well as with hostnames. When I run xntpd, : nothing happens. ntpq -p shows the two servers, but all the fields are zero : and never go non-zero. I tried doing a tickadj. Don't know if that could : have helped -- it didn't.

Howdy, Troubleshooting is always a bit arcane. I'll list some steps I'd use to try to get going and some possible causes of troubles.

First some troubles: Usually the make dies on trouble, but I still watch for errs and warnings. If things fail with IP#s, then it isn't the DNS. Multiple copies of xntpd on the same host seem bad. You might check "ps -aux | grep xntpd" With Sun boxes, you need to run tickadj -s or you will get "adjtime didn't complete" or lots of steps in syslog. If there is a firewall/router in the path, it can block NTP and still let through ping and other protocols. Somethimes the servers have been configured to be very "restrict"ed or require "auth" to be able to hear your probes. Sometimes the server is running old style NTP. My older SunOS needed an added line in /etc/services ntp 123/udp # Network Time Protocol to make ntp stuff work. The tcp line isn't correct.

Second selected tools and techniques Using "tick" as the name of your supposedly working higher level server: Look at syslog and try to understand the ntpdate or xntpd complaints. Is the newtork even connected ? "ping tick" (I knocked the power cord off my repeater earlier this month.) "ntpdate -d tick" should show the transmits. If there are no packets received, try "ntptrace tick" which happens to use the old version just as "ntpdate -d -o 1 tick" would. "ntpq tick" and "xntpdc tick" also exchange packets with tick. Use the "peer" command to see if the server is sync'ed and in xntpdc sysi syss show server status. A xntpd at stratum 16 or with LEAP set to 11 (binary) won't be accepted even if it responds. Also wild root dispersions or delays (20 sec?) are ignored in some places (xntpd) but not always in others (ntptrace). xntpdc "monl" can show if your packets are reaching the server, but not getting back. Looking at the server's "resl" and "authi" might show that you are locked out. You might point to another nearby xntpd host. If "ntpdate -d tick" looks good, but "ntpdate tick" fails to find servers (must be run as root, since it tries to send on the privledged 123 port), the trouble is likely a firewall/router filter that lets the high port probes from ntpq, xntpdc, ntptrace and "ntpdate -d" get though but blocks ntp/udp port traffic.

Try running with the lots of debug -D 9 when launching xntpd (or -ddddddddd). I think that 6 is actually the max used. You will get lots of output ! and you can find why packets that come back are being dropped (flash bits).

If you add server 127.127.1.0 # local clock fallback fudge 127.127.1.0 stratum 10 # show poor quality you will at least have a chance at getting a local live xntpd to play with, since the host will take its own clock as a time reference.

Avoid auth, -cast and restrict until you have things working, then add them in slowly. There are many ways for xntpd to reject time packets and having all of them turned on at the start can lead to confusion.

: Also, I set up two machines which have each other as peers and each have : a different set of servers. Everybody else on the network has the two : machines as servers. (One machine on each of the other subnets looks : to these machines and the other machines look to that one machine.)

Sounds good so far. These are frequently CNAMEd tick and tock. Don't be quite so concerned about have a few extra NTP packets flowwing about. They are fairly small and infrequent. In the building where I work, the two top servers (tick and tock) serve all the clients through the router on all the subnets. We're having the router b-cast to the subnets and the less critical clients will be moved to b-cast receivers someday.

: I thought that this setup would provide redundancy without having too : many machines going to the outside world, but it doesn't work too well.

I agree that you should only be contacting the outside world with 2 or 3 hosts and have the rest look to them.

: What happens is that after a while, one of the servers starts looking : only at the other server (its peer).

This will happen if tick is at a better (smaller number) stratum / dispersion than the servers tock is also looking at. This might be OK and at least tock is providing the same time as tick. This might also be a sign that you aren't connecting with the outside. Look at the "xntpdc -p tock".

: The other lines in ntp.conf don't : even show up in an ntpq -p.

If they don't show up at all, it might mean the DNS hasn't returned an answer for the ntp.conf line "server tick.some.where.outside". You might try IP#s. If the line has the server, but no "reach" and dispersion 16 seconds (ntpq 16000 ms), you aren't getting through to the server.

: If this is a really elementary question, I : apologize, but I've spent a considerable amount of time looking at NTP : documentation, and I haven't found a straightforward explanation of how : to set up NTP for a medium sized site.

I suggest starting small. Get one working, perhaps with a local refclock line like I suggested above (127.127.1.0). Get it working to the outside. Wait a few days and watch how it does. Reach should be 377 nearly always (8 bit shift register shown in octal, newest recv response in LSB) and the offsets in the 5 to 10 ms range if your are close by your servers, perhaps 20s over slow links, and dispersion well under a second. (Dispersion is an estimate of the worst error in the measurement including roundtrip delay, precision and age of the reference time.)

Bruce Bartram bbartram@etl.noaa.gov just another chimehead posted followup and emailed

From: jtt@news.cs.columbia.edu (James "retired crf" Tanis) [-/+]Date: 30 Apr 1997 01:16:27 -0400 [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: Year 2000 & NTP [-/+]X-Keywords: bug [-/+] implementation [-/+]

In decree <TGL.97Apr28203253@netcom13.netcom.com>, Tom Lane<tgl@netcom.com spake, avowing: > David Orr <david.orr@fmr.com> writes: > > My management is asking me if NTP will be affected by the Year 2000 > > bug. I don't beileve so but I could not find any info on the net > > about this. so does anyone have anything I can give them? > > The NTP protocol doesn't have a problem with 2000AD. The protocol > does have a field that should've been wider, but it will wrap around > in 2038 or so, IIRC.

Hmm Well two replies have each said 2028 but I thought the year of the Invalid Time was 2036 (and in each 136 year interval starting at 1900).

136 makes sense if compute (2^32 / (60 * 60 * 24 * 365.25)

At any rate NTP, as Tom points out NTP will not even hiccup at the 2000 Year mark -- and by the time we get to 2036, someone will have *effectively* extended the "second" field to some integer greater than 32 (by "effectively" I mean I don't know exactly *how* the implentation will look, but by diambiguating pre 2036 dates from post 2036 dates, it will have effectively increased the second field).

> > xntpd, as a particular implementation of NTP, might have a few > lurking bugs with the Y2K boundary; naming of logfiles is the > only thing that springs to mind. I doubt there's any critical > problems there; at worst some transient misbehavior. > > The protocol does need fixed, but it can wait --- the stuff that > *is* going to break 32 months from now is higher priority. > > regards, tom lane

From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]Date: 21 Apr 1997 17:41:07 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: request keyid 65535 not found X-Keywords: bug [-/+] driftfile [-/+] FAQ [-/+] glitch [-/+] keytype [-/+] requestkey [-/+]

Alexandre Lebrun (lebrun@Lisa.rwth-aachen.de) wrote: : Hi ! : I tried to install xntp3-5.90 on a Sparc 10 running sunos 4.1.3. : with ./configure --prefix=/Shared/bin; make; make install

: I created a /etc/ntp.conf :

: #ntp.conf :

: server timehost.rz.rwth-aachen.de : server timehost.informatik.rwth-aachen.de : server silvester : driftfile /etc/ntp.drift : # end of /etc/ntp.conf

: ntpdate works well, : but when I launch /Shared/bin/xntpd it logs : 'request keyid 65535 not found'

: and ntpq says :

: # /Shared/bin/ntpq -c peers lisa : No association ID's returned

: What am I missing ? : I have too linux's with precompiled & preconfigured xntpd, (debian) : that work well, with this sort of config

: I probably made a grob mistake, but I followed the instructions, : and there is nothing about that in the FAQ.

: Thanks for any help, : Alexandre

Howdy, While I can't explain what is actually wrong, I can explain a little about where the message comes from.

When xntpd starts up and has to resolve hostnames, it forks off a process "ntp_intres". intres makes the calls to change names to IP#s, which can take a long time. When it has answers, intres sends xntpd a mode 7 xntpdc-ish control line using a requestkey. If there isn't a ntp.keys file with a requestkey already defined, ntp_config.c generates a random key with keyid 65535 (-1?) and fakes the requestkey line. Since intres inherits a copy of ntp_control.c's memory, it should be able to find the keyid, keytype and key so it can pass a valid message to xntpd.

I read your error message as some kind of error in this process. Possilbe work-arounds would include defining a requestkey in a valid ntp.keys file or using IP#s. ntp.conf added lines: requestkey 15 keyfile /usr/local/etc/ntp.keys /usr/local/etc/ntp.keys contents 15 M yourpswd

If there other trouble reports, somebody is going to have to dig in the code on a broken system to find the bug. Launching with script /Shared/bin/xntpd -dddddd then waiting for the daemon to complain, ^C and exit will give useful information in finding the glitch.

Bruce Bartram bbartram@etl.noaa.gov just another chimehead posted followup and emailed

From: tgl@netcom.com (Tom Lane) [-/+]Date: Tue, 29 Apr 1997 03:32:53 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: Year 2000 & NTP [-/+]X-Keywords: bug [-/+] implementation [-/+]

David Orr <david.orr@fmr.com> writes: > My management is asking me if NTP will be affected by the Year 2000 > bug. I don't beileve so but I could not find any info on the net > about this. so does anyone have anything I can give them?

The NTP protocol doesn't have a problem with 2000AD. The protocol does have a field that should've been wider, but it will wrap around in 2038 or so, IIRC.

xntpd, as a particular implementation of NTP, might have a few lurking bugs with the Y2K boundary; naming of logfiles is the only thing that springs to mind. I doubt there's any critical problems there; at worst some transient misbehavior.

The protocol does need fixed, but it can wait --- the stuff that *is* going to break 32 months from now is higher priority.

regards, tom lane

From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]Date: 1 May 1997 16:51:50 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: New to NTP-what's a reasonable drift? X-Keywords: delay [-/+] dispersion [-/+] Linux [-/+] nist [-/+] nsec_per_tick [-/+] peer [-/+] PLL [-/+] poll [-/+]

Geoffrey T Cheshire (gtc@u.arizona.edu) wrote: : Hi,

: After reading the docs I still haven't been able to anwser this simple : question. I'm running xntp 3-5.90 on a Linux-i586 machine connected : (almost) full-time to the 'net via 28.8 PPP and providing time services : to my small lan.

: My ntp.drift has stablized to about: -77.857

While I'd like a drift of +/- 1 ppm, I have to trim the OS to get near it. On a linux system, I think xntpd directly adjusts the frequency (PLL code), so any drift the xntpd can live with should be fine. On other type hosts, such as sparc-SunOS 4.1, trimming via tickadj only has 100 ppm control. A drift above 100 ppm should be trimmed if you can, but anything that works and is under 300 isn't too scary. (Being a complete chimehead, I'd trim anything I could to make the adjtime()s as small as possible. On sparc-Solaris 2.5, I think I'm within a couple of ppm in a typical office environment.)

If the drift were 1000, every second xntpd would be making a 1 ms adjtime() call on systems without PLL. This means the host's clock is a bit rough.

Some host-OS combinations take a long time to make a large adjtime() and have hard limits as to the largest adjtime() that can be made in one second (I think the xntpd variable tickadj has something to do with this value). On such systems, xntpd will hit the limit and will keep stepping. The only hope is to trim the clock to within the working range before launching xntpd.

: doing 'ntpq> rl' yields: : status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg : system="Linux", leap=00, stratum=2, rootdelay=209.84, : rootdispersion=184.83, peer=65000, refid=time.nist.gov, : reftime=b7122ac7.2d06b000 Wed, Apr 30 1997 13:32:07.175, poll=6, : clock=b7122aff.9d7c4000 Wed, Apr 30 1997 13:33:03.615, phase=91.022, : freq=-77856.69, error=91.28

: What can I tell from these stats?

The RFC1305 is the source for all these details, but I think ntpq has already decoded them for you. The status 06f4 decodes to leap 00, source ntp, 15 exception events, and the last was sync-peer or stratum change. leap=00 means no leap second tonight (11 means host is not synched or shouldn't be trusted). Stratum 2 shows your getting time from a stratum 1 source, so you are at 2. rootdelay is the routndtrip time summed from the reference source down the sub-net (in ms in ntpq). rootdispersion is an estimated error limit summed from the root. This includes effects from rootdelay, precisions, and staleness of reftime. I think reftime is the timestamp you last got from your next higher server. I'm going out on some very tenuous limbs in guessing "clock" is the host's time when the rv was processed, freq is the freq drift in ppb, since ntpq tends to think in ms instead of seconds, like xntpdc, and the value matches. I don't know what the "phase" or "error" are. I suffer a bit from variable name and meaning confusion in xntp land.

In summary, your box is at stratum 2, listening to its peer with association number 65000 (look at peer and assoc to figure who that is), and the top of the chain is time.nist.gov. Poll time of 64 seconds (2^6), shows that your host is polling quickly. If the dispersion was lower, the poll time would run out to 2^10, but over a thin link such as a modem, I'd expect low poll interval.

My system shows: status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg system="SunOS", leap=00, stratum=3, rootdelay=12.25, rootdispersion=73.64, peer=27196, refid=nic-srvr-atm.boulder.noaa.gov, reftime=b713455b.e8141000 Thu, May 1 1997 10:37:47.906, poll=9, clock=b7134608.1459e000 Thu, May 1 1997 10:40:40.079, phase=-1.781, freq=869.61, error=2.08 which is much the same, but note my root delay is 12 ms, and root dispersion is 73. Since I've trimmed this sparClassic nsec_per_tick, my freq is 0.869 ppm (if I understand the units correctly, this matches ntp.drift and is temp dependent at the ppm level). And my error is much smaller. I'm on Ethernet or faster to the reference source.

: Thanks! : Geoff : -- : Geoffrey T. Cheshire <gtc@U.arizona.EDU> : Pgp Key <http://www.U.arizona.EDU/~gtc/home.html>

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

From: Terje Mathisen <Terje.Mathisen@hda.hydro.com> [-/+]Date: Wed, 30 Apr 1997 09:29:27 +0200 [-/+]Newsgroups: comp.protocols.time.ntp Subject: [++] Re: Year 2000 & NTP [-/+]X-Keywords: bug [-/+] RFC [-/+] SNTP [-/+]

James retired crf Tanis wrote: > > In decree <TGL.97Apr28203253@netcom13.netcom.com>, > Tom Lane<tgl@netcom.com spake, avowing: > > David Orr <david.orr@fmr.com> writes: > > > My management is asking me if NTP will be affected by the Year 2000 > > > bug. I don't beileve so but I could not find any info on the net > > > about this. so does anyone have anything I can give them? > > > > The NTP protocol doesn't have a problem with 2000AD. The protocol > > does have a field that should've been wider, but it will wrap around > > in 2038 or so, IIRC. > > Hmm Well two replies have each said 2028 but I thought the year of the > Invalid Time was 2036 (and in each 136 year interval starting at 1900). > > 136 makes sense if compute > (2^32 / (60 * 60 * 24 * 365.25)

2036 is right, is is Unix which will have some problems in 2038 (136 / 2 = 68, 1970 + 68 = 2038) due to lots of code that uses (long) for time() calls, instead of (time_t) (which is unsigned).

> At any rate NTP, as Tom points out NTP will not even hiccup at the 2000 > Year mark -- and by the time we get to 2036, someone will have *effectively* > extended the "second" field to some integer greater than 32 (by > "effectively" I mean I don't know exactly *how* the implentation will look, > but by diambiguating pre 2036 dates from post 2036 dates, it will have > effectively increased the second field).

The SNTP RFC (2030?) suggests wrapping the time stamps around 2036, i.e. if the SNTP seconds field has the top bit clear, assume the date is after 2036, instead of below 1968. This would carry us forward until 2104.

A _much_ simpler way to implement is to just assume all time stamps are after 1970!

When converting from NTP seconds to Y-M-D, start by subtracting (modulo 2^32) the number of seconds between 1900 and 1970, and use the resulting 32-bit number as a Unix time stamp, correct between 1970 and 2106. This has the added benefit of making conversion trivial: Just use the <time.h> standard functions.

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: fvance@plum.wg.waii.com (Frank Vance) [-/+]Date: 30 Apr 1997 18:59:42 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: Stratum-1 source for < $5,000? [-/+]X-Keywords: Arbiter [-/+] Bancomm [-/+] Datum [-/+] Mills [-/+] WWVB [-/+]

H. Peter Anvin (hpa@transmeta.com) wrote: : I would like to hear suggestions for a stratum-1 source that is : accurate to ~ 1 ms or so, and works well with xntpd. If possible, I : would like to keep this under $5,000.

: Unfortunately, the xntp docs aren't really helpful in determining how : well the various supported clocks work.

I am awaiting the arrival of our Arbiter Systems 1092A, which sells for about $850 (USD). Arbiter loaned a unit to Dr. Mills, so he could write a xntp driver. That driver is now included in the xntp distribution (driver type 11).

This unit is a standard GPS time code receiver, and requires a host of some sort to interface with it and do all the NTP phase-locked loop and protocol stuff.

Arbiter Systems can be reached at +1 800 321 3831 (for those outside the US and Canada the number is +1 805 237 3831)

A solution I have not priced, but I suspect is less than $5,000 is the BanComm TymServe 2100. In one rack-mounted box, you get the GPS receiver, some sort of processor, and a 10BaseT and AUI connection for Ethernet. And it speaks NTP version 3.

Datum Inc. (Bancomm's parent) can be reached at +1 800 348 0648 (for those outside the us and Canada Bancomm's number is +1 408 578 4161).

A non-GPS solution is the SpectraCom NetClock/2, which is a WWVB receiver. In 1994, it listed for $1500. I don't know what it costs now, but it works with xntp driver type 4.

SpectraCom is at +1 716 381 4827.

There are probably others I don't know about.

-- Frank Vance +1 713 963 2426 Western Geophysical Frank.Vance@waii.com 10001 Richmond Avenue FAX: +1 713 963 2490 Houston, TX 77042 USA

Next part