Re: Monsters from the id

2006-01-14 Thread Rob Seaman
On Jan 13, 2006, at 12:46 AM, John Cowan wrote: In the end, it will be impossible to maintain the notion that a solarday is 24h of 60m of 60s each: we wind up, IIRC, with the solar dayand lunar month both at about 47 current solar days. There's a lot of difference between what happens over a billion yearsand a million years.  Length of day increases only about 20s per millionyears.  Should we be here to care in a million years, only a 1/4 of 1/10 ofone percent tweak to the length of the "civil second" would suffice to allowour Babylonian clock paradigm to continue in use.  Alternately, we mightdecide to add one second to just one minute out of each hour.I won't claim one of these would be the choice.  There are manifoldoptions for representing time.  But I do assert that our descendants - foras long as they may be regarded as human - will desire to have somecommon way to represent fractions of a day.  And no matter whatrepresentation they choose, they will still face the quadraticaccumulation of leap seconds or their equivalent.Far from being a motivating factor for deprecating leap seconds, thequadratic clock lag resulting from the roughly linear tidal slowing ofthe Earth is precisely the strongest argument for preserving meansolar time as our common basis for timekeeping now and forever.Besides, it is simply a charming fact of life in the solar system thatour Moon is receding while the Earth spins down.  Apollo era laserretro-reflectors show that for each second our day lengthens, theMoon's orbital radius grows by a mile or so.Time is a fundamental element of all that we do.  Surely publicpolicy should not be governed by a drab and dystopian vision ofa fragmented planet scrabbling randomly to keep our disjointclocks aligned.The simplest - nay, the only - way to keep our clocks synchronizedone to the other is to keep them all tied to Mother Earth. "You think the Earth people think we're strange you think."Rob SeamanNOAO

Re: Report of Leap Second Problem with GPS Data

2006-01-14 Thread Rob Seaman

On Jan 13, 2006, at 6:26 AM, Richard Langley wrote:


FYI.


Thanks!  Actual reports from the field, how novel!


**

IGS Station Mail  12 Jan 14:59:42 PST 2006  Message
Number 760
**


Author: Michael Moore

  Geoscience Australia
Australian Regional GPS Network
  Geodetic Operation

ADVISORY:

High rate data, 1Hz 15 minute files, from the ARGN suffered a software
problem due to the recently introduced UTC leap-second. Data from
DOY 001 to
DOY 009 is 1s off in the timestamps reported n the RINEX files.
This problem
only applies to the 1Hz 15minute files submitted from the ARGN. The
software
problem has been fixed, and all files from DOY 010 is reporting the
correct
time.

RINEX headers for DARR from DOY 009, was incorrectly reporting an
antenna
height of 0.000. The headers have now been fixed to report the correct
antenna height of 0.0025, and the data from DOY 009 has been
resubmitted with
the correct header information.


I won't claim to know the intrinsic importance attached to this.
Critical systems may depend on the information.  But is it fair to
sum up the situation by saying that a leap second triggered a couple
of bugs (or perhaps one common bug), they were detected, have been
fixed, and affected data products have been remediated?  Also, it
appears that some other data products were unaffected?

So, the issue has been resolved - would likely have been resolved
sooner if a leap second had occurred earlier - and is no longer
directly pertinent to a discussion of future leap seconds?

Well done, Geoscience Australia!

Rob Seaman
NOAO


Re: Report of Leap Second Problem with GPS Data

2006-01-14 Thread M. Warner Losh
In message: [EMAIL PROTECTED]
Poul-Henning Kamp [EMAIL PROTECTED] writes:
: In message [EMAIL PROTECTED], Rob Seaman writes:
: On Jan 13, 2006, at 6:26 AM, Richard Langley wrote:
:
: I won't claim to know the intrinsic importance attached to this.
: Critical systems may depend on the information.  But is it fair to
: sum up the situation by saying that a leap second triggered a couple
: of bugs (or perhaps one common bug), they were detected, have been
: fixed, and affected data products have been remediated?  Also, it
: appears that some other data products were unaffected?
: 
: So, the issue has been resolved - would likely have been resolved
: sooner if a leap second had occurred earlier - and is no longer
: directly pertinent to a discussion of future leap seconds?
:
: Yeah, right
:
: This goes counter to my claims so it is of no importance.
:
: Sorry, things don't work that way Rob.

This time, there were no reports of death with the leap second,
therefore they can't be too bad... :-)

Warner


Re: Problems with GLONASS Raw Receiver Data at Start of New Year

2006-01-14 Thread Rob Seaman

On Jan 13, 2006, at 7:51 AM, Richard Langley wrote:


The International GNSS Service (IGS) includes a sub-network of
continuously
operating GLONASS monitor stations (about 50) including one at the
University
of New Brunswick (UNB1).  At UNB1 we lost C1 (coarse code on L1
frequencies),
P1 (precision code on L1), and P2 (precision code on L2)
observations on the 5
GLONASS satellites we were tracking at 00:01:30 GPS Time on 1
January 2006
along with phase jumps in L1 (carrier phase on L1) and L2 (carrier
phase on
L2).


Perhaps you can expand on the meaning of all this.  Presumably this
would represent an infrequent occurrence?  What are the implications
for downstream systems?  For that matter, what systems lie downstream?


Code measurements were back at 00:04:00.


So the problem extended for 2.5 hours from 00:01:30 - 00:04:00 GPS
Time?  Were there repercussions that have persisted after this?


I have just learned from one of the IGS analysis centres that all
January 1
IGS GLONASS observation files that they checked show a similar
problem.


The leap second has not been mentioned, but presumably we are to
infer that it triggered this behavior?  Would be absolutely delighted
to learn more about the IGS, both in general and to provide context
for interpreting this report.

As with the previous mail, I won't claim to be able to attach an
estimation of the importance of the events described.  We obviously
all believe leap seconds are worthy of discussion or we wouldn't be
here.  I presume many of us read RISKS Digest and can dream up scary
scenarios.  But there are also risks associated with *not* having
leap seconds, with allowing DUT1 to increase beyond 0.9s, for
instance.  And events triggered by those risks would not draw
worldwide scrutiny - they could occur year-round and the media circus
would have moved on.

Rob Seaman
NOAO


Re: Report of Leap Second Problem with GPS Data

2006-01-14 Thread Rob Seaman

This goes counter to my claims so it is of no importance.


and


This time, there were no reports of death with the leap second,
therefore they can't be too bad... :-)


I invite derision with my flights of rhetoric.  But this is an
internet forum and a little leeway may be warranted.  We all have our
day jobs with more pragmatic requirements.  For whatever reason, UTC
is of importance to each of us - both the immediate day-to-day issues
as well as the long term philosophical issues.

Reports of significant misbehavior triggered by the leap second are
to be expected.  Honestly, I am surprised that there have been so few
so far - but perhaps two weeks is about the right time for data to be
gathered and turned into a report.  I won't belabor the notion that
the solutions to any problems revealed in these reports might indeed
be expected to be a little more subtle than never issue another leap
second.

But let's imagine we were to identify a consensus vision for the path
forward.  (Seems a bit unlikely at the moment :-)  So all the
interested parties would be in agreement on the changes to be made to
UTC (and/or TAI and/or whatever else) - and in agreement that any
changes were needed at all.  Again - just for the sake of argument.

There would still need to be an implementation plan.  That plan would
need to analyze risks (and benefits) and costs.  It would need to
reveal a schedule, likely in stages over many years.  If you believe
there are significant risks associated with the complex system
involved with the issuance of leap seconds, are significant risks not
to be expected with making changes to that system?

We're all concerned about risks.  Unplanned changes to deployed
systems are among the most dangerous.

Rob


Re: Problems with GLONASS Raw Receiver Data at Start of New Year

2006-01-14 Thread John Cowan
Rob Seaman scripsit:

 But there are also risks associated with *not* having
 leap seconds, with allowing DUT1 to increase beyond 0.9s, for
 instance.  And events triggered by those risks would not draw
 worldwide scrutiny - they could occur year-round and the media circus
 would have moved on.

I'd expect to see a wave of breakage as DUT1 exceeded 0.9s for the first
time, and a second wave as it exceeded 1s for the first time.  After
that, of course, the problems would no longer be relevant.  :-)

--
They tried to pierce your heart John Cowan
with a Morgul-knife that remains in the http://www.ccil.org/~cowan
wound.  If they had succeeded, you wouldhttp://www.reutershealth.com
become a wraith under the domination of the Dark Lord. --Gandalf


Re: Report of Leap Second Problem with GPS Data

2006-01-14 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Rob Seaman writes:

I invite derision with my flights of rhetoric.

As published papers [1] document, you have way to go.

Poul-Henning

[1] George August, Anita Balliro et all, study of Rotation of the
Earth, approx 1993.  (find it yourself).

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


Re: Problems with GLONASS Raw Receiver Data at Start of New Year

2006-01-14 Thread Rob Seaman

On Jan 14, 2006, at 11:20 AM, John Cowan wrote:


I'd expect to see a wave of breakage as DUT1 exceeded 0.9s for the
first time, and a second wave as it exceeded 1s for the first
time.  After that, of course, the problems would no longer be
relevant.  :-)


I haven't been able to decipher what the humor is meant to be here -
will gladly admit that this is likely a failure on my part.  I won't
ask you to explain the joke, but rather I suspect you had a more
basic point you were seeking to make.  Is there some reason that
risks resulting from a diverging DUT1 can be expected to be mitigated
(even in part) as it grows past 1s?

If we discount the melodramatics of this list (will gladly admit to
being one of the offenders), we are left with a rather interesting
technical discussion of how best to deliver both interval time and
earth orientation information to a variety of classes of users.
Whatever the context of that discussion and of our own personal
points of view, one large element of confusion is precisely that TAI
mimics UTC mimics GPS mimics...  We might more easily recognize the
distinct character of each time-scale if neither their values or the
representations of those values permitted them to masquerade one for
the other.

Atomic Time is naturally represented as an unending count of
seconds.  Universal Time is naturally represented as a fraction of a
day (equivalent to an angle).  It is that naive heuristics exist that
claim to convert Atomic Time into fractional days - or alternately,
to convert Universal Time into a count of seconds - that creates
confusion between the two.

Rob Seaman
NOAO