UTC
Certainly. But what's your point? I don't see these utilities failing
if a second slips here or there. The one case where time is critical
is the power grid, and they keep their own time (Which, IIRC
approximates UTC).
The long term average of the power grid in the US is 60.000 Hz. Short
term variations from that can and do happen. It is to make sure that
the clocks run on time, on the average. It might be better to say
that the power grid approximates the SI second, since it has no notion
of which second it is (although the control infrastructure for the
grid most likely does).
Warner
The truly critical time functions will continue to use TAI,
or some variant as they currently do....
TAI time isn't a silver bullet. It is a timescale that one can
recover, with some effort, but only if one can get the leapsecond
meta-data from somewhere else, since time is overwhelming distributed
in UTC (even from GPS receivers that could give you TAI, but usually
choose not to). Using it does not eliminate the need to know leap
second information in general, since you have to interface to the
outside world in UTC at some point.
I know this because I've written several control systems that do use
TAI internally, and the issues with leap seconds are large, if you
want to get them right. If you refuse to accept this, then you are
denying reality.
Warner
Certainly. But what's your point? I don't see these utilities failing
if a second slips here or there. The one case where time is critical
is the power grid, and they keep their own time (Which, IIRC
approximates UTC).
The power companies used to use GOES heavily;
early this year the last of them switched to GPS
as a time and phase reference. If there's a power
industry person in time-nuts we'd love to ask you
a few questions.
The long term average of the power grid in the US is 60.000 Hz. Short
term variations from that can and do happen. It is to make sure that
the clocks run on time, on the average. It might be better to say
that the power grid approximates the SI second, since it has no notion
of which second it is (although the control infrastructure for the
grid most likely does).
Warner
For real plots of 60 Hz mains frequency, including
Allan deviation, see:
http://www.leapsecond.com/pages/mains/
The tolerance is good; but so far from the level of
astronomical or atomic seconds that it's not an
issue.
/tvb
Hi Tom:
Does your phase plot mean that a mains powered wall clock might be off
by 10 seconds?
Have Fun,
Brooke Clarke, N6GCE
w/Java http://www.PRC68.com
w/o Java http://www.pacificsites.com/~brooke/PRC68COM.shtml
http://www.precisionclock.com
Tom Van Baak wrote:
. . .
For real plots of 60 Hz mains frequency, including
Allan deviation, see:
. . .
/tvb
I have a digital clock that runs from the 60 hertz power. I have
noticed several times that TVA power can gain time up to 15 seconds
compared to UTC. Takes a few weeks.
I also did a stability test using a rubidium and dividers and I showed
about a +/- 0.03 hertz deviation over one hour, during a 24 hour test
period.
Maybe we all should run a power line test at the same time and we should
be able to see who is leading and lagging !
Brian N4FMN
Brooke Clarke wrote:
Hi Tom:
Does your phase plot mean that a mains powered wall clock might be off
by 10 seconds?
Have Fun,
Brooke Clarke, N6GCE
In message 42E813E4.4090001@erols.com, Chuck Harris writes:
[I split off this topic, it's interesting in its own right I think]
It may not be their fault. Have you tried taking modern toys apart
? Or a radio ? A TV-set ? There is nothing in there our kids can
learn anything from :-(
I must be very unusual, I fix modern TV's, radios, and other consumer
electronics doo-dads. It isn't generally economical to do what I do, but
it does keep me in touch with the bleeding edge of consumer manufacturing
techniques.
Right, but if you were a 7 year old kid, would you learn from it ?
The problem is that microelectronics obscure the basic circuit and
prevents you from poking around with anything but a few peripheral
capacitors which are mostly there for decoupling anyway...
When I took a television apart, there were a schematic pasted on the
back panel, and I could trace the circuit and with a book about
radio reception in hand, I could follow the signals progress. I
could look at the schematic and figure out what happened when I
pushed this button and turned that knob.
If my kid takes a television apart, he can trace any wire with a
signal until it hits an integrated circuit and then what ?
Yes, he'll learn that "it's all the black centipedes which do all
the stuff" and that is both valuable and precise knowledge, but it
is hardly going to make him think electronics is interesting.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Does your phase plot mean that a mains powered wall clock might be off
by 10 seconds?
Have Fun,
Brooke Clarke, N6GCE
Yes. I also keep an old AC synchronous motor
wall clock around just to see this effect. To be
fair, it is unusual for it to be off this much, or
for very long.
Maybe we all should run a power line test at the same time and we should
be able to see who is leading and lagging !
Brian N4FMN
You know, if the stackable TAPR module
project catches on another PCB on the list
could be a mains frequency monitor.
It would robustly filter and divide the 50/60 Hz
mains frequency to 1 PPS and then onboard
compare that 1 PPS against the local (OCXO,
atomic, or GPS) 1 PPS to a modest precision
(say, 1 or 10 us).
This would be a cheap board and then many
of us could monitor mains phase and log it in
a standard format. With the right software you
could get plots like this in real-time:
60 Hz AC Mains Frequency Accuracy Measurement
http://www.leapsecond.com/pages/mains/
For extra credit we could follow the GPScon
Z3801A web plot model. See:
International Web Plots
http://www.realhamradio.com/GPS_websites_list.htm
Also, while we're on the subject of monitoring
mains frequency do see Bryan Mumford's page.
Measuring the accuracy of 60 cycle power
http://www.bmumford.com/clocks/60cycle/index.html
If any of you also have an interest in precision
pendulum clocks and don't already have one
of his timers you should look into it:
MicroSet Precision Clock and Watch Timer
http://www.bmumford.com/microset.html
In message 42E813E4.4090001@erols.com, Chuck Harris writes:
Just because people don't care or notice, doesn't mean not important
to them.
Most people don't care about water, sewers, electricity and civil
order. That doesn't mean it's not important to them. They care
a lot as soon as it doesn't work.
Certainly. But what's your point?
It's just above in the first sentence: Just because your neighbor
hasn't heard about leap seconds doesn't mean that they are not
important to him.
No, your position is diffrent from Robs, you just don't recognize
the potential for harm at all, Rob at least recognizes that.
You may think that, but you would be wrong. I see things differently
than you. I don't see a world where the truly critical systems need
to be synced to UTC. Like all of the foibles engineers make, if time is
truly critical to an application, then the application will contain its own
timekeeping, and perhaps its own timescale. (Think NASA and mission
time. ) TAI was developed to handle those cases where seconds needed
to be handled in an unambiguous way.
That's a nice point of view, but experience seems to indicate that you
have not been able to sell it much. Practically anything I see these
days stipulate UTC time.
Until after a leap-second hands in the unbudgeted expense or if
we are lucky: the budget request.
You won't see any such budget request. None happened 7 years ago,
and none will happen this time either.
Have you seriously contemplated the difference between the systems
which were deployed 7 years ago and those deployed today ?
The time functions where leap seconds
matter will simply get another line added to their tables of anomalies. The
time functions where leap-seconds don't matter (most), will march along as
if nothing happened.
And someplaces those two kind of systems meet and trouble ensues...
Because unlike your ideal world, in the real world people slap computer
systems up without thinking about time.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
In message 20050727.171934.28808808.imp@bsdimp.com, Warner Losh writes:
Certainly. But what's your point? I don't see these utilities failing
if a second slips here or there. The one case where time is critical
is the power grid, and they keep their own time (Which, IIRC
approximates UTC).
The long term average of the power grid in the US is 60.000 Hz.
Are you sure this is still the case ?
Here in the "NordPool" area in nothern europe, 50Hz average went
out the window with the deregulation of the electricity grid because
nobody wanted to be forced to provide the extra power during one
season to gain back what was lost during the other.
And before that, the short term variations were on the order of
a year...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
In message 002d01c5933c$6c1d2f60$8e18f204@computer, "Tom Van Baak" writes:
You know, if the stackable TAPR module
project catches on another PCB on the list
could be a mains frequency monitor.
It would robustly filter and divide the 50/60 Hz
mains frequency to 1 PPS and then onboard
compare that 1 PPS against the local (OCXO,
atomic, or GPS) 1 PPS to a modest precision
(say, 1 or 10 us).
I actually wrote one in a Z80 many years ago: It would
measure the period of 50 mains cycles (ie: 1 second)
calculate the reciprocal and display frequency with
4 decimals.
Do it on a PIC18F* and feed it a 10MHz atomic clock
and you are done.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.