UTC
In message: 87396.1122531897@phk.freebsd.dk
"Poul-Henning Kamp" phk@haven.freebsd.dk writes:
: >> 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 Turin leap second survey said that loss of life had occurred due
to a leap second insertion event. The survey didn't provide any
additional details. However, I've not been able to find any media
coverage of such an event, nor find other documentary evidence to
support it.
Warner
The Turin leap second survey said that loss of life had occurred due
to a leap second insertion event. The survey didn't provide any
additional details. However, I've not been able to find any media
coverage of such an event, nor find other documentary evidence to
support it.
Sorry, I haven't ever seen anything on this either.
But on a related note, let's do some math. The
population of Earth is 6.4e9. The birth rate is
21 / 1000 / year so there are 4.3 births per
second (4.3 Hz for the purists ;-). The death
rate is 9 / 1000 / year so there are 1.8 deaths
per second.
That suggests about 4 babies are born and
2 people die during a leap second.
/tvb
TVB said, "If there's a power
industry person in time-nuts we'd love to ask you
a few questions."
I'm not a power industry person, but I've researched the
problem over the years. Here are some of the results.
The generators are all synchronous machines. The ones in
one power plant rotate with very little phase angle
difference between them. Long transmission lines act like
springs, so that phase angles in different plants can be
different, maybe by tens of degrees.
If you had one isolated generator, perhaps the power plant
for a small island, you would have a speed control loop for
the turbine (or engine) throttle that controls power to the
generator shaft. Then you would have a second controller
that could integrate frequency error in a way that trims the
speed control to precisely hold the frequency.
Changes in power delivered to the load by the generator cause
the speed control to change the power delivered to the generator.
If there is a step change in power, like the 5 minute shutdown
of industry at noon on Armistice Day in the 1920s, the power
difference between turbine and generator causes the rotor to
accelerate or decelerate. The speed controller changes the drive
power quickly but not immediately. Stability requires less than
infinite gain. The slower integrating frequency control gradually
brings the frequency error back to zero.
One form of integrating control consists of a person looking at
the powerhouse clock and a standard like WWV. As the error grows,
the person fine-tunes the speed control. Changes may be made a few
times per day.
If the generator is part of a power network then it is not possible
to use integrating frequency control, because you can only have one
of them in a system. Two or more will not track and the result is
wasted power as they fight each other for control. One generator
can't possibly affect the thousands of generators connected to a
power network.
Power distribution networks have dispatchers in regional offices.
As I understand it, the dispatcher watches the time error as well
as the balance of power flows. The dispatcher tells a power plant
how many megawatts to put into the line, not what speed to run.
One of the factors in adjusting the megawatt balance is the time
error.
The US is divided into 3 or 4 independent zones that are isolated
by very high voltage DC transmission lines. Maybe it was 3 - East,
West and Texas.
About 15 years ago, I used a frequency input on a control system to
compare and plot the difference between power line and crystal time.
The power line lagged during the day as industrial loads exceeded
the dispatcher's requests for power and caught up again in the early
morning hours. The swings seldom exceeded +/- six seconds in MN.
I don't know if they do this, but adding a one-second change in UTC
would be no problem at all. Of course, it would take several hours.
Hope this was useful,
Bill Hawkins
At 02:40 AM 7/28/2005, M. Warner Losh wrote...
The Turin leap second survey said that loss of life had occurred due
to a leap second insertion event.
That is a deliberately misleading statement. It MUST be the case that the loss of life occurred due to and improperly designed, incorrectly specified, or improperly used system. The person/organization at fault seeks to misplace blame.
Tom Van Baak wrote:
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:
I'm all for it -- maybe not as a formal TAPR project (because I suspect
the volume would be fairly low) but certainly we could share a design,
and I strongly suspect (but can't promise) that TAPR could at least make
the boards available, if not a full kit.
Someone want to take on the design challenge? If so, contact me
off-list and I can provide the mechanical and electrical details for the
stacked board design -- basically, it's just a standard board size with
standardized locations for up to 6 output BNCs, one input BNC, and
headers so the raw DC in and reference in can be routed to boards above
and below.
John
Mike S wrote:
At 02:40 AM 7/28/2005, M. Warner Losh wrote...
The Turin leap second survey said that loss of life had occurred due
to a leap second insertion event.
That is a deliberately misleading statement. It MUST be the case that the loss of life occurred due to and improperly designed, incorrectly specified, or improperly used system. The person/organization at fault seeks to misplace blame.
I've stayed out of this argument, because frankly I don't have a strong
view on the subject, but I don't think this is misleading at all. The
point Warner and Poul-Henning have been trying to make is that leap
seconds will cause programming errors, and this seems to be (anecdotal
and undetailed) evidence of that.
Certainly the death (if it occurred) was not an automatic result of the
leapsecond, but rather was the result of something that broke because it
wasn't properly programmed to deal with the leapsecond. But that's the
one of the points the anti-leapsecond folks are trying to make -- things
will break, because the majority of programmers don't know how to, or
that they even need to, program for leapseconds, and the infrequent and
unpredictable occurrence of leapseconds makes it unlikely that situation
will change.
John
In message: 6.2.3.4.0.20050728064100.02d9dc68@mjs.alientech.net
mikes@flatsurface.com (Mike S) writes:
: At 02:40 AM 7/28/2005, M. Warner Losh wrote...
:
: >The Turin leap second survey said that loss of life had occurred due
: >to a leap second insertion event.
: That is a deliberately misleading statement. It MUST be the case
: that the loss of life occurred due to and improperly designed,
: incorrectly specified, or improperly used system. The
: person/organization at fault seeks to misplace blame.
Well duh! Designing things is hard. Let's go shopping instead! The
point is that there's a number of real world consequences to badly
designed thing. That's part of the cost of getting something right,
isn't it?
Warner
At 08:29 AM 7/28/2005, John Ackermann N8UR wrote...
Mike S wrote:
That is a deliberately misleading statement. It MUST be the case that the loss of life occurred due to and improperly designed, incorrectly specified, or improperly used system. The person/organization at fault seeks to misplace blame.
that leap seconds will cause programming errors,
Programmers cause programming errors. Leap seconds may make them apparent.
Certainly the death (if it occurred) was not an automatic result of the leapsecond, but rather was the result of something that broke because it wasn't properly programmed to deal with the leapsecond.
The counter argument is that removing leapseconds will break properly implemented systems in unknown ways, the blame will them be not with someone who did things in violation of a well documented specification, but with those who changed the specification in a fundamentally incompatible way for selfish reasons.
mikes@flatsurface.com (Mike S) writes:
Programmers cause programming errors. Leap seconds may make them apparent.
Certainly the death (if it occurred) was not an automatic result of the leapsecond, but rather was the result of something that broke because it wasn't properly programmed to deal with the leapsecond.
The counter argument is that removing leapseconds will break properly implemented systems in unknown ways, the blame will them be not with someone who did things in violation of a well documented specification, but with those who changed the specification in a fundamentally incompatible way for selfish reasons.
How does a properly implemented system accounting for leapseconds fail
when leapseconds fail to come? Sure there will be unnessesary code
that could be removed. But I do not see why the system would break.
--
Björn
In message m3k6jabyoh.fsf@lysator.liu.se, Bjorn Gabrielsson writes:
mikes@flatsurface.com (Mike S) writes:
Programmers cause programming errors. Leap seconds may make them apparent.
=20
Certainly the death (if it occurred) was not an automatic result of the =
leapsecond, but rather was the result of something that broke because it wa=
sn't properly programmed to deal with the leapsecond.
=20
The counter argument is that removing leapseconds will break properly imp=
lemented systems in unknown ways, the blame will them be not with someone w=
ho did things in violation of a well documented specification, but with tho=
se who changed the specification in a fundamentally incompatible way for se=
lfish reasons.
How does a properly implemented system accounting for leapseconds fail
when leapseconds fail to come? Sure there will be unnessesary code
that could be removed. But I do not see why the system would break.
My interpretation of this is that systems which assume that DUT < 1s
fail, when leap seconds are applied.
That's probably true, but since DUT is only relevant if you study
extraterrestial objects, we can safely assume that 99.9% or more
of those systems involve astronomers and optics.
--
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.