From: Steve Allen <[EMAIL PROTECTED]>
Subject: Re: [LEAPSECS] Introduction of long term scheduling
Date: Mon, 8 Jan 2007 22:57:23 -0800
Message-ID: <[EMAIL PROTECTED]>
Steve,
> On Mon 2007-01-08T01:54:56 +, Zefram hath writ:
> > Possibly TT could also be used in some form, for interval calcul
On Jan 8, 2007, at 22:57, Steve Allen wrote:
GPS is not (TAI - 19)
What is GPS time, anyway? I had assumed someone had simply defined
GPS to be TAI - 19, and made the goal of the satellites to
approximate GPS time, i.e. that GPS and TAI are the same (up to
isomorphism in some "category of meas
On Mon 2007-01-08T01:54:56 +, Zefram hath writ:
> Possibly TT could also be used in some form, for interval calculations
> in the pre-caesium age.
Please do not consider the use of TT as a driver for the development
of any sort of commonplace API. In the far past no records were made
using TT
In message: <[EMAIL PROTECTED]>
Tony Finch <[EMAIL PROTECTED]> writes:
: On Sat, 6 Jan 2007, M. Warner Losh wrote:
: >
: > Unfortunately, the kernel has to have a notion of time stepping around
: > a leap-second if it implements ntp.
:
: Surely ntpd could be altered to isolate the kerne
On Sat, 6 Jan 2007, M. Warner Losh wrote:
>
> Unfortunately, the kernel has to have a notion of time stepping around
> a leap-second if it implements ntp.
Surely ntpd could be altered to isolate the kernel from ntp's broken
timescale (assuming the kernel has an atomic seconds count timescale)
Ton
In message <[EMAIL PROTECTED]>, Zefram writes:
>Poul-Henning Kamp wrote:
>>We certainly don't want to transmit the leap-second table with every
>>single NTP packet, because, as a result, we would need to examine
>>it every time to see if something changed.
>
>Once we've got an up-to-date table, bar
On Mon, 8 Jan 2007, Zefram wrote:
> Possibly TT could also be used in some form, for interval calculations
> in the pre-caesium age.
In that case you'd need a model (probably involving rubber seconds) of the
TT<->UT translation. It doesn't seem worth doing to me because of the
small number of app
Poul-Henning Kamp wrote:
>We certainly don't want to transmit the leap-second table with every
>single NTP packet, because, as a result, we would need to examine
>it every time to see if something changed.
Once we've got an up-to-date table, barring faults, we only need to check
to see whether the
On Mon, 8 Jan 2007, Zefram wrote:
>
> Conciseness is useful for network protocols. Bandwidth is increasingly
> the limiting factor: CPU speed and bulk storage sizes have been
> increasing faster. An NTPv3 packet is only 48 octets of UDP payload;
> if a leap second table is to be disseminated in t
In message <[EMAIL PROTECTED]>, Zefram writes:
>Clive D.W. Feather wrote:
>>Firstly, I agree with Steve when he asks "why bother?". You're solving the
>>wrong problem.
>
>Conciseness is useful for network protocols.
On the other hand, one should not forget that the OSI protocols was
killed by conc
Clive D.W. Feather wrote:
>Firstly, I agree with Steve when he asks "why bother?". You're solving the
>wrong problem.
Conciseness is useful for network protocols. Bandwidth is increasingly
the limiting factor: CPU speed and bulk storage sizes have been
increasing faster. An NTPv3 packet is only
Rob Seaman said:
> Which raises the question of how concisely one can express a leap
> second table.
Firstly, I agree with Steve when he asks "why bother?". You're solving the
wrong problem.
However, having said that:
> So, let's see - assume:
>1) all 20th century leap seconds can be sta
12 matches
Mail list logo
