Received: from louie.udel.edu by huey.udel.edu id aa25630; 1 May 94 10:13 EDT Received: from ni.umd.edu by louie.udel.edu id aa05526; 1 May 94 10:07 EDT Received: by ni.umd.edu id AA23445 (5.65c/IDA-1.4.4 for ntp-list); Sun, 1 May 1994 10:05:23 -0400 Received: from frogpond.rutgers.edu by ni.umd.edu with SMTP id AA23441 (5.65c/IDA-1.4.4 for ); Sun, 1 May 1994 10:05:17 -0400 Received: by frogpond.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04620; Sun, 1 May 94 10:05:05 EDT Date: Sun, 1 May 94 10:05:05 EDT From: Rick Thomas Message-Id: <9405011405.AA04620@frogpond.rutgers.edu> Subject: Preliminary FAQ -- send updates to rbthomas@rutgers.edu Expires: Wed, 1 Jun 1994 00:00:01 EDT Apparently-To: ntp@ni.umd.edu Everybody talks about how we need a FAQ, but nobody does anything about it. So I decided to do something about it. Here is the text of several recent messages that answered questions that everyone agrees should be on a FAQ. Send updates to me -- Please write it up in a form I can include in the FAQ, and I'll include it. Note, This is a "non-fat" FAQ. I include stuff from other people that I think is applicable. I include it as it comes to me, warts and all. I don't usually write things myself because I don't have the time. I don't usually edit things unless I write them myself. Because of the un-edited format, you should read the *whole thing* before you act on anything you read here. Frequently, later items contain corrections to earlier items. I have tried to group related items together, but sometimes that is not possible. This was last updated $Date: 1995/08/09 18:18:15 $ I post the accumulation once a month. It's rough but ready. ======================================================================== Rick Thomas, Manager Supercomputer Remote Access Center Rutgers University, College of Engineering Internet: rbthomas@jove.rutgers.edu UUCP: {any backbone site}!rutgers!rbthomas ======================================================================== Standard disclaimers apply. All messages quoted here are the opinions of their respective authors, and do not necessarily represent the opinions (if any) of their respective employers, or of the compiler of this FAQ. If you act on the advice contained herein you do so at your own risk. Nobody involved makes any warranty. ============================================================================= From: iglesias@draco.acs.uci.edu (Mike Iglesias) Subject: Re: xntpd: previous time adjustment didn't complete rtc@icf.hrb.com (Rob Callahan) writes: >I am also getting lots (I mean lots) of these messages on all Suns running >xntpd as a client. An example of the /usr/adm/messages file follows: > >Feb 24 10:03:21 lilith last message repeated 48 times >Feb 24 10:03:30 lilith xntpd[535]: Previous time adjustment didn't complete Make sure you run tickadj on your Suns before you run xntpd. Here's how we run tickadj: tickadj -A -s -q -t 9999 You can leave off the -t 9999 if you want. We find that our Suns drift less with that setting. Also, if you don't use a window system on the console, the slow console proms will make the system loose interrupts and the time will drift. We *really* need a FAQ for this list. This question gets asked several times a month. :-( ============================================================================= From: glenn@athena.cs.uga.edu (Glenn F. Leavell) Subject: Re: xntpd: previous time adjustment didn't complete I recently worte: >We're using xntp3 to broadcast the time on our campus network. Client >machines accross the network "listen" for the time by running xntpd as: > > xntpd -b -f /etc/ntp.drift > >Recently, some of our Sun4 users (SunOS 4.1.1) have reported seeing the >error: > > xntpd: previous time adjustment didn't complete > >in their syslogs. What would normally cause such a message? Is it serious? Thanks very much to everyone who responded to my question (both via e-mail and directly to the net.) The consensus seems to be that the Sun clock is a very bad one. I was already using 'tickadj -A' to set the value of tickadj to an optimal value in the running kernel. However, a couple of other paramaters are also useful (and most likely necessary): tickadj -A -s -t 9999 The -s option sets the value of dosynctodr to zero in the running kernel. This has the effect of telling the OS to stop trying correct the clock's drift (the work is left for xntp!). The -t 9999 option sets the value of tick in the running kernel to 9999. According to several of the responses I received, this is a good value for most Suns. However, I have not seen a complete list. Thanks again for the help. ============================================================================= From: iglesias@draco.acs.uci.edu (Mike Iglesias) Subject: Re: ntpdate: errors when trying to synch to other xntp hosts Keywords: ntpdate xntp3 art@cs.UAlberta.CA (Art Mulder) writes: > For the most part, everything runs fine, but on some of our > workstations we get: ``no server suitable for syncronization found'' > when ntpdate runs. Make sure those systems can convert hostnames to IP addresses at that point (i.e. make sure everything necessary to use nameservers is up and running if you are using them), and that any routing that needs to be setup is in place before you run ntpdate. > The only solution I have found is to to pick some different hosts for > ntpdate. Maybe those hosts can get to the servers that work but not the other ones, as I mentioned above. >ps: It would be really nice if some central version numbering scheme > were set up for xntp3. It would sure make it easier to track. YES! PLEASE! ============================================================================= From: Mills@UDEL.EDU Subject: Re: NTP peers chongo, I do not have the resources to provide individual configuration advice for a specific installation - there are many thousands of them now. The ntpd (version 1) distribution has been obsoleted twice over and been replaced by NTP Version 3. A comprehensive Unix daemon is available in the compressed tar archive pub/ntp/xntp3.tar.Z on louie.udel.edu. It includes scads of information on installation, configuration and peer selection. Other files in the pub/ntp/doc directory on that host contain probably more than you will ever care to know about timekeeping in general and, in particular, the file clock.txt, which contains a list of public stratum-1 and stratum-2 time servers. Happy chime. Dave ============================================================================= From: jones@hermes.chpc.utexas.edu (William L. Jones) Subject: Just a few small suggestions! Thanks! We really need a faq for comp.protocols.time.ntp. When you talk about using tickad on a sun you need to mention that if you are running Sun OS 4.1.3 you don't need the "-t 9999" on tickadj. Bill Jones ============================================================================= From: geertj@ica.philips.nl (Geert Jan de Groot) Subject: Re: Reachability keeps resetting zero after a STEP joey@tessi.com (Joey Pruett) writes: >I just recently started trying to use ntp on my sun systems. I've >compiled the xntp3 stuff from louie.udel.edu and things kinda run. The >behavior I am seeing is that everytime a STEP is performed, all the >servers I talk to have their reachability reset to 0 and everything >starts over again. This even happens to the LOCAL_CLOCK I configured >into the server. Any help would be greatly appreciated. I don't >understand much about ntp yet, so I am probably not understanding >something... I have the same problem, but after a note from Dave it now seems to be solved. Dave, please correct me if I am wrong, and maybe it is a good idea to include it in the notes files.. The first problem is that SUNs have too much tolerance on their clocks. Because NTP requires removal of synchonisation to the built-in NVram clock (that is where tickadj -s option is for, to reset dosynctodr). Now your SUN really starts drifting, and ntp tries to get up with that, but because the clock error is high (several hundreds of ppm), NTP does not succeed at first, and it takes a few days to adjust. In that time, the SUN will frequently loose synchonisation , which you can determine by looking at the status words in your log file, combined with appendix A of RFC1305. Hence, it is a bad idea to have the SUN synchonize anything else. Wait for things to stabilize first! The approach I used is to start xntpd on a new machine (as slave - I didn't want to confuse the server I used), wait for two or three days, and then check /etc/ntp.drift. Because xntpd raises or lowers the drift value only a few ticks per hour, at first xntp is not able to correct the frequency error. After a while, the time error between your clock and the reference gets higher and higher and xntpd starts to complain: >08:21:56 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.177012563) >08:23:00 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.248992682) >08:24:06 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.248992682) >08:25:08 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.404627085) >08:26:12 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.404627085) >08:27:16 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.404627085) >08:28:20 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.577525616) >08:29:24 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.757438898) >08:30:28 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.759768605) >08:31:34 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.757438898) >08:32:36 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.757438898) >08:33:40 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.757438898) >08:34:44 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.757438898) >08:35:48 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.757438898) Then, after a while, some hold-off timer times out and the time is SET, no longer ADJUSTED. This is what you see: >08:36:52 xntpd: adjust: STEP 16.1.0.22 offset 0.821858644 As a result, xntpd declares itself invalid and starts to synchonize: >08:36:53 xntpd: system event 5 status c043 >08:36:54 xntpd: peer 130.43.2.2 event 84 status 9024 >08:36:54 xntpd: system event 4 status c655 >08:36:54 xntpd: peer 129.189.134.11 event 84 status 9024 >08:36:55 xntpd: peer 127.127.1.5 event 84 status 8024 >08:37:56 xntpd: peer 16.1.0.22 event 84 status 9024 After a while, xntpd synchonizes again and declares healthy again: >08:42:13 xntpd: system event 3 status 664 and the thing starts over again. In time, these events happen less and less often, until the drift value is close enough that xntpd is able to steer the local time within its limits. The basic idea is to sit on your hands for a few days, don't use the server (yet) to synchonize others, and see what ntp.drift does. I find your steps quite huge. Did you run tickadj -As before you started xntpd? After that, your offset is probably still too large. Start ntpq, do 'rv' and look for the frequency offset. Divide by 1000 to get the real frequency error in ppm, which should be less than +-100 ppm. Now, you should vary the 'tick' value of tickadj to make the frequency error (the value in /etc/ntp.drift), or (rv / 1000), less than +-100. You will find that xntpd synchonizes much more quickly - in my case, it needed only one time STEP. Suitable values for tick are 9999 +-2 or so. I found that sun4/60's are nearly similar to each other, sun4/280's too, but there is a severe difference between these families. It seems that there is a difference in mechanism between sunos 4.1.2 and sunos 4.1.3, but I have not found the details in my news archive. This is as far as I am now - I'm adjusting tick for various machines. xntpd no longer complains about time STEPs. I stress that this knowledge is not my wisdom - Dave Mills helped a lot, and I am just describing the experience I got by following Dave's hints. In return, I hope that this message helps others too. Would an xntp guru care to correct my story? Then, it might be Americanized (I'm no native English speaker, but you already figured that out :-), and maybe this information can be added to the xntpd documentation. I am glad I am not the only one that had the problems you have. Dave, thanks! Warning: clock hacking is very addictive. On the other hand, I find it much fun, so you might want to become addicted too! Hope this helps, Geert Jan ============================================================================= From: corrigan@weber.ucsd.edu (Michael J. Corrigan) Subject: Re: Preliminary FAQ -- send updates to rbthomas@rutgers.edu A question I have answered by email a couple of times is: "My newly installed version 3 xntp can't talk to any of the systems it used to talk to. What's wrong ?" You need a line like: peer host.dom.top version 2 if the host is still running version 2. ============================================================================= From: folta@cs.umd.edu (Wayne Folta) Subject: Re: Preliminary FAQ -- send updates to rbthomas@rutgers.edu >Make sure you run tickadj on your Suns before you run xntpd. Here's >how we run tickadj: > > tickadj -A -s -q -t 9999 > >You can leave off the -t 9999 if you want. We find that our Suns drift >less with that setting. I read in c.p.t.ntp that Sun OS 4.1 -- Sun OS 4.1.2 have an off-by-one bug that requires -t 9999 to fix. Sun OS 4.1.3 and beyond do not have this problem, is is said. -- Wayne Folta (folta@cs.umd.edu 128.8.128.8) ============================================================================= From: rbthomas@frogpond.rutgers.edu (Rick Thomas) Subject: Re: Using xntp without radio clock or internet connection? Keywords: clock ntp internet Eric.Boehm@union.edu writes... > We would like to set up time synchronization for a network of ~500 > hp9000-700 workstations. Unfortunately we don't have a connection to > the internet (yet) nor do we have a radio clock. Is there any way to > fool xntpd into thinking it is a stratum 1 server? > > Other solutions or suggestions would be appreciated (I am also looking > at timed). Well, here's one way... In xntp (both v2 and v3) there is a pseudo-radio-clock driver that uses the CPU's own local clock as its time source. Read the docs for how to compile with this feature turned on. (In v2 you set "-DREFCLOCK -DLOCALCLOCK" in the Config file. I'm not sure what you do for v3, but it's probably pretty much the same.) That pseudo-clock can be configured so that it appears to be at any given stratum from 1 to 15. Pick one "master" system, and one "backup" system. Configure the "master" so that its local clock is at stratum 10 and the backup system so that its local clock is at stratum 12. The master and backup have their ntp.conf files set up to talk to each other as "peer"s, and all the rest of the systems' ntp.conf files use both the master and backup as "server"s. With that configuration, the master will free-run and all other clocks on the local net (including the backup) will track the master at stratum 11; unless the master goes down, in which case they will track the backup at stratum 13 and the backup itself will free-run. You use different stratum numbers for the master and backup so the clients don't have two equally attractive choices, each with a different idea of what time it is. Thanks to Cary Gray for pointing out that the master and backup need to be separated by 2 strata, not 1. The reason is (in Cary's words): > If you configure the local clock for host A a stratum 6 and for B at > stratum 7, and A and B peer, then B's peers are: > A at stratum 7 [sync'd to A's clock at stratum 6] > B's clock at stratum 7 > For any of the NTP implementations, B is almost certain to prefer the > second peer, which will have lower dispersion and synchronizing distance > (unless you've done some very careful work with the fudge factors). > > I learned this the hard way using ntpd back at Stanford. > > Cary When you finally get a radio clock, it will be at stratum 1 and will automatically take over as the most attractive source. If you connect it to your "master", you don't need to change anything (except to turn on the appropriate driver). You can even leave LOCALCLOCK configured on the master at stratum 10 as a backup to the radio clock incase it goes down. If you put the radio clock on another system, you need to make the obvious changes to the ntp.conf files to have all systems (including the master and backup) use that machine as (yet another) server. If you get an internet connection instead of a radio clock, then have your master and backup talk (as clients) to a couple of stratum 1 or 2 hosts on the internet (for redundancy, use a different couple of servers for the backup from the couple you chose to serve the master.) Leave LOCALCLOCK configured at stratum 10 and 12 as backups incase the internet connection dies. Leave everybody else unchanged, as clients of the master and backup machines. That keeps the traffic to the internet stratum 1 or 2 server down to a minimum. Best of all is to combine the two approaches; have *both* an internet connection *and* a radio clock. That should do it. Enjoy! Rick ============================================================================= From: ariel@world.std.com (Robert L Ullmann) Subject: Re: Using xntp without radio clock or internet connection? I cringe every time I see someone talking about configuring a local-clock (self-referential clock) at strata like 3 or 4. If you are going to do it, use 10 and 11 (or similar); it will work perfectly well, but you don't run the risk of confusing systems that can see your clocks as well as _real_ strata 3 or 4 sync'd to active radio clocks. I'd like to see the code fixed to prevent configuring local-clock at less than 10. Or better, increasing infinity to 31, and specifying min local-clock as 16; so a strata of 15 or less implies _real_ time reference. (Whatever _real_ is! :-) My implementation uses 31 as infinity; as long as the code is careful not to adjust the clock using samples that had strata larger than the (immediately) previous sample from the peer, you don't suffer bogus adjustments as the servers wander out to infinity. (This is a good idea regardless of the value of infinity.) Writing an independent implementation to the written specification without reference to the PD source is instructive; there are real holes in the protocol specification, as well as interesting improvements available to things like the filter algorithm. (Yes, I will be telling about various things I've found as I get time to do it. :-) Rob -- Robert Ullmann Ariel@World.STD.COM +1 508 879 6994 x226 ============================================================================= From: joey@tessi.com (Joey Pruett) Subject: What I've learned about sun clocks and ntp Organization: Test Systems Strategies, Inc., Beaverton, Oregon This is all my opinion about how things work (or should work) and are by no means authoritative. I assume that the reader understands how to create the configuration file and have read about tickadj. This is the procedure that I've come up with to get the clock on a sun system working pretty well. It is a sun 4/670 running 4.1.2. # tickadj -s -a 5 This stops the system from resetting the clock from the hardware clock. If you don't do this, ntp and the hardware clock fight over the correct time. It also sets the adjtime step to 5 usec which allows ntp to make a change of 500 usec/sec. # ntpdate server [server...] This will set the clock to a semi-sane value. Try to use more than 1 server. # xntpd The ntp server (duh!). Let it run for at least a day, if not longer. Over that time it should be able to figure out how bad your clock is. This value is recorded in the driftfile (usually /etc/ntp.drift) and is updated once an hour. Monitor this and when it seems to have stabilized for a couple hours, you should be ready. Kill the ntp server when you're ready to fiddle with things. Now the value you will want to use for 'tick' is 10000 + int(drift/100). So if your drift is 213.64, then tick should be 10002, -172.12 would be 9999. Edit the driftfile and remove the hundreds part, so the examples would be 13.64 and -72.12. I decided that I like having a positive adjustment, so I add 1 more to tick if the value is still negative, and then update the driftfile to be 100+olddrift. So, my example of drift=-72.12, tick=9999 gets turned into drift=27.88, tick=10000. If the absolute value of drift is not > 100, then you can just use 10000 for tick. # tickadj -s -a 1 -t # xntpd Run these and also update rc.local to do the same. After doing this, ntp will be able to make change things up to 100 usec/sec and the changes can be as small as 1 usec. This keeps the time as accurate as possible by not accumulating adjustments until large enough to call adjtime(). And now a question. In the kernel, there is a variable called 'clkdrift' that looks like it might be a trim value. It seems like things would work much nicer if the kernel could always be trimming the clock rather than having ntp adjtime() every second. Does anybody now how this variable is used? Hopefully, I haven't made a horrible error in my method, or in my description of it... ============================================================================= From: sam@ug.uk.sun.com (Sam Pierson) Subject: Summary: NBS NIST PSTI WWV WWVB GOES Organization: Sun Microsystems (UK) Ltd Thanks to all who answered my post about these acronims. I have summarised all the info I received below in case anyone is interested in using it in the forthcoming FAQ. I make no claims to the accuracy of the information, I just collated it. Thanks go to Chris Polk, David B. Brown, Ross Alexander and Ian Phillipps. -Sam. ---- BIH Bureau International d'Huere Organization in Paris France, that keeps track of world time. GOES Geosynchronous Orbiting Environmental Satellite A set of satellites that provides weather satellite imaging for the North American continent. GOES satellites also provide a timecode that is NIST-traceable and is uplinked by NOAA (operators of GOES) at Wallops Island, NC. Can be received by very simple equipment. Carrier is around 137 Mhz. Accuracy is in the lower milliseconds. GPS Global Positioning System A satellite navigation system usable for accurate timekeeping, Its accuracy range is normally about 100 nanoseconds and the 3D coverage is getting close to the desired 24 hours a day. NBS National Bureau of Standards. This is the old name for the NIST. NIST National Institute of Standards and Technology A department of the US Department of Commerce. Headquarters in Boulder, Co. Responsible for maintaining reference physical standards such as time, meter, kg etc. The civilian counterpart of the USNO (see below). PSTI Precision Standard Time Inc. A company that produces a WWV[B] tracking timepiece. UNSO United States Naval Observatory Keepers of UTC (Universal Coordinated Time). WWV Radio station call sign. American radio station run by the NIST that broadcasts standard time frequency (and weather ?) information on 2.5, 5, 10, 15, and 20 MHz from Fort Collins, Colorado. WWVB Radio station call sign. 60Khz version of WWV. Sited in Washington DC (?) [Actually Ft Colins CO] WWVH Radio station call sign. Hawaii station of WWV service. --- Sam Pierson -- European Support Services, SunSoft Inc. High Wycombe, UK. Internet: Sam.Pierson@Sun.COM UKnet: sam.pierson@sun.co.uk I do not speak for SunSoft, Inc or Sun Microsystems, Inc. ============================================================================= From: John C Sager Rick, Thanks for the FAQ. here are some corrections. > BIH Bureau International d'Huere > Organization in Paris France, that keeps track of world time. Bureau International de L'Heure ^ I believe that this has now become part of the International Bureau of Weights & Measures (IBWM), another acronym for the list. > GPS Global Positioning System > A satellite navigation system usable for accurate timekeeping, > Its accuracy range is normally about 100 nanoseconds and the 3D ^^^ > coverage is getting close to the desired 24 hours a day. Make that several hundred ns, due to the effect of Selective Availability. The absolute maximum should be < 1us. I believe the spec on |(GPS time - UTC) modulo 1 sec| is < 176ns for the case where S/A is compensated (military kit). > UNSO United States Naval Observatory ^^? > Keepers of UTC (Universal Coordinated Time). Not really. The IBWM keep UTC as a synthesis of UTC clocks kept by USNO NPL (National Physical Laboratory (UK)), and other organisations in France, Germany, Russia & other places. There is generally some small difference between all these national standards. I understand GPS will be the vehicle for significantly reducing these differences. regards, John ============================================================================= From: Mills@UDEL.EDU Subject: Re: Need a reference clock Dorian, Tired ticker ncarfuzz.ucar.edu has come victim of oxide plow, while clepsydra.dec.com has been rehomed to a VAX. Use DNS to resolve its true address. Ticker dcn5.udel.edu has gone to the great clock in the sky and several other fuzzbums unnoticed in the swamp have been eaten by alligators. The remaining ones fuzz on, although some are grossly overloaded (clock.sura.net and umd1.umd.edu). I would dearly love to see the fuzzbums retired and replaced with modern silicon, but for various reasons, squeaky time is not a priority issue with those that count the beans. In any case and in order to avoid overheating the tired old silicon and redline DMZs, we should all avoid pecking on the stratum-1 servers, both fuzz and otherfuzz, unless prepared to front for a biggish bunch of churlish clients. Please note the file clock.txt changes on about a monthly basis, so any file that "came with the distribution" is surely long of tooth. Dave ============================================================================= From: ken@SDD.HP.COM (Ken Stone) Subject: Re: HP version of ntp wanted > I need some assistance in locating a version of ntp/ntpd for HP-UX V8.x, > would you be able to point me in the right direction. The standard xntp3 code works just fine with the addition of a seperate daemon (adjtimed) to compensate for the lack of adjtime(2). Pick up the code from louie.udel.edu. I have it running on over 350 8.X HP-UX machines on this site alone ... s300/s700/s800 all work. -- Ken ============================================================================= From: rbthomas@frogpond.rutgers.edu (Rick Thomas) Subject: Re: 3 or 9 Internet NTP servers? Organization: Rutgers Engineering Supercomputer Lab ^% The DEC documentation says: ^% "If your site is connected to the Internet, you should configure three ^% (but no more than three) NTP primary servers at your site that ^% synchronize to three highly accurate (stratum 1 or stratum 2) hosts on ^% the Internet." ^% ^% I may be having a brain fart, but this seems ambiguous. Does ^% each local NTP primary server use three different Internet servers or ^% the same three? Well, one way of doing it is to have 3 onsite primaries (stratum 3, say) connected to 4 offsite servers (stratum 2, say) as follows onsite-1 is client of offsite-a, offsite-b, offsite-c, and peer to onsite-2, onsite-3 onsite-2 is client of offsite-a, offsite-b, offsite-d, and peer to onsite-1, onsite-3 onsite-3 is client of offsite-b, offsite-c, offsite-d, and peer to onsite-1, onsite-2 This spreads your load around and gives you a little extra redundancy, but not enough to cause severe confusion. Peering onsites with fellow-onsites makes sure you get consistent time amongst them. Enjoy! Rick ============================================================================ From: wai@socs.uts.EDU.AU (Wai Yat Wong) Subject: Re: Help --- xntpd[122]: Previous time adjustment didn't complete ? Organization: School of Computer Science, UTS A great thank you to Anthon Ouwendijk I now have an answer . Anthon emailed me and explained the following: |> All my workstations here that are running 'xntpd -b' |> occasionally have these console messages: |> |> xntpd[122]: Previous time adjustment didn't complete |> You have Sun workstations, haven't you? Maybe this is what you are looking for ... SunOS 4.1.x has a lousy software clock: clock ticks are lost, and it contains other bugs too. Therefore SunOS adjusts its software clock to the battery-backup clock and this plays havoc with the operation of xntpd. (Two captains on a single ship, fighting for clock-control). So, on SunOS you have to call 'tickadj -s' (see man-page) after booting. Tickadj -s turns off the kernel parameter dosynctodr, that controls SunOS synchronizing to its hardware clock. The lousy software clock will be adjusted by xntpd. So .... add the following lines to your ntprc file: if [ ! -x /tickadj ] then echo "NTP error, file tickadj missing." >&2 exit 0 fi /tickadj -s -q Thanks again, Anthon , all the way from the Netherlands. ============================================================================ From: mrapple@quack.kfu.com (Nick Sayer) Subject: Re: Help --- xntpd[122]: Previous time adjustment didn't complete ? Organization: The Duck Pond public unix: +1 408 249 9630, log in as 'guest'. wai@socs.uts.EDU.AU (Wai Yat Wong) writes: >/tickadj -s -q While you're at it, that ought to be /tickadj -Aqs This will also have tickadj compute and install an appropriate value for tickadj, which allows xntpd to work around a bug in most kernels having to do with the precision with which adjtime()s are applied to the clock. See notes.me for more info. ============================================================================= From: rbthomas@frogpond.rutgers.edu (Rick Thomas) Subject: Re: what are the /etc/ntp.drift units? >> What are the units of the /etc/ntp.drift file value? ... >> What I want is some way to sanity check a drift value. I have systems >> that lose about 1.1 seconds per day when left to run on their own. >> What might I expect the drift value to be? >> >> chongo <> /\oo/\ I heard a rumor that the units changed between xntp and xntp3. The rumor went on to say that in xntp (v2 of the protocol) the drift in the drift file is to be divided by 4096 to get parts per million. I.E. microseconds of drift per second of time. The rumor went on further and said that in xntp3 (v3 of the protocol) the units had changed so that one could read the contents of ntp.drift directly as parts per million. I think (degree of verification now less than rumor) that ntp (v1 of the protocol) used the same units as xntp (v2). Nick Sayer sent me some corrections to my rumor... % % Not quite. The drift file under v2 is 4096 parts per unit, not per % million. So divide by 4096 and multiply by 1e6 and you get % parts per million. And Louis A. Mamakos sent the following addition % % Off the top of my head, I believe that ntpd uses the same units as % xntpv2 does. The format of the file is slightly different, as I % recall, as the last few computed samples (one per hour) are recorded. % % This is from memory; we run xntp3 now and I don't recommend ntpd for % any new applications. To which Dave Mills adds % % The units in the file are in ppm, but the units shown in ntpq are 1000 times % that amount or in parts in 10^9. Life lurches on. And Lars Mathiesen (U of Copenhagen CS Dep) adds % Almost ppm. (I should know, I put it in myself.) The actual unit is % 2**-20 (a pure number, or seconds per second if you like). I was also % surprised by the multiply-by-1000 behaviour of ntpq, which is a legacy % of the Fuzzball era, I think % % (The old (xntpd v2) code used a 64-bit fixed-point register. I think % it was effectively in units of 2**-12, since it was shifted by % CLOCK_FREQ and applied once every four seconds. That is, the value in % the drift file grew by a factor of 256.) There are 86400 seconds in a day, so 100 ppm would be 8.64 seconds per day. Rick ============================================================================ From: thorinn@diku.dk Subject: drift units... The value in the drift file: I was talking of units. To convert the value in the xntp v3 drift file, in units of 2**-20, to units of ppm (10**-6), you have to _divide_ the number by 1.048576 (or multiply it by 0.95367431640625). In other words, the value is about 5% high. If I am right (remember, I am not totally certain of this) the older implementations expressed the value in units of 2**-12. To get ppms, divide by .004096, or multiply by 244.140625. Or just say that in the old format, the number was 256 times smaller. Lars Mathiesen (U of Copenhagen CS Dep) (Humour NOT marked) ============================================================================ From: "Louis A. Mamakos, NTP mailing list maintenance" Subject: NTP mailing list vs NTP netnews > Thanks, Louie! > > Incidentally, to what e-mail address should I send the once-a-month FAQ > so that the ntp mailing-list gets it as well as the > comp.protocols.time.ntp netnews group. > > Are they gatewayed? It doesn't seems so, but I can't tell for sure. > Perhaps you could write something for the FAQ on how readers of the > netnews group can get connected to the mailing-list. If you do, I will > add something about the netnews group for readers of the mailing-list. There is a one-way gateway which causes traffic sent to the NTP mailing list (NTP@NI.UMD.EDU) to be injected into the comp.protocols.time.ntp newsgroup. This is being done at Apple by Erik Fair. If I can find some good bidirectional news <-> mail gateway software, I may consider making a local gateway which operates in both directions. I encourage all interested parties to read the USENET newsgroup rather than subscribe to the mailing list. louie AKA: NTP-REQUEST@NI.UMD.EDU ============================================================================ From: wollman@sadye.emba.uvm.edu (Garrett Wollman) Subject: Re: Previous time adjustment didn't complete Organization: University of Vermont, EMBA Computer Facility In article <9304201216.ZM25019@hansen> chongo@ncd.com writes: >What changes should make (if any) when xntpd (V3) issues the following >syslog message: > Apr 18 14:00:55 hansen xntpd[13203]: Previous time adjustment didn't complete It really depends on the machine you're using. My machine generally prints it out only once a day, usually correlated with other system activity (when I'm re-compiling my kernel, for example, or expiring news), so I don't worry about it. >How often to 'too often'? What is 'normal' for a system where all is well? I'll let others answer the first question. `Normal' is probably `not at all'; I believe that the messages in my system probably result from bugs in the interrupt handling code, although I'm not absolutely sure and I'm not enough of a hardware hacker to look at it and see what it's doing when this happens. -GAWollman ============================================================================ From: cudep@csv.warwick.ac.uk (Ian Dickinson) Subject: Re: time going backwards Date: 18 May 93 14:03:09 GMT In article lindy@olsen.ch (Lindy Foster) writes: >I expected the behaviour to be more like date -a, where the >system clock is _gradually_ slowed down using adjtime so there is no >backwards time jump. This is really important to us, as we receive real >time data which is date stamped on arrival, and a consistent forward flow >of time is critical. I'm making the assumption that it only does this relatively soon after booting. If this isn't the case, I think you may have other problems. The best workaround is to run ntpdate as early as possible in the boot sequence, sleep for however many seconds it would take for the adjtime call to succeed, call nntpdate again to do some finer adjustment, sleep again, and then start xntpd. For instance (culled from README.solaris2): tickadj -s -a 1000 ntpdate -v server1 server2 sleep 20 ntpdate -v server1 server2 sleep 20 tickadj -a 200 xntpd Your values for tickadj may need changing. (BTW, the tickadj kernel variable doesn't exist under Solaris 2.2 - what should one be doing in this case???) ============================================================================ From: lichtin@olsen.ch (Martin Lichtin) Subject: SUMMARY: Weird NTP behaviour (well, maybe not) Date: 3 Jun 93 14:22:47 GMT Organization: Olsen & Associates, Zurich, Switzerland My question (basically) was: > We have a DCF radio clock and are running xtnpd on machine A. There's > also a machine B, not running xtnpd and time off by 250 seconds > relative to machine A. I then start up xntpd on machine B (with > /etc/ntp.conf containing: "server A") . > A (date;sleep 2) loop says: > Tue Jun 1 18:40:48 MET DST 1993 > Tue Jun 1 18:40:50 MET DST 1993 > Tue Jun 1 18:36:43 MET DST 1993 > Tue Jun 1 18:36:45 MET DST 1993 > And now, clocks have synchronized. But wasn't this a bit rude? The common answer was that for time deltas greater than CLOCK_MAX = 128ms, the clock is stepped and then the PLL (Phase-Lock Loop) takes over. However, I'm still waiting for someone who knows a way to avoid this behaviour. Imagine a machine that only receives NTP packets for a few hours a day. Do I need to set tickadj to a higher value? Can I twiddle NTP to be less precise and allow correcting bigger offsets? Martin. ---------------------------------------------------------------------------- The Answers: From: John C Sager To: lichtin@olsen.ch (Martin Lichtin) Date: Wed, 2 Jun 93 12:18:50 BST Martin, This is the way xntpd is supposed to work. If the error between the system clock and the reference derived from the peer(s) it is using is greater than CLOCK_MAX (128ms) then the clock is stepped to get it to within a few milliseconds, and then the PLL control takes over. I suspect this is done because the PLL time constant is so long (some hours) and underdamped to some degree, that it would take a long time to settle, and the adjustment capability would be exceeded. With the recommended value for tickadj, the maximum adjustment rate available is 500us per second. Adjusting at this rate it would take about 5.5 days to remove a 240 second offset, and the daemon would try to command far greater rates than this. In practice, the frequency error measured by the daemon would ramp up to a limit of about 390 ppm where the daemon assumes something is badly wrong and quits. John C Sager Mail: B67 G18, BT Labs -------------------- From: Frank Kardel To: lichtin@olsen.ch Date: Wed, 2 Jun 93 13:41:01 +0200 Please let the daemon run all the time. Then it will be able to keep the time with 128ms and all is well. NTP is not designed for casual use. Frank Kardel ============================================================================ From: Mills@UDEL.EDU Date: 5 Jun 93 19:30:05 GMT Rick & Co., A few comments on your faq compendium follow. Sorry I don't have the photonic bandwidth to eyeball the ntp newsgroup directly. All Sun4s I know of have the local oscillator frequency at least 100 ppm fast, so the -t 9999 argument to tickadj is almost always required. It is a good idea to get this right, whether 9999 or something else, as the residual error affects the actual jitter of the clock, as well as the frequency error should the NTP daemon be interrupted for some reason. It is always the case that dosynctodr should be disabled. While I haven't laid paw to SunOS 4.1.3 yet, I doubt it is any different than 4.1.1 in these areas. Rob Ullmann mentions an untainted implementation ex spec. I would very much like to hear of such adventures and what holes remain in the spec. It will also help the case if and when the spec is advanced beyond the present Draft Standard status. Frankly, my experience in promoting the present status has left me rather disenchanted with the standards process, so advancement is not high on my agenda. I don't think you want to meddle with clkdrift; it causes the differenct between the tod clock and system clock to be displayed, if more than one tick apart. In fact, if dosynctodr is NOT reset, xntp will not work at all. Fixup on anachronisms: So far as I know, NIST is headquartered in Gaithersburg, MD, WWV and WWVB transmitters are at Ft Collins, CO. Conventional wisdom (as opposed to Politically Correct) is that USNO keeps the time and NIST keeps the frequency, but each reads each other's timekeeper's notices. As for GPS time relative to UTC time, you need to be equally delicate on turf. GPS receivers keep GPS time as coordinated within GPS and may not split the weenieseconds with respect to UTC. Without the military codes, GPS users are not expected to achieve accuracies much better than LORAN-C, allegedly 0.25 nm or well over a microsecond. Don't believe it; with a good timing receiver, 5-7 satellite averaging, a decent local timebase and occasional discipline to LORAN-C, I'm getting better than 100 ns almost all of the time. This is verified by cesium oscillator calibrated to USNO and is much better than early civilian GPS receivers. Dave ============================================================================ From: cjj@spdev.east.sun.com (Christopher Jackson - Special Projects) Date: 6 Jun 93 14:55:16 GMT Organization: Sun Microsystems, Columbia MD In article <9306051530.aa08395@huey.udel.edu> Mills@UDEL.EDU writes: >All Sun4s I know of have the local oscillator frequency at least >100 ppm fast, so the -t 9999 argument to tickadj is almost always >required. It is a good idea to get this right, whether 9999 or >something else, as the residual error affects the actual jitter >of the clock, as well as the frequency error should the NTP daemon >be interrupted for some reason. It is always the case that dosynctodr >should be disabled. This is not quite correct. While our oscillators are not perfect (otherwise there'd be no need for NTP, right? :-) ), the consistent 100ppm error is due to software, rather than hardware. Previous versions of SunOS 4.X had a bug where the real-time clock register was initialized to one less than the proper value. The clock interrupt thus fired one tick too early, and the system clock gained an extra 1us every 10 ms. >While I haven't laid paw to SunOS 4.1.3 yet, >I doubt it is any different than 4.1.1 in these areas. This bug (Sun Bug 1094383) is fixed in SunOS 4.1.3, under which the -t 9999 adjustment should no longer be necessary. (Yes, you do still need to disable dosynctodr.) Chris Jackson ============================================================================ From: aegl@ossi.com (Tony Luck) Date: 8 Jun 93 17:42:11 GMT Organization: Fujitsu Open Systems Solutions, Inc. gdonl@sunrise.ssi1.com (Don Lewis) writes: >I'm not so sure it is fixed. Our two Sparc 2's are running 4.1.2, >and with the -t 9999 adjustment, they are off by 19ppm and 34ppm. >Our 10/41 running 4.1.3 without the -t 9999 adjustment is off by 106ppm. >This is a small sample, but the 106ppm error is more than I would >have expected. A few more data points about how far out some Sun4's crystals can be. Most of these are IPXen, with a couple of SPARCstation2's, and a 4/690 and 4/330. All are running SunOS 4.1.2 ntp.drift tick ========= ==== -89.83615 10000 -73.36331 10000 -72.51350 9998 -66.32201 10000 -64.02086 10000 -62.21976 10000 -55.62454 10000 -54.74640 10000 -50.99059 10000 -6.39066 10000 -4.19466 9998 -1.12428 9999 9.57497 9999 12.04364 10000 22.07689 9999 39.67384 9999 51.66208 9999 >From these numbers, it looks to me like 106ppm is well within the range of speeds that Sun4 crystals actually run. A while back somebody posted a suggestion of running xntpd for a few days, then look at the drift file. If the absolute value is too big (>100?) then kill the xntpd daemon. If the drift value is negative, you should reduce 'tick', if it is positive, then increase 'tick' ... add/subtract 100 to the value in the drift file for every point that you change tick, then start a new xntpd daemon. Sounds like the FAQ should tell people to start at "-t 9999" on pre-4.1.3 systems ... but be prepared to tune a point or two on all Suns. -Tony Luck ============================================================================ From: mrapple@quack.kfu.com (Nick Sayer) Date: 10 Jun 93 10:56:31 GMT Organization: The Duck Pond public unix: +1 408 249 9630, log in as 'guest'. gdonl@sunrise.ssi1.com (Don Lewis) writes: >In article <1ut0gk$sli@spdev.east.sun.com> cjj@spdev.east.sun.com (Christopher Jackson - Special Projects) writes: >>This bug (Sun Bug 1094383) is fixed in SunOS 4.1.3, under which >>the -t 9999 adjustment should no longer be necessary. (Yes, you >>do still need to disable dosynctodr.) >I'm not so sure it is fixed. Our two Sparc 2's are running 4.1.2, >and with the -t 9999 adjustment, they are off by 19ppm and 34ppm. >Our 10/41 running 4.1.3 without the -t 9999 adjustment is off by 106ppm. >This is a small sample, but the 106ppm error is more than I would >have expected. I think the bug was sun4c specific, but the fix was applied to all Sun 4 platforms in 4.1.3. Which means that sun4ms running 4.1.3 need to have tick incremented by one. sigh. The best thing to do is do it on an individual basis. If your clock is off by more than 50 ms, increment/decrement tick until it isn't. ============================================================================ From: cjj@spdev.east.sun.com (Christopher Jackson - Special Projects) Date: 13 Jun 93 15:26:00 GMT Organization: Sun Microsystems, Columbia MD In article mrapple@quack.kfu.com (Nick Sayer) writes: >I think the bug was sun4c specific, but the fix was applied to all >Sun 4 platforms in 4.1.3. Which means that sun4ms running 4.1.3 >need to have tick incremented by one. sigh. Well, it turns out that Mr. Sayer is correct; the bug is not completely fixed for sun4m machines. The clock initialization for sun4, sun4c, and sun4m platforms was broken in 4.1.2. A fix was made to all three platforms for 4.1.3. Unfortunately, the sun4m clock is a little different from the sun4/sun4c clock, and the fix needs to be a little different as well. The result is that in 4.1.2, sun4 and sun4c were 100ppm fast, while sun4m was 50ppm fast; in 4.1.3, sun4 and sun4c are no longer broken, but sun4m is 50ppm slow. (Since it's 50ppm, not 100ppm, you can't really fix this with the -t flag.) A bug has just been filed on this, and it will hopefully be fixed in a future release of SunOS. In the meantime, the exceptionally brave may wish to try the following patch. Notes: This patch is for sun4m machines running 4.1.3 only; sun4s and sun4cs don't need it, and applying it to earlier 4.X releases will probably result in a crash. THIS IS NOT AN OFFICAL SUN PATCH; if it trashes your system, melts your disks, or turns your hair green, don't complain to me or to the Answer Center. Caveat Emptor. The patch: cp /vmunix /vmunix.bak adb -w /vmunix startrtclock+2c?W 110007a0 startrtclock+34?W 90122480 startrtclock+3c?W 912a2009 startrtclock+40?W 1000000 startrtclock+44?W 1000000 $w $q reboot If anyone actually tries this, I would be interested to hear how much it helps. Chris Jackson ============================================================================ From: amoss@picton.cs.huji.ac.il (Amos Shapira) Subject: Re: help with ntp Date: 26 Jun 93 16:04:34 GMT Organization: Inst. of Comp. Sci., Hebrew University, Jerusalem, Israel jm@TAO.UNIV-PARIS8.FR (Jean Mehat) writes: I would like which version of ntp, xntp etc... is the most current one? We are running a small network of sun4 on the internet (< 10 machines). I have been said that time synchronisation is an important issue in security. I am somewhat lost between various releases of Network Time Protocol. Can you give me a pointer to the most recent release (like a ftp site & directory) ? -- Jean Mehat, universite de Paris 8 Vincennes a Saint Denis, jm@tao.univ-paris8.fr, (1) 49 40 64 03, (1) 49 40 67 83 (fax) As far as I followed it, the most recent *released* version is 3.1, the "home site" of xntp is louie.udel.edu directory /pub/ntp. You will find there also some alpha releases of a newer version. The drawback of this site is that it is located inside the U.S. and therefore you can't take advantage of the DES code it can use (you still can have the MD5 code). A release with DES which is located outside the U.S. is available on ftp.csc.liv.ac.uk file /hpux/Networking/xntp-3.1.tar.Z. This is the one I'm running a few months by now and it seems to work greate. Cheers, --Amos ============================================================================ From: mrapple@quack.kfu.com (Nick Sayer) Subject: Re: NTP for Mac? Date: 6 Jun 93 16:40:17 GMT Organization: The Duck Pond public unix: +1 408 249 9630, log in as 'guest'. mrapple@quack.kfu.com (Nick Sayer) writes: >I remember hearing some time ago about an NTP control panel or INIT >for Macs. Is this true? What's it called and where can I ftp it? >Thanks in advance. Thanks to Randy Bush who not only pointed me towards, but mailed me a copy of "Network Time", a control panel that does exactly that. ============================================================================ From: Mills@UDEL.EDU Subject: Re: Leap second? Date: 30 Jun 93 20:00:25 GMT The fuzzballs are now so overloaded that I can't reach in and set the leap bits manually. Between the smoke and steam of the xntp-alpha stuff, new radio drivers and busted radios, not to mention new kernels with leap stuff built in, I decided my bandwidth for this particular leap event had been exceeded. Most of the radio services you mention already have leap-warning bits and at least some of the clocks (CHU and WWVB) do decode them in xntp-alpha. The problem here is that I haven't completed the xntp-kernel interface for the kernels I have modified to handle the leap event correctly. Standard kernels will of course not bump the time until at least one update has been seen from the source. Dave ============================================================================ From: warb@tgf.tc.faa.gov (Dan Warburton) Subject: Re: ntpdate version 3.1 on HP-UX A.09.01 A 9000/715 Date: 7 Jul 93 16:28:08 GMT Organization: FAA Technical Center, Pomona, NJ warb@tgf.tc.faa.gov (Dan Warburton) writes: >ringi@x.co.uk (Ian Ringrose) writes: >>I having problems getting "ntpdate" to work on a HP-UX 9 system, I have not >>set up any config files, but have started "adjtimed". >>When I do: >> # ./ntpdate 128.175.7.4 >>I get: >> ./ntpdate: no server suitable for synchronization found >>When I do: >> # ./ntpdate -d 128.175.7.4 >Yes, it seems that is might work. I have the same problem. I have >just tested with my Internet firewall down and things seem to work. >There must be a back socket that needs access. >Is there any one out there that Knows what port and protocal TCP or UPD >this back channel might be? I'll check the sources, but would like >confirmation of my guess. OK, here's my answer: ntp uses a udp back port of 123 on my Internet fire wall (a cisco router) my access list needed the following: !ntp network time protocal access-list 101 permit udp 0.0.0.0 255.255.255.255 155.178.0.0 0.0.255.255 eq 123 This allows udp access to port 123 from anywhere on the internet to any host on my Class B address space. P.S. Maybe this should go into the FAQ? -- Dan Warburton warb@faa.gov warb@tgf.tc.faa.gov warb@pilot.njin.net ============================================================================ From: dunigan@thdsun.epm.ornl.gov (Tom Dunigan) Subject: Re: ntpdate version 3.1 on HP-UX A.09.01 A 9000/715 Date: 7 Jul 93 20:44:37 GMT Organization: Oak Ridge National Laboratory In debug mode, ntpdate uses a non-privileged port number for its "source UDP port" to do the query. When not in debug mode, ntpdate uses port 123 as its source port. Some systems (Ultrix), or maybe its the xnptd version, refuse to reply to the 123-port request. -- Tom Dunigan dunigan@msr.epm.ornl.gov ============================================================================ From: feigin@iis.ee.ethz.ch (Adam W. Feigin) Subject: Re: syslog() bogosity Date: 29 Jul 93 13:32:36 GMT Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH jim@jagubox.gsfc.nasa.gov (Jim Jagielski) writes: >emcguire@intellection.com (Ed McGuire) writes: >>The virtually identical syslog code found in each >>of these processes should be consolidated, but before I do that, has >>it been cleaned up already in the alpha? >Why not in the main ntp*.h include file do a: > #ifdef LOG_DAEMON > #undef LOG_DAEMON > #endif > #define LOG_DAEMON LOG_LOCAL0 >Or maybe put this in Config... Ugh. Its in there already as of xntp-alpha. All you need to do is to change the DEFS line in your config file, and add the following: -DLOG_NTP=LOG_(insert your favorite syslog facility here) Its not really documented in the Config file anywhere, and I can't remember where I came across it, but it does work. I just checked, and it looks like I gleaned this from the code in xntpd/ntp_control.c (line 1724) and xntpd/ntpd.c (line 190). /AWF ============================================================================ From: ntp-adm@inria.fr Subject: NTP FAQ: update for Sony Date: Thu, 05 Aug 1993 10:31:25 +0200 Sender: Alain.Durand@inria.fr A little while ago I posted a request for help to run xntdp on Sony News. Everybody agreed the answer was worth an entry in the FAQ. This is a summary of the answers I got: The problem is that Sony boxes do not take care of leap seconds correctly. xntpd seems to synchronize well, but the date program pretends the clock is 14 seconds off. The solution is to remove the MET file in /etc/zoneinfo with all its links and to replace it with a good one (sun's for example) and then to restart inetd. If you are in another time zone, you might have to change some other files. Thanks to: Heiko Trautwein : ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > hello, > on our SONY Workstations ( mips and mc68030 ) we had this problem too, > the clock differs 14 or 15 seconds from all the other clocks, if > timezone is MET, if you change the timezone to e.g. GMT the clocks > are in time. > So I think the GMT timezone is corrupt and copied the MET file from > one of our Sun's on the Sony, and clocks where synched. > > Heiko jcs@zoo.bt.co.uk (John C Sager) & aegl@ossi.com (Tony Luck) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > In article <230vca$h66@nym.ossi.com>, aegl@ossi.com (Tony Luck) writes: > > durand@nuri.inria.fr (durand alain denis) writes: > > > > >I'm trying to install xntp-alpha on various machine on our network. > > >It's just fine for sun's, but for sony mips, it's really wierd. > > > > I think that this was discussed a couple of months ago ... as far as I recall > > the problem is that the Sony systems have a table of the leap seconds so that > > that can try to be really clever about telling you the time. As a result, > > they have a different idea of how many seconds there have been since 1970. > > This confuses xntp somehow (maybe its date conversion code doesn't match the > > libc ctime() stuff?) ... and the net result is that xntp sets the time to > > a value that ctime() says is some number of seconds out (depending on how > > many leap seconds ctime() is trying to account for). > > NTP ticks UTC, as do most Unix boxes, so at each leap second, it, and the > Unix clock, get stepped appropriately. This is explained at length by Dave > Mills in rfc1305 pages 76-79. > There was some discussion on this group some time ago as to whether NTP > should tick TAI, and the corrections done for leap seconds in the same > manner as timezone & DST corrections are currently done (as the Sony > box seems to do). At the time I argued that the current system is more > convenient for most users, and the small number who need TAI can do the > reverse correction at their own expense. > > > > > Can't recall whether anyone had a fix for this though ... if anyone does, its > > probably worth an entry in the FAQ. > > I would agree an entry in the FAQ migh prevent future puzzlement. - Alain Durand. ============================================================================ From: barrett@lucy.ee.und.ac.za (Alan Barrett) Subject: Re: NTP for Novell???????? Date: 10 Aug 93 00:44:36 GMT Organization: Elec. Eng., Univ. Natal, Durban, S. Africa MVICKERS@fhcrc.org (Mark F. Vickers) writes: > Is there an NTP client for Novell??? This question should be in the FAQ, but is not there. I usually email replies to this question, but will post this time. I don't know of an NTP implementation for Novell, but I do know of two ways of synchronising the times of Novell servers using the RFC 868 time protocol (commonly called "rdate"). * There is an RDATE NLM from Murkworks that allows the Novell fileserver to synchronise its time from an rdate server. Available from ftp://netlab2.usu.edu/misc/rdate.zip * Brad Clements' Charon mail/lpr gateway can synchronise its time from an rdate server, and can set the times of the attached Novell fileservers using some Novell method. Available from ftp://omnigate.clarkson.edu/pub/cutcp/charon --apb Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa RFC822: barrett@ee.und.ac.za ============================================================================ From: aegl@ossi.com (Tony Luck) Subject: Re: Problems with xntpdc and ntpq in xntp(3.1) Date: 12 Aug 93 17:19:07 GMT Organization: Fujitsu Open Systems Solutions, Inc. cmoore@corazon.mit.edu (Christopher B. Moore) writes: >well under control. But I'm having trouble running ntpq and xntpdc to >get a look at what's going on. Both programs fail with the message: >ntp/udp: unknown service. Can someone suggest what I might have done >wrong? I think that "ntp" is one of the well known services that Sun forgot to put in /etc/services. Just add the line: ntp 123/udp # Network Time Protocol to /etc/services (For some bizarre reason this file is controlled by NIS (formerly yellow pages), so if you are in the unfortunate situation of using NIS you need to add this line to /etc/services on your server and run ypmake/yppush/whatever). -Tony Luck ============================================================================ From: schoo@cs.rulimburg.nl (Patrick Schoo) Subject: Re: Problems with xntpdc and ntpq in xntp(3.1) Date: 16 Aug 93 10:08:16 GMT Organization: University of Limburg, Maastricht aegl@ossi.com (Tony Luck) writes: >I think that "ntp" is one of the well known services that Sun forgot to >put in /etc/services. Just add the line: >ntp 123/udp # Network Time Protocol >to /etc/services (For some bizarre reason this file is controlled by >.. >-Tony Luck Sun didn't forget to put ntp in /etc/services, they just use the wrong protocol (tcp instead of udp). In my original services file this line was included (SunOS 4.1.1). ntp 123/tcp # Network Time Protocol Does anyone know if this is a bug, or if there is a specific reason for this? Patrick Schoo (schoo@cs.rulimburg.nl) ============================================================================ From: geertj@ica.philips.nl (Geert Jan de Groot) Date: 13 Aug 93 20:48:26 GMT Organization: Philips Consumer Electronics, Eindhoven, The Netherlands Mills@UDEL.EDU writes: >The offset looks too high. Note the frequency slowly climing, which >suggests the usual problem with SPARCs. Your /etc/rc.local file should look >something like this: >if [ -f /usr/local/bin/tickadj ]; then > /usr/local/bin/tickadj -t 9999 -a 5 -s & echo -n ' tickadjusted' >fi >if [ -f /usr/local/bin/xntpd ]; then > /usr/local/bin/xntpd & echo -n ' xntpd' >fi >This assumes SunOS 4.1.1. I am told, but have not confirmed, that 4.1.3 >has a bugfix which removes the necessity for the -t 9999 above. Then, >I am told that Sun 5.x has a new bug which requires -t 10001. Your >mileage may vary. I found the offset to be CPU-specific. That means, when I needed to have one CPU replaced, I had to re-find the right 'tick' value for that specific board. It looks like the clocks are just made with a larger tolerance than NTP can handle. For each box running xntp, I build a file /etc/ntp.tick that contains the tick value. I have values between 9997 and 10001, just to keep the offset between +- 100 ppm on 4/280, 4/490, 4/690, 4/60, 4/65.. For a new CPU, I just set ntp.tick to 9999, let xntp run a day, change ntp.tick if the offset is out of range, re-start xntp, and retry. This usually stabilizes withing a few days. If the offset is much too high (>250ppm), I found that xntp does not obtain lock at all. These are all 4.1.3 machines. Geert Jan ============================================================================ From: mose@ns.ccsn.edu (Russell Mosemann) Subject: Re: NTP for VMS Date: 24 Aug 93 19:32:28 GMT Organization: Concordia College, Seward, NE irv@ccstat.mc.duke.edu writes: >I have been reading this group for a few months now and have never seen >mention of a version of NTP for VAX/VMS. I also checked the archives at >UDEL.EDU. Did I miss is or is there no version for VAX/VMS? There is no version that I know of unless you use Multinet. I am finishing a port of ntpdate to VMS. I need to smooth out the code in a couple of places and document it, but for the most part it is done. When it is complete, I will submit it to the archives. Watch this space for further news. If I get really exicted some day, I might try to port xntpd to VMS, but that won't happen for at least a year. -- Russell Mosemann Concordia College Voice: (402) 643-7445 Computing Center Seward, NE 68434 Fax: (402) 643-4073 ============================================================================ From: iglesias@draco.acs.uci.edu (Mike Iglesias) Subject: Re: NTP for VMS Date: 24 Aug 93 23:02:37 GMT Organization: University of California, Irvine Both Wollongong and Multinet support NTP for VMS. Wollongong is ntp v1, and I believe that Multinet is also. -- Mike Iglesias Internet: iglesias@draco.acs.uci.edu University of California, Irvine BITNET: iglesias@uci Office of Academic Computing uucp: ...!ucbvax!ucivax!iglesias Distributed Computing Support phone: (714) 856-6926 ============================================================================ From: Mills@UDEL.EDU Subject: Re: xntp problem Date: 25 Aug 93 00:00:22 GMT Wesley, The ntpdc works with NTP Version 1 implementations (ntpd) and not Version 2 nor Version 3 implementations (xntp, xntp3, xntp-jones). The equivalent program for the latter implementation is xntpdc included in the xntp3, xntp-jones distributions. This program also works with the Version 2 implemenation. Having said this, the program of choice to fondle v2 and v3 implementations is ntpq in the xntp3, xntp-jones distribution. This program conforms to the NTP Version 2/3 specifications rfc-1119, rfc-1305, respectively and should work with other implementations now coming online. The xntpdc program is very implentation dependent and nto likely to work with any other implementation. Dave ============================================================================ From: dkatz@CISCO.COM (Dave Katz) Subject: churchy.udel.edu Date: 6 Sep 93 20:32:42 GMT I did a little monitoring of churchy (a cisco IGS) which is filling in at a peer address that was idle for some months. In 20 minutes, 650 NTP requests were received from 106 hosts. Three sites had seven peers chiming with churchy. A number of the peers are running version 1 NTP. Looks like mucho cruft out there... ============================================================================ From: JDB6@psuvm.psu.edu Subject: Novell server time module available Date: 14 Sep 93 17:58:24 GMT Organization: Penn State University There is now a directory on FTP.OTC.PSU.EDU which contains information and software for synchronizing time on Novell Netware servers with a Network Loadable Module (NLM) that uses the unix "rdate" protocol. This NLM will allow Netware servers to synchronize their time to time servers (eg: CLOCK.PSU.EDU) within one second of accuracy. This is not an implementation of Network Time Protocol (NTP), which could provide better accuracy. Novell has committed to that effort through the Distributed Time Service (DTS) portion of OSF's Distributed Computing Environment (DCE). An announcement on that from Novell will probably not happen before the first quarter of 1994. Delivery schedule is even more uncertain at this point. (Feel free to correct me if you know something more current. :-) *I don't speak for Penn State, Novell, or anyone else... * The following is an information file included in the directory: --- enclosed file follows --- Info on files in /pub/ntp/ms_dos/novell on ftp.otc.psu.edu. rdatenlm.txt This file. ASCII text. rdatenlm.zip PKZIPed (tm) RDATE.NLM and README.TXT. Binary file. --- beginning of README.TXT (extracted from RDATENLM.ZIP) --- This package contains an RDATE NLM for Novell Netware 386 (tm) +-------------------------------------------------------------------+ |Permission is hereby granted for this archive to be distributed via| |BBS, Compuserve, Anonymous FTP and any other means so long as no | |fee is charged for distribution and all components of this archive | |remain together. | +-------------------------------------------------------------------+ The RDATE NLM is Copyright (c) 1992 MurkWorks, All Rights Reserved. RDATE.NLM - 10/12/92 ** This is free software ** MurkWorks has provided this NLM to the Novell user community at no charge. Purpose: The RDATE NLM allows the supervisor to synchronize the time of a Novell NW386 file server with the time of a nearby Unix host (or any other host which supports the time protocol). [...] [eof] ============================================================================ From: jcs@zoo.bt.co.uk (John C Sager) Subject: Re: any reason for ntp/tcp service? Date: 21 Sep 93 09:19:07 GMT Organization: BT Laboratories, Martlesham, Ipswich, UK In article <27l3svINNb67@srvr1.engin.umich.edu>, darrin@engin.umich.edu (Darrin P Cardani) writes: > Several of our /etc/services files listed ntp as a tcp service only, or > as a udp and tcp service. The ones that listed it as tcp only, didn't work, > so I fixed them by changing it to udp. Is there any reason to include tcp > service, though? I have seen it on 2 platforms so far. SunOS 4 /etc/services files are/were all like this, probably due to a misunderstanding at Sun. Dunno about other manufacturers. As you say, a change to udp will fix it. John C Sager Mail: B67 G18, BT Labs Email: jcs@zoo.bt.co.uk Martlesham Heath Tel: +44 473 642623 IPSWICH IP5 7RE Fax: +44 473 637614 England Disclaimer: This is me, not BT. ============================================================================ From: eggert@twinsun.com (Paul Eggert) Subject: Re: Puzzled about leap seconds Date: 22 Sep 93 02:29:03 GMT Organization: Twin Sun Inc, El Segundo, CA, USA t.d.g.sandford@bradford.ac.uk (Thomas Sandford) writes: I think it means that ntp maintains the clock as though leap seconds do not exist. I'm not quite sure what you mean, but if you mean that NTP forgets past leap seconds, you're correct. Therefore on a system running ntp your timezone file must *not* contain any leap second entries. That depends on what you mean by ``your timezone file''. If you're maintaining an astronomical application synchronized with NTP, there's a good chance you will need a leap second database (if NTP suffices at all). But if you're merely maintaining a Unix (or, more precisely, a Posix.1) host, then you probably don't need leap second entries, since Posix.1 pretends that leap seconds don't exist and this maps conveniently into NTP's fire-and-forget leap second handling. Also could you enlighten my ignorance. What exactly is TAI? The quick answer is that TAI is Temps Atomique International, i.e. International Atomic Time. UTC = TAI + (integral leap second corrections). The exact answer is a bit much to cover in a Usenet article, but here's my best shot. TAI is established on the basis of clock comparison data supplied to the Bureau International des Poids et Mesures by timekeeping labs around the world. It is a coordinate time scale defined in a geocentric reference frame with the SI second as realized on the rotating geoid as the scale unit, i.e. it is not a proper time scale if you take relativity into account. To find out exactly what TAI is, see B. Guinot and C. Thomas, ``The establishment of International Atomic Time'', BIPM Annual Report of Time Section 1, part D (1989). More accessible reports appear in Metrologia 24, 195-198 (1987), Metrologia 28, 57-63 (1991), and Proc IEEE 79, 894-905 (1991). ============================================================================ From: beland@ireq.hydro.qc.ca (Jean Beland) Subject: Re: NTP-client for MAC Date: 24 Sep 93 14:38:48 GMT Organization: Hydro-Quebec Another NTP client for Macintosh is "Network Time 2.0", from Peter Resnick. Available by anonymous FTP at sumex (shareware). -- Jean Beland | Institut de Recherche d'Hydro-Quebec Chercheur / Research Worker | 1800 Montee Ste-Julie, tel: (514) 652-8076 | Varennes, Quebec, CANADA. J3X 1S1 fax: (514) 652-8424 | Internet: ============================================================================ From: mingo@panix.com (Charlie Mingo) Subject: Re: NTP-client for MAC Date: 26 Sep 93 04:56:50 GMT In article , Rick Thomas wrote: > >Seriously, could somebody put it up for anonymous FTP? If I had a place >to point to, I'd put a notice of it in the FAQ. I posted a copy to mac.archive.umich.edu. It should appear in a few days. ============================================================================ From: tas@concert.net (Tim Seaver) Subject: SunOS zs serial port delays Date: 24 Sep 93 16:25:03 GMT Organization: CONCERT Network This may be old news to most of you running STREAMS kernel drivers for radio clocks on Sun workstations, but I don't recall it being mentioned before. In the course of tracking down a 30 millisecond variation in timestamps on our WWVB radio clock PPS signal, I discovered that, by default, SunOS only services the zs serial port receive buffers every 3 clock ticks. There's an internal flag used with the mouse port that allows immediate interrupts, but I could find no way to set it from user mode (other than by patching the kernel with adb once the port is open). What this seems to imply is that every radio clock kernel module running under SunOS on the zs serial ports should do a putctl1(WR(q)->q_next, M_CTL, MC_SERVICEIMM) in the module open routine to pass the MC_SERVICEIMM (service immediately) flag to the zs serial driver. In the xntp3 distribution, the dcf77 driver does set this, but the other kernel modules don't. Setting this flag dropped a 30 millisecond variation in our PPS timestamps to under 100 microseconds and quite often under 10 microseconds over 5-10 second intervals. Tim ============================================================================ From: pb@swan.cl.cam.ac.uk (Piete Brooks) Subject: Re: XNTP3 on a Sun-3 Date: 27 Sep 93 21:44:55 GMT Organization: U of Cambridge Computer Lab, UK In article <28739v$ous@spatula.csv.warwick.ac.uk> cudep@csv.warwick.ac.uk (Ian Dickinson) writes: >Could anyone provide correct values for Sun4m SunOS4 and Sun4d SunOS5 please? * -20 for the former (well, that's what I use). >I don't know how to calculate these values so far. * The code I use (in my clock driver) just finds the time to read the clock. * Old Sun4s increment the usec each time the clock is read, then suddenly * jumps up 20ms. So this is a plausible kind of guess as to what it might * approximate to ... * Try it a few times, or better still, just keep reading the clock and printing * the deltas. If you have multicast, look at the code to check the idle time * of an MBone mrouted -- it's tweaked to do go fast -- microtime makes quite a * change :-) /* Find the precision of the system clock by reading it */ #define USECS 1000000 #define MINSTEP 5 /* some systems increment uS on each call */ #define MAXLOOPS (USECS/9) static int ees_get_precision() { struct timeval tp; struct timezone tzp; long last; int i; long diff; long val; gettimeofday(&tp, &tzp); last = tp.tv_usec; for (i=0; i< 100000; i++) { gettimeofday(&tp, &tzp); diff = tp.tv_usec - last; if (diff < 0) diff += USECS; if (diff > MINSTEP) break; last = tp.tv_usec; } syslog(LOG_INFO, "I: ees: precision calculation given %duS after %d loop%s", diff, i, (i==1) ? "" : "s"); if (i == 0) return -20 /* assume 1uS */; if (i >= MAXLOOPS) return EESPRECISION /* Lies ! */; for (i=0, val=USECS; val > 0; i--, val /= 2) if (diff > val) return i; return EESPRECISION /* Lies ! */; } ============================================================================ From: armand@bcvms.bc.edu Subject: Re: network time server recommendations? Date: 27 Sep 93 18:35:02 GMT Organization: Boston College In article <1993Sep27.121527.1@bcvms.bc.edu>, armand@bcvms.bc.edu writes: > > I'm interested in dedicated Network Time Servers, specifically their relative > price/performance/reliability information. I've seen an ad for Bancomm's > Tymserve(tm) box in a recent trade journal, but have nothing to which to > compare it. Any help would be appreciated. Since this question is likely to > have been asked many times in the past, a reference to when it was last > discussed would give me a place to start. > I guess I spoke/wrote too quickly. I just found a list of timecode receivers currently available on the market in CLOCK.TXT Any experiences and/or recommendations would still be welcomed. Armand --- Boston College Computer Center Internet: armand@bc.edu 140 Commonwealth Ave. Bitnet: armand@bcvms Chestnut Hill, MA 02167 ============================================================================ ============================================================================ From: Mills@UDEL.EDU Date: 1 Oct 93 18:33:07 GMT Dave, See the file clock.txt in the pub/ntp/doc directory on louie.udel.edu for a comprehensive list of public primary and secondary servers, along with advice on how to set up a local NTP subnet. Advice can also be found in the doc directory of the xntp3.3.tar.Z distribution in the pub/ntp directory on louie. Dave ============================================================================ From: denny@eng.sun.com (Denton Gentry) Subject: Re: tickadj -A on Solaris Date: 4 Oct 93 17:55:02 GMT Organization: Sun Microsystems Computer Corp In article k7s@spatula.csv.warwick.ac.uk, cudep@csv.warwick.ac.uk (Ian Dickinson) writes: >That's the 'problem' - Solaris 2.2 has been fixed to work correctly. >You only need to call tickadj with the -s flag to turn off dosynctodr, >tickadj doesn't exist anymore and tick is correct. You can also turn off dosynctodr in the /etc/system file, by putting in a line as follows: set dosynctodr=0 (Just on general principles, to avoid mucking around in a running kernel with tickadj -s). Denny ============================================================================ From: WhiskerP@logica.co.uk (Peter Whisker) Subject: Re: NTP for DOS? (We've done everything else...) Date: 12 Oct 93 11:02:03 GMT Organization: Logica DCG Ltd. In article fitz@wang.com (Tom Fitzgerald) writes: >From: fitz@wang.com (Tom Fitzgerald) >Subject: NTP for DOS? (We've done everything else...) >Date: Tue, 5 Oct 1993 03:22:29 GMT >Macs and Novell servers are covered - but how about DOS clients? Anyone >have NTP client code for them? Even a simple boot-time ntpdate equivalent >would be welcome. >This should probably be in the FAQ too, if someone has an answer to it. Perhaps this might help ... ;************************************************************************* ;** USING PDCLKSET TO SET THE PC SOFTWARE CLOCK ** ;************************************************************************* ;** ** ;** PDCLKSET sets the time and date of the PC clock using a TIME server.** ;** To do so, the following information is required: ** ;** ** ;** - This clients unique IP number. ** ;** - The IP number of an UDP/IP time server (most Unix systems). ** ;** - The time zone offset from UTC (GMT) at this place. ** ;** - If daylight saving (summer) time is used, which algorithm to use. ** ;** ** ;** All the above info can be supplied as arguments to PDCLKSET. If any ** ;** of the first three are missing, it will send a BOOTP request to try ** ;** to find the missing info. If you are not using BOOTP you probably ** ;** must use gateway and mask arguments too. Except for client IP number** ;** and network mask, arguments to PDCLKSET override BOOTP info. ** ;** Using a BOOTP server is highly recommended, freeware code exists ** ;** for Unix systems and MSDOS PCs. ** ;** ** ;** BOOTP can not supply which dst algorithm to use; also, zone offset ** ;** can't always be trusted. So, in practice, zone offset and dst algo- ** ;** rithm (if applicable) are required arguments. On the other hand, ** ;** these parameters will stay the same all around the year, no need to ** ;** change the setup. ** ;** ** ;** If PDCLKSET finds more than one time server (sum of arguments and ** ;** BOOTP fields) and the first one does not answer, it will try the ** ;** other servers. The same applies for gateways. ** ;** ** ;** It is very hard to get accurate info on all the dst algorithms used ** ;** all over the world, so the one you choose, you should test out. Use ** ;** the alter argument to add or subtract time and days, and check that ** ;** the dst switch occurs correctly. When using the alter argument, the ** ;** date and time is displayed as usual, but the PC clock is not set. ** ;** If you find any errors, mail me the correct info to my mail address ** ;** below. If you want to, you can customize your own dst algorithm, ** ;** see detailed info below. ** ;** ** ;** PDCLKSET talks to the network card via a packet driver. If you have ** ;** more than one packet driver, it will use the first one (lowest ** ;** packet interrupt number) unless you use the pktintno argument. ** ;** I have only tested PDCLKSET with Ethernet or Ethernet simulating ** ;** packet drivers. I have one report that it works with S&K FDDI ** ;** interfaces, if so it should work for token ring too, but I've got ** ;** no confirmation on that. ** ;** ** ;** Running through remote bridges or slip links may require longer ** ;** than default timeouts. Add the number of extra seconds you need ** ;** with the argument LongerTimeout= time. ** ;** ** ;** If you want to omit the "End of pdclkset..." msg, add Flag=128 ** ;** ** ;** In AUTOEXEC.BAT you should first load the packet driver, then call ** ;** PDCLKSET. It is very small (13 kbyte) and executes fast, so you will** ;** not notice any delay. PDCLKSET is not memory resident and does not ** ;** use any CONFIG.SYS devices, so no memory is wasted. Use TERMIN.COM ** ;** if you want to unload the packet driver. See call syntax below. ** ;** Note: If you always log into a Novell server after a boot, you ** ;** don't need this program, the PC clock will be set from the server. ** ;** However, if you are the supervisor, use PDCLKSET+SRVTIME to set it ** ;** (available at msdos.ftp.sunet.se:pub/network/novelutl/srvtime). ** ;** ** ;************************************************************************* ;** USING PDCLKSET TO SET A TIMEZONE VARIABLE ** ;************************************************************************* ;** ** ;** PDCLKSET can also assign the proper normal or dls timezone name to ** ;** an environment variable (TZ is used by most systems). Argument ** ;** "Zone= #" will assign numeric zones to TZ (like TZ=+0100). If you ** ;** want anything else, use the alternative syntax, e.g. ** ;** "Zone= tzone=MET,METDST" will set TZONE=MET or METDST. ** ;** ** ;************************************************************************* ;** SYNTAX AND EXAMPLES FOR TIMESETTING ** ;************************************************************************* ;** ** ;** (time is [- | +] [h] [m] [[s]] ) ** ;** ** ;** pdclkset (displays a usage message) or ** ;** ** ;** pdclkset b[ootp] (only if dst not used) or ** ;** ** ;** pdclkset [o[ffset]=time] ** ;** ** ;** [d[aylightsave]=PAC | USA | CUB | CHIL | BRZ | GBR | ** ;** W_EU | M_EU | E_EU | LIBY | EGY | TURK | ** ;** ISR | IRAN | PRC | ROK | AUS | TASM | ** ;** NSW | LHI | NZE | ** ;** FrTime,FrWeekDay,FrDayOfYear, ** ;** ToTime,ToWday,ToDayOfYr,AddTime] ** ;** ** ;** [z[onename]= # | varible=normalname,dlsname ** ;** ** ;** [i[pnr]=n.n.n.n] [t[imservers]=n.n.n.n[,n.n.n.n[,...]]] ** ;** ** ;** [m[ask]=n.n.n.n g[ateways]=n.n.n.n[,n.n.n.n[,...]]] ** ;** ** ;** [p[ktintno]=hexnr] [a[lter]=days,time] [f[lags]=flagnr] ** ;** ** ;** [l[ongertimeout]=time] ** ;** ** ;** ** ;** All arguments to pdclkset must be on the same line, no continuation.** ;** For arguments to BAT files, use ":" instead of "=" and ";" instead ** ;** of "," . ** ;** ** ;** Valid flags for this mode: ** ;** 128 = half quiet (skip the End of pdclkset line if no errors) ** ;** ** ;** Examples: ** ;** ** ;** pdclkset o= -1h d=M_EU z=# (my IP nr and timeserver(s) from BOOTP)** ;** ** ;** pdclkset offs=6h dst=USA zonename= tz=CST,CDT (sets TZ=CST or CDT) ** ;** ** ;** pdclkset o=8h d=PAC ip=123.45.6.7 ts=123.45.6.8 (BOOTP not used)** ;** ** ;** pdclkset o=-9h30m t=1.2.3.4 i=2.3.4.5 g=2.3.4.1 m=255.255.255.0 ** ;** ** ;** ** ;** Part of an AUTOEXEC.BAT file may look like this: ** ;** ** ;** \net\wd8003e -w 0x7d 3 0x280 0xd000 (install packet driver) ** ;** \net\winpkt 0x7c 0x7d (install winpkt driver) ** ;** \net\pdclkset o=-1h d=M_EU z=# (set PC clock and TZ) ** ;** ** ;** If you don't want to keep the paket drivers in memory, add the ** ;** following line: ** ;** ** ;** \net\termin 0x7c (remove packet drivers) ** ;** ** ;** If you just need timesetting, use pdclksml instead of pdclkset. ** ;** ** ;************************************************************************* ;** WHERE TO GET IT FROM ** ;************************************************************************* ;** ** ;** Current version of PDCLKSET can be obtained by anonymous FTP from ** ;** ftp.lu.se:/pub/network/pdclkset/pdclkxxx.zip or from ** ;** msdos.ftp.sunet.se:pub/network/pdclkset/pdclkxxx.zip or from Novell ** ;** server LUSTORFS/ARC:PUB\NETWORK\PDCLKSET\PDCLKxxx.ZIP ** ;** (Netware access only in Lund and around). ** ;** Major releases will also be available on wsmr-simtel20.army.mil and ** ;** its mirror archive sites in the msdos.pktdrvr directory. ** ;** ** ;* * ;* Jan Engvald, Lund University Computing Center * ;* ____________________________________________________________________ * ;* Address: Box 783 E-mail: Jan.Engvald@ldc.lu.se * ;* S-220 07 LUND Earn/Bitnet: xjeldc@seldc52 * ;* SWEDEN (Span/Hepnet: Sweden::Gemini::xjeldc) * ;* Office: Soelvegatan 18 VAXPSI: psi%2403732202020::xjeldc * ;* Telephone: +46 46 107458 (X.400: C=se; A=""; P=Sunet; O=lu; * ;* Telefax: +46 46 138225 OU=ldc; S=Engvald; G=Jan) * ;* Telex: 33533 LUNIVER S * ;* * ;************************************************************************* Peter Whisker ============================================================================ From: Mills@UDEL.EDU Subject: Re: Looking for NTP for SVR4 Date: 12 Oct 93 01:51:44 GMT Ash, Yes, the latest xntp3.3 has a SVR4 port. There is quite a bit of information in the various README and man pages scattered through the directories. Most directories have READMEs describing the contents. The build process is mostly automated, unless you have an oddball Unix port. For even more information, see the pub/ntp/doc directory on louie.udel.edu. Dave ============================================================================ From: schaede@lan.ccit.arizona.edu (Barry Schaede) Subject: Re: Looking for NTP for SVR4 Date: 12 Oct 93 19:04:10 GMT Organization: U. of Az. Center for Comp. & Info. Tech. In article <9310112134.AA07630@fender>, ash@DEVNULL.MPD.TANDEM.COM (Ashvini Nangia) says: > >tex deleted... > I'm also interested in using a "radio-clock" as the external > time source. If you have any information or tips as to where > I can get the hardware (who sells it in the US) that would > be very helpful. > We purchased the UTS-10, which is a radio receiver with display and an RS-232 port from Odetics. Their address is: Odetics - Precision Time Division 1515 South Manchester Avenue Anaheim, Ca. 92802-2907 Phone 714-758-0400 ============================================================================ From: amoss@picton.cs.huji.ac.il (Amos Shapira) Subject: clockdiff - measure difference in clock among UNIX machines Date: 19 Oct 93 17:58:48 GMT Organization: Inst. of Comp. Sci., Hebrew University, Jerusalem, Israel Hello, Here is a small programme to measure the difference in the clocks among machines across an Internet network. It consists on just one file so I didn't bother to package it or anything. It is also available for anonymous ftp on host ftp.huji.ac.il file /pub/network/clockdiff.c.gz (in Gzip format). I don't know how accurate this programme is, will appreciate any feedback. Read the comments at the beginning for more info. Bye, --Amos [[ It was 500 lines long, so I deleted it -- get it from FTP or send mail to Amos -- Rick]] ============================================================================ From: rbthomas@jove.rutgers.edu (Rick Thomas) Date: Fri, 22 Oct 93 17:27:03 EDT Subject: RE -- What I've learned about sun clocks and ntp In a previous article, joey@tessi.com (Joey Pruett) says -- %>Let it run for at least a day, if not longer. %>Over that time it should be able to figure out how bad your %>clock is. This value is recorded in the driftfile (usually %>/etc/ntp.drift) and is updated once an hour. Monitor this and when it %>seems to have stabilized for a couple hours, you should be ready. %>Kill the ntp server when you're ready to fiddle with things. %> %>Now the value you will want to use for 'tick' is 10000 + int(drift/100). I have a couple of comments based on talking with a friend of mine who has a Solbourne with a particularly horrible clock. First, the formula Joey gives is appropriate for xntp version 3, only. The units of the number reported in the drift file changed between version 2 and version 3. For those of us still running version 2 (or -- horrors! -- version 1) there is a different formula. The version 3 "drift" value is reported in part per million. "Tick" is parts per 10000, so the "100" in Joey's formula comes from 1000000/10000 = 100 (As a side note, the "parts-per-million" is really "parts per 2^20", so the "real" value of the denominator should be 104.8576, but who's counting?) The version 1 and 2 "drift" value is in parts per 4096. "Tick" is still parts per 10,000, so we use 4096/10000 = 0.4096 as the denominator in these cases. Hence, for ntp (v1) and xntp (v2), the correct "tick" value for use in the "tickadj -t " is 10000 + int (drift/0.4096) Second, you can tell if the drift value has stabilized by looking in your /var/adm/messages file (or wherever else you have configured the syslog deamon to put messages from xntpd) for hourly historical drift values. This advice is independent of which version of the software you are using. Rick ============================================================================ From: dundas@netcom.com (John A. Dundas III) Date: Sun, 14 Nov 1993 13:25:13 -0800 Subject: Macintosh NTP Client Could you please add the following to the NTP FAQ? Thanks...John Dundas Another NTP client for the Macintosh is 'NTP Client' by John Dundas. This shareware is available at a number of archives; use archie to search for 'macntp'. This software features the ability to use NTP over either UDP/IP or AppleTalk. (Special servers are required for AppleTalk. The author currently has servers implemented for Macintosh, VAX/VMS (AppleTalk for VMS), and A/UX. Contact the author for more details at dundas@netcom.com.) ============================================================================ From: duwe@immd4.informatik.uni-erlangen.de (Torsten Duwe) Subject: Re: xntpd 3.3a on Linux: stuck? Keywords: tickadj, Linux, PC Date: 24 Nov 93 13:35:34 GMT Organization: CSD., University of Erlangen >>>>> "HPA" == H Peter Anvin N9ITP writes: [...] HPA> However, when /etc/ntp.drift reached the value -100.0000 is got HPA> firmly stuck, [...] Yes, +-100 ppm is the limit, as you might know. One of the boxes I run Linux on (a 486dx33, OPTI cs) gets as bad as -330 ppm. How do I know ? tick adjustment - see below... HPA> tickadj just gives me "The value of tick is silly", this is after HPA> making a link from /vmunix to /usr/src/linux/zBoot/zSystem. Right - this would be the way to do old-fashioned, ugly /dev/kmem-ing in Linux, but even if you don't get errors it still wouldn't work. tick gets reset to 10000 every tick :-(. Looks like you're another customer for the hwtickadj for PCs I am (about) to write. It is going to do outb()s to adjust the divider value in the timer chip. Temporary workaround: fix the divider in linux/include/linux/timex.h (line 67:CLOCK_TICK_RATE) in steps of 100 (the resolution that gets fed into the divider). +100 compensates for approx. -83.8 ppm drift. After recompiling and booting the new kernel you should be fine. Hope that helps Torsten --- Torsten Duwe duwe@informatik.uni-erlangen.de | /etc/init: respawn failed. Friedrich-Alexander-Universitdt Erlangen-N|rnberg | fork license for Informatik IV (Betriebssyteme, verteilte Systeme) | uid 0 has expired. ============================================================================ From: shotokan@diku.dk (Kim H|glund) Subject: Re: HP problem with ntp Date: 30 Nov 93 08:45:57 GMT Organization: Department of Computer Science, U of Copenhagen darrin@engin.umich.edu (Darrin P Cardani) writes: >I have a handful of hp's running hp_ux90 which are losing sync like crazy >for some reason. We have several hp's running hp_ux90, which are running >fine. For some reason these few machines (all on different subnets, all >able to reach their broadcasters) are losing sync several times a day. >Has anyone heard of this, and does anyone know of a solution? They're logging >several thousand messages a day. Any help would be greatly appreciated. Several people (including myself) have experienced this with xntpd v3.3. For the time being I believe the solution is to use xntpd version 3.1. --Kim ============================================================================ From: scottr@news.plexus.com (Scott Reynolds) Subject: Re: HP problem with ntp Date: 30 Nov 93 19:36:46 GMT Organization: Plexus Corp. -- Neenah, Wisconsin In <1993Nov30.084557.18923@odin.diku.dk> shotokan@diku.dk (Kim H|glund) writes: >darrin@engin.umich.edu (Darrin P Cardani) writes: >>I have a handful of hp's running hp_ux90 which are losing sync like crazy >>for some reason. [...] >Several people (including myself) have experienced this with xntpd v3.3. >For the time being I believe the solution is to use xntpd version 3.1. I have been running xntpd-3.3b for the last week with no ill effects on both the 400 series HP-UX 9.0 and 700 series HP-UX 9.01 platforms. You might consider giving this a try. Don't forget to install (and run!) adjtimed. Note that the config script will understand the OS as v8, not v9. -- Scott Reynolds Assistant System Adminstrator Technology Group, Inc. scottr@plexus.com ============================================================================ From: philip@charon.citicorp.com (Philip Gladstone) Subject: Re: request for example kernel PLLs Date: 12 Dec 93 23:20:50 GMT Organization: Citicorp Duane Voth (duanev@mpd.tandem.com) wrote: : So, can anyone send me an example of a proper adjtime() (or ntp_adjtime()) : system call? Maybe even something with a PLL attached? We are running a : USL SVR4 kernel here. Please, no actual copyrighted code. You might like to look at the Linux kernel that includes a PLL clock implementation that seems to work. Look at your local Linux archive for sources or try tsx-11.mit.edu -- Philip Gladstone - Consultant Citicorp Global Information Network I don't speak for Citicorp. I presume that somebody else does! ============================================================================ From: duanev@mpd.tandem.com (Duane Voth) Subject: Re: ntp black box? Date: 10 Dec 93 22:56:13 GMT Organization: TANDEM Computers, Inc (MPD) In article <1993Dec8.194428.10913@advtech.uswest.com>, huntting@advtech.uswest.com (Brad Huntting) writes: > I'm looking for a dedicated "plug-n-play" stratum 1 ntp server to > attach to ethernet or fiddi. > > Does such a beast exist? Yes. I know of two from one company, there should be a couple more companies offering these things too... The Bancomm division of DATUM INC. sells: a) Tymserve 2000 LAN Time Server $ 8,500 b) BC700LAN GPS Network Time Server $12,700 You can get Global Positioning System receivers for both (prices quoted include GPS) to make it truely worthy of a stratum 1 server: accuracies quoted are less than +/- 2 usecs of UTC. If you have an IRIG time code source near by you can skip the GPS option and knock off $2k-$4k. The BC700 appears to free-run at 0.5ppm with an oven option to go to 0.002ppm! (thats right 2x10e-9!) Can't seem to find a ppm spec on the Tymserve - it may not free-run at all. Bancomm is in San Jose, CA 1-800-348-0648 I have not used one of these yet but hope to soon. ============================================================================ Date: Wed, 22 Dec 93 16:58:34 EST From: rbthomas@jove.rutgers.edu (Rick Thomas) Subject: Re: faster scrolling on raw SPARCstation screen Here is the NVRAM patch that speeds up scrolling on Sun4c bare consoles by copying the FORTH console driver into (fast) RAM, instead of allowing it to execute out of (slow) ROM. It incidentally fixes (most) of the dropped interrupts that cause "last adjustment didn't complete". Heed the warnings! Do NOT use this with early ROM revisions! Enjoy! Rick PS -- don't despair if you have a ROM rev below 2.2. Latest rev ROMs can be purchased from SUN for a cost of about US$50. > Date: Sun, 2 Jan 1994 21:47:41 -0800 > From: Nick Sayer > > I didn't see any mention of this... > > You can make a vast improvement both in the clock accuracy and the speed > of the ROM console (at the cost of 200K of RAM or so) with this (works > only with boot ROM rev 2.0 or higher, which should be available on > any sparc apart from the sun4_ kernel architecture. I just got an > upgrade for my SS1+ that bumped it up from 1.mumble to 2.9!): > ::::::::::::::: cut here and make an executable file :::::::::::::::::::::: #! /bin/sh echo 'Be VERY careful -- install this ONLY on machines with PROM revision 2.2' echo 'or higher. This will cause very unpeasant hangs in lower revs. "Very' echo 'unpleasant" means "refuses to boot and may require a service call to' echo 'get it fixed." On PROM revs equal to or later than 2.2, you can use' echo 'the "-N" sequence to set all EEPROM values back to factory default.' echo '(Hold down the key and the "N" key while the power is turned on.)' echo '' echo 'got that?' echo 'Answer "yes" to continue.' read answer if [ "$answer" != "yes" ] then exit 1 fi eeprom 'nvramrc=probe-all install-console ramforth : cache-page dup pgmap@ cacheable swap pgmap! ; up@ cache-page here origin do i cache-page pagesize +loop banner' eeprom 'use-nvramrc?=true' exit 0 ::::::::::::::: cut here and make an executable file :::::::::::::::::::::: ============================================================================ From: ken@sdd.hp.com (Ken Stone) Subject: Re: adjtimed dies on HP-UX 9.0 (s800) Date: 23 Dec 93 21:29:30 GMT Organization: Hewlett Packard, San Diego Division In article <1993Dec23.093917.13538@walter.cray.com> osh@cray.com (John O'Shaughnessy) writes: >I've installed xntp 3.1 on an HP 9000-845 running HP-UX 9.0. >It builds just fine, and when launched manually, runs just fine. >I've included the following in the /etc/netbsdsrc startup file: > > /usr/local/etc/adjtimed -r > /usr/local/etc/xntpd > >Both startup OK, but adjtimed dies immediately, with the following line >in syslog: > > Dec 22 18:06:16 a00308 adjtimed[188]: read message: Identifier removed Geez ... maybe this oughta go in the FAQ ? In a stock 9.X s700/s800 systems, there is a bug in DIAGMON that causes it to trash all message queues when it starts up. The possible solutions range as follows .... a. Get the DIAGMON patch from the response center .... b. Start adjtimed/xntpd shortly after DIAGMON (ie not in netbsdrc) c. Just don't run DIAGMON (ie comment it out in /etc/rc) And life will be much better ... -- Ken ============================================================================ From: Mills@UDEL.EDU Subject: Culturally correct chime Date: 1 Jan 94 21:37:43 GMT Folks, A problem previously mentioned and often casually ignored has come to the point I must vigorously protest; and, I suspect my problem may be generic to a bunch of other places. It has to do with the use of private, unannounced server resources. I have several private time servers here used for experiment and local service, one of which is being hounded by over 50 unapproved rascals, 12 of which from the same net(!). That breaks several of the culturally correct expectations spoused in the file clock.txt frequently announced to this list. I'd like these rascals to go away, especially as this host is used for all kinds of experiments and sometimes tells awful time. I'd rather not be more specific; but, if anybody is punching net 128.4 clocks other than public primary servers rackety.udel.edu (128.4.1.1) and churchy.udel.edu (128.4.1.2) and secondary server louie.udel.edu (128.175.1.3), I`d sure like them to contact me first. On a related matter, cultural correctness calls for no more than two clients from any net to gang up on any single primary server. On rackety I see as many as 19 clients from the same net! It may be time, as I had to do in the fuzzballs, to put code in the NTP daemon that enforces this. It's a terrible idea in the first place, since it introduces a serious hazard, should the primary server go berserk. In fact, rackety has a dead radio right now and is operating at stratum 2 by chiming another stratum-1 server. If that radio comes bum, all of our servers back out to a WWVB radio, which is not working correctly either. See what I mean? Finally, note that we have on the order of 1000 clients now honking our three servers, quite a few running old versions (1 and 2) of the protocol. The problem is, these versions do not scale back the rate of chime once the local clock has stabilized. There would be a considerable reduction in network loads (about a factor of 16) if these old versions could be upgraded to version 3 (xntp3.3b.tar.Z on louie.udel.edu in the pub/ntp directory). This is one of those problems that we tend to ignore until, one day, the network just freezes up. Dave ============================================================================ From: scoggin@delmarva.com (John K Scoggin Jr) Subject: Re: Question: How to time sync VAX/VMS and Ultr Date: 9 Jan 94 15:13:01 GMT Organization: Delmarva Power & Light In article 855@gtewd.mtv.gtegsc.com, gidleyk@gtewd.mtv.gtegsc.com writes: > A (hopefully) quick question for the "Time-Gods": > > We have a small isolated network, with a mix of VAX 4000's (running VMS) and > DECstation 5000's (running Ultrix 4.2/4.3a). The VAXes are all getting > IRIG-B time signals and having their internal clocks sync'ed to that. > We would like to have the VAXes distribute their time to the Ultrix > machines, especially to a database server machine. Is there a simple way > to accomplish this? Accuracy to less than one-half second is desirable, but > less than one second is probably OK. I looked that the latest NTP (v3) stuff, > but it is mostly greek to me, and I don't see anything that looks like it > will compile on the VAX/VMS systems. We use TGV Multinet - it has a version 1 NTP implementation. Old, but it is functional. - John ============================================================================ From: nsayer@quack.kfu.com (Nick Sayer) Subject: Re: Culturally correct chime Date: 12 Jan 94 14:27:57 GMT Organization: The Duck Pond public unix: +1 408 249 9630, log in as 'guest'. terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.) writes: >[...] I'm not sure what would be a good, inexpensive clock, though >[the two seem rather mutually exclusive 8-]. Does this mean it's time for a CHU preach? :-) A CHU receiver/modem is so durn close to being free I can't believe there aren't more of them among the stratum 1 population. Rather than bellow on and on, anyone who doesn't know about CHU, write me and I'll fill you in. The reader's digest version is: shortwave radio + 3 chips + Sun running 4.1.3 + 1 serial port = +/- 1-2 ms. ============================================================================ Date: Thu, 13 Jan 1994 15:40 -0500 From: SHIBUYA@process.com Subject: Re: Preliminary FAQ -- send updates to rbthomas@rutgers.edu Concerning the question "NTP on VMS", it will be appreciated if you could add our product TCPware from Process Software as another alternative for supporting NTP on VMS. -- Hiroto Shibuya Process Software Corporation Framingham, MA ============================================================================ From: mogul@pa.dec.com (Jeffrey Mogul) Subject: Re: Unix boxes with only timed Date: 14 Jan 94 03:05:41 GMT Organization: DEC Western Research In article <1994Jan13.160016.272@process.com> shibuya@process.com (Hiroto Shibuya) writes: >|>Speaking in generalities, all modern UNIXen will *support* NTP, though few >|>if any have it *bundled* with the OS. You'll have to obtain, compile and >|>configure it. Your machine will support NTP just fine. > >Of course. Please read 'support' as 'vendor support'. I'm interested in >this information since there is a demand to run timed on non-AIX box >connected to network primarily consists of AIX, which is currently using >timed for clock sync. I just wanted to find out if there is any other >machine with timed as 'vendor supported' clock sync mechanims so I can >have wider range of testing to interoperate with 'vendor supported' timed. DEC "supports" both NTP and timed as bundled parts of the ULTRIX and OSF/1 operating systems. From the Software Product Description for OSF/1: Network Time Protocol DEC OSF/1 provides the Network Time Protocol (NTP) Version 2 to syn- chronize and distribute the time for all machines in a network envi- ronment. The time synchronization daemon, xntpd, is used to distribute time to all machines in a network. Time Synchronization Protocol DEC OSF/1 provides Berkeley's Time Synchronization Protocol (TSP). TSP synchronizes the time of all machines in a network without ensuring the accuracy of the time that is provided. TSP = timed, I believe. I suspect that most other Unix vendors also support timed. -Jeff ============================================================================ From: per@erix.ericsson.se (Per Hedeland) Subject: Re: Unix boxes with only timed Date: 15 Jan 94 12:05:02 GMT Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden In article <2h5s95$ppi@spatula.csv.warwick.ac.uk> cudep@csv.warwick.ac.uk (Ian Dickinson) writes: >In article <2h5265$fbb@usenet.pa.dec.com>, > mogul@pa.dec.com (Jeffrey Mogul) writes: >>I suspect that most other Unix vendors also support timed. > >Most do. > >SunOS 4.x does (but no NTP). That's news to me - I certainly had to install it from 4.3BSD sources (+ some additions) back when I started to take an interest in correct timekeeping on our Suns (before I had learned about NTP:-), and the only timed I can find on my current SunOS 4.1.3 system is in /usr/local/etc, where it certainly wasn't put by Sun:-). >Miraculously, Solaris 2.x ships with neither NTP or timed. Seems that Sun's idea of timekeeping remains "use rdate every now and then"...:-( ============================================================================ From: Jerry_Scharf@corpmis.sjc.hw.sony.com (Jerry Scharf) Subject: Re: Latest/cheapest in GPS clocks ? Date: 21 Jan 94 03:32:53 GMT Your timing is perfect. My GPSWorld issue with the annual GPS receiver survey arrived yesterday. Here are some of the vendors that list clock support specificly. As Dave Mills said, you have to be a bit careful if you are after the full accuracy. I have left out a >$5K units, and have listed some OEM units, but it may be impossible for you to buy one of the OEM units, so I will list them last. I just gave one listing per company. This is a personal transcription of a manufacturers survey, so lots of things may not be just right, or omitted. One plug. We have the TrueTime unit, and have a driver ready for it. We like it alot. Jerry Scharf Banncom bc627AT $3695 pc board 6541 Via Del Oro, San Jose, Ca 95119 (408)578-4161 Datum 9390-52000 $4000 rack 1363 S State College Blvd, Anaheim, Ca 92806 (714)553-6333 Odetics GPSync varies rack 1515 S Manchester Ave, Anaheim, Ca 92802 (714)758-0400 Spectrum Geophysical GPS Time-Machine $2795 box 1900 W Garvey Ave S., Ste 200, West Covina, Ca 91790 (714)544-3000 Stellar GPS model 100 $2495 box 800 Charcot Ave, Ste 110, San Jose, CA 95131 (408)383-1515 Trak Systems 8821 GPS clock $3500 rack 4726 Eisenhower Blvd, Tampa FL, 33634 (813)884-1411 TrueTime GPS-TMS $3495 box 2835 Duike St. Santa Rosa, CA 95407 (707)587-1230 ---------- Magellan GPS Brain Timing ??? oem board 960 Overland Ct, San Dimas, Ca 91773 (909)394-5000 Trimble Acutime II ??? pod oem? 645 N MaryAve, Sunnyvale CA 94086 (408)481-8000 ============================================================================ From: rbthomas@frogpond.rutgers.edu (Rick Thomas) Subject: Re: Newbie questions. Date: 29 Jan 94 22:46:06 GMT Organization: Rutgers Engineering Supercomputer Lab robert@lunatix.lex.ky.us (Robert Sexton) writes -- robert> Hello All, robert> robert> After reading c.p.t.n for a while, I have decided to throw some robert> basics on the table. I have read the FAQ, but it seems awfully robert> slanted towards those people on BSD with access to the net. That's cause the people who have the answers are that kind of people. I'm afraid it's unavoidable. To try to redress the balance, I'll include this question and my answers in the FAQ. (Ahhh! The power of being an editor!) robert> 1. Do you have to meet an accuracy requirement to be considered robert> Stratum 1? Or is it enough to be connected to a radio clock? robert> I think I can use CHU to get accuracy to about 1 ms. One millisecond is just fine for a stratum 1 clock. As they say -- "Come on in, the water's fine!" And I might add, "And welcome! We can always use another stratum 1." robert> 2. I have the schematics for Marcus Leech's CHU reciever, but robert> are there less expensive oftions for getting radio time signals? robert> Can anybody recommend an inexpensive, easily interfaced radio robert> clock? I have considered using WWV, but it looks like the signal robert> may be harder to work with. Nick Sayer also has schematics for a CHU receiver he designed. His address is nsayer@quack.kfu.com . Take a look at them and see if they meet your needs better. robert> robert> 3. What sort of time signals are the ntp sources designed to robert> work with? will I have to write my own stuff for use with CHU? robert> SCO UNIX does have adjtime(), so I have the basic tools robert> available. Well, for your purposes, Nick Sayer has contributed a CHU driver for the current xntp (v3) that talks to his receiver. It may also talk to other CHU receivers as well. In any case, it shouldn't take too much work to make it talk to them. robert> 4. Is there any software out there for non-tcp time update? I robert> would like to offer time signals to BBS's in my area. Not that I know of. Why don't you write some? robert> Thanks for your time. And thank you for your questions. They are good ones. robert> Robert Sexton Rick ============================================================================ From: jcs@zoo.bt.co.uk (John C Sager) Subject: Re: It's Official: GPS Anti-spoofing Is Now on Continuously Date: 17 Feb 94 09:48:23 GMT Organization: BT Laboratories, Martlesham, Ipswich, UK In article , rbthomas@athos.rutgers.edu (Rick Thomas) writes: > > 1. CONDITION: A/S WAS ACTIVATED ON DAY 031 (JAN 31 94) AT 0000 UTC. > > DUE TO THE 8 DEC 93 DECLARATION OF INITAL OPERATIONAL CAPABILITY > > (IOC) THE P-CODE WILL NOT NORMALLY BE AVAILABLE TO USERS WHO DO NOT > > HAVE VALID CRYPTOGRAPHIC KEYS (IAW FEDERAL RADIONAVIGATION PLAN 1992). > > Can somebody who knows tell us all what this means to us? > If I get a good answer, I'll put it in the FAQ. > GPS signals carry two sets of codes, the C/A code, with a chip rate of 1.023 MHz, which is the one used by civilians, and also helps the military receivers to lock on quickly. The other code is the P/Y code, with a chip rate of 10.23 MHz. This is used by military receivers and is capable of higher location accuracy. The P code is published, and was in use hitherto. The Y code is an encrypted version of the P code, and is now used instead. To use it you need a P-code receiver with a decrypter, and a source of keys from the DoD (I assume they are security-conscious enough to change them periodically!). The term 'anti-spoofing' is used because it is now all but impossible for anyone to create false GPS signals which could fool a military receiver. This is probably of little consequence to most NTPers, as we all use C/A code GPS receivers, ie they only use the civilian code. (Anyone want to own up to using a P/Y code receiver for timekeeping?). John C Sager Mail: B67 G18, BT Labs Email: jcs@zoo.bt.co.uk Martlesham Heath Tel: +44 473 642623 IPSWICH IP5 7RE Fax: +44 473 637614 England Disclaimer: This is me, not BT. ============================================================================ Date: Fri, 4 Mar 94 14:11:13 EST Return-Path: kherron@s.ms.uky.edu (Kenneth Herron) Subject: Re: Preliminary FAQ -- send updates to rbthomas@rutgers.edu Organization: University of Kentucky, Dept. of Math Sciences The two entries that mention "-t 9999" on suns could be more clear that this is only right for the sun4 (i.e., sparc) architecture. The standard tick value on sun3's is 20,000 so -t 9999 makes it run at just about half speed (which is so terrible that xntp 3 gives up :-) ============================================================================ From: dupuy@cs.columbia.edu (Alexander Dupuy) Subject: Re: NTP in demand dialup network Date: 4 Mar 94 00:25:16 GMT Organization: Columbia University Department of Computer Science I posted a somewhat longish message a month or so ago about running NTP over demand-dialup IP. You can check the ppp-users archive at ftp.morningstar.com, or the NTP mailing list archive (is there one?). The brief summary is that you should use xntpdc, not ntpdate, synchronized with a few secondaries (if you can teach your demand dial software not to bring up the link just because there's an NTP packet which wants to go out). Set up a local clock "peer" at stratum 5 or 6, so that xntpdc will stay synchronized when the link is down. Link up times of only slightly more than 5 minutes appear to be sufficient to keep my IPX within 50 msec of our secondaries, once the drift rate is accurately calculated (this may take a day or two). ============================================================================ From: jcs@zoo.bt.co.uk (John C Sager) Subject: Re: DST switching Date: 10 Mar 94 09:08:57 GMT Organization: BT Laboratories, Martlesham, Ipswich, UK ks0102@cetrel.lu (KESSELER GEORGES) writes: > Hi, > > how does an unix machine decide when it has to change to DST? As I understand xntp does not provide > this information to unix as it works in UTC. Is there an algorithm or a table in unix for DST? As you say, the system clock keeps UTC time (on a correctly configured system). The kernel & library routines which provide timezone and DST information refer to one of a set of files in a directory somewhere. On Sun systems this is /usr/share/lib/zoneinfo, but it may be elsewhere on other systems, eg /etc/zoneinfo. The method of selecting the file differs. On BSD-type systems a hard link is made between the particliar zone info file and a filename 'localtime' in the zoneinfo directory. On SVR4-type systems, an environment variable, TZ, is set to the name of the file to be used. The file contains information about the zone offset from UTC, and the dates of DST changes. Look at the man pages for zic(8), zdump(8), & tzfile(5) for more info. ============================================================================ From: J.vanOuwerkerk@delftgeot.nl (Hans van Ouwerkerk) Subject: PC sync solutions needed (Reply) Date: 23 Mar 94 11:52:47 GMT Norman H. Chang from Hewlett-Packard Laboratories asked: > > We would like to sync PCs running MS-DOS and Windows3.1 to 0.1 sec > across LAN/WANs. > What solutions exist out there? > Up to now I saw no answer to this question. We use LAN Manager, sold to us by Hewlett-Packard :-) The server runs xntp and when people login to the fileserver for LM (HP 9000/817) the PC is synchronised with the server. I suppose this is accurate to 0.1 sec, but of course the clock of the PC will drift away in the course of the day. Maybe this can help Norman if he uses LAN Manager. ============================================================================ From: slade@wrc.xerox.com (Mike Slade) Subject: Re: PC sync solutions needed (Reply) Date: 23 Mar 94 14:36:26 GMT A similar solution exists if you are running PCNFS. As part of the bootup sequence and after PCNFS is started, do an 'rdate' command to your favorite NTP machi ============================================================================ From: kardel@nessy.informatik.uni-erlangen.de (Frank Kardel) Subject: Re: please answer: slewing the time on a "local clock" master server. Date: 26 Mar 94 10:29:27 GMT Organization: CSD., University of Erlangen duanev@mpd.tandem.com (Duane Voth) writes: >In article <199403151940.OAA01649@marlins.ctron.com>, hendrick@marlins.ctron.com (James R. Hendrick) writes: >> >> Hi, >> Pardon me if this is a trivial question. I have a machine running >> xntp that runs a bit fast. Recently, someone "pointed out" that my servers >> clocks were all 5-10 minutes fast. I have looked and cannot seem to find a way >> to do the equivalent of: "date -a -600". I tried this first, and it seems >> that xntp won't let this adjustment occur (maybe it is due to date's use of >> adjtime??) I am running "tickadj -A -s" on boot time before starting xntp. From the manual (doc/xntpd.8): The local clock driver uses only the fudge time1 parameter. This parameter provides read and write access to the local clock drift compensation register. This value, which actu- ally provides a fine resolution speed adjustment for the local clock, is settable but will remain unchanged from any set value when the clock is free running without external synchronization. The fudge time1 parameter thus provides a way to manually adjust the speed of the clock to maintain reasonable synchronization with, say, a voice time announce- ment. It is actually more useful to manipulate this value with the xntpdc(8) program. Thus you can use the "fudge 127.127.1.x time1 x.xxx" command to change the speed of your clock to gradually get in sync with reality. (You must have configured keys and passwords in order to be able to use remote configuration from xntpdc. If you didn't do that you have to re-start xntp anyway with a new config file.) There is another parameter which will set the total offset of the ntp clock (time2). This will allow to correct for the absolute error. The comment in the code indicates that this method works best if the daemon was compiled with SLEWALWAYS. By looking at the code I got an initial impression that it might even work without SLEWALWAYS compiles in, but no guarantees here. So to sum up: - You must have configured xntpd for remote configuration if you want to avoid re-starting it. - xntpdc: fudge 127.127.1.x time1 x.xxx will modify the drift rate of the local clock and thus allow you to gradually get in sync with reality (semiautomatic process - you have to figure out the intrinsic drift of your system) - xntpdc: fudge 127.127.1.x time2 x.xxx will (hopefully) change the system time to match reality. You still have to figure out the intrinsic drift. This is not tested and might not do what you and i expect. - get a real reference clock and forget the problem above (sorry - but I had to mention that 8-) Frank Kardel (time@informatik.uni-erlangen.de) ============================================================================ From: kardel@immd4.informatik.uni-erlangen.de (Frank Kardel) Subject: Re: lower stratum host is terminated Date: 25 Mar 94 21:00:41 GMT Organization: CSD., University of Erlangen tommy@crd.yokogawa.co.jp (Tomi Masahiko) writes: >Running xntpd in these environment, strange behaviour was observed. >Problem was that when offset exceeded approximately 1000 seconds, >xntpd of host_B (stratum 2) was terminated, and never recovered. >(Actually this is not confined to broadcast mode, it also occurs >in both client/server and peer mode.) >We would like to know > > (1)if this matter is specified, Yes, its the CLOCK_WAYTOOBIG define in include/ntp.h. > (2)if so, whether it is possible to change the "critical offset value > (this time 1000s)" and it is unique to hp-ux. No it is common for all normal xntp configurations on all platforms. You can change it if you want (you have the source). An error of more than 1000 secs is very unusual so exiting is a valid option on such misconfigured systems (initial time zone configuration errors or wacky hardware clocks or long downtimes). There is a compile time option to avoid the exiting of the daemon when the time exceeds CLOCK_WAYTOOBIG. Define BIGTIMESTEP to keep xntp running even if the local clock is off by more than CLOCK_WAYTOOBIG seconds. ============================================================================ From: kardel@nessy.informatik.uni-erlangen.de (Frank Kardel) Subject: Re: NTP client? Date: 26 Mar 94 09:51:58 GMT Organization: CSD., University of Erlangen victor@mickey.cc.utexas.edu (V Menayang) writes: >Frank Kardel wrote: >> >>Well, then use ntpdate from the xntp distribution and throw the rest >>away. >> >Thanks, to you and others who responded to my query. >I finally decided to get the whole xntp package and compile >the ntpdate utility. BTW, perhaps because how I configure >the compile, I can only query NTP V3 servers. Is this an expected >behavior of the ntpdate V3? Yes, unless you specify "-o " on the command line. Version 3 is the default. If you want to query version 2 servers just do a "ntpdate -o 2 ". ============================================================================ Subject: NTP internet survey Date: 14 Mar 94 15:50:34 GMT Organization: CSD., University of Erlangen Here are the results of the latest NTP network survey. The NTP synchronisation network was scanned via NTP control messages. This survey just shows the ntp hosts reachable from the University of Erlangen in the time frame below. NTP synchronisation net statistics ================================== Information reflects the state of the net as reachable from University of Erlangen-Nuernberg, Germany. It is based on information collected from Thu Mar 3 10:39:22 GMT 1994 to Mon Mar 14 15:15:02 GMT 1994 The most recent NTP host was discovered Mon Mar 14 15:15:02 GMT 1994 The database reaches back to Thu Mar 3 10:39:22 GMT 1994 Number of hosts: 6774 OK out of 21148 queried Strati: S-1: 73, S-2: 1867, S-3: 4834, (higher strati have not been considered) Versions: v3: 4516, v2: 2258, Bad hosts: Timeout on connect: 11565 Protocol error : 9 Hosts at Stratum 1: v3: 64, v2: 9, Hosts at Stratum 2: v3: 1288, v2: 579, Hosts at Stratum 3: v3: 3164, v2: 1670, Analysis per toplevel domains: Stratum 1 Stratum 2 Stratum 3 Bad Hosts Domain Total v3 v2 | Total v3 v2 | Total v3 v2 | Timeout Protoco --------------------------------------------------------------------------------------- ARPA : 0 0 0 | 1 0 1 | 3 2 1 | 0 0 AT : 1 1 0 | 15 15 0 | 3 2 1 | 37 0 AU : 2 2 0 | 43 32 11 | 112 29 83 | 363 0 BE : 0 0 0 | 8 7 1 | 28 28 0 | 6 0 CA : 3 3 0 | 63 40 23 | 229 156 73 | 314 0 CH : 2 1 1 | 123 46 77 | 186 82 104 | 835 1 CL : 0 0 0 | 3 2 1 | 1 1 0 | 2 0 COM : 8 7 1 | 246 187 59 | 292 169 123 | 1402 2 DE : 14 14 0 | 233 142 91 | 738 364 374 | 674 0 DK : 0 0 0 | 8 6 2 | 29 24 5 | 108 0 EDU : 10 6 4 | 433 286 147 | 1902 1399 503 | 3039 0 ES : 0 0 0 | 7 6 1 | 44 44 0 | 8 0 FI : 0 0 0 | 2 2 0 | 15 14 1 | 32 3 FR : 1 1 0 | 15 13 2 | 39 30 9 | 104 0 GB : 0 0 0 | 1 1 0 | 0 0 0 | 0 0 GOV : 9 8 1 | 151 69 82 | 144 117 27 | 512 0 IE : 0 0 0 | 5 5 0 | 7 7 0 | 42 0 IL : 1 1 0 | 1 1 0 | 5 5 0 | 17 0 IS : 0 0 0 | 4 0 4 | 0 0 0 | 0 0 IT : 0 0 0 | 3 2 1 | 12 11 1 | 26 0 JP : 1 1 0 | 37 27 10 | 125 64 61 | 101 0 LU : 0 0 0 | 1 1 0 | 0 0 0 | 2 0 MIL : 0 0 0 | 26 21 5 | 64 48 16 | 215 0 MX : 0 0 0 | 2 2 0 | 3 3 0 | 7 0 MY : 0 0 0 | 2 2 0 | 3 3 0 | 3 0 NET : 7 7 0 | 70 54 16 | 85 81 4 | 96 0 NL : 1 1 0 | 47 40 7 | 120 51 69 | 257 0 NO : 0 0 0 | 9 9 0 | 253 121 132 | 209 0 NZ : 0 0 0 | 3 2 1 | 0 0 0 | 1 0 ORG : 2 0 2 | 16 13 3 | 11 8 3 | 226 0 PL : 0 0 0 | 2 2 0 | 1 1 0 | 4 0 PT : 0 0 0 | 4 4 0 | 5 4 1 | 9 0 SE : 1 1 0 | 22 19 3 | 18 13 5 | 55 0 SI : 0 0 0 | 3 3 0 | 1 1 0 | 4 0 SU : 0 0 0 | 3 2 1 | 0 0 0 | 2 0 UK : 9 9 0 | 223 205 18 | 283 244 39 | 791 2 US : 0 0 0 | 1 1 0 | 0 0 0 | 7 0 ZA : 0 0 0 | 0 0 0 | 1 0 1 | 4 0 [UNRESOLVED] : 1 1 0 | 31 19 12 | 71 38 33 | 2036 1 seahawks : 0 0 0 | 0 0 0 | 1 0 1 | 0 0 --------------------------------------------------------------------------------------- *TOTAL* : 73 64 9 | 1867 1288 579 | 4834 3164 1670 | 11565 9 Following domains only had not responding hosts: BG, CZ, HR, SG, TH, lepton, pentium, righton. The "top level domains" seahawks, lepton, pentium an righton are a result of misconfigured reverse address translation information. Frank Kardel & Rainer Pruy ============================================================================ From: kardel@nessy.informatik.uni-erlangen.de (Frank Kardel) Subject: Re: DST switch time Date: 21 Mar 94 20:01:06 GMT ks0102@cetrel.lu (KESSELER GEORGES) writes: >Hello, >I have the following machines syched via ntp: ultrix, AIX, HP-UX, SCO, TandemUX >The big question is now: will they all switch to DST at the correct time? Ok, frustrating answer time: Ask your vendor whether their timezone library works correctly and how it is configured correctly. The DST switch is not a matter of NTP. Its a matter of the timezone code in the library anf its configuration. This question is the yearly fun part. Which vendors/sysadmins did it right this year in the current OS version ? Actually I don't know which OS will do it right in what configuration. One thing is sure - NTP does not have anything to do with it 8-). NTP just chews on UTC. The only problem UTC introduces is the leap seconds. So June 30th will be the time where we all sit and watch the leap second and what it will do to our receivers an the leap second code in xntp 8-). ============================================================================ From: per@erix.ericsson.se (Per Hedeland) Subject: Re: please answer: slewing the time on a "local clock" master server. Date: 29 Mar 94 22:25:20 GMT Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden In article <2n12q7Elio@uni-erlangen.de> kardel@nessy.informatik.uni-erlangen.de (Frank Kardel) writes: [ lots of good stuff about how to tweak xntpd to keep better time when synced only to the local clock ] >Thus you can use the "fudge 127.127.1.x time1 x.xxx" command to change >the speed of your clock to gradually get in sync with reality. Back before we had Internet access, I used this technique with very good results - of course, to avoid having to do a lot of boring measurements and calculations, I made a little script 'xntpdadj' to do them for me: "Xntpdadj will, given an observed deviation from real time, and knowledge ... about the time elapsed since the last time of agreement with real time, a) adjust the clock (slowly) to agreement with real time, and b) set a new time1 value that should keep the clock in better agreement in the future." I have put this script along with some info etc up for anon ftp in euagate.eua.ericsson.se:/pub/unix/networking/xntpdadj.shar - note however that it was written for, and has only been tested with, V2 xntp - it should be possible to modify it for V3 though (it *does* need to be modified). I also eventually combined this script with a program that dialed up one of those time-via-modem places to get a good offset from real time, and ran it from cron every 6 hours, feeding the offset into xntpdadj if it was > 50 ms - which it actually rarely was after a while (this was with the clock of a good old VAX 11/750, sitting in a cooled computer room, though...). --Per Hedeland per@erix.ericsson.se or per%erix.ericsson.se@sunic.sunet.se or ...uunet!erix.ericsson.se!per ============================================================================ From: kardel@nessy.informatik.uni-erlangen.de (Frank Kardel) Subject: Re: lower stratum host is terminated Date: 30 Mar 94 12:09:33 GMT Organization: CSD., University of Erlangen tommy@crd.yokogawa.co.jp (Tomi Masahiko) writes: >In such cases that the host whose local clock was without >battery is booted (which means there is no guarantee that >offset is under 1000s), > (1) do we need to adjust the local clock manually? > (I mean, the only way to avoid the problem mentioned > before is to insert "ntpdate" in the /etc/rc.local > start up script?) This is one solution which might fail if ntpdate doesn't find any hosts suitable for synchronisation. In that case it will not correct the clock and the daemon would still give up. > (2) Otherwise, xntpd has a drive doing it automatically? > if yes, I would like to know how to configure. It would if the offset is less than CLOCK_WAYTOOBIG. There is, however, a compilation option where xntp will not give up on large offsets. Compile xntpd with -DBIGTIMESTEP and xntp will set the local clock to whatever time it finds via the NTP protocol. This may or may not be a good idea to do. Most offsets > CLOCK_WAYTOOBIG stem from misconfigured time zone information (leading to a wrong utc time in the kernel although date seems to show the correct time) and thus should be corrected before xntp is brought into operation. If you can trust your synchronisation network and the system configuration the BIGTIMESTEP option can be used to force xntp to set the time to network time even when the offsets exceeds CLOCK_WAYTOOBIG. Frank Kardel (time@informatik.uni-erlangen.de) ============================================================================ From: ken@sdd.hp.com (Ken Stone) Subject: Re: when is drift value used Date: 14 Apr 94 23:03:46 GMT Organization: Hewlett Packard, San Diego Division > (1)I'd like to know how and when adjtimed uses "skew" and "drift", > which are first and second derivative of offset with time > respectively. This drift value is updated every polling? It doesn't ... all adjtimed does is talk to code in xntpd and emulate the BSD adjtime(2) system call. > (2)The other is about "tick" and "tickadj". I don't understand > what these variables(tick and tickadj) originally mean. > I mean how these variables are estimated and how will be used. > And are these variables only for adjtime()? Not used by "adjtimed"? tick and tickadj are meaningless (more or less on HP-UX right now. > (3)It is said drift balue is specific to the computer xntp runs > on(parameter of the computers oscillator). > Is there any relation between drift value and these > variables(tick and tickadj)? Not on HP-UX ... at least yet anyway :-) HP-UX 9.03 for the s300's is shipping now and while it does not have xntpd shipped with it (and probably never will ?) ... it does have the adjtime(2) system call !! Look for NTP support and adjtime(2) on s700/s800 at 10.0. -- Ken ============================================================================ From: brett@airgun.wg.waii.com (Marc Brett) Subject: Re: HELP WITH CONFIG (Your opinions) Date: 14 Apr 94 11:09:24 GMT Organization: Western Geophysical, Div. of Western Atlas Int'l, Houston, TX Dave Zarnoch (davez@ibx.com) wrote: : A. Is my definition of a "peer" correct for the slaves? Looks OK to me. : B. In my definition for the clients, will they always : try to sync with the first server line or will they : take an average of the two servers and sync to this? : (I really don't want to overload one slave if they : will only read the first line only) Each machine looks at all of the servers and peers in its ntp.conf file and syncs to the "best" one. As the clocks stabilize, the total network load decreases, but all the servers and peers are sampled periodically (about every 1-17 minutes). : C. If my timeserver goes down or reboots, will the network : try to "keep up" until the timeserver comes back up? As you have set it up, if the timeserver goes down, then all the slaves and clients will be running free on their own clocks. Not good. To keep them all in sync, the slaves should have a "server 127.127.1.x" line, where x is greater than the timeserver's level. To avoid contention, the values of x should be different on the two peered slaves, say 127.127.1.5 on slv07_A and 127.127.1.6 on slv07_B, 127.127.1.5 on slv09_A and 127.127.1.6 on slv09_B (assuming that the A slaves have the better clocks). If both A and B slaves are at the same stratum, then the two slaves' clocks will drift apart and the clients will "clock hop" between the two. : D. Are these stratum levels correct? Free-running time servers probably should be at stratum 10. If the clients are nested deeply, then this could be raised so that no client tries to exceed stratum 16. : E. Is it necessary to add "ntpdate " to : my rc.local file also? No, but it is a very good idea. Why boot a machine with an inaccurate clock? All of our Suns have this in rc.local before the calls to tickadj and xntpd. if [ -f /usr/local/bin/ntpdate ]; then /usr/local/bin/ntpdate -b fi -- Marc Brett Marc.Brett@london.waii.com Western Geophysical Tel: +44 81 560 3160 ============================================================================ From: ken@sdd.hp.com (Ken Stone) Subject: Re: xntpd on HP Date: 14 Apr 94 23:06:41 GMT Organization: Hewlett Packard, San Diego Division >I have gotten xntpd version 3.3q which I plan to implement on an HP700 series >running HP-UX version 9. Is it true that this version has eliminated the time- >warping problem? Someone please let me know if this is so. I would also like >to know where the problem existed and how it was fixed. I have verified that it is gone at p ... so I would hope that anything after that is OK also ... the problem was in the handling of adjtime() failing. Just happens that on most machines, its pretty hard for a simple system call to fail ... whereas on HP's, adjtime() is anything but a simple system call :-( -- Ken ============================================================================ Subject: Re: ntp for dummies ... Date: 4 May 1995 18:15:27 GMT Organization: St. Louis Users' Groups Introduction to Network Time Synchronization with NTP Richard E. Schmidt Directorate of Time U. S. Naval Observatory 3450 Massachusetts Ave, NW Washington, DC 20392-5420 (202)653-0487 res@tuttle.usno.navy.mil NTP, the Network Time Protocol [DARPA Network Working Group Report RFC-1305], is a powerful utility for the synchronization of system clocks over TCP/IP networks. It can provide a precise time base for networked workstations and servers. At the root of an international timekeeping network are primary NTP time servers, those with atomic clocks, GPS or radio timing receivers. NTP provides a "software-only" solution for obtaining timing information from the servers over network connections, and optionally supports selected timing devices. The latest source code version with drivers for popular hardware clocks is also available via anonymous ftp from louie.udel.edu, in /pub/ntp. Because packet-switched network paths are largely non- deterministic, NTP provides the ability to accurately gauge roundtrip delays and local clock offsets from servers. Clock synchronization at the 10-millisecond level over long distance (2000 km) WANs, and at the 1-milllisecond level for LANs, is routinely achieved. Why synchronize system times? In "enterprise computing," "client/server computing", DCE-- or however one describes current computing systems--the isolated standalone processor is becoming increasingly uncommon. Simplified networking and the economies of small processors have spurred the growth of distributed processing systems that share common databases. Coordinated transaction processing and time- stamping of instrumental data are but two examples of the need for agreement about the time-of- day among involved processors. Use of the "make" facility over NFS mounts is another. System calls return clock time with microsecond resolution, but the uncompensated crystal oscillators in HP 9000 SPU's show typical drifts of 0.1 to 10 seconds per day - about 100 parts per million. Fortunately, the UNIX system clock can be controlled by software, and can be synchronized to an external source of time to a stability of milliseconds per day or better without any special hardware, and to microseconds per day with add-on hardware timing sources. NTP is a system of "architectures, algorithms, entities, and protocols"[1] for the synchronization of UNIX and non-UNIX hosts over local and wide area networks and (optionally) over local buses. Dennis Ferguson, Advanced Network Systems, is the original author of NTP. David Mills, University of Delaware, is the author of Network Working Group RFC-1305, the complete specification of the NTP implementation. An NTP synchronization subnet consists of a number of hosts that query time from remote networked time servers (peers), and that may or may not redistribute time to hosts at lower levels (strata) in the hierarchy of timekeepers. Typically, the top stratum (stratum 1, or primary servers) is populated with hosts with bus or serial interfaces to reliable sources of time, such as radio clocks, GPS satellite timing receivers, or atomic clocks. Stratum 2 servers might be company or campus servers that obtain time from some number of primary servers over Internet paths, and provide time to many local clients. The stratum 2 servers may be configured to peer with each other, comparing clocks and coming to a consensus on a synchronized time value. NTP operates well over the non-deterministic path lengths of packet-switched networks, because it makes robust estimates of three key variables in the relationship between a client host and a timeserver: network delay, dispersion of time packet exchanges, a measure of maximum clock error between the two hosts, and clock offset, the correction that should be applied to a client's clock to synchronize it. The standard NTP distribution includes configuration support and NTP drivers for a large number of timing receivers, including GPS satellite receivers, WWV radio timecode receivers, IRIG-b interfaces, and others that can be compiled into xntpd, the NTP daemon. There are even drivers for the NIST ACTS and Naval Observatory modem time services. Included in the standard distribution are the control and inquiry programs xntpdc and ntpq, a traceroute-like utility, ntptrace and an rdate-like utility, ntpdate, useful for resetting the system clock at bootup. Controlling the UNIX clock The generic UNIX system clock consists of an oscillator or frequency generator and a hardware counter which keeps track of the number of cycles and fractions of cycles since the clock was last initialized to some value. Typically overflow of the hardware counter triggers an interrupt to the system, about 100 times per second, and increments a software clock counter by a kernel variable called tick, which typically has the value 1/100 second, or 10,000 microseconds. In free-running mode the UNIX clock increments by one tick every 1/100th second. When corrections to the clock are to be made, it is desirable to change time smoothly rather than in jumps, and to avoid jumping backward in time. A second kernel variable, tickadj, allows one to run the UNIX clock at two more rates, by incrementing the soft clock by tick + tickadj microseconds per interval (to speed up the clock), or tick - tickadj microseconds per interval (to slow down the clock). A typical value for tickadj is 5 microseconds. Kernel tweaks to the UNIX clock are made accessible to privileged users via the adjtime(2) system call. The argument to the adjtime call is a signed timeval structure of seconds and microseconds of time to be added to the current system time. The time correction ë is not instantaneous. It is achieved over an interval t = ë(tick/tickadj), i.e., taking 2,000 times the size of the requested correction to be applied by smooth rate variations. The standard NTP distribution for HP-UX uses an adjtimed daemon written by Tai Jin of Hewlett-Packard. Obtaining and compiling NTP You can obtain a compressed tar file of the latest NTP release via anonymous ftp from louie.udel.edu in the /pub/ntp directory. As of April, 1995 xntpd3.4n.tar.Z was the latest release. The makefile is quite clever in poking around and determining what release of HP-UX you are running and whether to include its own adjtime code. The default "make" with no options builds an NTP suite for a host with no external reference clock. It will run off the local system clock if operating as a time server. Root can install the binaries with the "make install" command. Configuring NTP Before running NTP, let's configure a host as a client for a remote network time server. We are running HP-UX 9.03 on an HP9000//715 workstation. First we must create a config file /etc/ntp.conf. Here is a simple example that requests time from two high-stratum servers at the U. S. Naval Observatory: #/etc/ntp.conf for a machine in CLIENT MODE # #path to a place to record the clock frequency driftfile /etc/ntp.drift # # The server statement causes polling to be done in client mode # Here are two nearby time sources I can use: server 192.5.41.40 # tick.usno.navy.mil at USNO server 192.5.41.41 # tock.usno.navy.mil at USNO # # optional restrictions: (uncomment if needed) # restrict 192.5.41.40 # restrict 192.5.41.41 #here are some optional logging commands (uncomment if needed) #statsdir /usr/adm/ #statistics loopstats clockstats peerstats #filegen peerstats file peerstats type day enable #filegen loopstats file loopstats type day enable #filegen clockstats file clockstats type day enable #End of /etc/ntp.conf This is a minimal config file which specifies the IP addresses of two known time servers. The file /pub/ntp/doc/clock.txt on louie.udel.edu lists high-stratum time servers and their access restrictions. If you are adding a local hardware clock device, its driver is identified here by a directive like: server 127.127.XX.0 where 127.127 alerts NTP that this is a local rather than a remote network peer, and XX is a clocktype described in the NTP distribution. The restrict directive in this config file specifies that this host will only talk to the two IP addresses specified; it won't trust anyone else, and it won't serve time to anyone else. There are many restriction options documented in the distribution. For example, this host could be configured as a time server with the line: restrict default notrust nomodify which says that it will server time packets on request but will not sync to other peers. The statistics and filegen facility of NTP allows me to log records of my NTP performance. For example, the records in /usr/adm/peerstats have the format: MJD Second Peer IP Stat Offset Delay Dispersion 49815 60424.676 192.5.41.40 9614 -0.000040 0.00169 0.00793 This entry on Modified Julian Date 49815, at 60424.676 seconds since the beginning of the UT day, shows that compared to the time server at address 192.5.41.40 my clock was offset by - 0.000040 seconds. The network delay between us was computed as 0.00169 second (its actually only in the next room!), and the dispersion of a sample of delay estimates was 0.00793 seconds. The Stat field gives ntp status flags as detailed in the RFC-1305 document. The public NTP release includes utilities in the scripts/stats directory for summarizing these log files. Among other configuration options worth exploring are: broadcast mode, useful for synchronizing LANs with many nodes, and incorporation of the DES encryption algorithm for implementing "trusted" associations. Firing up NTP Next we create the (empty) file /etc/ntp.drift so that NTP can keep a record of its clock frequency updates. Now it is time to start up the external adjtimed daemon (Hewlett-Packard machines, pre-10.0/9.10 only), and secondly the NTP daemon. These commands can be put in /etc/rc : [ HP systems pre 9.10 need this: /usr/local/bin/adjtimed ] /usr/local/bin/xntpd You can verify NTP's operation by looking at the records it records in /usr/adm/syslog: Apr 8 16:07:46 tuttle xntpd[9892]: xntpd version=3.4n (beta multicast); Sat Apr 8 16:04:59 UTC 1995 (1) Apr 8 16:07:46 tuttle xntpd[9892]: tickadj = 5, tick = 10000, tvu_maxslew = 495 Apr 8 16:07:46 tuttle xntpd[9892]: precision = 23 usec Apr 8 16:07:46 tuttle xntpd[9892]: system event 1 status c010 Apr 8 16:07:47 tuttle xntpd[9892]: peer 192.5.41.40 event 84 status 9014 Apr 8 16:07:48 tuttle xntpd[9892]: peer 192.5.41.41 event 84 status 9014 Apr 8 16:12:03 tuttle xntpd[9892]: system event 4 status c621 Apr 8 16:12:03 tuttle xntpd[9892]: system event 3 status 634 Apr 8 16:12:03 tuttle xntpd[9892]: system event 4 status 643 Apr 8 17:07:46 tuttle xntpd[9892]: offset -0.000057 freq 11.108 poll 10 The status codes are defined in the RFC-1305 available via ftp. The offset and polls shown here are not representative of fresh installs. If your system clock time is very wrong, NTP will not trust external time sources for the first 15 minutes, during which you will see a number of lines saying something like: xntpd[163]: clock correction 100.516493 too large (ignored) followed after 15 minutes by the entry: xntpd[163]: clock reset (step) 100.516441 NTP will step initial clock offsets rather than attempt to slew the clock freqency. You will see messages such as: reset (step) -11.598845 This too is normal. How well does NTP work? An instant report on how well you are synched to your peers of choice can be obtained with the xntpdc utility included in the public distribution. The command xntpdc -c peers returns results as: remote local st poll reach delay offset disp ================================================================= =tock.usno.navy. 192.5.41.43 1 1024 377 0.00172 -0.000155 0.00786 *tick.usno.navy. 192.5.41.43 1 1024 377 0.00194 -0.000123 0.00787 NTP has been running for over a year on a local 802.3 LAN at the Naval Observatory in Washington, DC. Two HP9000/747i workstations have Datum/Bancomm bc635vme VMEbus interfaces to an IRIG-b source of timing from the USNO Master Clock #2 Sigma Tau hydrogen maser[2]. Following the example drivers for other hardware devices, an NTP driver for the Bancomm VME card was written and compiled as an NTP refclock. This application uses a Bancomm HP- UX kernel driver that fetches time from bus registers in a few tens of microseconds. [ Figures not included -Ed. ] Figure 1 shows a histogram of several months of comparisons of the UNIX system clock vs. the VMEbus clock, which is kept to within 125 microseconds of UTC(USNO). Figure 2 shows the system clock offset of a local HP9000/715 system peering to the two local time servers. Sub-millisecond synchronization is routinely achieved. Figure 3 shows an HP9000/425t system located in Miami, FL. To peer with the Washington servers it links through two 56kb lines and six or seven intermediate NASA routers. Even though pings can take up to a few seconds in heavy traffic periods, the system clock offset has been kept below 10 ms over many months. Figure 4 shows an experimental NTP time synchronization between Washington and Miami over 2B+D ISDN. HP ISDN BRI links on an HP9000/I60 and an HP9000/715 carried the NTP packets transparently, and millisecond synchronization--comparable to LAN offsets--is achieved. References [1] Mills, D. L., Network Time Protocol (Version 3) specification, implementation, and analysis. DARPA Network Working Group Report RFC-1305, University of Delaware, March 1992 [2] Schmidt, R. E. , Network Time Synchronization Servers at the U.S. Naval Observatory, Proceedings of the 26th Precise Time and Time Interval Applications and Planning Meeting, Dec. 1994, in press. From Markus Kuhn, Computer Science student ermkesj@su.ericsson.se (Kent Sjolund) writes: >I wonder what time is delivered in the GPS signal. I have heard that it is GMT? GPS delivers a time that is relative to UTC(USNO) better than 340 ns in 90% of all measurements. >And if so, what is the difference between GMT and UTC? GMT is a historic term which is today obsolete. It is today called Universal Time (UT). Universal time is the local time on the zero meridian which goes through the old observatory in Greenwich, London, UK. If you are interested in time more precisely than 1 s, then you have to make a difference between the following versions of universal time: UT0 is the precise siderial local time on the zero meridian. UT1 is UT0 corrected by a number of periodic effects (UT0 has different "speeds" at different times of the year). UTC is a time defined not by the movement of the earth, but by a collection of atomic clocks all over the world. When UTC and UT1 drift apart for more than 0.9 s, then a leap second will be inserted into UTC to correct this. The next leap second will be 1995-12-31 23:59:60 UTC, so watch you GPS receiver if it can really handle leap seconds. The C in UTC stands for "coordinated". UT2 is an even better corrected version of UT0 which is used in astronomy. GMT is a term that has been used before time was defined internationally by an atomic time reference in the late 1950s. People who talk today about UTC (e.g. BBC still uses this abbreviation for patriotic reasons ;-) really mean UT or more precisely UTC. TIA (fr. temps internationale atomique) is also a clock identical to UTC with the only exception that TIA has never any leap seconds, i.e., TIA is now 29 s ahead of UTC and will be 30 s ahead of UTC next January. TIA and UTC have been identical in the late 1950s, when atomic time was introduced. DUT1 is the difference between UTC and UT1 published by USNO rounded to 0.1 s each week. This results in the UT1 which is used e.g. for space navigation. If you are interested in UTC more precisely than a microsecond, then you also have to make the following difference: The abbreviation UTC can also be followed by an abbreviation of the organization who published this time reference signal. E.g. UTC(USNO) is the US reference time published by the US Naval Observatory, UTC(PTB) is the official German reference time signal published by the Physikalisch Technische Bundesanstalt in Braunschweig and UTC(BIPM) is the most official time published by a buero in Paris, however UTC(BIPM) is only a filtered paper clock published each year that is used by the other time maintainers to resynchronize their clocks against each other. All these UTC versions do not differ by more than a few nanoseconds. And there is of course also UTC(GPS). Information about the world time standard UTC (e.g. when will the next leap second be inserted in time, etc.) is available from the 'International Earth Rotation Service' (IERS) with anonymous ftp from mesiom.obspm.circe.fr. Also is a good start if you want to learn more about time and the USNO has also a good time web site, however I don't remember the URL. Markus --- Markus Kuhn, Computer Science student -- University of Erlangen, Internet Mail: - Germany WWW Home: