On 2011-09-22, Harlan Stenn wrote:
> Bill wrote:
>> On 2011-09-21, Harlan Stenn wrote:
>> > Bill wrote:
>> >> On 2011-09-21, Harlan Stenn wrote:
>> >> > Bill wrote:
>> >> >> Some operating systems (eg Linux) have the ability to do a much faster
>> >> >> than 500PPM rate change (10PPM in the
Bill wrote:
> On 2011-09-21, Harlan Stenn wrote:
> > Bill wrote:
> >> On 2011-09-21, Harlan Stenn wrote:
> >> > Bill wrote:
> >> >> Some operating systems (eg Linux) have the ability to do a much faster
> >> >> than 500PPM rate change (10PPM in the case of Linux) but ntp does
> >> >> not make
Richard B. Gilbert writes:
> I'm not going to do ANYTHING on Mars! We could, in principle, land a
> man on Mars. The cost would be enormous. The probable return on the
> investment does not appear sufficient to tempt anyone.
Well, we have machines on and around Mars that need to keep time and
t
On 2011-09-21, Harlan Stenn wrote:
> Bill wrote:
>> On 2011-09-21, Harlan Stenn wrote:
>> > Bill wrote:
>> >> Some operating systems (eg Linux) have the ability to do a much faster
>> >> than 500PPM rate change (10PPM in the case of Linux) but ntp does
>> >> not make use of that.
>> >
>> > .
On 9/21/2011 4:55 PM, John Hasler wrote:
Richard B. Gilbert writes:
Too bad that the movements of of the planets, moons, etc. are not
better behaved. Lacking the powers of the divine we must work around
the fact that the earth does not rotate exactly once in each
twenty-four hours, and the fact
Bill wrote:
> On 2011-09-21, Harlan Stenn wrote:
> > Bill wrote:
> >> Some operating systems (eg Linux) have the ability to do a much faster
> >> than 500PPM rate change (10PPM in the case of Linux) but ntp does
> >> not make use of that.
> >
> > ... because it would violate the assumptions a
On Sep 21, 3:04 pm, Harlan Stenn wrote:
> The timescale is a necessary part of the metadata.
>
> I think this overall situation is a case where "implied metadata" is
> biting us.
Worse than that, the IERS still refers to the 1986 version CCIR Rec.
460-4
ftp://hpiers.obspm.fr/iers/bul/bulc/BULLETI
On 2011-09-21, Harlan Stenn wrote:
> Bill wrote:
>> Some operating systems (eg Linux) have the ability to do a much faster
>> than 500PPM rate change (10PPM in the case of Linux) but ntp does
>> not make use of that.
>
> ... because it would violate the assumptions and rules about the loop
>
On 2011-09-21, David Woolley wrote:
> unruh wrote:
>> On 2011-09-21, David Woolley wrote:
>>> Richard B. Gilbert wrote:
>>>
It's unfortunate that the earth DOES NOT rotate exactly 360 degrees in
exactly 24. hours. This bit of poor design causes all sorts
>>> It's nothing l
unruh wrote:
On 2011-09-21, David Woolley wrote:
Richard B. Gilbert wrote:
It's unfortunate that the earth DOES NOT rotate exactly 360 degrees in
exactly 24. hours. This bit of poor design causes all sorts
It's nothing like it. It out by approximately 1 degree a day!
well, no
Chris wrote:
> Once upon a time, unruh said:
>> Posix clearly has never even though about leapseconds, so their
>> recommendations are pretty irrelevant.
>
> I wouldn't say they never thought about them; they made a choice to
> avoid them because too much code assumes "(time()%86400)==0" means
Harlan Stenn writes:
> Being able to rely on a common timescale is a great way to save huge
> amounts of time and money.
Such as, for example, a stream of sequentially-numbered TAI seconds.
> Put another way, going to a situation where there are multiple
> timescales will cause areas of great fri
On 2011-09-21, Richard B. Gilbert wrote:
> On 9/21/2011 2:59 PM, John Hasler wrote:
>> Richard B. Gilbert writes:
>>> It's unfortunate that the earth DOES NOT rotate exactly 360 degrees in
>>> exactly 24. hours. This bit of poor design causes all
>>> sorts of problems. Leap seconds ar
On 2011-09-21, David Woolley wrote:
> Richard B. Gilbert wrote:
>
>> It's unfortunate that the earth DOES NOT rotate exactly 360 degrees in
>> exactly 24. hours. This bit of poor design causes all sorts
>
> It's nothing like it. It out by approximately 1 degree a day!
well, not if
Richard B. Gilbert writes:
> Too bad that the movements of of the planets, moons, etc. are not
> better behaved. Lacking the powers of the divine we must work around
> the fact that the earth does not rotate exactly once in each
> twenty-four hours, and the fact that its revolution around the Sun
Bill wrote:
> Some operating systems (eg Linux) have the ability to do a much faster
> than 500PPM rate change (10PPM in the case of Linux) but ntp does
> not make use of that.
... because it would violate the assumptions and rules about the loop
behavior (I'm painting with a wide brush here)
I suspect any decision along these lines would require a *lot* of
discusison and analysis.
Some folks are fine with time precise to within a few minutes' time.
Some think a second is OK. Others have needs for milliseconds, and
there are folks with needs for greater precision.
One thing timestamp
E-Mail Sent to this address will be added to the BlackLists wrote:
Marco Marongiu wrote:
Would the ntpd -x (slew always) command line option
meet your needs?
That's just a short hand for setting a 10 minute step threshold with
tinker. It makes slews unlikely, but it also turns off the ker
Richard B. Gilbert wrote:
It's unfortunate that the earth DOES NOT rotate exactly 360 degrees in
exactly 24. hours. This bit of poor design causes all sorts
It's nothing like it. It out by approximately 1 degree a day!
___
questions ma
On 09/21/11 16:09, Richard B. Gilbert wrote:
> On 9/21/2011 2:59 PM, John Hasler wrote:
>> Richard B. Gilbert writes:
>>> It's unfortunate that the earth DOES NOT rotate exactly 360 degrees in
>>> exactly 24. hours. This bit of poor design causes all
>>> sorts of problems. Leap seconds
On 9/21/2011 2:59 PM, John Hasler wrote:
Richard B. Gilbert writes:
It's unfortunate that the earth DOES NOT rotate exactly 360 degrees in
exactly 24. hours. This bit of poor design causes all
sorts of problems. Leap seconds are just one of the symptoms!
Leapseconds are localizati
On 2011-09-21, Richard B. Gilbert wrote:
> On 9/21/2011 11:28 AM, Dave Hart wrote:
>> On Wed, Sep 21, 2011 at 15:06, Marco Marongiu wrote:
>>> Il 21/09/2011 16:51, Brian Utterback ha scritto:
Define "the right way".
>>>
>>> > From my original message, and D.Hart's reply, I'd say the right wa
Marco Marongiu wrote:
> The point is: would it be useful that such a feature
> is implemented in ntpd natively, and activated only
> "on demand" with a configuration directive or command
> line option?
Would the ntpd -x (slew always) command line option
meet your needs?
--
E-Mail Sent to thi
Richard B. Gilbert writes:
> It's unfortunate that the earth DOES NOT rotate exactly 360 degrees in
> exactly 24. hours. This bit of poor design causes all
> sorts of problems. Leap seconds are just one of the symptoms!
Leapseconds are localization, like time zones, daylight saving, a
On 9/21/2011 11:28 AM, Dave Hart wrote:
On Wed, Sep 21, 2011 at 15:06, Marco Marongiu wrote:
Il 21/09/2011 16:51, Brian Utterback ha scritto:
Define "the right way".
> From my original message, and D.Hart's reply, I'd say the right way
would be that the system support either to have a second
Once upon a time, unruh said:
>Posix clearly has never even though about leapseconds, so their
>recommendations are pretty irrelevant.
I wouldn't say they never thought about them; they made a choice to
avoid them because too much code assumes "(time()%86400)==0" means
midnight UTC, and leap se
On 2011-09-21, Marco Marongiu wrote:
> Il 21/09/2011 16:51, Brian Utterback ha scritto:
>> Define "the right way".
>
>>From my original message, and D.Hart's reply, I'd say the right way
> would be that the system support either to have a second 60 after the
> second 59 (leap insertion) or that se
On Sep 21, 7:51 am, Brian Utterback
wrote:
> The point is, there is no "right way" pr even "best way". There is only
> the "way that bests meets your needs".
Alternatively "pick which standard least upsets you to violate".
In many cases it may better not to use UTC. That's possible
with deployed
On 2011-09-21, Marco Marongiu wrote:
> Hi
>
> Thank you all for the interesting answers!
>
> I'd have one more question. Wouldn't it be convenient for ntpd to have
> an option, so that users may refuse to step back the clock in case of a
> leap second, and adjust the clock speed instead?
ntpd doe
On Wed, Sep 21, 2011 at 15:06, Marco Marongiu wrote:
> Il 21/09/2011 16:51, Brian Utterback ha scritto:
>> Define "the right way".
>
> >From my original message, and D.Hart's reply, I'd say the right way
> would be that the system support either to have a second 60 after the
> second 59 (leap inse
Il 21/09/2011 16:51, Brian Utterback ha scritto:
> Define "the right way".
>From my original message, and D.Hart's reply, I'd say the right way
would be that the system support either to have a second 60 after the
second 59 (leap insertion) or that second 00 follows 58.
But this would break POSIX
On 09/21/11 03:26, Marco Marongiu wrote:
> Almost all here seem to agree on the fact that POSIX systems don't
> manage leap second insertion the right way.
Define "the right way". Do you want the system time to be:
1. Monotonically increasing.
2. Such that interval arithmetic is valid.
3. Match t
Il 21/09/2011 10:09, Terje Mathisen ha scritto:
> This is what Google does, except for two tweaks:
Yep
The point is: would it be useful that such a feature is implemented in
ntpd natively, and activated only "on demand" with a configuration
directive or command line option?
-- bronto
___
Marco Marongiu wrote:
Il 21/09/2011 09:26, Marco Marongiu ha scritto:
Wouldn't it be convenient for ntpd to have
an option, so that users may refuse to step back the clock in case of a
leap second, and adjust the clock speed instead?
PS: I'd like to clarify I am not thinking about something li
Il 21/09/2011 09:26, Marco Marongiu ha scritto:
> Wouldn't it be convenient for ntpd to have
> an option, so that users may refuse to step back the clock in case of a
> leap second, and adjust the clock speed instead?
PS: I'd like to clarify I am not thinking about something like the
tinker direct
Hi
Thank you all for the interesting answers!
I'd have one more question. Wouldn't it be convenient for ntpd to have
an option, so that users may refuse to step back the clock in case of a
leap second, and adjust the clock speed instead?
I understand the risk for this: systems in two subnets, ea
36 matches
Mail list logo
