Very Computer

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: 1994/05/01 05:30:41 $

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: rbtho...@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: igles...@draco.acs.uci.edu (Mike Iglesias)
Subject: Re: xntpd: 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: gl...@athena.cs.uga.edu (Glenn F. Leavell)
Subject: Re: xntpd: previous time adjustment didn't complete

I recently worte:

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: igles...@draco.acs.uci.edu (Mike Iglesias)
Subject: Re: ntpdate: errors when trying to synch to other xntp hosts
Keywords: ntpdate xntp3

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.  

Maybe those hosts can get to the servers that work but not the other ones,
as I mentioned above.

YES!  PLEASE!

=============================================================================
From: Mi...@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: jo...@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: gee...@ica.philips.nl (Geert Jan de Groot)
Subject: Re: Reachability keeps resetting zero after a STEP

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:

Then, after a while, some hold-off timer times out and the time is
SET, no longer ADJUSTED. This is what you see:
As a result, xntpd declares itself invalid and starts to synchonize:
After a while, xntpd synchonizes again and declares healthy again:
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: corri...@weber.ucsd.edu (Michael J. Corrigan)
Subject: Re: Preliminary FAQ -- send updates to rbtho...@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: fo...@cs.umd.edu (Wayne Folta)
Subject: Re: Preliminary FAQ -- send updates to rbtho...@rutgers.edu

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          (fo...@cs.umd.edu  128.8.128.8)

=============================================================================
From: rbtho...@frogpond.rutgers.edu (Rick Thomas)
Subject: Re: Using xntp without radio clock or internet connection?
Keywords: clock ntp internet

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):

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: ar...@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          Ar...@World.STD.COM +1 508 879 6994 x226
=============================================================================
From: j...@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 <tick value>
# 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: s...@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.Pier...@Sun.COM   UKnet: sam.pier...@sun.co.uk
         I do not speak for SunSoft, Inc or Sun Microsystems, Inc.

=============================================================================
From: John C Sager <j...@zoo.bt.co.uk>

Rick,
Thanks for the FAQ. here are some corrections.

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.

                                             ^^^

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).

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: Mi...@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: k...@SDD.HP.COM (Ken Stone)
Subject: Re: HP version of ntp wanted

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: rbtho...@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: w...@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 <ouwen...@prso.pttnwb.nl>

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 <your-path>/tickadj ]
then
        echo    "NTP error, file tickadj missing." >&2
        exit 0
fi
<your-path>/tickadj -s -q

Thanks again, Anthon , all the way from the Netherlands.

============================================================================
From: mrap...@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'.

w...@socs.uts.EDU.AU (Wai Yat Wong) writes:

While you're at it, that ought to be

<your-path>/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: rbtho...@frogpond.rutgers.edu (Rick Thomas)
Subject: Re: what are the /etc/ntp.drift units?

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 <mrap...@quack.kfu.com> 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 <lo...@ni.umd.edu> 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 <Mi...@udel.edu> 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) <thor...@diku.dk> 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: thor...@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) <thor...@diku.dk> (Humour NOT marked)

============================================================================
From: "Louis A. Mamakos, NTP mailing list maintenance" <NTP-REQU...@ni.umd.edu>
Subject: NTP mailing list vs NTP netnews

There is a one-way gateway which causes traffic sent to the NTP
mailing list (N...@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-REQU...@NI.UMD.EDU

============================================================================
From: woll...@sadye.emba.uvm.edu (Garrett Wollman)
Subject: Re: Previous time adjustment didn't complete
Organization: University of Vermont, EMBA Computer Facility

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.

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: cu...@csv.warwick.ac.uk (Ian Dickinson)
Subject: Re: time going backwards
Date: 18 May 93 14:03:09 GMT

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: lich...@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 <j...@zoo.bt.co.uk>
To: lich...@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 <Frank.Kar...@informatik.uni-erlangen.de>
To: lich...@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: Mi...@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: c...@spdev.east.sun.com (Christopher Jackson - Special Projects)
Date: 6 Jun 93 14:55:16 GMT
Organization: Sun Microsystems, Columbia MD

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.

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  <c...@sun.com>

============================================================================
From: a...@ossi.com (Tony Luck)
Date: 8 Jun 93 17:42:11 GMT
Organization: Fujitsu Open Systems Solutions, Inc.

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

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: mrap...@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'.

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: c...@spdev.east.sun.com (Christopher Jackson - Special Projects)
Date: 13 Jun 93 15:26:00 GMT
Organization: Sun Microsystems, Columbia MD

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  <c...@sun.com>

============================================================================
From: am...@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

   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,
   j...@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: mrap...@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'.

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: Mi...@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: w...@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

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 w...@faa.gov w...@tgf.tc.faa.gov w...@pilot.njin.net

============================================================================
From: duni...@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
        duni...@msr.epm.ornl.gov

============================================================================
From: fei...@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

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-...@inria.fr
Subject: NTP FAQ: update for Sony
Date: Thu, 05 Aug 1993 10:31:25 +0200
Sender: Alain.Dur...@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 <traut...@fb3-s7.math.tu-berlin.de>:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

j...@zoo.bt.co.uk (John C Sager) &  a...@ossi.com (Tony Luck)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

        - Alain Durand.
============================================================================
From: barr...@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

MVICK...@fhcrc.org (Mark F. Vickers) writes:

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: barr...@ee.und.ac.za
============================================================================
From: a...@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.

cmo...@corazon.mit.edu (Christopher B. Moore) 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
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 <a...@ossi.com>

============================================================================
From: sc...@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

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 (sc...@cs.rulimburg.nl)

============================================================================
From: gee...@ica.philips.nl (Geert Jan de Groot)
Date: 13 Aug 93 20:48:26 GMT
Organization: Philips Consumer Electronics, Eindhoven, The Netherlands

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: m...@ns.ccsn.edu (Russell Mosemann)
Subject: Re: NTP for VMS
Date: 24 Aug 93 19:32:28 GMT
Organization: Concordia College, Seward, NE

   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: igles...@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:    igles...@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: Mi...@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: dk...@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: J...@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: j...@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 <27l3svINN...@srvr1.engin.umich.edu>, dar...@engin.umich.edu (Darrin P Cardani) writes:

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:          j...@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: egg...@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

        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: bel...@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: <bel...@ireq.hydro.qc.ca>

============================================================================
From: mi...@panix.com (Charlie Mingo)
Subject: Re: NTP-client for MAC
Date: 26 Sep 93 04:56:50 GMT

In article <Sep.21.14.29.17.1993.11...@frogpond.rutgers.edu>,

I posted a copy to mac.archive.umich.edu.  It should appear in a few days.

============================================================================
From: t...@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: p...@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

* -20 for the former (well, that's what I use).

* 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: arm...@bcvms.bc.edu
Subject: Re: network time server recommendations?
Date: 27 Sep 93 18:35:02 GMT
Organization: Boston College

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: arm...@bc.edu
140 Commonwealth Ave.                               Bitnet: armand@bcvms
Chestnut Hill, MA 02167
============================================================================

============================================================================
From: Mi...@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: de...@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 k...@spatula.csv.warwick.ac.uk, cu...@csv.warwick.ac.uk (Ian Dickinson) writes:

  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: Whisk...@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.

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 [- | +] [<hours>h] [<minutes>m] [<seconds>[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.Engv...@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: Mi...@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: scha...@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>, a...@DEVNULL.MPD.TANDEM.COM (Ashvini Nangia) says:

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: am...@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: rbtho...@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, j...@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 <tick>" 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: dun...@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 dun...@netcom.com.)

============================================================================
From: d...@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> 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      d...@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: shoto...@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

dar...@engin.umich.edu (Darrin P Cardani) writes:

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: sco...@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.18...@odin.diku.dk> shoto...@diku.dk (Kim H|glund) writes:

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.
sco...@plexus.com

============================================================================
From: phi...@charon.citicorp.com (Philip Gladstone)
Subject: Re: request for example kernel PLLs
Date: 12 Dec 93 23:20:50 GMT
Organization: Citicorp

: 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: dua...@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.10...@advtech.uswest.com>, huntt...@advtech.uswest.com (Brad Huntting) writes:

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: rbtho...@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.

::::::::::::::: 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 "<L1>-N" sequence to set all EEPROM values back to factory default.'
echo '(Hold down the <L1> 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: k...@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

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: Mi...@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 ...

read more »