Date: Thu, 11 Dec 1997 09:37:50 EST [-/+]
From: Dave Mills <mills@huey.udel.edu> [-/+]
To: Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>
Cc: mills@udel.edu
Subject: Re: NTP-FAQv2 ready for release
Message-ID: <199712110937.aa21646@huey.udel.edu>
Ulrich,
That's wunnerful. Can you drop on the www.eecis.udel.edu/~ntp folks?
That's the HP/UCLA folks - I don't maintain that page.
Dave
Date: Wed, 21 Jan 1998 12:38:19 EST [-/+]
From: Dave Mills <mills@huey.udel.edu> [-/+]
To: Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>
Cc: "Kristofer T. Karas" <ktk@ktk.bidmc.harvard.edu>, mills@huey.udel.edu
Subject: Re: ntp4.0.71/linux - seems "success" a bit premature. [-/+]
Message-ID: <199801211238.aa18797@huey.udel.edu>
X-Keywords: FLL [-/+] PLL [-/+] poll [-/+]
Guys,
Indeed, the kernel model is unchanged; however, FLL is currently disabled
pending reolution of Solaris 2.6 kernel bugs (somebody used a int instead
of a long). As I said eralier, FLL should be disabled for the present.
As for longer poll intervals, the simulator says it is safe to
well over a day. The simulator should know, since it ruthlessly copies the
actual parameters and algorihtms and eats real measred data; however,
the adaptive code that figures out how much of the PLL and how much off
the FLL estimates should wiggle the clock needs more testing. That
brings up the problem of how/when to st the FLL bit for the kernel,
since in the v4 model there is no switch, just an estimator. That
has yet to be resolved.
Dave
Date sent: Sat, 15 Nov 1997 20:01:18 -0500 (EST)
From: "Jay R. Ashworth" <jra@scfn.thpl.lib.fl.us> [-/+]
To: Ulrich.Windl@rz.uni-regensburg.de
Subject: Re: Inexpensive GPS clock for NTP? [-/+]
Organization: Ashworth & Associates
X-Keywords: FAQ [-/+] Mills [-/+] synchronized [-/+] WWVB [-/+]
[CC of a followup to your news posting]
On 10 Nov 1997 09:40:25 GMT,
Ulrich Windl <wiu09524@rrzc4> wrote:
> In article <01bced86$d52c92c0$76e1d2cc@GerardM.Foley.columbus.rr.com> "Gerard M. Foley" <gfoley@netexp.net> writes:
> > Are the radio-corrected clocks advertised by Radio Shack at under
> > $50, which use WWVB signals, any use in your application? What is
> > NTP?
>
> "What is NTP?" is possible the thing that's missing in the
> FAQ. Someone out there with a good 5 sentence summary?
When networking computers, keeping their clocks synchronized is
important for many reasons, including security tracking and system
maintenance. When using computers for scientific applications,
synchronizing them to "absolute time" becomes as important. NTP is the
name of a network protocol and software suite developed by Dr. David
Mills at the University of Delaware, with help from dozens of other
people on the net, which makes both of these tasks possible, although
not always simple. As with database design, time synchronization
system design can be more complicated than it looks, depending on what
you want to do. Far more information than you need (:-) can be found
at the NTP Home Page: http://www.eecis.udel.edu/~ntp/ -- read the whole
page; the descriptive entries are _after_ the releases.
That good enough? (Ok; I cheated with the semicolon, there...)
Cheers,
-- jra
--
Jay R. Ashworth jra@baylink.com
Member of the Technical Staff Unsolicited Commercial Emailers Sued
The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby,
Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592
From: Casper.Dik@Holland.Sun.Com (Casper H.S. Dik - Network Security Engineer) [-/+]
Date: 22 Oct 1997 21:02:44 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntpd and rtc on Solaris
X-Keywords: daylight [-/+]
[[ Reply by email or post, don't do both ]]
jason.ahrens@fulcrum.com (Jason Ahrens) writes:
>I am wondering weather I should disable the /usr/ucb/rtc on Solaris if using
>xntpd... rtc does a few things with the clock, one of them attempting to
>adjust for daylight savings...
/usr/bin/rtc you mean?
Rtc is a program that sync's the DOS clock with current time of day.
Since Solaris keeps time relative to GMT and Windows/DOS relative to
the local time, the system clock must be adjusted when daylight savings
time starts/ends.
It doesn't interfere with xntpd (and it's only for x86).
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
From: Andrew Hood <ajhood@fl.net.au> [-/+]
Date: Thu, 23 Oct 1997 22:27:33 +1000 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Last resort servers
X-Keywords: peer [-/+] prefer [-/+]
Jason Ahrens wrote:
>
> All thing being equal, a server with a 'prefer' in the argument will be chosen
> all the time.
>
> What if I want to 'last resort' server approach... That is, a server that will
> only be chosen should all others fail? Can I have multiple 'prefers' in the
> config file?
>
> ie:
>
> #regular servers
> server a.a.a.a
> server b.b.b.b
> server c.c.c.c
>
> #last ditch
> serve d.d.d.d
>
Today I tried
server a.a.a.a prefer
server b.b.b.b prefer
peer c.c.c.c
peer d.d.d.d
peer e.e.e.e
on three Solaris 2.x boxes (c.c.c.c d.d.d.d and e.e.e.e).
Two settled down synced to a.a.a.a, one to b.b.b.b (both GPS).
CUL8R,
Andy
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 22 Oct 1997 07:12:59 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: prefer ATOM? [-/+]
X-Keywords: Arbiter [-/+] ATOM [-/+] DCF77 [-/+] dispersion [-/+] fudge [-/+] peer [-/+] PPS [-/+] prefer [-/+]
In article <62imgi$91o$4@news.du.etx.ericsson.se> per@erix.ericsson.se (Per Hedeland) writes:
> In article <WIU09524.97Oct21092016@rrzc4>, wiu09524@rrzc4 (Ulrich Windl)
> writes:
> >I'm seeking for an answer to a non-obvious question: Should the
> >ATOM(PPS) clock be "prefer"d?
>
> My limited understanding, based on experiments and poring over the docs,
> is that it should not - or at least need not. My current config with an
> Arbiter clock on SunOS 4.1.4, using the "ppsclock" package to pick up
> the PPS signal, is basically this:
>
> server 127.127.11.0 prefer # Arbiter
> fudge 127.127.11.0 time1 0.0043 # Seems about right for SS2/IPX/SS5 w SunOS 4.x
> fudge 127.127.11.0 flag3 1 # Enable ppsclock support/usage
> server 127.127.22.0 # Needed for PPS with ppsclock
>
> With this setup, xntpd always marks the Arbiter as the sync source - but
> it actually minimizes the offset to ATOM! This was very obvious when I
> didn't have the time1 fudge for the Arbiter in there - it would always
> have ~ -4 ms offset, while ATOM's offset was close to 0. Makes some
> sense, I guess, since the "prefer" is intended to indicate where the PPS
> is coming from, and that *is* the time source - I don't have a cesium
> clock...:-)
According to my knowledge and experience the following happens:
Once the ATOM's dispersion is below 1.0 it will be included in the
sets of valid time sources (the survivors). Usually xntpd will set up
a trust interval (or whatever it is called there) made up from the
survivors. If the prefer peer has a high dispersion the trust interval
will be rather large and possibly wrong. Without prefer xntpd would
select the interval with the lower dispersion.
The final offset is the mean value of all the survivor's' offsets.
>
> Also, excerpts from the html/prefer.html page:
>
> 1. The _prefer peer_ is designated using the prefer keyword with the
> server or peer commands. [ ... ]
>
> 2. When a PPS signal is connected via the PPS Clock Discipline driver
> (type 22), this is called the _PPS peer_. [ ... ]
>
> and
>
> [ ... ] In all cases, a specific, configured peer or server must be
> designated as associated with the PPS signal. This is done using the
> _prefer_ keyword as described previously. The PPS signal can be
> associated in this way any peer, but is most commonly used with the
> radio clock generating the PPS signal.
Read/knew that.
>
> - seem to indicate that when using ATOM, you should only designate one
> single *other* peer as "prefer"ed. Finally, the fact that the ATOM's
> offset is minimized even though it isn't "prefer"ed (but not the fact
> that the Arbiter is marked as sync source) agrees with the rules from
> the same page:
>
> 1. If there is a prefer peer and it is the local-clock peer or the
> modem peer; or, if there is a prefer peer and the kernel time
> discipline is active, choose the prefer peer as the system peer
> and its offset as the system clock offset. [ ... ]
Does not apply here.
>
> 2. If the above is not the case and there is a PPS peer, then choose
> it as the system peer and its offset as the system clock offset.
I'm not sure whether this is right: In my case the PPS (pps_sync) is
not activated automatically, but when I activate it the ATOM will
become the primary source of synchronization and the prefer peer ist
still included as a survivor. Unfortunately if the PPS signal is of
poor quality (in my case) the algorithm is not robust enough (I had
some 10ppm and 20ppm jumps in pps frequency).
>
> 3. If the above is not the case and there is a prefer peer (not the
> local-clock or modem peer in this case), then choose it as the
> system peer and its offset as the system clock offset.
>
> I.e. rule 2 comes into effect, with the result that rule 3 doesn't apply.
Maybe the ture summary is: The are in fact two modes for ATOM: being
primary reference, or being just another server. For the first case
you are right, for the second case there's still a problem (with poor
quality PPS signals).
((I'm mad enough to try to use DCF77 AM pulses as PPS signal))
Thank you for the response!
Ulrich
From: Raimo Koski <rkoski@pp.weppi.nowhere>
Date: Tue, 21 Oct 1997 06:41:37 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: xntp-3.5f-3 behind a firewall
X-Keywords: firewall [-/+]
Background:
===========
I have tried to set up a local time server. My ISP has a
firewall which restricts access to ports below 1024. The
intended ntp server is running Caldera OpenLinux Standard,
which includes xntp-3.5f-3.
When I had set up a minimalistic /etc/ntp.conf, starting
xntp displays following:
[root@rk2 ftp]# /etc/rc.d/init.d/ntp start
Starting time synchronization (NTP): (ntpdate) 21 Oct 02:28:30
ntpdate[14498]:
no server suitable for synchronization found
xntpd
I found the culprit quite soon and the following commands
should verify my suspicions:
[root@rk2 /root]# ntpdate nic.funet.fi
21 Oct 02:32:49 ntpdate[14513]: no server suitable for synchronization
found
[root@rk2 /root]# ntpdate -u nic.funet.fi
21 Oct 02:45:23 ntpdate[14773]: adjust time server 128.214.248.6 offset
0.071435
ntpdate -u doesn't use the normal port 139, but instead
non-restricted higher port.
Question:
=========
Is there any way to configure xntp to use higher ports
or do I have to set up cron to run ntpdate -u periodically?
From: mark.symons@za.eds.com (Mark Symons)
Date: Tue, 21 Oct 1997 20:14:13 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP client for NT that runs as a service [-/+]
X-Keywords: broadcast [-/+] Tardis [-/+]
On Tue, 21 Oct 97 15:30:43 GMT, jason.ahrens@fulcrum.com (Jason
Ahrens) wrote:
>I am attemtpting to find an NTP client that runs as a service on NT, something
>that is started when the machine is booted, not when someone logs on to that
>machine. Does anyone know of such a beast?
Tardis for NT v3.0 runs as a service:
From a previous message, dated 16th Oct:
> I have been running a packet sniffer against Moe looking for the
> broadcast packets, but it doesen't seem that Moe is broadcasting,
> at least nothing is comming from Moe that I can see.
Tardis NT also acts as an NTP broadcast client, which provides an
alternative way of detecting broadcast packets. However, K9 (a
utility from the same author as Tardis) is an NTP broadcast cleint
with a debug mode that makes it easier to identify the origin of the
packets.
Mark Symons
EDS Africa
From: jussi.torhonen@tietosavo.fi (Jussi Torhonen)
Date: 24 Oct 1997 06:15:05 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP client for NT that runs as a service [-/+]
In article <a157cd$b833.35@news>, jason.ahrens@fulcrum.com says...
>
>I am attemtpting to find an NTP client that runs as a service on NT, something
>that is started when the machine is booted, not when someone logs on to that
>machine. Does anyone know of such a beast?
TimeSync (shareware) is a NTP client that can be installed as a service:
http://www.intsoft.com/timesync.html
xntpd server (freeware) has also been ported for NT and it runs also as a
service:
ftp://ftp.cs.uta.fi/pub/av/ntp/xntp3-5_90_3-gui.zip
ftp://ftp.bond.edu.au/pub/NT/xntpd/xntp3-5_90_3-gui.zip
Jussi
--
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Jussi Torhonen / Internet: jussi.torhonen@tietosavo.fi
Tietosavo Oy / AX.25: OH7DC@OH7RBA.#KUO.FIN.EU
P.O.Box 1582 / X.400: C=fi; ADMD=elisa; PRMD=tsnet; O=tietosavo;
FIN-70461 KUOPIO / S=torhonen; G=jussi
FINLAND / Tel: +358-17-193 231, Fax: +358-17-193 355
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
From: roger.foss@oslo.itservice.telenor.no (Roger Foss)
Date: Thu, 23 Oct 1997 11:34:59 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: SNTP client for Novell NW 4.1
X-Keywords: NIST [-/+] Novell [-/+] SNTP [-/+] update [-/+]
[This followup was posted to comp.protocols.time.ntp and a copy was sent
to the cited author.]
In article <344d4994.7381760@news.isd.net>, P&D (phowe@Isd_._Net) says...
> Our Unix staff has recently placed an SNTP time source on our TCP/IP network.
> Does anyone know of software we can load on our Novell 4.1 reference time
> server? We'd like to keep all of our NW and Unix servers on the same time base.
>
> Thanks.
> -------
> Remove the dashes from my address to reply
>
Two products come to mind:
Cadence Time Synchronization for Netware, from
Polygon Inc.
http://www.polygon.com
which seems a little bloated and expensive for
your needs.
and
SNTP Client for Netware, from NeaTech.
Very low price (ie. 10-15$ for a single license),
seems stable and has all you need.
http://www.neatech.ch/sntpclnt/
The Cadence is able to use dialin time sources like NIST,
but if you want to use (S)NTP you have to buy the extra
NTP module. Cadence is also able to update clients more
often then at login time (say, every hour), using
broadcasts (it sends a chime signal). The clients have
to run a Cadence client and the mechanism is proprietary.
I'd suggest using SNTP Client for Netware to keep your NDS tree
(NW servers) accurate, and if workstations need to have their
time updated more frequently, get a share/freeware SNTP
client for Win95/NT..
<<DISCLAIMER>> This is not an official endorsement of any
of the products mentioned.
Roger Foss
Telenor Bedrift
Oslo, Norway
From: Alan Kuresevic <alan@rasip.fer.hr>
Date: Wed, 22 Oct 1997 12:24:15 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Offset behaviour [-/+]
This is a multi-part message in MIME format.
--------------69FE21E821A3CD737569495A
From: Unknown Author <none> (auto-inserted) [-/+]
Subject: none (auto-inserted) [-/+]
X-Keywords: configuration [-/+] documentation [-/+] monitor [-/+] monitoring [-/+] TrueTime [-/+]
Dear all,
We have been doing some offset measurements on our NTP configuration in
order to verify installations and driver we developed ourselves. In
course of doing this, few questions popped up for which we (with fairly
limited experience in NTP) could not find explanation.
CONFIGURATION
The NTP configuration is following: We have two stratum 1 servers
connected to the two independent GPS sources. One of them is TrueTime
while other is actually custom build time distribution unit that
distributes time from another GPS. For TrueTime we are using the
standard driver that comes with xntpd3.5f distribution, while for the
other one we wrote our own.
For the purpose of this explanation lets call those servers as follows:
server T - stratum 1 connected to TrueTime
server D - stratum 1 connected to time distribution unit
The third host (server F) is a stratum 2 configured to use both stratum
1 servers (T and D) for synchronization. We enabled the monitoring on F
to monitor offset between F and T and F and D and got following results:
1. F shows it takes T as "selected for synchronization", and D as
"included in the final selection set"
In that period offsets are following:
F offset to T is stable at value around -0.001+-0.0005 s with occasional
peeks going up to -0.035 s. Peeks are irregular and they happen cca 5
time a day.
F offset to D is stable at 0.0035+-0.007 s without peeks.
2. Server T is physically disconnected and D is now "selected for
synchronization"
Here offset between F and D is 0.000+-0.001 s.
3. Server T is physically connected again. D stays "selected for
synchronization" and T is now "included in the final selection set".
Offsets come back to the values in point 1.
F offset to T is stable at value around -0.001+-0.0005 s with occasional
peeks going up to -0.035 s. Peeks are irregular and they happen cca 5
time a day.
F offset to D is stable at 0.0035+-0.007 s without peeks.
QUESTIONS
1. Why are offsets in case 1 and case 3 same although different servers
are "selected for synchronization"? It looks like that both stratum 1
servers (T and D) are taken into consideration when adjusting stratum 2
server (F) time. If this is a case, and from NTP documentation it looks
like this, what is then a difference between being "selected for
synchronization" and "included in the final selection set"?
2. Why we have occasional offset peeks (in case 1) on server T connected
to TrueTime?
Any help will be appreciated.
Best regards
Alan Kuresevic
--------------69FE21E821A3CD737569495A
From: Unknown Author <none> (auto-inserted) [-/+]
Subject: none (auto-inserted) [-/+]
Content-Description: Card for Alan Kuresevic
begin: vcard
fn: Alan Kuresevic
n: Kuresevic;Alan
adr: 14b, rue Bour;;;Bereldange;;L-7216;Luxembourg
email;internet: alan@rasip.fer.hr
tel;work: (+352) 710 725 218
tel;fax: (+352) 710 725 416
tel;home: (+352) 33 76 76
From: Unknown Author <none> (auto-inserted) [-/+]
Subject: none (auto-inserted) [-/+]
version: 2.1
end: vcard
--------------69FE21E821A3CD737569495A--
From: ckc@dmi.min.dk (Casper K. Clausen) [-/+]
Date: 22 Oct 1997 13:30:26 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Offset behaviour [-/+]
X-Keywords: delay [-/+] dispersion [-/+] poll [-/+] precision [-/+] TrueTime [-/+]
>>>>> "A" == Alan Kuresevic <alan@rasip.fer.hr> writes:
A> 2. Why we have occasional offset peeks (in case 1) on server T connected
A> to TrueTime?
My guess would be network congestion. My workstation, for instance,
synchronizes to a stratum-2 server, with a stratum-4 server as
fallback. I do an ntpq -p every hour on the hour, perhaps the most
efficient diagnostic tool when dealing with NTP. A snippet of what
this yields follows (names altered for clarity and protection of the
innocent):
==============================================================================
*strat 2 err.ethz.ch 2 u 45 128 377 9.64 0.194 14.18
strat 4 LOCAL(1) 4 u 285 1024 377 3.43 -122.42 9.26
remote refid st t when poll reach delay offset disp
==============================================================================
*strat 2 benoni.Uit.No 2 u 2 64 377 7.10 11.022 2.01
start 4 LOCAL(1) 4 u 142 512 377 8.19 -107.14 5.51
remote refid st t when poll reach delay offset disp
==============================================================================
*strat 2 benoni.Uit.No 2 u 19 64 377 6.50 34.794 3.98
strat 4 LOCAL(1) 4 u 236 1024 377 15.84 -88.478 36.96
remote refid st t when poll reach delay offset disp
==============================================================================
*strat 2 benoni.Uit.No 2 u 31 64 377 6.74 0.402 0.61
strat 4 LOCAL(1) 4 u 248 1024 377 33.54 -139.62 19.20
remote refid st t when poll reach delay offset disp
==============================================================================
*strat 2 benoni.Uit.No 2 u 47 64 377 6.61 -1.790 0.21
strat 4 LOCAL(1) 4 u 776 1024 377 45.97 -96.299 41.44
remote refid st t when poll reach delay offset disp
==============================================================================
*strat 2 benoni.Uit.No 2 u 64 64 377 6.74 1.607 0.50
strat 4 LOCAL(1) 4 u 282 1024 377 4.06 -132.55 18.25
As you can see, the decrease in precision follows an increase in
dispersion (aka network quality). This behavior is consistent over
time, and points to network congestion being the sole reason for
offset peaks. Try examining your own setup for these sorts of signs;
it's a very common thing.
My workstation has to go through a couple of switches, a hub and a
netbuilder before getting in touch with "strat 2". Our supercomputer,
which is on the same FDDI ring as "strat 2", experiences very few
offset peaks (one or two per week, usually) and those that happen are
less severe.
Regards,
Kvan.
--
-------Casper Kvan Clausen------ | 'Ah, Warmark, everything that passes
----------<ckc@dmi.dk>---------- | unattempted is impossible.'
Lokal 544 |
I do not speak for DMI, just me. | - Lord Mhoram, Son of Variol.
From: Valdis Kletnieks <valdis.kletnieks@vt.edu>
Date: 23 Oct 1997 12:50:11 -0400 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Configuring xntp on AIX 4.2.1
--pgp-sign-Multipart_Thu_Oct_23_12:50:10_1997-1
From: Unknown Author <none> (auto-inserted) [-/+]
Subject: none (auto-inserted) [-/+]
X-Keywords: AIX [-/+] DCF77 [-/+] synchronized [-/+]
Tobias.Muehlhuber@t-online.de (Tobias Muehlhuber) writes:
> Hi,
> I've been trying to get this to work for several weeks now.
> We use xntp on a RS/6000 7015R50 (AIX 4.2.1). We intend to synchronize
> this machine to a DCF77 radio clock.
> If the machine is not synchronized to the radio clock (e.g. 10 Minutes
> difference) and we
> start the xntpd nothing happens within the first 5 minutes. Then the
> time of the machine is synchronized to the radio clock at one big step.
> IBM-Hotline told us that this is normal . But as far as I understood the
> working of xntp it is not.
> Is there a way to synchronize in very small steps so that user and
> applications do not
> recognize the synchronization ?
Well, this *IS* normal. It will take *one* big jump to get it within
a second or so, and then use adjtime() to *slowly* move in.
If your clock is drifting so bad that adjtime() can't keep it in sync,
you have BIGGER problems. First thing to check is if you're also
running 'timed' on that machine, and timed and xntpd are jerking the
clock back and forth....
--pgp-sign-Multipart_Thu_Oct_23_12:50:10_1997-1
From: Unknown Author <none> (auto-inserted) [-/+]
Subject: none (auto-inserted) [-/+]
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBNE+AQ9QBOOoptg9JAQHP7AQAx/wPJiUTQ9T2XGmQSgXlwhZB+eFAwQna
8EwP1W7YVONz4WhA8MSSUBoRr0KI43l3ZysMBD2mKY0lnfmW1fTfpclGnLn7YX8d
1uAWfFUXJL0vZXoFTNLXpulB6wOtn9sUGk1O5ZiRaOH9XnE44Q3QRdaVPNGPg53F
FATReDlAh+U=
=1DQg
-----END PGP MESSAGE-----
--pgp-sign-Multipart_Thu_Oct_23_12:50:10_1997-1--
Date: Mon, 27 Oct 1997 11:15:52 -0500 (EST) [-/+]
From: "Jay R. Ashworth" <jra@scfn.thpl.lib.fl.us> [-/+]
Message-Id: <199710271615.LAA19990@scfn.thpl.lib.fl.us>
To: rbthomas@lilypad.rutgers.edu
Posted-To: comp.protocols.time.ntp
Subject: Re: Commercial NTP ??? [-/+]
References: <3447EAA1.59C@ix.netcom.com> <62gq9d$doj@lilypad.rutgers.edu>
Organization: Ashworth & Associates
X-Keywords: antenna [-/+] Bancomm [-/+] Datum [-/+] Mills [-/+]
[CC of a followup to your news posting]
On 20 Oct 1997 19:42:37 -0400,
Rick Thomas <rbthomas@lilypad.rutgers.edu> wrote:
> What do you mean by "commercial"?
>
> Several vendors now supply (usually very old) versions of xntpd with
> their OS shipments. Some have even included Dr Mills' kernel
> timekeeping mods in their OS. Is that "commercial" enough?
>
> Or taking another possible meaning - There are a number of NTP boxes
> you can buy that have a GPS antenna and an ethernet port. They listen
> to the satellites and speak NTP to the ethernet. (Sounds kinda
> mystical... doesn't it! 8->)
>
> Or taking yet another meaning of "commercial" - I'll be happy to sell
> you some consulting time in support of the public domain NTP software
> at my usual rates... I'm sure there are lots of other people out
> there who would do the same.
Going in even another direction, The Bancomm division of Datum, Inc.,
among other people, sell GPS Strat 1 clocks with built in NTP servers.
Cheers,
-- jra
--
Jay R. Ashworth jra@baylink.com
Member of the Technical Staff Unsolicited Commercial Emailers Sued
The Suncoast Freenet "Pedantry. It's not just a job, it's an
Tampa Bay, Florida adventure." -- someone on AFU +1 813 790 7592
From: jra@scfn.thpl.lib.fl.us (Jay R. Ashworth) [-/+]
Date: 27 Oct 1997 16:19:27 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Commercial NTP ??? [-/+]
X-Keywords: antenna [-/+] Bancomm [-/+] Datum [-/+] Mills [-/+]
On 20 Oct 1997 19:42:37 -0400,
Rick Thomas <rbthomas@lilypad.rutgers.edu> wrote:
> What do you mean by "commercial"?
>
> Several vendors now supply (usually very old) versions of xntpd with
> their OS shipments. Some have even included Dr Mills' kernel
> timekeeping mods in their OS. Is that "commercial" enough?
>
> Or taking another possible meaning - There are a number of NTP boxes
> you can buy that have a GPS antenna and an ethernet port. They listen
> to the satellites and speak NTP to the ethernet. (Sounds kinda
> mystical... doesn't it! 8->)
>
> Or taking yet another meaning of "commercial" - I'll be happy to sell
> you some consulting time in support of the public domain NTP software
> at my usual rates... I'm sure there are lots of other people out
> there who would do the same.
Going in even another direction, The Bancomm division of Datum, Inc.,
among other people, sell GPS Strat 1 clocks with built in NTP servers.
Cheers,
-- jra
--
Jay R. Ashworth jra@baylink.com
Member of the Technical Staff Unsolicited Commercial Emailers Sued
The Suncoast Freenet "Pedantry. It's not just a job, it's an
Tampa Bay, Florida adventure." -- someone on AFU +1 813 790 7592
From: dalton@cup.hp.deletethis.com (David Dalton) [-/+]
Date: 23 Oct 1997 21:06:31 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: TAPR TAC-2 works modestly well [-/+]
X-Keywords: antenna [-/+] delay [-/+] dispersion [-/+] fudge [-/+] Garmin [-/+] HP-UX [-/+] jitter [-/+] NMEA [-/+] poll [-/+] PPS [-/+] Spectracom [-/+] Trimble [-/+] WWVB [-/+]
This is not intended as an endorsement of any product, nor an offer of HP
support. I was just looking for a home project while expanding my NTP
experience. Your Mileage May Vary. If you can't connect to a public
timeserver and can't afford a standard radio/GPS receiver costing
thousands of $$, you might be able to get a decent NTP reference clock
for about US$350 and a little work.
==========================================================================
I have just constructed a reference clock consisting of a TAPR TAC-2 with
a Garmin GPS-20 and attached it to NTP through the undocumented NMEA driver
(#20), and it works reasonably well. As expected, the accuracy is modest
(around 50 milliseconds) because the NMEA output is the lowest priority task
of the GPS unit. I am not able to use the pulse-per-second (PPS) signal on
HP-UX right now, but it is possible that the accuracy would improve by two
orders of magnitude or more with the PPS. Has anyone tried this? I would
also be very interested if anyone has tried one of these clocks with other
GPS boards (Motorola, Trimble, etc): do the more expensive OEM GPS boards
have better accuracy?
NTP DETAILS
-----------
The NTP statistics from the first day of operation are OK, but not great.
I understand that budget GPS receivers are not very good about the on-time
arrival of the timecode data on the serial port, and that some have
dispersion of 500 milliseconds (or maybe worse). In general NTP wants
things inside 128 milliseconds or it will jump around a lot, and my unit
appears to be at 50 milliseconds or thereabouts. I wouldn't claim to be a
stratum-1 server for the world with this kind of performance, but it could
be adequate for network synchronization on a budget within your own
organization.
It appears that a fudge time1 value of 0.240 seconds is needed for this
unit, although that is only a rough estimate (considering the dispersion).
server 127.127.20.1 # TAPR TAC-2 with /dev/gps1
fudge 127.127.20.1 time1 0.240 # apparent correction factor
Below are my "ntpq -p" statistics at fifteen minute intervals during the
first few hours of operation. You can see the offset and dispersion
wandering around, and I am presuming this to be due to the jitter in the
timecode delivery.
CONSTRUCTION DETAILS
--------------------
The TAC-2 is a build-it-yourself kit offered by Tuscon Amateur Packet Radio
club (TAPR), and it has options for several different GPS boards:
Garmin GPS-20 approx US$ 180
Motorola Oncore approx US$ 290
Trimble SK-8 approx US$ 285
The TAC-2 board is a very nice plated-through-hole pc board (approx 3
inches by 4 inches) that is bare when you get it, with a small collection
of parts for approx US$140. Anyone with a soldering iron can follow the
very clear instructions and assemble this kit in about four hours. You must
provide your own power supply (5VDC @ 300 mA) and housing. The Garmin unit
did not include any antenna, so I will have to build something. Right now
I am borrowing the antenna from my HP GPS unit. The Motorola and Trimble
units appear to include a "hockey puck" antenna.
See the TAPR TAC web page at: http://www.tapr.org/tapr/html/tac2.html
or contact them at:
e-mail tapr@tapr.org
phone (940) 383-0000
fax (940) 566-2544
Looking at the Trimble SK-8 datasheet it appears you could just buy their
"Starter Kit" and get everything you need without any parts from TAPR, but
I haven't done this so I'm not sure. I'm not sure how much the "Starter
Kit" costs.
The hardest part of the whole project was attaching five little 26ga wires
to the tiny connector for the GPS board. The pins are very small and hard
to handle, even under magnification with needle nose forceps. The kit
provides several spares, and I screwed up all of the spares before getting
five of them crimped securely. In retrospect it would have been easier to
use my own 30ga wires instead of the 26ga wires that came with the kit.
I found an interesting undocumented feature on the TAC-2 board:
surface-mount pads. On the otherwise component-free back side of the
board, next to the power pin of each IC and also at the regulator pins, is
a pair of square pads that are clearly intended for little SMT capacitors
for power supply bypass, a complement to the standard bypass caps on the
top of the board. One pad is connected to +5V and the other to GND. I
installed a little 0.1uF ceramic cap at each of these locations, and also
some big solid-slug tantalum caps right on the regulator pins. Clean power
is always a good thing.
I built a power supply consisting of a $5 transformer, a rectifier, and an
electrolytic capacitor (6800uF). This feeds into a 7805 voltage regulator
on the TAC-2 board that powers everything. I housed the whole thing in a
plastic box that formerly contained a 1200 baud modem.
-> My $.02 only. Not an official statement from HP.
--
As far as we know, our computer has never had an undetected error.
---------------------------------------------------------------------------
David Dalton dalton@cup.hp.deletethis.com 408/447-3016
Keep in mind that "dispersion" is the primary indicator of time service
quality. If you are using a network timeserver, then "dispersion" is
looking at the timeserver+network quality, and the network is usually the
first suspect if there are problems. If you have your own hardware clock,
the network is eliminated and "dispersion" is looking at the time service
quality of the clock itself.
The old adage is: You Get What You Pay For....
The statistics below are gathered with "ntpq -p", a very useful debugging
tool in the world of NTP.
For comparison purposes, look at the low offset and dispersion of my HP58503A
GPS clock, even with no PPS active:
remote refid st t when poll reach delay offset disp
==============================================================================
*GPS_HP(1) .GPS. 0 l 63 64 377 0.00 -0.005 1.01
hpuxps.cup.hp.c hpisrhw 2 u 34 1024 377 6.24 8.391 0.46
Here is the somewhat less expensive Spectracom Netclock/2:
remote refid st when poll reach delay offset disp
===========================================================================
*WWVB_SPEC(1) .WWVB. 0 115 64 377 0.00 -0.10 2.44
+hpntcyh.cup.hp. .GPS. 1 18 64 377 4.15 -2.14 1.04
Here are the statistics from the TAPR TAC-2 with Garmin GPS20. These are
at 15 minute intervals after everything had stabilized:
remote refid st t when poll reach delay offset disp
==============================================================================
*GPS_NMEA(1) .GPS. 0 l 1 64 377 0.00 -26.243 20.08
+hpisrhw.cup.hp. .WWVB. 1 u 48 64 377 3.10 14.276 22.66
hpindzoa.cup.hp hpisrhw.cup.hp. 2 u 221 512 366 34.01 -12.285 16.72
remote refid st t when poll reach delay offset disp
==============================================================================
*GPS_NMEA(1) .GPS. 0 l - 64 377 0.00 9.695 20.36
+hpisrhw.cup.hp. .WWVB. 1 u 51 64 377 3.16 -14.470 23.15
hpindzoa.cup.hp hpisrhw.cup.hp. 2 u 608 512 356 10.03 3.727 16.36
remote refid st t when poll reach delay offset disp
==============================================================================
*GPS_NMEA(1) .GPS. 0 l - 64 377 0.00 -1.573 34.12
+hpisrhw.cup.hp. .WWVB. 1 u 55 64 377 3.28 -0.067 8.10
hpindzoa.cup.hp hpisrhw.cup.hp. 2 u 484 1024 272 -14.11 -7.457 14.02
remote refid st t when poll reach delay offset disp
==============================================================================
*GPS_NMEA(1) .GPS. 0 l - 64 377 0.00 -24.403 21.97
+hpisrhw.cup.hp. .WWVB. 1 u 59 64 377 3.56 2.937 2.94
hpindzoa.cup.hp hpisrhw.cup.hp. 2 u 360 1024 166 19.91 9.448 27.33
remote refid st t when poll reach delay offset disp
==============================================================================
*GPS_NMEA(1) .GPS. 0 l 1 64 377 0.00 -6.965 10.38
+hpisrhw.cup.hp. .WWVB. 1 u 63 64 377 3.34 9.964 6.45
hpindzoa.cup.hp hpisrhw.cup.hp. 2 u 236 1024 356 12.19 5.961 20.36
remote refid st t when poll reach delay offset disp
==============================================================================
*GPS_NMEA(1) .GPS. 0 l - 64 377 0.00 25.745 40.37
+hpisrhw.cup.hp. .WWVB. 1 u 3 64 377 3.34 1.350 3.42
hpindzoa.cup.hp hpisrhw.cup.hp. 2 u 112 1024 357 18.37 -4.797 23.56
remote refid st t when poll reach delay offset disp
==============================================================================
*GPS_NMEA(1) .GPS. 0 l - 64 377 0.00 16.283 14.60
+hpisrhw.cup.hp. .WWVB. 1 u 7 64 377 3.11 -5.078 3.16
hpindzoa.cup.hp hpisrhw.cup.hp. 2 u 1012 1024 336 18.37 -4.797 23.56
remote refid st t when poll reach delay offset disp
==============================================================================
*GPS_NMEA(1) .GPS. 0 l 1 64 377 0.00 -17.505 22.52
+hpisrhw.cup.hp. .WWVB. 1 u 12 64 377 3.59 -15.492 2.44
hpindzoa.cup.hp hpisrhw.cup.hp. 2 u 889 1024 276 17.50 -7.925 21.13
remote refid st t when poll reach delay offset disp
==============================================================================
*GPS_NMEA(1) .GPS. 0 l - 64 377 0.00 29.369 24.61
+hpisrhw.cup.hp. .WWVB. 1 u 15 64 377 3.34 2.857 12.37
hpindzoa.cup.hp hpisrhw.cup.hp. 2 u 764 1024 176 36.39 -9.323 18.62
remote refid st t when poll reach delay offset disp
==============================================================================
*GPS_NMEA(1) .GPS. 0 l - 64 377 0.00 -6.487 7.84
+hpisrhw.cup.hp. .WWVB. 1 u 19 64 377 3.33 2.913 6.24
hpindzoa.cup.hp hpisrhw.cup.hp. 2 u 640 1024 376 -7.08 -11.308 17.99
remote refid st t when poll reach delay offset disp
==============================================================================
*GPS_NMEA(1) .GPS. 0 l 1 64 377 0.00 13.011 18.19
+hpisrhw.cup.hp. .WWVB. 1 u 24 64 377 3.34 -6.010 2.21
hpindzoa.cup.hp hpisrhw.cup.hp. 2 u 517 1024 376 12.60 -24.359 28.59
remote refid st t when poll reach delay offset disp
==============================================================================
*GPS_NMEA(1) .GPS. 0 l - 64 377 0.00 -5.601 20.40
+hpisrhw.cup.hp. .WWVB. 1 u 27 64 377 3.16 22.778 10.21
hpindzoa.cup.hp hpisrhw.cup.hp. 2 u 392 1024 376 -11.41 -14.959 21.01
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 27 Oct 1997 09:38:58 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: year 200 again: reference clocks
X-Keywords: DCF77 [-/+] RFC [-/+]
Hi,
yesterday I realized that many reference clocks use a two-digit format
for the year. Even worse, dome data formats for broadcasting like the
German DCF77 only have enough bits for a two-digit year.
The interesting question is: While NTP clients without local reference
clocks have no problems with the year 2000, servers with reference
clocks may have problems. It seems a good idea if some authors of the
refclock drivers could verify year 2000 compliance.
--
--- &disclaimer; ---
Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de+no-spam>
Klinikum der Universitaet Regensburg, Rechenzentrum DV-med
Franz-Josef-Strauss-Allee 11\\D-93042 Regensburg, Germany
%%[PGP 2.3a/2.6ui Public Key 0x[e8]43660d on at least one key server]%%
%1024/E843660D 1994/03/26 = CF D7 43 A1 5A 49 14 25 7C 04 A0 6E 4C 3A AC 6D
Stop the SPAM, read the Nettiquette (RFC 1855)!
From: dave@delta.demon.co.uk (David Godfrey)
Date: Sun, 26 Oct 1997 14:18:11 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: TAPR TAC-2 works modestly well [-/+]
X-Keywords: antenna [-/+] delay [-/+] Garmin [-/+] HP-UX [-/+] NMEA [-/+] poll [-/+] PPS [-/+] Trimble [-/+]
dalton@cup.hp.deletethis.com (David Dalton) writes:
>I have just constructed a reference clock consisting of a TAPR TAC-2 with
>a Garmin GPS-20 and attached it to NTP through the undocumented NMEA driver
>(#20), and it works reasonably well. As expected, the accuracy is modest
>(around 50 milliseconds) because the NMEA output is the lowest priority task
>of the GPS unit. I am not able to use the pulse-per-second (PPS) signal on
>HP-UX right now, but it is possible that the accuracy would improve by two
>orders of magnitude or more with the PPS. Has anyone tried this? I would
>also be very interested if anyone has tried one of these clocks with other
>GPS boards (Motorola, Trimble, etc): do the more expensive OEM GPS boards
>have better accuracy?
I have a GPS-20 connected to a Linux box. Rather than wait for the
TAPR TAC-2 to be finalised, I just connected it to the internal 5v PC
supply, the NMEA output to a serial port and the pps signal to the
interrupt line of the parallel port. (No doubt there are lots of
reasons not to make these direct connections, but it works for me.)
Then with a slightly modified kernel to time stamp the pps, and a
modified NMEA driver to feed the time stamps to the ATOM_PPS driver, I
get very good results. e.g.
remote refid st t when poll reach delay offset disp
==============================================================================
+GPS_NMEA(0) .GPS. 0 l 3 64 377 0.00 -0.016 0.02
oATOM_PPS(0) .PPS. 0 l 18 64 377 0.00 -0.014 0.02
delta.local-net 0.0.0.0 16 u - 1024 0 0.00 0.000 16000.0
xwang.local-net .PPS. 1 u 29 64 376 1.43 -1.548 0.69
remote refid st t when poll reach delay offset disp
==============================================================================
+GPS_NMEA(0) .GPS. 0 l 49 64 376 0.00 -0.017 0.02
oATOM_PPS(0) .PPS. 0 l 48 64 377 0.00 -0.017 0.02
delta.local-net 0.0.0.0 16 u - 1024 0 0.00 0.000 16000.0
wang.local-net .PPS. 1 u 251 64 360 1.39 -1.543 16000.0
>CONSTRUCTION DETAILS
>--------------------
>The TAC-2 is a build-it-yourself kit offered by Tuscon Amateur Packet Radio
>club (TAPR), and it has options for several different GPS boards:
> Garmin GPS-20 approx US$ 180
> Motorola Oncore approx US$ 290
> Trimble SK-8 approx US$ 285
>The TAC-2 board is a very nice plated-through-hole pc board (approx 3
>inches by 4 inches) that is bare when you get it, with a small collection
>of parts for approx US$140. Anyone with a soldering iron can follow the
>very clear instructions and assemble this kit in about four hours. You must
>provide your own power supply (5VDC @ 300 mA) and housing. The Garmin unit
>did not include any antenna, so I will have to build something. Right now
>I am borrowing the antenna from my HP GPS unit. The Motorola and Trimble
>units appear to include a "hockey puck" antenna.
There is a antenna available for the GPS-20 - the GA 27. It seems to
me that the GPS-20 needs a good signal.
>The hardest part of the whole project was attaching five little 26ga wires
>to the tiny connector for the GPS board. The pins are very small and hard
>to handle, even under magnification with needle nose forceps. The kit
>provides several spares, and I screwed up all of the spares before getting
>five of them crimped securely. In retrospect it would have been easier to
>use my own 30ga wires instead of the 26ga wires that came with the kit.
What a nightmare! I used a made up plug that came with 8" leads, tho I
can't find any references numbers for it at the moment. No doubt
Garmin could tell you if not actually supply it.
Regards
--
Dave Godfrey
dave@delta.demon.co.uk
Fax +44 181 286 1909
PGP key available
From: jra@scfn.thpl.lib.fl.us (Jay R. Ashworth) [-/+]
Date: 27 Oct 1997 16:53:58 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP n Daylight Saving Time
X-Keywords: adjustment [-/+] DST [-/+]
On Fri, 24 Oct 1997 16:04:07 GMT,
RP Pelletier <ranpel@moscow.nsc.com> wrote:
> Scott Chapman wrote:
> > Can someone point me to the info on how the NTP protocol will
> > work with this weekends Clock going back one hour here in the USA.
> > What is the defined interaction with the systems it is installed on (Unix)
> > which try to do their own adjustments?
>
> I'd like to second that request. If anyone answered Scott could you
> please forward that reply to me?
Simple. NTP feeds your machine _UTC_. UTC doesn't care about DST.
Your machine's software is _supposed_ to do it's own adjustment.
At this stage in the software game, anyone who allows their machine's
bios to do DST adjustments deserves everything they get. :-)
Cheers,
-- jra
Cheers,
-- jra
--
Jay R. Ashworth jra@baylink.com
Member of the Technical Staff Unsolicited Commercial Emailers Sued
The Suncoast Freenet "Pedantry. It's not just a job, it's an
Tampa Bay, Florida adventure." -- someone on AFU +1 813 790 7592
From: per@erix.ericsson.se (Per Hedeland) [-/+]
Date: 21 Oct 1997 16:50:26 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: prefer ATOM? [-/+]
X-Keywords: Arbiter [-/+] ATOM [-/+] fudge [-/+] peer [-/+] PPS [-/+] prefer [-/+]
In article <WIU09524.97Oct21092016@rrzc4>, wiu09524@rrzc4 (Ulrich Windl)
writes:
>I'm seeking for an answer to a non-obvious question: Should the
>ATOM(PPS) clock be "prefer"d?
My limited understanding, based on experiments and poring over the docs,
is that it should not - or at least need not. My current config with an
Arbiter clock on SunOS 4.1.4, using the "ppsclock" package to pick up
the PPS signal, is basically this:
server 127.127.11.0 prefer # Arbiter
fudge 127.127.11.0 time1 0.0043 # Seems about right for SS2/IPX/SS5 w SunOS 4.x
fudge 127.127.11.0 flag3 1 # Enable ppsclock support/usage
server 127.127.22.0 # Needed for PPS with ppsclock
With this setup, xntpd always marks the Arbiter as the sync source - but
it actually minimizes the offset to ATOM! This was very obvious when I
didn't have the time1 fudge for the Arbiter in there - it would always
have ~ -4 ms offset, while ATOM's offset was close to 0. Makes some
sense, I guess, since the "prefer" is intended to indicate where the PPS
is coming from, and that *is* the time source - I don't have a cesium
clock...:-)
Also, excerpts from the html/prefer.html page:
1. The _prefer peer_ is designated using the prefer keyword with the
server or peer commands. [ ... ]
2. When a PPS signal is connected via the PPS Clock Discipline driver
(type 22), this is called the _PPS peer_. [ ... ]
and
[ ... ] In all cases, a specific, configured peer or server must be
designated as associated with the PPS signal. This is done using the
_prefer_ keyword as described previously. The PPS signal can be
associated in this way any peer, but is most commonly used with the
radio clock generating the PPS signal.
- seem to indicate that when using ATOM, you should only designate one
single *other* peer as "prefer"ed. Finally, the fact that the ATOM's
offset is minimized even though it isn't "prefer"ed (but not the fact
that the Arbiter is marked as sync source) agrees with the rules from
the same page:
1. If there is a prefer peer and it is the local-clock peer or the
modem peer; or, if there is a prefer peer and the kernel time
discipline is active, choose the prefer peer as the system peer
and its offset as the system clock offset. [ ... ]
2. If the above is not the case and there is a PPS peer, then choose
it as the system peer and its offset as the system clock offset.
3. If the above is not the case and there is a prefer peer (not the
local-clock or modem peer in this case), then choose it as the
system peer and its offset as the system clock offset.
I.e. rule 2 comes into effect, with the result that rule 3 doesn't apply.
--Per Hedeland
per@erix.ericsson.se
From: "Bob Vance" <Bob_Vance@sbm.com> [-/+]
Date: 28 Oct 1997 14:10:22 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP client for NT that runs as a service [-/+]
I forgot to mention that d4time is
totally free !
bv
Bob Vance <Bob_Vance@sbm.com> wrote in article
<01bce3a8$3ba967a0$1d9ab326@bobvh.sbm.com>...
A client running as a service? Sounds like an oxymoron.
We just installed "d4time", which I have been running on my
Win95 PCs for a while, on some NT3.5.1 servers and it works fine.
Trivial to install, configure, and use -- I love it.
Just unzip it and move the executable to the startup group for
3.5.1. I has a regular .inf file for 95 and 4.0 installation.
Obtain from
www.thinkman.com/~thinkman
-----------------------------------------------
Tks | bobv@sbm.com
BV | bobvance@alumni.caltech.edu
Bob Vance
VP Technical Consulting, SBM
Vox 770-446-0404 11455 Lakefield Dr.
Fax 770-409-3112 Duluth, GA 30097-1511
===============================================