Re: ideas for new UTC rules
Only hours ago did I learn of the recent problems with D-Link routers. Remarkable! Just imagine the logical disconnect at the product development meetings. The marketing folks emphasizing the highly desirable feature of NTP compliance and the tech folks tossing a list of 50 servers into the center of the table - a list they probably spent all of a half hour compiling immediately before the meeting. Neither group pondering for even the briefest flicker what effect their product and customers would have on the servers, or conversely, what value the company was proposing to scavenge for free from using those servers. Even people in the internet industry appear to believe that it just exists free for the picking. These bozos haven't a leg to stand on. Am especially baffled at why it wouldn't occur to D-Link that it was their responsibility to field their own NTP servers. This is even more basic than the resource discovery issue. Hardwired host names - bah! Hardwired host names belonging to somebody else? Absolutely absurd. Not to give the slightest indication of blaming the victim, but am a bit perplexed exactly why this devolves to an issue of Danish infrastructure at all. Would think the EU would be the appropriate entity to plan, specify, fund and deploy time servers. I heartily applaud PHK for undertaking this volunteer commitment, but he's not the first and won't be the last good samaritan to caught up in the gears of commerce. Rob NOAO
Re: ideas for new UTC rules
Am especially baffled at why it wouldn't occur to D-Link that it was their responsibility to field their own NTP servers. This is even They don't even need to do that. They could have simply wired pool.ntp.org into the device. See http://www.pool.ntp.org/ for more info. -Tim Shepard [EMAIL PROTECTED]
Re: ideas for new UTC rules
In message [EMAIL PROTECTED], Steve Allen writes: ==During the second five years after the date of adoption. (YA+5 through YA+9) On a semi-annual basis the IERS should publish an immutable schedule of leap seconds predicted for five years into the future. This would be a big improvement. Along with the five-year immutable schedule published monthly, the IERS should continue to publish the provisional schedule of leap seconds for the next ten years. I'm not sure I see how this is useful other than judging how well the predictions turn out. If you put a provisional table of leapseconds into your products and reality turns out differently, who is liable for the discrepancies ? Anyone can attempt to make their own provisional table already now, yet nobody does it or at least nobody has admitted that they do so, so I somehow doubt that it will catch on later. If you add 10 more leapsecond opportunities per year you will decrease reliability of the provisional table, compared to if there is only two opportunities per year. -- 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: ideas for new UTC rules
On Apr 13, 2006, at 10:41 PM, Steve Allen wrote:Today is one of the four days in the year when Newcomb's_expression_ for the equation of time has a value of zeroand it was Samuel Beckett's hundredth birthday. Leap second as Godot: ESTRAGON: And if he doesn't come? VLADIMIR: We'll come back tomorrow. ESTRAGON: And then the day after tomorrow. VLADIMIR: Possibly. ESTRAGON: And so on. VLADIMIR: The point is— ESTRAGON: Until he comes. VLADIMIR: You're merciless. ESTRAGON: We came here yesterday. VLADIMIR: Ah no, there you're mistaken.I suspect that this is almost certain to offend everyone.Ok, I'll bite - you scurrilous traitor!Yesterday was also Maundy Thursday - the day Judas betrayed (or did he?) Jesus.Today, of course, is the anniversary of Lincoln's assassination.I would not be surprised to learn that the Time Lords arealready contemplating a scheme akin to this one.One suspects the Time Lords have never seriously consideredany option that would preserve leap seconds in any form, to anytolerance, utilizing any scheduling algorithm - no way no how.==Educate, educate, educatebut can you explain your scheme in under 23 seconds?The ITU-R should openly publish the UTC specification.Boy! On this Easter weekend one has to believe that thiswould require a miracle second only to the resurrection.The reality is that the ITU-R "specification" is just a minorfootnote pertaining to obsolete technologies of time signaltransport. One presumes nothing would stop the IERS frompublishing any scheduling algorithm such as you describe.The IERS should enter into dialog with the International VirtualObservatory Association (IVOA) and the Internet Engineering Task Force(IETF) to determine an adequately robust scheme for guaranteeing thedistribution and availability of the XML documents which give theschedule of upcoming leap seconds.This was indeed one of the notional use cases for VOEvent(http://www.ivoa.net/Documents/latest/VOEvent.html).The specification might benefit from dedicated IETF blessedsupport for leap second "aware" semantics, but it would be trivialeven using the current standard to represent such a schedule.The emerging VOEvent transport protocol(s) could certainlypropagate leap seconds as easily as reports of Supernovae,Gamma Ray Bursts and Earth-killer asteroids.To hear the detractors talk, a leap second is made to seem asdire an event as these cosmic catastrophes.As the five year prediction scheme goes into effect this will probablymean that there will be times when UT1 - UTC exceeds 0.9 seconds, butnot by very much.Cannot simultaneously constrain look-ahead and DUT1 tolerance.Suggest that rather than pick any fixed window, it is sufficientto define a mechanism and format for reporting the schedule -whatever it may be at any given time. After all - what if thestate of the art improves enough to permit accurate ten yearpredictions?Simply allow the IERS to announce any number of leap secondsin advance extending over any time horizon - and yes - occurringat the end of any month. If predictability is the goal, relaxingunnecessary constraints is the solution.Actually - one presumes the IERS currently has the authority todo both of these things. Have never heard anyone suggest thatthe next two leap seconds might not be announced simultaneously.And the ITU-R has already signed off on the monthly schedulingof leap seconds - this is the law of the land.What precisely is stopping us from implementing some variationof Steve's scheduling algorithm right now, today, this minute?All in favor, say aye!I am still not convinced that there is any need for change. I wouldlike to see further examples of why the status quo is not tolerable.I think even this gives the current "process" too much credit.There has not been a single cogent example of any negativeconsequence of leap seconds described in a convincing andwell characterized fashion. Moaning and moping is not thesame thing as making a coherent argument.Surely someone could draft a two page white paper describingto some (any) level whatsoever of technical, scientific, economicor sociological detail exactly what dreadful things happen to someparticular system in the presence of a leap second? And more tothe point, to provide evidence why we should believe the cure won'tbe worse than the disease.Rob SeamanNational Optical Astronomy Observatory
Re: ideas for new UTC rules
On Fri 2006-04-14T09:43:45 +0200, Poul-Henning Kamp hath writ:
If you put a provisional table of leapseconds into your products and
reality turns out differently, who is liable for the discrepancies ?
It's a good question. My immediate response is that my notions are
also part of the
Full Time-Scale-Aware Lawyer Employment act of {YA}
If you add 10 more leapsecond opportunities per year you will
decrease reliability of the provisional table, compared to if
there is only two opportunities per year.
The motivation is that allowing ten more per year requires action on
the part of all systems to upgrade anything which now believes only
June and December (and they get ten years of notice to do so). More
importantly, it allows the IERS to react better to any surprises in
decadal fluctuations of LOD.
I should add one more culturally-derived defense of a possible problem.
The DUT1 signals which only allow as much as 0.7 or 0.8 s of
magnitude. What sorts of applications will be affected by that?
Paraphrasing Westly in the fireswamps of The Princess Bride
DUT1 signals? I don't think they exist.
Well, I don't think anyone uses them. If there are still many
applications for DUT1 signals, most likely they are for sextant-style
navigation. If the leap seconds are being predicted five years in
advance then the annually published navigation almnacs can incorporate
projections which are as good as the broadcast signals.
--
Steve Allen [EMAIL PROTECTED]WGS-84 (GPS)
UCO/Lick ObservatoryNatural Sciences II, Room 165Lat +36.99858
University of CaliforniaVoice: +1 831 459 3046 Lng -122.06014
Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m
Re: ideas for new UTC rules
In message: [EMAIL PROTECTED] Rob Seaman [EMAIL PROTECTED] writes: : Simply allow the IERS to announce any number of leap seconds : in advance extending over any time horizon - and yes - occurring : at the end of any month. If predictability is the goal, relaxing : unnecessary constraints is the solution. There's a lot of timing gear that will fail if leap second is inserted not at the end of June or December, not least ntp. Warner
Re: ideas for new UTC rules
In message [EMAIL PROTECTED], Rob Seaman writes: The reality is that the ITU-R specification is just a minor footnote pertaining to obsolete technologies of time signal transport. One presumes nothing would stop the IERS from publishing any scheduling algorithm such as you describe. Actually, since ITU is an UN institution and IERS is not, decisions made by former will take legal precedence over decisions made by the latter in most countries. The specification might benefit from dedicated IETF blessed IETF is not really relevant here, POSIX is, and that takes us into ISO territory, which means YAIO (yet another international organization) which also doesn't have a real mandate. (ISO standards only take effect if the national Standards Institutes bless/ratify/translate them.) Actually - one presumes the IERS currently has the authority to do both of these things. Have never heard anyone suggest that the next two leap seconds might not be announced simultaneously. And the ITU-R has already signed off on the monthly scheduling of leap seconds - this is the law of the land. What precisely is stopping us from implementing some variation of Steve's scheduling algorithm right now, today, this minute? All in favor, say aye! aye! -- 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: ideas for new UTC rules
In message [EMAIL PROTECTED], Steve Allen writes:
On Fri 2006-04-14T09:43:45 +0200, Poul-Henning Kamp hath writ:
If you put a provisional table of leapseconds into your products and
reality turns out differently, who is liable for the discrepancies ?
It's a good question. My immediate response is that my notions are
also part of the
Full Time-Scale-Aware Lawyer Employment act of {YA}
I don't want us to adopt anything that makes that necessary.
If you add 10 more leapsecond opportunities per year you will
decrease reliability of the provisional table, compared to if
there is only two opportunities per year.
The motivation is that allowing ten more per year requires action on
the part of all systems to upgrade anything which now believes only
June and December (and they get ten years of notice to do so). More
importantly, it allows the IERS to react better to any surprises in
decadal fluctuations of LOD.
How does it allow IERS to react better if their horizon is defined
as five or ten years ?
Paraphrasing Westly in the fireswamps of The Princess Bride
DUT1 signals? I don't think they exist.
Well, I don't think anyone uses them. If there are still many
applications for DUT1 signals, most likely they are for sextant-style
navigation. If the leap seconds are being predicted five years in
advance then the annually published navigation almnacs can incorporate
projections which are as good as the broadcast signals.
Agreed.
--
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: ideas for new UTC rules
On Fri 2006-04-14T19:39:31 +0200, Poul-Henning Kamp hath writ:
In message [EMAIL PROTECTED], Steve Allen writes:
It's a good question. My immediate response is that my notions are
also part of the
Full Time-Scale-Aware Lawyer Employment act of {YA}
I don't want us to adopt anything that makes that necessary.
My apologies for unfortunate timing on my joke.
Only hours ago did I learn of the recent problems with D-Link routers.
http://people.freebsd.org/~phk/dlink/
and the media coverage at
http://yro.slashdot.org/article.pl?sid=06/04/07/130209
http://news.bbc.co.uk/1/hi/technology/4906138.stm
which hearks back to the older similar problem with NetGear
http://www.cs.wisc.edu/~plonka/netgear-sntp/
--
Steve Allen [EMAIL PROTECTED]WGS-84 (GPS)
UCO/Lick ObservatoryNatural Sciences II, Room 165Lat +36.99858
University of CaliforniaVoice: +1 831 459 3046 Lng -122.06014
Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m
