Hi Tom,
Seems to me this conversation is drifting back and forth between objectives.
It started out to explore if a common method of smear could be found for
purposes as Google, AWS, and Bloomberg are using it. As I understand it,
the whole point there is to "hide" the Leap Second from the ver
NTP is designed to disseminate the SI second and a UTC timestamp. If you want a
completely different timescale (e.g., UT1, or some smeared variant of UTC) it
seems like this could be part of NTP, not some opaque hack below or above NTP
so as to "fake out" ancient or hardcoded assumptions of NTP.
On 28 September 2016 at 14:39, Tony Finch wrote:
> Steve Summit wrote:
>> Me, I'd very much rather *not* add this sort of thing to (say)
>> NTP, because NTP doesn't have a problem with leap seconds.
This does seem true - hacking ntp feels like the wrong solution.
> Except that every leap second
> Actually, cosine with a much higher frequency might be the way to
> beat the median filter.
If the only application of leap smear is to placate NTP, and if all NTP clients
use the same hardcoded filter parameters, then, yes, by all means, find a
higher, optimal frequency.
But I would worry ab
In message <5538148C9CFA4B1FACC82994D3371084@pc52>, "Tom Van Baak" writes:
>Get down to the details about PC clock frequency instability and
>OS measurement jitter and I suspect you'll find that cosine vs.
>triangle is a red herring.
Actually, cosine with a much higher frequency might be
Steve Summit wrote:
>
> Me, I'd very much rather *not* add this sort of thing to (say)
> NTP, because NTP doesn't have a problem with leap seconds.
Except that every leap second is screwed up by a large proportion of NTP
servers...
Tony.
--
f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h p
Tony Finch wrote:
> Steve Summit wrote:
> > There seems to be a presumption in several comments in this
> > thread that (3) is necessarily identical to (2), but I think
> > that's a bad idea.
>
> You are completely right up to here, but it's probably unwise to dictate
> how (which part(s) of the s
Richard Thomas wrote:
> On Sep 27, 2016, at 7:41 PM, Steve Summit wrote:
> > It just feels right to me that any shenanigans should be confined
> > to the day that the leap second is at the end of, and that on the
> > next day, everything is back to normal.
>
> Remember that the leap second occurs
Harlan,
Get down to the details about PC clock frequency instability and OS measurement
jitter and I suspect you'll find that cosine vs. triangle is a red herring.
I would almost vote for random smear. The purpose of a smear is to obscure the
extra / missing second in UTC. If someone downstream
On 28 September 2016 at 12:35, Martin Burnicki
wrote:
> I think in general we need to distinguish if
>
> - smearing is done by a server, so that it hides the leap second from
> all its clients, and the clients don't even become aware of the leap second
>
> - smearing is done by a client, which rec
Martin,
Cosine smearing might need to be a choice. It's harder to track the
leap second if you get a sample during when both phase and frequency are
changing.
--
Harlan Stenn
http://networktimefoundation.org - be a member!
___
LEAPSECS mailing list
> Hm, IMO the advantage of the initial smear approach (24 hours before the
> leap second) is that smearing is finished as soon as the leap second has
> occurred, so the beginning of the next UTC day /hour / minute is accurate.
Martin,
I suspect your idea only works in cases when the time server i
> Does it matter that in Seattle the smear occurs at 5:00 in the afternoon,
> local time,
Richard,
When using local time, it's one step more complicated; in Seattle:
4:00 PM PST is when a leap second occurs in Winter (e.g., December 31)
5:00 PM PDT is when a leap second occurs in Summer (e.g
Tony Finch wrote:
> Steve Summit wrote:
>>
>> I think there are aspects of the implementation of any smearing
>> that are maybe being glossed over. I think it's important to
>> distinguish pretty carefully between three distinct "clocks",
>> or views of time:
>> 1. The time exchanged between mach
On Sep 27, 2016, at 7:41 PM, Steve Summit wrote:
> Stephen Colebourne asked:
>> 2) When to smear?
>> Some smear up to midnight, some smear after midnight, some smear both
>> sides. What are the arguments for/against each?
>
> I have a personal preference for smearing up to midnight.
> It just f
Steve Summit wrote:
>
> I think there are aspects of the implementation of any smearing
> that are maybe being glossed over. I think it's important to
> distinguish pretty carefully between three distinct "clocks",
> or views of time:
> 1. The time exchanged between machines by a protocol such as
Christopher Hoover wrote:
> This I believe is the most recent public statement on the topic:
>
> https://cloudplatform.googleblog.com/2015/05/Got-a-second-A-leap-second-that-is-Be-ready-for-June-30th.html
>
> One could imagine having a public ntp pool on the interwebs that
> implemented smearing.
Michael Shields via LEAPSECS wrote:
> On Tue, Sep 27, 2016 at 2:02 AM, Tony Finch wrote:
>> So, if everyone who is smearing is doing so piecewise-linear, it seems
>> there is a great opportunity for them to get together and choose a
>> consensus set of smear parameters.
>
> I think that would be
18 matches
Mail list logo
