Previous part

From: Dave Sill <dsill@sws5.ctd.ornl.gov>
Date: 13 Jan 1998 11:02:57 -0500
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Extremely poor timekeeping under Irix 6.2?

Neil Crellin <neilc@wallaby.stanford.edu> writes:

> We recently upgraded a collection of our Irix 5.3 machines to Irix 6.2
> and installed xntp on them. The results were worse than useless, ...

I haven't seen any problems upgrading from 5.3 to 6.2, but when I
replaced my 6.2 Indy with a 6.3 O2, all hell broke loose. I never
could get xntp to run, but by fiddling with timetrim (from the xntp
distribution) I was able to get Nick Maclaren's msntp running
reasonably well. It still occasionally loses synchronization, though.

Maybe I should try xntp again now that I've figured out timetrim, but
I *like* the idea of a small, simple client like msntp.

--
Dave Sill <dsill@sws5.ctd.ornl.gov>        <URL:http://web.infoave.net/~dsill>
Lockheed Martin Energy Research   Oak Ridge National Lab   Workstation Support
Take the qmail Challenge. See <URL:http://web.infoave.net/~dsill/qmail.html>


From: bob@hobbes.dtcc.edu (Bob Rahe) [-/+]
Date: 12 Jan 1998 18:03:59 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP and Cisco routers
X-Keywords: Cisco
[-/+] documentation [-/+] timezone [-/+]

In article <34b7a59b.129529047@news-s01.ny.us.ibm.net>,
Lyndon Griffin <lgriffin|naviant.com> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>I'm looking for a quick, low-down on how to configure a Cisco 2500
>series, running IOS 10.0, to sync off a secondary NTP server.
>Unfortunately, I was unable to find anything in Cisco's documentation
>(have you ever tried to read through Cisco's documentation?!?!).

  Do it all the time.  No problem.

>If anyone possesses, or has a link to, such a document, could you
>please post it here or email to me?

  Well, I can give you the commands you need, then check the docs for
all the gory details.  Here's excerpts from a config I use:

----------------------------------------
...
!
clock timezone EST -5
clock summer-time edt recurring
...

ntp server 123.456.789.001
ntp server 123.456.987.100
...
----------------------------------------

    Fill in the server addresses as appropriate for you network.(I.e.
the IP addresses of the timeservers you want to sync to.)

  Enjoy,

    Bob
--
----------------------------------------------------------------------------
|Bob Rahe, Delaware Tech&Comm Coll. /                                      |
|Computer Center, Dover, Delaware /                                        |
|Internet: bob@hobbes.dtcc.edu /                                           |
----------------------------------------------------------------------------


From: jim@shell1.interlog.com (bJf)
Date: 12 Jan 1998 15:44:38 -0500
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Error compiling xntpd on Linux
[-/+]
X-Keywords: restrict
[-/+] Slackware [-/+]

In article <693hea$6nb$1@newton.a2000.nl>,
Jorg Heijnis <j.heijnis@cable.a2000.nl> wrote:
>I use the Slackware 3.4 distrubition with te gcc compiler, the output of
>make is :

This question was covered about a week ago here, but for the benefit of those
without access to dejanews, here's the answer:

The gcc compiler shipped with Slackware 3.4 is slightly customized, and
includes a routine called 'restrict'.  This conflicts with the xntpd routine
'restrict' and causes the errors you saw.  To resolve this problem, get a clean
copy of gcc, either from source and build it yourself, or grab a binary
distribution off sunsite or one of the other happy Linux sites.

Bryan
--
bryanf@samurai.com     Home      "You know, sometimes I just want to
bryanf@canoe.ca        Work       be a chicken." - Master FehHead
bryanf@feh.net         FEH!


From: Dave Pascoe <dave@mathworks.com>
Date: 13 Jan 1998 18:31:40 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntpd 3-5.91 for Windows NT
X-Keywords: broadcast
[-/+]

Not wanting to use an undocumented feature we had the NT Service start
with this tiny app:

----begin ntpkicker.c----
#include <stdio.h>
#include <stdlib.h>

main(){
        int res = 0;

        res = _spawnl( 0, "c:\\winnt\\system32\\ntpdate.exe", "ntpdate.exe",
"-b", "time.yourdomain.com", NULL );
        res = _spawnl( 0, "c:\\winnt\\system32\\xntpd.exe", "xntpd.exe", NULL
);
        exit( 0 );
}
----end ntpkicker.c----

So now NT "coarse syncs" with ntpdate and then runs in broadcast mode
for "fine sync" (we configure broadcast client in ntp.conf).

--
Dave Pascoe  | mailto:dave@mathworks.com  |  Voice: 508.647.7362
K M 3 T      | http://www.mathworks.com   |    FAX: 508.647.7002
PGP fingerprint: 53 AD 71 88 2F AA 45 AC D0 2E 68 91 71 77 39 AF


From: Kevin Oberman <oberman@es.net> [-/+]
Date: 13 Jan 1998 09:50:45 -0800
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: no server suitable error
X-Keywords: dial
[-/+] release [-/+]

johnson@isn.dac.neu.edu (Chris Johnson) writes:

>      I'm running xntp 3.5a.  I have two servers running and getting
> their time successfully from their sources.  I have a number of
> clients also running 3.5a.  They ask for time updates from my servers.
> For some reason my clientsare now getting the following in response to
> an npdate
>
> ntpdate[1244]: no server suitable for synchronization found

OK. We are talking ancient history here, so I may not be aware of some
problem specific to 3.5a. I really would suggest trying the current
release (3-5.91), but I don't think that it fix this problem.

TH normal cause of this message is that all of the servers in the list
fail to respond with a time close enough to the current system time to
allow the time to be drifted into sync. If the time would need to be
stepped, ntpdate considers the server unsuitable.

I suggest listing several servers instead of just a single one. This
makes it less likely that an error on a server will block things.

But the real fix is to always run ntpdate at boot time with the -b
option. This WILL cause the clock to be stepped to match the selected
server's time.

N.B. The -b option should be used only at boot time as discontinuities
in the system time can really mess some applications up. Use -b to set
the time correctly at boot time and then either run ntp to keep it in
sync continuously or use ntpdate regularly to keep the time from
drifting too far out. I set the time hourly from a cron job on my Sun
that has to dial in to get the time. I suspect that most systems will
do fine if the time is set every 6 or 8 hours, but that depends on
your system clock accuracy.
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest Orlando Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman@es.net                          Phone: +1 510 486-8634


From: thomas.g.booth@den.mmc.com (Booth, Thomas G)
Date: 13 Jan 1998 21:54:11 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Use Power line frequency with PPS?
[-/+]
X-Keywords: configuration
[-/+] fudge [-/+] jitter [-/+] PLL [-/+] PPS [-/+] WWVB [-/+]

In article <slrn6bn1ra.dte.ivy@frith.acs.ohio-state.edu>,
ivy@frith.acs.ohio-state.edu (Michael Iverson) wrote:

> Is it possible to use the AC line frequency to conditon the local
> clock frequency?

> It would be pretty easy to build an opto-isolated PPS circuit which uses the
> AC frequency.

> I'm thinking about this since I have a system which is infrequently connected
> to the internet, and has problems with drift. I really can't justify the
> cost of a better time source. The power company conveniently provides a
> stable frequency source.

> Mike

Mike, I'm not sure using a 1 PPS signal derived from 60 Hz power line
frequency will be stable enough for your purpose, at least in a simple
divide by 60 circuit.  Before jumping to this solution you might want to
characterize the amount of jitter in the derived 1 PPS signal and determine
if the jitter is acceptable.  If the jitter isn't OK, you may need to
consider a suitable PLL design to try and improve things.

Even if the jitter appears acceptable, keep in mind that the power line
frequency could be pulled to some extent, which for example may appear as a
day time slowdown & night time speedup (as the power co. slews line
frequency to "recover" the lost time accumulated during the day).  YMMV!

You'll also need to somehow characterize the fudge factors for your 1 PPS
signal relative to a trustworthy 1 PPS signal.

You don't mention what is your hardware/software configuration, so the
following suggestion may or may not be useful.  If your system supports
some means of trimming the system clock like tickadj, you might want to
consider taking advantage of it.  You may not be able to completely trim
out the frequency offset of the system clock, but it should provide an
improvement over your current configuration.

You might want to consider building a WWVB receiver and recover the serial
time code, which runs at 1 PPS, and use a suitably conditioned version of
the time code as your 1 PPS signal.  Temic Semiconductor
(http://www.temic.com) makes a couple of receiver ICs which are intended to
be used as a WWVB/DCF/MSF/etc. receiver; search for data sheets and
application notes for the U4223B family on the Temic site.

Good luck -

TGB

\\  The opinions expressed herein are my own.  //


From: Juha Takala <juha@viisa.dna.fi>
Date: 13 Jan 1998 21:24:37 +0200
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Use Power line frequency with PPS?
[-/+]
X-Keywords: filter
[-/+] PPS [-/+] stability [-/+] synchronized [-/+]

ivy@frith.acs.ohio-state.edu (Michael Iverson) writes:

> Is it possible to use the AC line frequency to conditon the local
> clock frequency?
>
> It would be pretty easy to build an opto-isolated PPS circuit which uses the
> AC frequency.
>
> I'm thinking about this since I have a system which is infrequently connected
> to the internet, and has problems with drift. I really can't justify the
> cost of a better time source. The power company conveniently provides a
> stable frequency source.

The short term stability of te power network is not good.  In fact, a power
network synchronized clock may get about 20 seconds off during one day,
based on measurements I have done.

The long time stability is fairly good.  This is because the network
frequency is adjusted so that on the average there are 24*3600*50 (or 60)
cycles in one day.  Or 7 times that in one week.  I don't know what is the
reference clock for that regulation (guess: gps).  The reason for the short
term variation is the difference in power production and consumption.

The power grid may also get faulty and might be run in "islands", and the
frequency is even less controlled in such situations.

A low pass filter with time constant longer than 24 hours would be needed,
and I am not sure if even this would solve the problem.  The 1 PPS interface
based on power network can not be used if we want accurate clock.

        -juha


From: Wolfgang Rupprecht <wolfgang@dailyplanet.wsrcc.com> [-/+]
Date: 14 Jan 1998 10:39:42 -0800
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Use Power line frequency with PPS?
[-/+]

wiu09524@rrzc4 (Ulrich Windl) writes:
> Somewhere I had read that the companies supplying electricity have a
> strong interest to synchronize the phase so that when connecting
> different power supplies won't case a loss of power (for a difference
> of pi/2 you would not get much for the sum of two sine waves).
> Therefore it seems surprising that the difference should be several
> seconds per day.

It is more than "a strong interest" in keeping the phase synced
between all the generators.  Its just the only way it can work.
Physics enforces the rules for you.

Picture several horses all pulling the same cart.  One horse is
pulling harder and is quite a bit in front of the others.  One horse
isn't pulling at all and is letting the harness pull him.  The ones
leading the pack are doing all the work.  The ones lagging the pack
are getting work done to them to keep them moving.

The same thing with generators.  The ones leading the power grid's
phase are doing more than their share.  The ones lagging the grid's
phase are doing less than their share.  The actual phase difference
you'll see between any two generators can be worked out by ohms law,
using the output current of the generators, the resistance of the wire
between the two generators in question, and the voltage difference
between the generators (gotten via the cosine of the phase offset
angle of the two generators.)  The upshot of this is that the
generators on a grid will always be running at the same rotational
speed as one another.  The only question is how many degrees offset
will one get between any two generators.

In the US the generators used to be time locked to within +/- 3
seconds from some absolute time.  Whenever the accumulated error got
too high the grid control systems would slowly bring the error back to
zero.  There was also some constraint on the maximum short-term
frequency offset one was allowed to have.  I think it was something
like 59.9 hz to 60.1 hz.

What is interesting is how did the power companies bring a generator
on line without destroying it?  In the old days the power company
would attach a set of light bulbs between the grid and the generator.
The light would flash with the beat frequency (difference frequency)
of the generator and the grid.  As the generator spun up the light
would blink slower and slower.  Finally one tried to spin the
generator at exactly the same phase as the grid by trying to keep the
light off the whole time.  One then threw the big switch shorting the
generator to the grid.  If one was very close in getting the phase
right one only got a small "thud".  If one was off by a bit one got a
hell of a big bang and a flash as the generator tried its damnedest to
move a large number of degrees in a very small amount of time.

-wolfgang


From: hpa@transmeta.com (H. Peter Anvin) [-/+]
Date: 14 Jan 1998 07:39:28 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Use Power line frequency with PPS?
[-/+]
X-Keywords: stability
[-/+]

Followup to:  <x7oh1gw51m.fsf@viisa.dna.fi>
By author:    Juha Takala <juha@viisa.dna.fi>
In newsgroup: comp.protocols.time.ntp
>
> The long time stability is fairly good.  This is because the network
> frequency is adjusted so that on the average there are 24*3600*50 (or 60)
> cycles in one day.  Or 7 times that in one week.  I don't know what is the
> reference clock for that regulation (guess: gps).  The reason for the short
> term variation is the difference in power production and consumption.
>

Actually, atomic clocks.

        -hpa
--
    PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD  1E DF FE 69 EE 35 BD 74
    See http://www.zytor.com/~hpa/ for web page and full PGP public key
        I am Bahá'í -- ask me about it or see http://www.bahai.org/
  "To love another person is to see the face of God." -- Les Misérables


From: pausch@electra.saaf.se (Paul Schlyter)
Date: 14 Jan 1998 13:30:11 +0100
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Use Power line frequency with PPS?
[-/+]
X-Keywords: PPS
[-/+]

In article <slrn6bn1ra.dte.ivy@frith.acs.ohio-state.edu>,
Michael Iverson <ivy@frith.acs.ohio-state.edu> wrote:

> Is it possible to use the AC line frequency to conditon the local
> clock frequency?
>
> It would be pretty easy to build an opto-isolated PPS circuit which uses the
> AC frequency.
>
> I'm thinking about this since I have a system which is infrequently connected
> to the internet, and has problems with drift. I really can't justify the
> cost of a better time source. The power company conveniently provides a
> stable frequency source.

A few decades ago, before quartz clocks became common, clocks which
were based on the AC frequency were quite common.  I had a few of
those back then.  My experience were: over long times these clocks kept
a very good accuracy, being off less than a minute during a month.  But
their short-range accuracy was less good: one day it could be 15 sec fast,
the next day 40 sec slow, the day after that 25 sec fast, etc.

It seems like the power companies count the cycles, and adjust the cycle
rate such that the average cycle rate is very close to wat it should be.
But there are short-term fluctuations.

There are alternatives to counting AC cycles:

1. Find out the drift of your particular system.  Write a piece of
software that runs automaticaully at regular intervals (e.g. once per
hour) and adjusts the system clock according to the known drift.
WHenever there's a connection to the Internet, that software can then
check the time tifference between your system clock and the NTP time
source, and adjust its perception of the drift rate of your system
clock accordingly.

2. Radio-controlled clocks are now getting common, and their prices
are getting lower.  They check radio time signals one per hour,
and adjust their internal quartz clock as soon as they succeed in
receiving these radio time signals.  Try to interface to one of these.

--
----------------------------------------------------------------
Paul Schlyter,  Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40,  S-114 38 Stockholm,  SWEDEN
e-mail:  pausch@saaf.se     paul.schlyter@ausys.se    paul@inorbit.com
WWW:     http://spitfire.ausys.se/psr    --  updated daily!


From: no@spam.please (William L. Gorder)
Date: Wed, 14 Jan 1998 18:52:45 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Use Power line frequency with PPS?
[-/+]
X-Keywords: stability
[-/+] synchronized [-/+]

On 13 Jan 1998 21:24:37 +0200, Juha Takala <juha@viisa.dna.fi> wrote:
>ivy@frith.acs.ohio-state.edu (Michael Iverson) writes:
>>
>> I'm thinking about this since I have a system which is infrequently connected
>> to the internet, and has problems with drift. I really can't justify the
>> cost of a better time source. The power company conveniently provides a
>> stable frequency source.
>
>The short term stability of te power network is not good.  In fact, a power
>network synchronized clock may get about 20 seconds off during one day,
>based on measurements I have done.

I should begin this by noting that I work for the power company which
maintains the time for the eastern US. Perhaps in Finland this is true, but
in the United States (where the original poster is located), short-term
stability is pretty good.  The current time deviation is +1.23 seconds in
the "Eastern Interconnected Network" (all of the US power system east of the
Rocky Mountains excluding Texas and including parts of Canada).  Alarms will
be issued if the time drifts more than (roughly) 4 seconds either way.  Of
course, this may not be good enough for many applications.  In addition, the
drift characteristics of the "power company time" are going to be
unpredictable from your standpoint, as they depend on numerous factors for
which you have no information.

In the past twenty years or so, the largest time deviation (that I recall
being mentioned) was about 30-40 seconds slow.  I would be very surprised if
there were any examples larger than this.

Note that other electric power systems will have different time stability
characteristics.

>The long time stability is fairly good.

Quite true.

> I don't know what is the
>reference clock for that regulation (guess: gps).

That is one of the references we use.

>The power grid may also get faulty and might be run in "islands", and the
>frequency is even less controlled in such situations.

Possible, but *highly* unlikely in this part of the US.  I'm in the same
part of the electrical network as the original poster.

Bill
--
My real e-mail address is wlg AT infinet | Sorry for the trouble, but I HATE
dot com                                  | junk e-mail!
                                        | I do NOT expect e-mail replies,
                                        | follow-ups are just fine thanks!
I do NOT speak for my employer!


From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 14 Jan 1998 09:50:43 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: [Q] How to set polling time?
X-Keywords: driftfile
[-/+] FAQ [-/+] fudge [-/+] poll [-/+] stability [-/+] Windows [-/+]

In article <34bcca57.66162807@news.supernews.com> steve@geodetic.com (Steve Folstein) writes:

> I am using xntp under Windows NT to sync our main server and to
> provide a network time service to multiple clients.  How do I set the
> minimum polling time?  Right now it is sending out a request packet to
> the ntp servers every one to two minutes. My ntp.conf file looks like

Every 64 seconds to be precise (try "ntpq -p" to find out). Alternatively try
to read the FAQ.

> this:
>
> #
> #    File:       ntp.conf
> #
> driftfile %windir%\ntp.drift        # path for drift file
> #
> #
> server tick.usno.navy.mil
> server tock.usno.navy.mil
> #
> #
> server 127.127.1.0            # local clock

> fudge 127.127.1.0 stratum 0

I hope you know what you are saying here.

> #
>
> Any ideas?  I would like the server to poll once or twice a day to
> sync the clock.

That is not impossible, because the polling interval is adjusted based
on an estimate of your clock's (and network's) stability. It does not
make much sense to synchronize less frequent that maybe half an
hour. (Well, it might for Windows/NT as the clock isn't quite exact
anyway).

If yor network connections are too expensive, you might schedule "ntpdate"
as infrequent as you like. (See this newsgroup for a sample).

Ulrich


From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 14 Jan 1998 09:40:35 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP convergence fudge?
X-Keywords: dispersion
[-/+] fudge [-/+] minpoll [-/+] PPS [-/+]

In article <4m67noz5cg.fsf@flatland.dimensional.com> David Michaels <rooth@flatland.dimensional.com> writes:

> I know it takes about 5 minutes for xntp to sync to its time source after
> it is started (assuming it is within 1000 seconds to begin with - which is
> accomplished at boot time in our startup scripts with ntpdate).
>
> I was wondering if there was a way to make this happen faster?  I think it
> does a check every 64 seconds (or something like that) until the dispersion
> is below 1.0.  I would like to increase this check frequency.  We have a

You can do that! Use "minpoll 4" for one good source, and it will sync 4 times as fast!

> very tiny network using, presently, just a local Sun clock as a time source
> (please don't hit me -- it's soon to be disciplined with a PPS signal
> (thanks Ulrich!), or maybe even a real GPS receiver if we can get it quick
> enough!).  The 5 minute wait for NTP syncrhonization is annoying, but the
> synchronization is required for the whole system to do its thing.
>
> I was thinking perhaps there'd be a fudge factor or some command line
> option to tell xntpd to perform checks every 8 seconds, or 32 seconds, or
> somesuch.  Does anyone know how this might be done?

Ulrich Windl


From: "Richard B. McDonald" <wb0nre@nospam.tstonramp.com>
Date: 15 Jan 1998 08:29:41 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Use Power line frequency with PPS?
[-/+]

This is getting a whole lot off-topic, but what the heck!

Wolfgang Rupprecht <wolfgang@dailyplanet.wsrcc.com> wrote in article
<x7g1mq7vdd.fsf@capsicum.wsrcc.com>...
<snip>
> What is interesting is how did the power companies bring a generator
> on line without destroying it?  In the old days the power company
> would attach a set of light bulbs between the grid and the generator.
> The light would flash with the beat frequency (difference frequency)
> of the generator and the grid.  As the generator spun up the light
> would blink slower and slower.  Finally one tried to spin the
> generator at exactly the same phase as the grid by trying to keep the
> light off the whole time.  One then threw the big switch shorting the
> generator to the grid.  If one was very close in getting the phase
> right one only got a small "thud".  If one was off by a bit one got a
> hell of a big bang and a flash as the generator tried its damnedest to
> move a large number of degrees in a very small amount of time.
>
> -wolfgang
>

I believe the light bulb has been replaced with a 12-bit A/D and the big
knife switch has been replaced with a HUMONGOUS 3 phase contactor, but the
principle is the same.

When I was going through power lab 23 years ago (BSEE '78, University of
Missouri-Rolla; go Miners!) each student had to bring a 75 KW alternator
on-line using the method you described.  Lab legend had it that some
lack-luster student threw the switch with the bulb at it's BRIGHTEST!
Concrete chips everywhere as the alternator tried to instantaneously synch
up, and the 100 hp DC motor driving the alternator was ripped out of the
concrete pier.  Nice story, but he would have had to make other errors as
well, such as having the excitation field current turned all the way up to
get that much torque out of the alternator.

The really interesting question is who starts pulling back toward 60 Hz?
Particularly when the frequency is low.

I toured a Southern California Edison plant shortly after the west-coast
brown-out ('79?), and the guide quoted some ridiculously large number of
megawatts flowing around the grid just to keep it stable.  No one power
station has enough horsepower to overcome this flow.  All the power plant
operator can do is put out the maximum rated power and hope that enough
others do the same.  In this situation the plant operator has basically one
knob he can directly control, output voltage.  For a given amount of input
horsepower and load demand, he can keep the voltage up and drag down the
rotational speed (frequency); or he can let the voltage go down and keep
the frequency up.  But the grid enforces the frequency, thus the voltage is
always what goes down.  This tends to damage things and cause an increase
in customer complaints.  At some point the operator has to decide if he
will keep his plant and his service area connected to the grid.  If the
operator can supply the load demanded in his service area, he can
disconnect the service area from the grid, thus forming an "island."
(Apparently PG&E around San Francisco did this in '79 and had a devil of a
time getting reconnected to the grid.  I gather they also incurred the
wrath of the other utilities that participate in the west-coast grid since
PG&E's action further over-loaded the generating capacity remaining on the
grid.)  The operator does have some intermediate options, such as selective
load shedding, but that also angers customers.  Bringing customers back
on-line may actually be harder than bringing an alternator on-line, since
customers have the annoying habit of leaving all of their loads switched
on.  No load to full load instantaneously.  Ouch!

Bringing down the grid frequency is easier since the operator just cuts
back on the steam and lets the alternator be dragged along supplying no
power to the grid.  Eventually enough others also cut-back, and the load
demand slows the whole system down.  Each utility has to decide when to
bring a unit back on-line based on the best economic operating point for
their system.  Each plant and unit has a different operating cost depending
on fuel type (coal, fuel oil, natural gas, JP-4, uranium), fuel source
(What is today's price for natural gas?), efficiency (units #1 & #2 are
good, but unit #3 needs the boiler cleaned out), etc.

Rich
-- 3.5 Vdc guy in a 208 Vac world --


From: per@erix.ericsson.se (Per Hedeland) [-/+]
Date: 15 Jan 1998 14:39:52 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Help! Solaris xntpd broadcastclient -- is it broken?
X-Keywords: authentication
[-/+]

In article <34BCC702.768AC5CE@bbt.com>, Jeff Layton <layton@bbt.com> writes:
> I'm starting simply
>by just running the clients w/o a config file, and with the '-b' option
>like so:
>
># xntpd -b

The short answer is: Use 'xntpd -Ab' instead. This turns off the
requirement for authentication, which may or may not be acceptable to
you.

--Per Hedeland
per@erix.ericsson.se


From: "Jorg Heijnis" <j.heijnis@cable.a2000.nl> [-/+]
Date: Fri, 16 Jan 1998 10:55:48 +0100
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Error compiling xntpd on Linux
[-/+]
X-Keywords: restrict
[-/+] Slackware [-/+]

>Jorg Heijnis <j.heijnis@cable.a2000.nl> wrote:
>>I use the Slackware 3.4 distrubition with te gcc compiler, the output of
>>make is :
>
>The gcc compiler shipped with Slackware 3.4 is slightly customized, and
>includes a routine called 'restrict'.  This conflicts with the xntpd
routine
>'restrict' and causes the errors you saw.  To resolve this problem, get a
clean
>copy of gcc, either from source and build it yourself, or grab a binary
>distribution off sunsite or one of the other happy Linux sites.
>
Thanks to this information I solved the problem by putting a #define
restrict restrict2 in my header file, seems to work ok.


From: Dan Hollis <goemon@sasami.anime.net>
Date: 16 Jan 1998 08:34:24 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Use Power line frequency with PPS? (and other cheap time sources)
[-/+]
X-Keywords: PPS
[-/+] synchronized [-/+]

Michael Iverson <ivy@frith.acs.ohio-state.edu> wrote:
: In article <slrn6bn1ra.dte.ivy@frith.acs.ohio-state.edu>, Michael Iverson wrote:
:>Is it possible to use the AC line frequency to conditon the local
:>clock frequency?
: Thanks for the information everyone. From the sound of your replies, it
: seems that AC is not the best choice for a PPS signal. The power company
: does offer a free linux box rebooting service, however :-P

How about extracting clocking from a telco T1 line? From what I recall,
telco clock sources are synchronized nationwide to stratum 1 sources, and
are *very* accurate (at these data rates, you would have to be).

On the plus side, lots of people have T1's. On the minus side, the
equipment to extract clock signal would probably be more expensive.

Has anyone done this?

-Dan


From: carl@five-ten-sg.com (Carl Byington) [-/+]
Date: Sun, 18 Jan 1998 21:52:30 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Setting up a time server for a local network
[-/+]

-----BEGIN PGP SIGNED MESSAGE-----

In article <69qp3k$ajd1@news.warwick.net>, khall@warwick.net says...

>Conversely, can anyone recommend a real ntp client that will run on an NT
>server and sync with xntpd?

http://www.five-ten-sg.com/util/ntp35903.zip is a port of NTP to NT.

- --
PGP key available from the key servers.
Key fingerprint 95 F4 D3 94 66 BA 92 4E  06 1E 95 F8 74 A8 2F A0

-----BEGIN PGP SIGNATURE-----
Version: 4.5

iQCVAgUBNMJ5ldZjPoeWO7BhAQHGRwQAqKbq8BC6qWv/dVy84aeSVM87XBqQcDCm
cV/fb0b3GjVGSTVk26gU/NO9bRHzAQLmsSGWKN8fpEymXhwZZoVZT4cCsJAx6rWZ
4UQljGIrsb25lrQecPeqZRUPECPzCoOaDmkp3XMP2g3TRN9/ASxjh1o4mECb7iGB
K0N7bznZjMg=
=8teU
-----END PGP SIGNATURE-----


From: !panderson!@westpac.com.au (Peter Anderson) [-/+]
Date: Sun, 18 Jan 1998 23:56:22 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Setting up a time server for a local network
[-/+]
X-Keywords: dial
[-/+]

In article <69qp3k$ajd1@news.warwick.net>, "Ken Hall" <khall@warwick.net> wrote:
>I have a Linux system that runs xntpd and syncs to Internet stratum 2
>servers periodically via demand dial.  I want to use this machine to provide
>time service to the rest of my network, which consists of a mix of Win95,
>NT, and Netware systems.
>
>Problem is, the only time clients I can find for those platforms use RFC-868
>and won't sync to xntpd.
>
>Can anyone tell me where I can find an RFC-868 SERVER that will run on my
>Linux system and provice time sync service to the rest of my network?
>
>Conversely, can anyone recommend a real ntp client that will run on an NT
>server and sync with xntpd?
>
>
Checkout http://www.eecis.udel.edu/~ntp/software.html

Peter Anderson


From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 19 Jan 1998 09:10:34 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Setting up a time server for a local network
[-/+]

I run Dimension 4 on Win95 sucessfully. http://www.thinkman.com/~thinkman

Ulrich


From: hjj@news1.tele.dk (Hans J Jakobsen) [-/+]
Date: 17 Jan 1998 19:45:21 +0100
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Use Power line frequency with PPS? (and other cheap time sources)
[-/+]
X-Keywords: synchronized
[-/+]

Dan Hollis <goemon@sasami.anime.net> writes:

>How about extracting clocking from a telco T1 line? From what I recall,
>telco clock sources are synchronized nationwide to stratum 1 sources, and
>are *very* accurate (at these data rates, you would have to be).

Depending on the setup the clock could be generated from the other end.
ie the T1 is passed thru the telco system at a speed determinded by a
(telco) external clock.
--
Tele Danmark Erhverv, Data Divisionen      TLF: +45 8947 3339
Hans J Jakobsen                            FAX: +45 8947 3308
Skanderborgvej 234 st tv
DK 8620 Viby J    Danmark             Internet:hjj@datacom.dk400.dk


From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 20 Jan 1998 15:09:23 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: passwd & minpoll (was: Re: Help with a dialup network!
[-/+]
X-Keywords: delay
[-/+] FAQ [-/+] minpoll [-/+] password [-/+] poll [-/+] prefer [-/+]

In article <slrn6c6soi.m5r.ivy@frith.acs.ohio-state.edu> ivy@frith.acs.ohio-state.edu (Michael Iverson) writes:

[...]
> Now back to the original problem. Now that I know how to send a
> noninteractive password, I'm having problems setting the "minpoll"
> argument via xntpdc. The html page seems to indicate that it can't be
> done, but the "help" line from xntpdc says something to this effect:
>
>  addserver host [minpoll | prefer]
>
> I tried "addserver 128.146.1.7 minpoll 4" and "addserver 128.146.1.7 4".
> the first generated an error, and the second did nothing to the minpoll value.
>
> Any ideas?

xntpdc> he addser
function: configure a new server
usage: addserver addr [ keyid ] [ version ] [ minpoll|prefer ]

### Try "addserver 128.146.1.7 0 3 4"
### Even if the syntax might indicate optional arguments, only the last
### arguments may be omitted, and none between .

BTW: It worked for me:

xntpdc> pe
    remote           local      st poll reach  delay   offset    disp
=======================================================================
=cismsun.univ-ly 132.199.169.222  2   64  363 0.06448  0.006221 0.13503
+pcphy4.physik.u 132.199.169.222  3   64  377 0.00281 -0.000175 0.00053
=ns1.net.ohio-st 5.0.0.0         16   16    0 0.00000  0.000000 16.0000
...

.ns1.net.ohio-st 132.199.169.222  3   16   37 0.15784 -0.068760 0.88271

Regards,
Ulrich

P.S: Another FAQ candidate?


From: Matthew.Healy@yale.edu (Matthew D. Healy) [-/+]
Date: Tue, 20 Jan 1998 17:31:23 -0500
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Use Power line frequency with PPS?
[-/+]

In article <x7g1mq7vdd.fsf@capsicum.wsrcc.com>, Wolfgang Rupprecht
<wolfgang@dailyplanet.wsrcc.com> wrote:

>
> What is interesting is how did the power companies bring a generator
> on line without destroying it?  In the old days the power company
> would attach a set of light bulbs between the grid and the generator.
> The light would flash with the beat frequency (difference frequency)
> of the generator and the grid.  As the generator spun up the light
> would blink slower and slower.

Back when I was an electrical engineer (designing contactors, relays,
motor controllers, and other things inside grey boxes marked "Danger:
High Voltage" that hung on walls), my boss once told me an amusing
story.  When he was a junior technician, one of his jobs was to babysit
big Diesel engines on the test stand.  There was a knob to adjust
the speed, and a meter he was supposed to keep within X% of specified
speed throughout the test.  He found this to be a royal pain, but
after a while he noticed the other technicians seemed to be able
to do it much more easily...

Eventually, he figured out that they were using the strobe effect
of the fluorescent lights overhead...
--------
Matthew.Healy@yale.edu           http://ycmi.med.yale.edu/~healy/
As of 20 Oct 1997, only 802 days until Y2K....
Resistance _is_ futile! I have been absorbed by the BORG!  After
years of Unix and MacOS, I just got myself a home Windoze Box :-(


From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 21 Jan 1998 07:50:43 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntp4.0.71/linux - seems "success" a bit premature.
[-/+]
X-Keywords: loopfilter
[-/+] PLL [-/+]

In article <JUHA.98Jan20150924@samuraj.c3l.tyreso.se> juha@c3l.tyreso.se (Juha Sarlin) writes:

> You can't use the kernel pll in Linux 2.0.33 with ntp 4.0.71,
> because it needs quite different loopfilter weights.

Never heard of that before! In one document about NTPv4 RFC-1589 is
still mentioned. Also it would not explain why the kernel PLL works
for a while and then goes crazy, i.e. seems no longer updated.

Ulrich


From: juha@c3l.tyreso.se (Juha Sarlin) [-/+]
Date: 21 Jan 1998 15:08:41 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntp4.0.71/linux - seems "success" a bit premature.
[-/+]
X-Keywords: loopfilter
[-/+] PLL [-/+] poll [-/+]

Juha> You can't use the kernel pll in Linux 2.0.33 with ntp 4.0.71,
Juha> because it needs quite different loopfilter weights.

>>>>> "Ulrich" == Ulrich Windl <wiu09524@rrzc4> writes:

Ulrich> Never heard of that before! In one document about NTPv4 RFC-1589 is
Ulrich> still mentioned. Also it would not explain why the kernel PLL works
Ulrich> for a while and then goes crazy, i.e. seems no longer updated.

It "goes crazy" mostly because the poll interval is reduced only when
offset > 5 * sqrt(error), the xntp3-5.91 limit is offset > error.

So, if your frequency changes more than what can be handled at the max
poll interval, the offset will not get very close to zero.

ntp 4.0.71 works fine for me on Linux, when not using kernel pll.


From: Harlan Stenn <stenn@whimsy.udel.edu> [-/+]
Date: 21 Jan 1998 13:16:30 -0500
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: xntp3-5.92 is available (Release Candidate)
X-Keywords: adjtimed HP-UX
[-/+] release [-/+]

xntp3-5.92 is available on:

        ftp://ftp.udel.edu/pub/ntp/

3 files are available:

        xntp3-5.91-5.92.diffs.gz
        xntp3-5.92.tar.gz
        xntp3-5.92-export.tar.gz

This release is different from 5.91 in 2 ways:

- HP-UX portability patch for adjtimed and tickadj

- Some bcast/mcast patch in ntp_proto

If all goes well, this will become xntp3-6.0 Real Soon Now.

H


Next part