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

Previous part

From: "Richard Mayston" <R.Mayston@comnet.co.nz> [-/+]Date: Wed, 22 Jan 1997 01:30:34 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: NTP for WidowsNT

Marek Grinberg <marek.grinberg@mailbox.swipnet.se> wrote in article <32E4A92A.3F23@mailbox.swipnet.se>... > Hello, > > I am trying to build xntp 3-5.88 for WindowsNT in my Sparc box running > SunOS 5.5. > I did: > ./configure --target=i586-windowsnt > make > 1. Is this the correct way to do it ? > 2. What directories/files are to be put into a WinNT master/client ? > > Any help will be greatly appreciated.

Greg Schueman has produced an excellent precompiled/Installshielded kit for NT, it is available from Larry Kahn's FTP site as ntxntpbin-gui.zip email access@drcoffsite.com for info on getting it. regards, Richard Mayston. -- Richard Mayston Comnet Technologies Limited R.Mayston@comnet.co.nz http://www.comnet.co.nz/maystonr/

From: rbthomas@lilypad.rutgers.edu (Rick Thomas) [-/+]Date: 22 Jan 1997 16:39:13 -0500 [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: Weird behaviour with xntpd 5.86 under BSD/OS 2.1 X-Keywords: logconfig [-/+] syslog [-/+]

mikep@valhalla.comshare.com (Michael Pelletier) writes: <majorly snipped for brevity>

> It almost seems like there's >some other something adjusting the clock behind xntpd's back.

Is "timed" running on your machine? Does the OS default to trying to sync its software real-time-clock to the machine's hardware Time-of-Day clock? Either of these could cause what you are seeing.

>There's also nothing in syslog. Does anyone have suggestions on what >kind of ntp.conf logging to turn on to try to track down the problem >here? Thanks!

I put

logconfig all

in my ntp.conf file, and

daemon.debug /var/adm/debug.log

in my syslog.conf file.

I believe this gives me all the logging info there is to get.

> -Mike Pelletier.

Rick

From: nmm1@cus.cam.ac.uk (Nick Maclaren) [-/+]Date: 22 Jan 1997 22:46:04 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: How many ntp servers should a client use? [-/+]X-Keywords: SNTP [-/+]

In article <32E67D6A.6D2C@hlo.mts.dec.com>, Terry Lemons <Terry.Lemons@hlo.mts.dec.com> wrote: > >How many ntp servers should a client use? I _believe_ that, in ntp (not >sntp), all servers that a ntp client has been told about are used each >time synchronization occurs. Further, I'm wondering if 3 servers is a >magic number, lending itself perhaps to some ntp algorithrm.

This is related to the question "how many angels can dance on the head of a pin?" I.e. it is a religious matter.

The practical answer is to estimate the probability of one of your servers being down for long enough to matter, and then estimate how many backups you need to reduce that to an infinitesimal value. My limited experience is that one server is enough, if it is also your gateway or DNS server :-)

My SNTP program has no support for multiple servers, and has not so far had any problems. But (a) I have not been using it for a long time 'for real' and (b) I work in academia, and who gives a damn about reality, anyway?

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

From: rbthomas@lilypad.rutgers.edu (Rick Thomas) [-/+]Date: 22 Jan 1997 16:54:41 -0500 [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: Hardware recommendations (modem,radio,GPS?) X-Keywords: precision [-/+]

"Fletcher B. Cocquyt" <fletch@ttmc.com> writes: <snip>

>I'm trying to decide on hardware for the time signal receiving

>My requirements for the system are: >1) Accuracy to within 100 milliseconds (shouldn't be hard) >2) Can't be internet based (security policy) >3) Cost < $1000 >4) Works well with Suns and Solaris 2.5 >5) Easy to setup and maintain.

>From reading the docs of the xntp package I'm leaning towards a >radio receiver for cost and reliability reasons...can anyone >recommend a specific brand/model that integrates well with the >xntp package? Would being in the middle of the Atlantic present >radio range problems!?

Being in the middle of the ocean suggests that a GPS receiver would be best. The one I use is the "KSI/Odetics TSAT/S" which is a bit pricey for your specs (US$3000 list), but it couldn't be simpler to use. It's a GPS receiver that connects to an S-Bus card that plugs into one of the slots on your Sun's mother-board. It comes with a software driver that implements a device you can do "read()" syscalls from. The read() returns the current time of day to microsecond precision with accuracy determined by the uncertainty in the amount of time it takes your CPU to process a read() syscall (Typically less than 100 microsecs). The xntp3-5.88 tarball comes with a stratum-0 driver for it (called TPRO for obscure reasons).

Hope this helps!

Rick

From: Craig_Everhart@transarc.com Date: Wed, 22 Jan 1997 17:14:50 -0500 [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: Client needed [-/+]X-Keywords: daylight [-/+]

Excerpts from netnews.comp.protocols.time.ntp: 22-Jan-97 Re: Client needed Michael Shunfenthal@nept (375)

> The newer VCRs are supposed to be able to read time encoded in the TV > signal and set their displays. I have not seen one, though.

I replaced a VCR and the new one did this. The doc says that the PBS feed generally carries the clock synch, and that the machine will probe around, after you turn it ``off'', for this signal. There's a complicated description of the overrides necessary in case you want to direct the VCR to a specific channel. This one also seems to handle the case in which the VCR is in one time zone and the signal source is in another, where one or both might not support daylight savings. Pretty cute! But the really interesting part is that the synchronization seems to put the VCR clock *ahead* of UT by some fraction of a minute, like 15 or 30 seconds. I'd guess that this is a feature designed according to the observations: - most folks don't care if their household clocks are up to a minute off - people like programming the VCR to start at the documented times, e.g. from 8:00 to 9:00, rather than 7:59 to 8:59 (as I'd gotten used to) - the VCR needs a few seconds to warm itself up and start tape spinning before it can record.

Now, it seems to me that a cleverer design could have left the clock saying *accurate* time, simply adjusting the VCR to turn itself on a few seconds *before* the moment when the indicated show was to come on.

All just FYI as far as NTP is concerned, though.

Craig

From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]Date: 22 Jan 1997 21:50:01 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: Client needed [-/+]X-Keywords: DCF77 [-/+] NIST [-/+] WWVB [-/+]

Howdy, My new VCR searchs for a PBS station and does set its time to the signal found there. There is messy section of the manual to handle the problems with timezones. Only one of the stations in my area seems to be sending the signal.

With the upcoming power increase to WWVB, direct radio clocks might become built into many more consumer devices. NIST got a US Navy VLF transmitter and is boosting WWVB by 6 dB, if my memory serves. There was an article in Science News a couple of months back. Perhaps the US will be served almost as well as Germany via DCF77 and maybe cheap WWVB receivers will appear.

Bruce Bartram bbartram@etl.noaa.gov just another chimehead ----- Michael D. Shunfenthal (Mike) (shunfemd@neptune) wrote: : The newer VCRs are supposed to be able to read time encoded in the TV : signal and set their displays. I have not seen one, though.

: ----- This electronic message made entirely from recycled electrons : Michael Shunfenthal | : mdshunfenthal@tasc.com | The Analytic Sciences Corporation : shunfemd@rest.tasc.com | Reston, VA 22090 : Compuserve: 76320,122 | 703 834-5000 x2456

From: fvance@plum.wg.waii.com (Frank Vance) [-/+]Date: 23 Jan 1997 21:53:43 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: Client needed [-/+]

Craig_Everhart@transarc.com wrote: : Excerpts from netnews.comp.protocols.time.ntp: 22-Jan-97 Re: Client : needed Michael Shunfenthal@nept (375)

: > The newer VCRs are supposed to be able to read time encoded in the TV : > signal and set their displays. I have not seen one, though.

: I replaced a VCR and the new one did this. The doc says that the PBS : feed generally carries the clock synch, and that the machine will probe : around, after you turn it ``off'', for this signal. [Further interesting discussion removed for brevity....]

Is this signal good enough to use as a reference clock for NTP? Who's going to build the first receiver-clock to extract the time from the PBS ether and provide it on an RS-232, in a useful format for xntpd?

But seriously, what is the origin of this time at each station? Is it traceable to the Naval Observatory?

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

From: "L. F. Sheldon, Jr." <lsheldon@creighton.edu> [-/+]Date: Thu, 23 Jan 1997 13:23:29 -0600 [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: How many ntp servers should a client use? [-/+]

On 23 Jan 1997, Ulrich Windl wrote:

> A heuristic approach: Why having at least three NTP servers for a client? > With one server you can't know whether the reported time is good. > With two servers you can find out if both servers agree on the time. > Beginning with three servers cou can make bets which server is more likely > to report the correct time ;-) > > Maybe this non-technical explanation helps a littele bit...

I have been following (and participating, I think) in this discussion, but there _is_ something that bothers me--and Old Saying (I have no idea where I first heard it--less about who might have first said it):

A man with two watches never knows what time it is".

-- -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- . . - L. F. (Larry) Sheldon, Jr. - . Unix Systems Administration . - Creighton University Computer Center-Old Gym - . 2500 California Plaza . - Omaha, Nebraska, U.S.A. 68178 We are all faced with - . lsheldon@creighton.edu great opportunities . - 402 280-2254 (work) brilliantly disguised as - . 402 681-4726 (cellular) impossible situations. . - 402 977-2946 (pager) - . 402 332-4622 (residence) Bits and Pieces . - - .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.

From: Terje Mathisen <Terje.Mathisen@hda.hydro.com> [-/+]Date: Thu, 23 Jan 1997 10:40:58 +0100 [-/+]Newsgroups: comp.protocols.time.ntp Subject: [++] Re: NTP for Novell? X-Keywords: FAQ [-/+] Novell [-/+] release [-/+]

Bret Watson wrote: > > A tired old question no doubt, but the FAQ version at > http://www.eecis.udel.edu/~ntp/ is two years old. > > Is there a NTP client/server for NOVELL? Novell's SYNC.NLM is not really > as stable as I'd like.

No, but there will be: I have been told that in a future NW release (5.0?), the use of XNTP instead of TimeSync will be optional.

Terje

-- - <Terje.Mathisen@hda.hydro.com> Using self-discipline, see http://www.eiffel.com/discipline "almost all programming can be viewed as an exercise in caching"

From: nmm1@cus.cam.ac.uk (Nick Maclaren) [-/+]Date: 28 Jan 1997 15:17:14 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: sntp/ntp middleground [-/+]X-Keywords: broadcast [-/+] dispersion [-/+] implementation [-/+]

As soon as I finish testing and package my latest version of msntp, you will be able to see :-) Roughly:

1) Take N packets and choose the best. For broadcast, that can mean only the (relatively) earliest, modified by the server's dispersion, and you have to guess at the error. For client server, you can do quite well (< 0.02 seconds relative to a local server, a couple of Ethernet segments away).

2) Take N packets at widely separated times, and estimate the correction and drift by regression. That is what my new code does. I am a bit suspicious about it, because it is printing unreasonably low estimates for the error in the drift, but otherwise it seems to work fairly well. I may have forgotten my statistics, of course!

My code does not use multiple servers, but that is really only necessary for very high reliability requirements. The other gain from the drift code is that it should survive quite long periods of server absence (depending on the parameters set).

Incidentally, all of the techniques I use predate NTP, often by centuries.

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

From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]Date: 28 Jan 1997 19:11:40 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: sntp/ntp middleground [-/+]X-Keywords: implementation [-/+] monitor [-/+]

stephen (stephen@lila.york.ac.uk) wrote: : i'm interested in getting reasonable (~100ms) time accuray : for a leaf node. xntpd seems over the top for this purpose, : while (so far as i can see) a direct sntp implementation : basically does

: send ntp packet : receive reply : believe what it says

: which gives no real information on the errors. what : algorithm could be employed to provide a reasonable : middle ground between full ntp and sntp, ie consults : several servers and takes into account transit times, : yet doesn't attempt the complexities of full ntp in : resolving these?

: thanks for any suggestions, : stephen

Have you considered "cron ntpdate <server> <server> <server>" combined with freq trim or tickadj -t xxxxx to get the clock to a reasonable drift rate ? Assuming 50 ppm drift and hourly cron, I think the accuracy is about 0.18 sec.

This is the simplest system I can see and it doesn't use use any memory all the time.

The advantage of full up xntp is having the same code everywhere, the ability to remote monitor, and the xntp team keeps improving and porting it to zillions of systems and OS upgrades. The cost is having the fairly large program locked in memory. I'm not really sure as to how to read my ps listing when a program locks because I think it locks the libs, too, but the libs are still useful to all the other processes. The 1.6 MB I see might be larger than the real impact (about 10 $ these days).

I hope the efforts for a middle ground can be fitted back into the main distribution so they will effectively become ported to all the supported systems. A small main section that uses ntp lib modules and includes might be a way to do it easily.

Happy chiming !

Bruce Bartram bbartram@etl.noaa.gov

From: nmm1@cus.cam.ac.uk (Nick Maclaren) [-/+]Date: 29 Jan 1997 11:45:31 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: sntp/ntp middleground [-/+]X-Keywords: configuration [-/+] monitor [-/+]

In article <5clj1c$sve$1@mwrns.boulder.noaa.gov>, bwb@etl.noaa.gov (Bruce Bartram) writes: |> |> Have you considered "cron ntpdate <server> <server> <server>" |> combined with freq trim or tickadj -t xxxxx to get the clock |> to a reasonable drift rate ? Assuming 50 ppm drift and hourly |> cron, I think the accuracy is about 0.18 sec.

I can do much better than that for 55 ppm drift and hourly packets without using the (grossly system-dependent) tickadj. But I agree that is the simplest way of using xntp if your system has it.

|> The advantage of full up xntp is having the same code everywhere, |> the ability to remote monitor, and the xntp team keeps improving |> and porting it to zillions of systems and OS upgrades. The cost |> is having the fairly large program locked in memory. I'm not |> really sure as to how to read my ps listing when a program locks |> because I think it locks the libs, too, but the libs are still |> useful to all the other processes. The 1.6 MB I see might be larger |> than the real impact (about 10 $ these days).

The disadvantage is that it is over a month's work for a real expert to port it to a new system, with no guarantee of success, and serious long-term maintenance problems. Full NTP is really something that should be implemented as part of the base system, by the system vendor. It is not the sort of thing that a local site should install itself.

But we have to live in an imperfect world :-(

|> I hope the efforts for a middle ground can be fitted back into |> the main distribution so they will effectively become ported |> to all the supported systems. A small main section that uses |> ntp lib modules and includes might be a way to do it easily.

It would be nice, but the xntp configuration will have to be improved by two orders of magnitude, and the system-dependencies isolated, before that becomes feasible.

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

From: hakanson@weasel.cse.ogi.edu (Marion Hakanson) Date: 28 Jan 1997 17:43:13 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: Determining active clients for NTP

In article <5cb5g5$aj11@farstar.frb.gov>, Greg G. Goldstein <m1ggg00@newfed.frb.gov> wrote: > . . . > I guess I am looking for something like an 'ntpping' which ping via > port 123 to see if there is a connection. > . . .

I just use: ntpdate -d <host> | tail -1

If the <host> in question has a working NTP server, you get an indication of how far off its clock is from the host you run the command on. If not, you get "no server suitable for synchronization found".

-- Marion Hakanson <hakanson@cse.ogi.edu> Systems Manager, CSE Computing Facilities.

From: rdodson@sonalysts.com (Robert Dodson) Date: Tue, 28 Jan 97 21:00:56 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Handy perl script X-Keywords: delay [-/+] poll [-/+]

Below is a handy little perl script to see how your ntp clients are doing. It primitive but works. It will hang for a while if a host it down. Note: you must add your host names to the @hosts list.

Enjoy, Rob

------CUT HERE------------------- #!/usr/local/bin/perl # # Collect NPT info from around the net. # # require 5.000;

@hosts= ( 'host1', 'host2', );

# force flush after every write select STDOUT; $| = 1;

printf("Host Time Source Reference Delay Offset St\n"); printf("-----------------------------------------------------------------------------------------\n");

$max_offset = 0.0; foreach $host (@hosts) { printf "%-14s ",$host;

`ping $host -n 1 > /dev/null`; if ( $? == 0) {

open(NTP,"/usr/sbin/ntpq -c rl -c peers $host 2> /dev/null |") || die "ntpq error\n";

$more = 0; while(<NTP>) { # # clock line from rl command # if (/^clock/o) { ($clock,$dayname,$Mon,$day,$year,$time,$phase) = split; ($time) =~ (s/,$//o); # rip trailing comma printf "% s ",$time; }

# # data line from peers command # if (/^[-*+ox#. ][a-zA-Z]+.*/o) { printf(" ") if ($more);

($remote,$refid,$st,$t,$when,$poll,$reach,$delay,$offset,$disp)=split; printf "%-16s %-16s %8.3f %8.3f %3d",$remote,$refid,$delay,$offset,$st;

if (abs($offset) > $max_offset) { $actual_max = $offset; $max_offset = abs($offset); $max_host = $host; }

printf "\n"; $more = 1; } } printf "down\n" if ($more == 0);

close(NTP); } else { printf "down\n"; } }

printf "\n";

exit 0;

<< Robert Dodson - Sonalysts, Inc. - Waterford CT USA >>

From: robk@oldtimer.win-uk.net (Robin Kimberley) [-/+]Date: Wed, 29 Jan 1997 08:37:18 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: Standalone network time servers? X-Keywords: Datum [-/+] TrueTime [-/+]

In article <32EE6AA7.5287@mitre.org>, Jerry Bass (gbass@mitre.org) writes: >Who else besides TrueTime and Datum make nice compact standalone network >time servers (GPS or externally fed)? > >I've seen the TrueTime NTS-100 and the Datum Tymserve 2000.

Datum now have a new model Tymserve 2100, with enhanced features, and lower price - it really is the best on the market.

Rob Kimberley

robk@oldtimer.win-uk.net rkimberley@sematron.demon.co.uk

From: m1ggg00@newfed.frb.gov (Greg G. Goldstein) Date: 29 Jan 1997 22:14:03 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: running multiple xntp3-5.86 gives obscure error message

you can start xntpd with -p [filename] and it will create a PID file for you.

In article <WIU09524.97Jan29124003@rrzc5>, wiu09524@rrzc5 (Ulrich Windl) writes: > Can't xntpd write a PID file itself? Would be simpler (= more simple)... > > -- > Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>

-- Gregory Goldstein Information Systems Analyst Federal Reserve Board ggg@frb.gov

From: "Greg Schueman" <schueman@ix.netcom.com> [-/+]Date: 31 Jan 1997 05:45:31 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: NTP for Windows NT X-Keywords: Trimble [-/+] Windows [-/+]

Brian L. Bowers <bowers@mtm.syr.lmco.com> wrote in article <32EFA89F.7731@mtm.syr.lmco.com>... > I am just coming up to speed with Network Time Protocol and would > appreciate some feedback, to some basic assumptions and questions I am > forming, as I scale the learning curve. > > I have been browsing this newsgroup, and the NTP web site > (http://www.eecis.udel.edu/~ntp/) for information, and have a general > idea of what is available, but I have not yet put all the pieces > together. > > I am in hope of obtaining a time synchronization story for an isolated > LAN which has mixed platforms ~UNIX SUN & DEC workstations and Windows > NT Dec Alpha�s and Intel Pentium PC�s. I also currently have Trimble > Acutime II Gps(s) as available time sources. I am interested in hosting > an NTP reference clock driver ( GPS ) or at least LOCAL_CLOCK reference > driver on two or more of the Windows NT machines, and synching the rest > of the network to them. > > Assumptions: True or False. Feel free to elaborate where necessary. > > 1. xntpd is public domain software, derived from many contributors, > localized at the University of Delaware. >

True.

> 2. Some version of xntpd does seem to be bundled with various UNIX OS > platforms. (i.e. Dec OSF, Solaris... ) but not all the major OS players > ( i.e. Microsoft�s Windows NT ).

True.

> > 3. xntpd 3.5x source can be downloaded and compiled for various OSs > including Windows NT.

True.

> > 4. xntpd source includes available reference clock drivers. > > 5. xntpd 3.5f source has been ported to Windows NT ( Greg Schueman ). > However no reference clock drivers were ported, not even for type 1 > local clock.

Get XNTP 3-5.87.6 source for the latest revision on Windows NT that includes local clock support. Later versions are experiencing some portability cleanup work that is still shaking out.

You can get intel binaries at: ftp.drcoffsite.com For access send email to <access@drcoffsite.com>. Larry Kahn has been kind enough to host a set of binaries. Look for ntxntpbin-{ gui or nongui }.zip

> > Questions: > 1. I have seen several mentions about Windows NT but I don�t understand > what my options are for this OS. How is Windows NT supported in the > world of NTP?

It's a full server, other than no reference clock support excepting the local clock.

> > 2. As part of the xntpd download, are the reference clock drivers > included, and do you use a compile option to make them available in an > image? > > 3. I have read news messages indicating that there are compile flags to > create a NT image. Does this mean that I can move the code, as is, to > an NT machine and run the make file on the PC to create an image ( How > can this be?). When someone indicates an NT �port� of xntpd are they > referring to a recompile with compile flags or actually modifying the > source code? I don't understand, but the port involved changing the source. I am not the only person involved. Viraj Bais started the port originally.

> 4. I have read news messages indicating that an NT port of v3.5-87 has > local clock support. How do I get and use this?

See above.

> > Possibly all I need is a shove in the right direction and some > clarification on how NTP and Windows NT work together. Please provide > the shove, just not too hard!

Hope that helps.

Greg Schueman

From: nmm1@cus.cam.ac.uk (Nick Maclaren) [-/+]Date: 30 Jan 1997 13:12:35 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: msntp-1.2 now available (SNTP client/server) X-Keywords: MVS [-/+]

msntp-1.2 is now available from oozelum.csi.cam.ac.uk in the file /dist/msntp-1.2.tar.gz.

It is a major upgrade, and now has a daemon mode in which it will estimate and correct for drift. It is only a Unix version, but about 2/3 of the 2,000 lines of source should compile even under MVS! It is unlikely that I shall develop it further, and shall probably post the sources after there has been time for bugs to be reported (and maybe even fixed).

On a machine with 55 ppm drift, located a couple of Ethernet segments away from the server, I can keep the relative error comfortably under 0.1 seconds with 5 packets a day. At that frequency, it takes 10 hours to start correcting for drift after a reboot, which I might regard as worth fixing.

Even xntp sites may find it useful, because its default mode is simply to print the time, the discrepancy and the estimated error.

WARNING: I don't personally use it as a server or with broadcasts, though I have checked that code. It won't work as a server to full NTP clients, and isn't meant to.

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

From: jtt@news.cs.columbia.edu (James "retired crf" Tanis) [-/+]Date: 3 Feb 1997 22:48:18 -0500 [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: Real difference between server and peer modes. [-/+]X-Keywords: configuration [-/+] documentation [-/+] implementation [-/+] peer [-/+] poll [-/+] synchronized [-/+] update [-/+]

In article <199702031757.JAA04332@outpost.zippo.org>, James Tanis <jtt@outpost.zippo.org> wrote: > > >Hi folks, > I was wondering if any kind soul out there could enlighten me on >some of the finer details of the difference between configuring an ntp >association as "server" vs. "peer". I am quite aware of the *documented*

I lied about how much documentation I had reviewed. While I have read rfc1305 twice in the past, I evidently had to reread it once more to make some sense of this issue. So I'll answer my own questino here ( although this thread seems to heading in some interesting directions).

Reader digest version: JTT sez, you should configure lower stratum servers as "server" *if* you know that you will never drop to their stratum (and generally you will know this). IE do pretty much what the documentation suggests you should do.

Long-winded version for real NTP masochists:

DM spends a number of pages in 1305 outlining the diferent type of operating modes. During these discussions he says some interesting things. For instance:

"Client (3): A host operating in this mode sends periodic messages regardless of the reachability state of the statum of its peer. By operating in this mode the host usually a LAN workstation, announces its willingness to be synchronized by, but not to synchronize the peer."

Later he makes the following comment about symetric ative.

"Symmetric active mode is intended for use by time servers operating near the end nodes (highest strattum) of the synchonization sbunet, REliazble time service can ususally be maintained with two peers at the next lower stratum level and one peer at the same statum level, so the rate of ongoing polls is ususally not significant even when connectivity is lost and error messages are being returned for every poll."

I found these two paragraphs a bit frustrating because they seemed to suggest that the configuration which I just changed was in fact correct. IE I was *not* LAN workstation (so perhaps I shouldn't use client) and while I was not operatin near the leaves, I was certainlly configuring a few lower stratum servers. So was I wrong to change?

Apparently not. He later goes over some psuedo-code which outlines how the reference implementation operates. In this section he talks about the difference between packet processesing in "xmit" and "pkt" mode (I have put this very poorly). The first algorithm is used when the a server receives a packet from a client, the second, when it receives a packet from a peer in sym_active while it is in sym_passive.

xmit: call paket; peer.hostpoll <- peer.peerpoll; call poll-update; call transmit; if (peer.config = 0 ) demobilize association; break;

pkt:

call paket; if (valid header) begin peer.reach <- peer,rach | 1; if (valide data ) call clock-update; endif els if ( peer.config = 0) begin peer.hostpoll <- peer.peerpoll; call poll-update; call transmit; demobilize association; endif

Now in a case where a higher stratum server unilateraly configures a lower, peer.config *will* equal 0 in the lower strat. server (this simply measn that the lower strat does not mention the former in its config), so the "if ( peer.config = 0 )" will always be true. This means that the code is identical except for the possibility of something happening in pkt if (valid header) is true.. However one of the test for valid header is a stratum check. If the incoming packet's stratum is higher than the server, valid header will fail. So valid header will *always* fail in our situation. Therefore the only thing one really does by configuring a *lower* stratum server as a "peer" is to cause that machine to spend more processing time (and memory allocation time) processing the packet.

So my conclusion is to configure lower level servers as "server" (which is probably what nearly everyone out there was doing anyhow :-) ).

*If* you had the patience to read this far, I hope this helped -- OH and you clearly have far far too much time on your hands :-)

Cherrs, /jtt

From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]Date: 5 Feb 1997 22:31:28 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: ntp.conf which will allow ntpdate? [-/+]X-Keywords: ACTS [-/+] auth [-/+] driftfile [-/+] firewall [-/+] fudge [-/+] NIST [-/+] restrict [-/+] RFC [-/+]

Jim Reiss (jim@accelr8.com) wrote: : I was wondering if any kind soul out there could help me. I'm trying to : configure xntp3.5f to synchronize my local network's time. On some systems : I need ntpdate to be available (most notably an Alpha AXP machine). : Unfortunately, no matter what I try, ntpdate says "no server suitable : for synchronization found." I think the problem is that my xntpd daemon : never gives any reference time other than 0.0. My ideal is to synchronize : the master machine's clock with time-A.timefreq.bldrdoc.gov, but all that's : necessary is for all of the other machines to be able to match the master : machine's time with either ntpdate or xntpd. This doesn't seem like it : should be hard to do, but I just can't seem to get it right. Can anyone : provide me with an answer, or at least a hint? Thanks very much.

Howdy, At the risk of giving advice that is too simple, here is my simple guide.

While xntpd is a bit complicated and has lots of knobs and details, it is fairly easy to get going and keep working.

The best advice is to start simple on a single host and build up to what you really need. You might want to start with a very simple ntp.conf like: server <outside public stratum 2 near by> server 127.127.1.0 # local refclock fallback fudge 127.127.1.0 stratum 9 # shown at a poor stratum driftfile /usr/local/etc/ntp.drift # freqncy error for faster restarts

At least then you'll have one local ntp host to get your learner's permit on. Don't add auth, restrict or -casting until you have the simple stuff cooking.

Play with the tools: ntpdate -d <server> shows packets and offset without whacking time ntptrace <server> walk back up the ntp time tree ntpq query using the RFC style and the best for last: xntpdc query just for this xntpd

Your server should report one stratum larger than your source, so if you are on your fall back, "xntpdc -c sysi" should report stratum 10.

If you can't seem to connect to outside servers, but your local system is up, you can at least keep your host using a common type of time.

If you can't reach the outside server with xntpd, but ntptrace <server> shows life, you might need to learn about older version packets.

If you see the <outside server> with ntpdate -d, but not xntpd, the packets could be getting blocked by a firewall. You'll need to find it and have it changed to allow ntp/udp packets through to & from, at least to your selected outside servers and your top level inside xntp hosts.

If you can't figure a way through the firewall, you could use the ACTS modem to NIST (in Boulder it isn't a toll call).

Bruce Bartram bbartram@etl.noaa.gov

From: "Edward J. Huff" <huffe@carbon.chem.nyu.edu> [-/+]Date: Thu, 06 Feb 1997 18:32:56 -0500 [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: recvbuf messages

Philip Tanner wrote: > > We recently started seeing the following messages on some of > our machines running xntpd: > > Feb 2 06:53:51 machine xntpd[176] too many recvbufs allocated (30) > > Can someone tell me why we're seeing this and what I need to do > to clear up the problem? > > Thanks, > > Phil > ptanner@sw.stratus.com

I saw this once, and grepped the source code for "too many recvbufs" and eventually figured out that this means the server has gotten behind on processing its packets so that more than 30 packets are outstanding (I guess that means that the recived timestamp hasn't been calculated yet for any of those packets, so the network transit time which ought to be the same for send and recieve will differ because of the inflated send time).

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

From: Kevin Oberman <oberman@es.net> [-/+]Date: 07 Feb 1997 08:16:04 -0800 [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: xntp3-5.88 takes all cpu SunOS 5.5.1 sparc X-Keywords: bug [-/+] syslog [-/+]

wiu09524@rrzc4 (Ulrich Windl) writes:

> Meanwhile I wonder whether that's a Sun kernel bug. Maybe next time > supply OS version. Any non-Sparc problems?

Yes. the same thing happens using Digital UNIX. I wrote a watchdog to restart xntpd when it becomes non-responsive. (And it is VERY non-responsive in this loop!)

It's in perl and nothing special, but, in case others would find it handy, here it is: #!/usr/local/bin/perl # # Watch the NTP server the local system and report if it is # not responding. Then restart (or try to.) # # Usage: # check_ntp [-f] # -f will run in the foreground # $version = "V1.1"; $notify = "whoever\@you.want" use Sys::Syslog; use Sys::Hostname; require 'getopts.pl'; Getopts('f'); $nodename = hostname(); print "Watching xntpd with $version\n"; unless (defined $opt_f) { fork && exit; setpgrp (0, $$); open PID, ">/var/run/watch_ntp.pid"; print PID "$$\n"; close PID; openlog "watch_ntp", 'ndelay,pid', 'daemon'; syslog('info', "Watching xntpd with $version"); } while (1) { @result = `/usr/local/bin/ntpq -p $nodename`; if ($#result < 4) { # The query failed! Try to restart xntpd! unless (defined $opt_f) {syslog 'notice', "xntpd not responding.";} else {print "xntpd not responding.\n";} system ("/sbin/init.d/xntpd stop"); sleep 15; system ("/sbin/init.d/xntpd start"); open (MAIL, "| Mail -s \"xntpd failure detected on $nodename\" $notify); print MAIL @result; close MAIL; unless (defined $opt_f) {syslog 'notice', "xntpd restart attempted. Mail sent.";} else {print "xntpd restart attempted. Mail sent.\n";} } sleep 300; }

-- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634

Howdy, At the risk of giving advice that is too simple, here is my simple guide.

While xntpd is a bit complicated and has lots of knobs and details, it is fairly easy to get going and keep working.

At least then you'll have one local ntp host to get your learner's permit on. Don't add auth, restrict or -casting until you have the simple stuff cooking.

Your server should report one stratum larger than your source, so if you are on your fall back, "xntpdc -c sysi" should report stratum 10.

If you can't seem to connect to outside servers, but your local system is up, you can at least keep your host using a common type of time.

If you can't reach the outside server with xntpd, but ntptrace <server> shows life, you might need to learn about older version packets.

If you can't figure a way through the firewall, you could use the ACTS modem to NIST (in Boulder it isn't a toll call).

Bruce Bartram bbartram@etl.noaa.gov

From: nmm1@cus.cam.ac.uk (Nick Maclaren) [-/+]Date: 3 Feb 1997 18:29:03 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: Real difference between server and peer modes. [-/+]X-Keywords: configuration [-/+] Mills [-/+] peer [-/+] poll [-/+]

In article <199702031757.JAA04332@outpost.zippo.org>, jtt@outpost.zippo.org (James Tanis) writes: |> |> Server mode clearly keeps state on the client side just as peer mode |> does, so this isn't really the right reason. On the other hand no ntp server |> will ever permit itself to synch to a machine at a higher statum, so *if* |> a strat 2 configures a strat 1 as "peer" the strat 1 will always ignore the |> offer to synchronize. |> |> So what *is* the difference (and I know there is one). Is it mostly that an |> ntp packet which arrives at a server with the indication that this is just |> a client poll takes up less time and processing on the server (meaning that |> using "server" mode is more socially graceful)?

Here is how I understand it, though I could be wrong:

The client and server modes are new in NTP v3, and there is no way of finding out out the version of an NTP server, so the use of solely peer configuration may have been for robustness (i.e. the ability to interwork with NTP v2 servers). I failed to persuade David Mills that it was a mistake for servers to hide their version from clients :-(

As far as a server is concerned, having the packet in client mode seems to be pretty well equivalent to declaring the client as stratum zero, or with a reference id. of zero, or with a reference timestamp of zero or with a LI field of 3. I.e. "tell me the time, but don't trust my time".

|> Please email replies (reply-to: should be set) and I'll post a summary (if |> anyone thinks it's worth it :-) )

I am afraid that it wasn't!

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

From: WhiskerP@logica.com (Peter Whisker) [-/+]Date: Mon, 10 Feb 97 10:30:51 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: NTP through FireWall [-/+]X-Keywords: firewall [-/+] UDP [-/+]

In article <32fe1b2c.0@news.getonthe.net>, Joe Smith <joey@cooldude.com> wrote: >We are behind a firewall located at corporate. Is there any product that >will do NTP through a firewall? We have http, ftp, and telnet available. > > What our Corporate firewall people did was to put xntpd on the Firewall server and then everyone who wants to inside the company can synchronise to the Firewall.

The Firewall syncs to a few Stratum-1 sources outside and thus provides Stratum-2 to users inside which is reasonable.

The alternative which is much less attractive is to put a hole in your firewall for UDP port 123 to some named IP addresses.

Peter Whisker

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

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

From: robk@oldtimer.win-uk.net (Robin Kimberley) [-/+]Date: Mon, 10 Feb 1997 12:44:35 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: NTP through FireWall [-/+]X-Keywords: Datum [-/+] firewall [-/+]

In article <32fe1b2c.0@news.getonthe.net>, Joe Smith (joey@cooldude.com) writes: >We are behind a firewall located at corporate. Is there any product that >will do NTP through a firewall? We have http, ftp, and telnet available. > > Howabout a standalone GPS time server such as Datum's TS2100 on your side of the firewall - advantages are maximum accuracy/security.

Rob Kimberley

robk@oldtimer.win-uk.net rkimberley@sematron.demon.co.uk

Next part