[LEAPSECS] LEAPSECS Digest, Vol 122, Issue 13
Jonathan Natale
jnatale at juniper.net
Tue Dec 27 09:57:16 EST 2016
Is it worthwhile to find a smear interval such that the true length of the smeared second can be represented exactly as a float? The current proposals do not seem to have this property. So the sum, over the entire smearing interval, of all the true lengths of all the smeared seconds, does not equal the length of the entire smearing interval. To add insult to injury, there are many subtle float bugs. For example, I ran into one where the sticky bit is only saved 8 bits out in python on VMs. Maybe it is better to write such code using longs and avoid floats altogether?
-----Original Message-----
From: LEAPSECS [mailto:leapsecs-bounces at leapsecond.com] On Behalf Of leapsecs-request at leapsecond.com
Sent: Friday, December 23, 2016 1:30 AM
To: leapsecs at leapsecond.com
Subject: LEAPSECS Digest, Vol 122, Issue 13
Send LEAPSECS mailing list submissions to
leapsecs at leapsecond.com
To subscribe or unsubscribe via the World Wide Web, visit
https://pairlist6.pair.net/mailman/listinfo/leapsecs
or, via email, send a message with subject or body 'help' to
leapsecs-request at leapsecond.com
You can reach the person managing the list at
leapsecs-owner at leapsecond.com
When replying, please edit your Subject line so it is more specific than "Re: Contents of LEAPSECS digest..."
Today's Topics:
1. alternative to smearing (John Sauter)
2. Amazon leaps and smears (Steve Allen)
3. Re: Leap second smearing test results (Martin Burnicki)
4. Re: Leap second smearing test results (Zefram)
5. Re: Leap second smearing test results (Warner Losh)
----------------------------------------------------------------------
Message: 1
Date: Thu, 22 Dec 2016 10:10:38 -0500
From: John Sauter <John_Sauter at systemeyescomputerstore.com>
To: Leap Second Discussion List <leapsecs at leapsecond.com>
Subject: [LEAPSECS] alternative to smearing
Message-ID: <1482419438.6023.3.camel at systemeyescomputerstore.com>
Content-Type: text/plain; charset="utf-8"
An alternative to smearing is to persuade applications to deal with UTC and the Gregorian calendar as it is, with its variable-length months and minutes. In support of that alternative, I am making available some subroutines which applications can use to deal with time. This is an update to the preliminary code that I previously posted to the leap seconds mailing list. The code can be extracted from the PDF file at this URL:
<https://commons.wikimedia.org/wiki/File:Avoid_Using_POSIX_time_t_for_T
elling_Time.pdf>
The subroutines use a table of changes in Delta T to track leap seconds. Most of the table in these subroutines was computed based on the latest research into historical values of Delta T from F. R.
Stephenson, L. V. Morrison and C. Y. Hohenkerk in this paper:
<http://rspa.royalsocietypublishing.org/content/472/2196/20160404>
The computations are described in an update of my earlier paper on this subject, at this URL:
<https://commons.wikimedia.org/wiki/File:Extending_Coordinated_Universa
l_Time_to_Dates_Before_1972.pdf>
I would be glad for any comments anyone might have on my work.
John Sauter (John_Sauter at systemeyescomputerstore.com)
--
PGP fingerprint?E24A D25B E5FE 4914 A603 ?49EC 7030 3EA1 9A0B 511E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20161222/48a41cae/attachment-0001.pgp>
------------------------------
Message: 2
Date: Thu, 22 Dec 2016 13:34:05 -0800
From: Steve Allen <sla at ucolick.org>
To: Leap Second Discussion List <leapsecs at leapsecond.com>
Subject: [LEAPSECS] Amazon leaps and smears
Message-ID: <20161222213404.GB24554 at ucolick.org>
Content-Type: text/plain; charset=us-ascii
Amazon's leap strategy is outlined today
https://forums.aws.amazon.com/ann.jspa?annID=4320
It is the same as in 2015 where different OS use different methods.
--
Steve Allen <sla at ucolick.org> WGS-84 (GPS)
UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855
1156 High Street Voice: +1 831 459 3046 Lng -122.06015
Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
------------------------------
Message: 3
Date: Fri, 23 Dec 2016 01:58:54 +0100
From: Martin Burnicki <martin.burnicki at meinberg.de>
To: leapsecs at leapsecond.com
Subject: Re: [LEAPSECS] Leap second smearing test results
Message-ID: <585C76CE.6080305 at meinberg.de>
Content-Type: text/plain; charset=UTF-8
Hi all,
I've run some more tests with smearing of leap seconds, and have updated the PDF with my results:
https://www.meinberg.de/download/burnicki/ntp_leap_smearing_test_results.pdf
It's late here right now and I've just finished the PDF, so I'm going to reply to some other emails in this thread tomorrow. ;-)
Martin
--
Martin Burnicki
MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burnicki at meinberg.de
Phone: +49 (0)5281 9309-14
Fax: +49 (0)5281 9309-30
Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Gesch?ftsf?hrer/Managing Directors: G?nter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung
Web: http://www.meinberg.de
------------------------------
Message: 4
Date: Fri, 23 Dec 2016 01:48:33 +0000
From: Zefram <zefram at fysh.org>
To: Leap Second Discussion List <leapsecs at leapsecond.com>
Subject: Re: [LEAPSECS] Leap second smearing test results
Message-ID: <20161223014833.GQ6507 at fysh.org>
Content-Type: text/plain; charset=us-ascii
Martin Burnicki wrote:
>I've run some more tests with smearing of leap seconds,
These new ones, with variable polling interval on the client, are much more useful than the former ones with fixed polling interval. It seems to me that these measurements should concentrate on clients with default settings, because if one is able to configure the client to better follow the smear then one could easily do an even better job by configuring the client to follow an honest server and to introduce the smear itself.
Only the case where the client can't be specially configured is really relevant to the concept of introducing the smear upstream.
I'd like to see a run of this client type with the 24 hour smears that you used earlier, or of a fixed-polling-interval client with the new 10 hour smears, so that variable polling interval can be directly compared against fixed polling interval. I'd interpreted your earlier tests generally based on the poll=10 client, in the expectation that the default variable polling interval would behave similarly, but it's not clear whether the reductions of polling interval that you see would result in a significant difference in performance.
It is strange that the polling interval varies so much more with the linear smear than with the sinusoidal smear. I would have expected them to remain stable at poll=10 for the bulk of the smear, after they've recovered from the initial frequency change. There is a point 2.5 hours into the smear where all the clients have returned to poll=10; can you explain why they reduce it again after that?
Also strange that the three clients had such different reactions to the end of the linear smear, having been so similar in their reactions to the start of it, and similar in all parts of the sinusoidal smear.
It is interesting that when the server suggests a smaller poll interval the shape of the smear makes a big difference to the tracking accuracy.
This is much like the difference that we intuitively expected the shape to make in the first place.
-zefram
------------------------------
Message: 5
Date: Thu, 22 Dec 2016 21:50:51 -0700
From: Warner Losh <imp at bsdimp.com>
To: Leap Second Discussion List <leapsecs at leapsecond.com>
Subject: Re: [LEAPSECS] Leap second smearing test results
Message-ID:
<CANCZdfpvqKvG1t6iPS3Z5E4AD9nGnmGGiLbXfqn=BM0t-A72Cg at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Thu, Dec 22, 2016 at 6:48 PM, Zefram <zefram at fysh.org> wrote:
> Martin Burnicki wrote:
>>I've run some more tests with smearing of leap seconds,
>
> These new ones, with variable polling interval on the client, are much
> more useful than the former ones with fixed polling interval. It
> seems to me that these measurements should concentrate on clients with
> default settings, because if one is able to configure the client to
> better follow the smear then one could easily do an even better job by
> configuring the client to follow an honest server and to introduce the smear itself.
> Only the case where the client can't be specially configured is really
> relevant to the concept of introducing the smear upstream.
>
> I'd like to see a run of this client type with the 24 hour smears that
> you used earlier, or of a fixed-polling-interval client with the new
> 10 hour smears, so that variable polling interval can be directly
> compared against fixed polling interval. I'd interpreted your earlier
> tests generally based on the poll=10 client, in the expectation that
> the default variable polling interval would behave similarly, but it's
> not clear whether the reductions of polling interval that you see
> would result in a significant difference in performance.
>
> It is strange that the polling interval varies so much more with the
> linear smear than with the sinusoidal smear. I would have expected
> them to remain stable at poll=10 for the bulk of the smear, after
> they've recovered from the initial frequency change. There is a point
> 2.5 hours into the smear where all the clients have returned to
> poll=10; can you explain why they reduce it again after that?
>
> Also strange that the three clients had such different reactions to
> the end of the linear smear, having been so similar in their reactions
> to the start of it, and similar in all parts of the sinusoidal smear.
>
> It is interesting that when the server suggests a smaller poll
> interval the shape of the smear makes a big difference to the tracking accuracy.
> This is much like the difference that we intuitively expected the
> shape to make in the first place.
I'd be curious what a longer smear time would do? Longer smears would give a smaller frequency error, which might be easier to digest. It also copes better with long-polling intervals in clients at the expense of a longer phase error in the clients.
I'd have to say that any hope of recovering actual UTC on the clients that are smearing is likely in vain. Too many steering loops involved to get a good, stable, reliable, predictable answer at any given moment, even if you on the average get decent behavior. If you need UTC, you must count in UTC and lie to the clients on your machine directly if you are smearing for their sake.
These are the reasons I hate leap seconds: they are of dubious value and cause all kinds of havoc because nobody expects them to work, and the programming standards are written as if they don't exist.
Warner
------------------------------
Subject: Digest Footer
_______________________________________________
LEAPSECS mailing list
LEAPSECS at leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
------------------------------
End of LEAPSECS Digest, Vol 122, Issue 13
*****************************************
More information about the LEAPSECS
mailing list