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:[email protected]] On Behalf Of [email protected] Sent: Friday, December 23, 2016 1:30 AM To: [email protected] Subject: LEAPSECS Digest, Vol 122, Issue 13 Send LEAPSECS mailing list submissions to [email protected] 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 [email protected] You can reach the person managing the list at [email protected] 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 <[email protected]> To: Leap Second Discussion List <[email protected]> Subject: [LEAPSECS] alternative to smearing Message-ID: <[email protected]> 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 ([email protected]) -- 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 <[email protected]> To: Leap Second Discussion List <[email protected]> Subject: [LEAPSECS] Amazon leaps and smears Message-ID: <[email protected]> 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 <[email protected]> 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 <[email protected]> To: [email protected] Subject: Re: [LEAPSECS] Leap second smearing test results Message-ID: <[email protected]> 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: [email protected] 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 <[email protected]> To: Leap Second Discussion List <[email protected]> Subject: Re: [LEAPSECS] Leap second smearing test results Message-ID: <[email protected]> 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 <[email protected]> To: Leap Second Discussion List <[email protected]> Subject: Re: [LEAPSECS] Leap second smearing test results Message-ID: <CANCZdfpvqKvG1t6iPS3Z5E4AD9nGnmGGiLbXfqn=bm0t-a7...@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 On Thu, Dec 22, 2016 at 6:48 PM, Zefram <[email protected]> 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 [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs ------------------------------ End of LEAPSECS Digest, Vol 122, Issue 13 ***************************************** _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
