Re: [LEAPSECS] 256-week / leap seconds / in the news

cond warning to other applications. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burni...@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hanno

Re: [LEAPSECS] 256-week / leap seconds / in the news

Tom, Tom Van Baak wrote: Steve, I'm thinking the problem is not with GPS or with modulo arithmetic. I fully agree. I'm in contact with Leo and others for the root cause or the scope of the problem as reported on twitter. I'll say more later. Per the GPS ICD, when dt_LS == dt_LSF there

Re: [LEAPSECS] Leap seconds have a larger context than POSIX

Meinberg, I'd like to point out that what I usually write in this and similar mailing lists is also not due to financial interests of any kind. It's just my personal opinion, from my technical and practical point of view. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH

Re: [LEAPSECS] Leap seconds have a larger context than POSIX

interval of 12 hours only, the German DCF77 transmitter sends the announcement only 1 hour in advance, and IRIG time codes (if they support it at all, like IEEE1344 / C37.118) only 10 seconds or so in advance. So I wonder which spec should have been relevant for NTP/ntpd? Martin -- Martin Bur

Re: [LEAPSECS] Leap seconds have a larger context than POSIX

(the protocol) or ntpd (the implementation) are blamed here. There's a lot of stuff in there which tries to sort out errors coming from external time sources, but I doubt there can be an implementation which is in no way affected by any potential error from outside. Martin -- Martin Burnicki Senior Softw

Re: [LEAPSECS] Leap seconds have a larger context than POSIX

ble everywhere. So IMO it's very practical that the expiration date is there, and that you have about 5 months to deploy a new version. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burni...@meinberg.de Phone: +49 5281 9309-414 Li

Re: [LEAPSECS] leap seconds in POSIX

finally managed to achieve a precision that other operating systems are already providing since decades. ;-) Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burni...@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.c

Re: [LEAPSECS] leap seconds in POSIX

Hal Murray wrote: > > Does anybody know of a good writeup of how to fix POSIX to know about leap > seconds and/or why POSIX hasn't done anything about it yet? I've made a number of presentations and whitepapers about leap seconds and problems related to them. However I'm not aware of an easy,

Re: [LEAPSECS] aircraft GPS receivers hit by leap second bug

Tom, Tom Van Baak wrote: >> What I meant is that if you try to derive the date of the last recent >> leap second from WNlsf if the 2 offsets *are* the same, the result is >> ambiguous since you don't know if you are in a +/- 128 weeks interval, >> or if another 256 weeks interval has passed.

Re: [LEAPSECS] aircraft GPS receivers hit by leap second bug

Tom Van Baak wrote: >> However, the current GPS/UTC offset numbers before and after the nearest >> leap seconds are still 18/18, so there is no current leap second >> announcement, and WNlsf may be ambiguous. > > Perhaps call it "immaterial" rather than "ambiguous"? The fact that it's > 18/18

Re: [LEAPSECS] aircraft GPS receivers hit by leap second bug

Paul Hirose wrote: > Thinking I had missed a pending leap second, I checked the IERS site, > but Bulletin C says the offset is still 37 seconds and nothing is > scheduled. ??? The GPS satellites transmit the week number of the nearest leap second (WNlsf) as 8 bit value only, giving a valid range

Re: [LEAPSECS] is leap smear legal in Germany?

's just because it's a reliable way to avoid problems caused by OS kernels which simply step the system time back to insert a leap second. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burni...@meinberg.de Phone: +49 5281 9309-

Re: [LEAPSECS] Running on TAI

Steve Allen wrote: > On Thu 2019-01-17T18:12:25+0100 Martin Burnicki hath writ: >> Hm, maybe that was originally the case. I wonder whether the folks who >> wrote the text just had UTC in mind when they "invented" time_t. > > The best insight into the POSIX c

Re: [LEAPSECS] Running on TAI

Steve Summit wrote: > Martin Burnicki wrote: >> Just a few general thoughts based on an internal note... > > And some very good points they were. > >> ...The same applies to the time_t type, IMO. If you let the system kernel >> run on TAI or whatever then the

Re: [LEAPSECS] Running on TAI

mmerize a couple of things. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burni...@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 1

Re: [LEAPSECS] Windows Server 2019

Nero Imhard wrote: > Martin Burnicki schreef op 2018-07-20 12:52: > >> Nero Imhard wrote: >>> If that translates to "don't smear ntp" I could not agree more. >>> Smearing is catering to those who won't clean up their act, >>> causing trouble for

Re: [LEAPSECS] Windows Server 2019

tions will have the same problems. Leap second smearing by an NTP server is just an optional way to avoid these problems because there's no better way to get around it. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burni...@meinberg.de

Re: [LEAPSECS] Windows Server 2019

only use cases. > > Indeed. However, this had to be made public so that software developers become aware of these features and what the differences are, so they can call clock_gettime() with the clock ID that is best suited for their application. If they are not aware of the differences in

Re: [LEAPSECS] Windows Server 2019

Stephen Colebourne wrote: > On 19 July 2018 at 11:24, Martin Burnicki wrote: >> As far as I know, UTC-SLS is done locally on a client, and since it's >> implemented in a Java runtime it is only "seen" by Java applications. >> >> This means if you get timesta

Re: [LEAPSECS] Windows Server 2019

s of the same server will have the same smeared time, which is of course off UTC during the smear interval, but at least all Java and non-Java applications on a particular machine will see the same system time. I think it depends on the requirements of the applications which way is to be preferred. Martin

Re: [LEAPSECS] Windows Server 2019

wing as a workaround for windows. If Windows starts to provide an API to handle leap seconds then these programs should use the API, if it is available, and skip the workaround. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burni...@meinberg.de Phone:

Re: [LEAPSECS] UT1 via NTP

Hi Gary, > Yo Warner! > > On Mon, 19 Mar 2018 14:12:40 -0600 Warner Losh > wrote: > >>> Looks to me about a kinda sort maybe 1 micro second per day >>> shift. >>> >> >> Should be closer to 1ms/day. And it is: the above is 4.6ms in 6 >> days or 770us/day. > > Yup, I read it

Re: [LEAPSECS] UT1 via NTP

Rob Seaman wrote: > One uses the tools as designed for diverse purposes. NTP in a pool > environment is accurate to a few milliseconds. With our local GNSS > references something better than a millisecond. With an IRIG shared > memory reference maybe an order of magnitude better. Hardware time >

Re: [LEAPSECS] current / future state of UT1 access?

that poll the same server. From the server's point of view it looks like all the requests from the nodes behind the router seem to come from the same (public) IP address, so a particular node on the NAT subnet may receive even less replies. Martin -- Martin Burnicki Senior Software Engineer MEIN

Re: [LEAPSECS] Leap smear at the IETF

Tony Finch wrote: > There's a discussion about standardizing leap smear at the IETF. Carsten > Bormann suggested the acronym “Smeared Leapsecond over twentyfour hours" — > SLOTH. > > https://mailarchive.ietf.org/arch/msg/art/4LSfOGjp_Tb6yQdnhhvK5w3jucU Thanks for the pointer

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Zefram wrote: > To be clear: obviously knowledge of the upcoming leap second must come > from some external source. A system with such advance knowledge is then > able to apply that knowledge at the proper time, maintaining a correct > clock through the leap second, without any further external

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Brooks Harris wrote: > On 2017-01-06 11:52 AM, Martin Burnicki wrote: >> >>> >>> - OS kernels with different features (Windows doesn't even know leap >>> seconds, AFAIK) >>> >>> > > It is often repeated on LEAPSECS that "Windows

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Steffen Nurpmeso wrote: > Martin Burnicki <martin.burni...@burnicki.net> wrote: > |Yes, and there needs to be an interface to timekeeping software in > |general, i.e. provide glibc and friends with updated tz rules, and make > |the leapsecond table available in a form that c

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Brooks Harris wrote: > On 2017-01-05 05:56 AM, Tony Finch wrote: >> Martin Burnicki <martin.burni...@burnicki.net> wrote: >>> Please note that NTP servers not necessarily need to be providers for >>> leap second files. There are some well known sites which p

Re: [LEAPSECS] Time math libraries, UTC to TAI

Steve Summit wrote (offlist): > In some ways I agree that running the kernel on TAI would be far > preferable. I've shied away from it so as to be able to answer > the critics who are always worrying about disconnected systems > that might not have a source of TAI-UTC at boot time, or at all. If

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Tony Finch wrote: > Martin Burnicki <martin.burni...@burnicki.net> wrote: >> >> Please note that NTP servers not necessarily need to be providers for >> leap second files. There are some well known sites which provide this >> file, and the NTP software package

Re: [LEAPSECS] Leap second smearing test results

Hal Murray wrote: > >>> I don't think the client pays any attention to that field in the packet. >> Hm, when Harlan made the proposal then he said the client did. > > You are right. There is some code in there. Thanks. > > It might be interesting to see what the RFC or book says about that

Re: [LEAPSECS] Leap seconds ain't broken

Michael Shields via LEAPSECS wrote: > On Wed, Jan 4, 2017 at 1:46 AM, Martin Burnicki > <martin.burni...@burnicki.net> wrote: >> I agree it would be good to implement this in an extension field, but >> generally care should be taken not to break compatibility. I mean, ho

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Tony Finch wrote: > Martin Burnicki <martin.burni...@burnicki.net> wrote: >> Tony Finch wrote: >>> >>> Even though NTP can represent current UTC correctly, it often gets leap >>> seconds wrong. It does not give confidence that we will be able to >&g

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Steffen Nurpmeso wrote: > Martin Burnicki <martin.burni...@burnicki.net> wrote: > |Steve Summit wrote: > |> Tony Finch wrote: > |>> Even though NTP can represent current UTC correctly, it often gets leap > |>> seconds wrong. It does not give confidence t

Re: [LEAPSECS] Leap second smearing test results

Warner Losh wrote: > 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 expect that the

Re: [LEAPSECS] Leap second smearing test results

Zefram 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 measuremen

Re: [LEAPSECS] Leap second smearing test results

Again, sorry for replying so late. I've been mostly offline over the holidays. Zefram schrieb: > Martin Burnicki wrote: >> https://www.meinberg.de/download/burnicki/ntp_leap_smearing_test_results.pdf > > This is interesting. The smear actually achieved on the downstream ntp >

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Michael.Deckers. via LEAPSECS wrote: >Why doesn't the NTP message include the TAI - UTC offset used for >the UTC timestamp in the message? Even a faultily configured server >knows when it changes this offset, and it could help avoid the >interpretation of incorrect warning bits.

Re: [LEAPSECS] JD & MJD, UT1 & UTC

John Sauter wrote: > On Wed, 2017-01-04 at 15:22 +0100, Martin Burnicki wrote: >> John Sauter wrote: >>> I did some experimenting with this on Fedora 25, Linux kernel >>> 4.8.15- 300.fc25.x86_64. I found that adjtimex sets STA_NANO >>> and returns nanose

Re: [LEAPSECS] alternative to smearing

Michael Rothwell wrote: > The Gregorian calendar doesn't mess up how computers keep track of time, > like leap seconds do. Neither do time zones. Leap seconds are different > -- a special kind of awful. I think this depends on what your basic time is, and what time you derive from it. If the

Re: [LEAPSECS] JD & MJD, UT1 & UTC

John Sauter wrote: > I did some experimenting with this on Fedora 25, Linux kernel > 4.8.15- 300.fc25.x86_64. I found that adjtimex sets STA_NANO and > returns nanoseconds only when NTP has been running for a while. > John Sauter (john_sau...@systemeyescomputerstore.com) Ah, interesting. Did

Re: [LEAPSECS] Time math libraries, UTC to TAI

Steve Summit wrote: > Martin Burnicki wrote: >> IMO another clock type to be used with clock_gettime() would help, as >> already proposed by Markus Kuhn (there was a link to this in a recent >> post here), which could be used by new or actively maintained software. > >

Re: [LEAPSECS] Time math libraries, UTC to TAI

Zefram wrote: > Martin Burnicki wrote: >> Of course it would be great if there was an API call which executes fast >> to yield a high performance, and returns a timestamp plus an associated >> status code consistently, in an atomic operation. > > A read-only

Re: [LEAPSECS] JD & MJD, UT1 & UTC

Zefram wrote: > Steve Summit wrote: >> And this is eerily similar to the idea of using a struct >> timespec with a nonnormalized tv_nsec field. > > For that matter, tm_sec==60 is the same class of trick too. We're just > varying at which digit position we stuff in an out-of-radix value. Yes,

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Tony Finch wrote: > It's pretty embarrassing that one of our main time distribution > systems routinely screws up leap seconds. And it's even more embarrassing that the maintainers of such an important piece of network infrastructure don't get more support from vendors, even big ones which have

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Steve Summit wrote: > Tony Finch wrote: >> Even though NTP can represent current UTC correctly, it often gets leap >> seconds wrong. It does not give confidence that we will be able to >> reduce bugs by teaching more code about leap seconds, when NTP cares >> about time and gets it wrong, and most

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Ask Bjørn Hansen wrote: > [1] As much as I dislike the leap seconds; smearing is only appropriate > if you specifically have chosen it so they’re not supposed to be in the > pool. Agreed. Smearing in the way it is currently done by some Google servers (and ntpd, if configured accordingly) is just

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Tony Finch wrote: > Warner Losh wrote: >> We have a >> specific legacy standard called POSIX that's causing all kinds of >> issues that pop up when you least expect it > > I haven't mentioned the usual litany of NTP servers getting it wrong, > including servers run by national

Re: [LEAPSECS] Time math libraries, UTC to TAI

Sanjeev Gupta wrote: > If I have understood you correctly, this is publicly available, based on > the IERS Bulletin C: > > https://www.ietf.org/timezones/data/leap-seconds.list Not to forget the new tzdist protocol which can be used to update the leap second table dynamically across the network.

Re: [LEAPSECS] Time math libraries, UTC to TAI

Steve Summit wrote: > The answer is that on a system with the mods installed, #1 > happens all the time for the system calls time(), gettimeofday(), > and clock_gettime(CLOCK_REALTIME). It does not happen for > adjtimex, on the assumption that that's what ntpd is using. > #2 happens only when you

Re: [LEAPSECS] Time math libraries, UTC to TAI

Sorry for jumping in so late. Zefram wrote: > Warner Losh wrote: >> Except that it does advance... It plays the second twice, once with >> the pending leap set, and once with it cleared I though. The current implementation of ntpd just calls clock_gettime( CLOCK_REALTIME ) to retrieve receive

Re: [LEAPSECS] Leap second smearing test results

in this thread tomorrow. ;-) Martin -- Martin Burnicki MEINBERG Funkuhren GmbH & Co. KG Email: martin.burni...@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, We

[LEAPSECS] Leap second smearing test results

Folks, I've run some tests with smearing of leap seconds. If you're interested, you can find the results here: https://www.meinberg.de/download/burnicki/ntp_leap_smearing_test_results.pdf Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.b

Re: [LEAPSECS] Time Synchronization in Financial markets

Hal Murray wrote: > > i...@bsdimp.com said: >> Except, last I checked, NTP doesn't use this. And applications don't re-read >> the zone file info when they are updated, so long running applications will >> use the old data. Also, that file doesn't have then pending leap second this >> December in

Re: [LEAPSECS] Time Synchronization in Financial markets

John Sauter wrote: > I took the lack of mention of leap seconds to mean that leap seconds > ere not a problem. The output of the NISTDC units is an astonishingly > accurate 1 pulse per second. That feeds NTP, which handles leap > seconds using a table. As long as the table is kept up to date,

Re: [LEAPSECS] Bloomberg announced its smear

Tom Van Baak wrote: >> Actually, cosine with a much higher frequency might be the way to >> beat the median filter. Yep. > 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

Re: [LEAPSECS] Bloomberg announced its smear

Harlan, Harlan Stenn wrote: > 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. Indeed it could be just a choice, but I think it's a very good one. Leap smearing in general is

Re: [LEAPSECS] Bloomberg announced its smear

Tom, Tom Van Baak wrote: >> 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

Re: [LEAPSECS] Bloomberg announced its smear

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

Re: [LEAPSECS] Leap second to be introduced at midnight UTC December 31 this year

Tom Van Baak wrote: >> The data format only has a "leap second pending flag", which means a >> leap second is to be inserted. > > Hi Martin, > > Ouch. Well that's a problem. LSEM aside, what are you going to do if the > earth continues to gradually speed up as it has the past couple of decades?

Re: [LEAPSECS] [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

Tony Finch wrote: > Martin Burnicki <martin.burni...@burnicki.net> wrote: >> >> IMO a better approach would be to let the system time run on TAI, and do >> the conversion to UTC, and local time in the next step, by runtime >> libraries. > > The kernel needs

Re: [LEAPSECS] [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

Hal Murray wrote: > > s...@ucolick.org said: >> This idea pushes extra complexity into every implementation of low level >> kernel-space software, firmware, and hardware. That's nice as a policy for >> full employment of programmers, but it's hard to justify by any other >> metric. Instead

Re: [LEAPSECS] [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

Tom Van Baak wrote: > Time to mention this again... > > If we adopted the LSEM (Leap Second Every Month) model then none of > this would be a problem. The idea is not to decide *if* there will be > leap second, but to force every month to have a leap second. The IERS > decision is then what the

Re: [LEAPSECS] [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

Warner Losh wrote: > On Wed, Jul 20, 2016 at 9:27 AM, Martin Burnicki > <martin.burni...@burnicki.net> wrote: >> Each bulletin C from IERS says: >> >> "Leap seconds can be introduced in UTC at the end of the months of >> December or June, dependin

Re: [LEAPSECS] [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

Brooks Harris wrote: > On 2016-07-20 01:08 AM, Tom Van Baak wrote: >> I recall this is a known problem in the Z3801A status reporting, and >> possibly other GPS receivers of that era as well. It stems indirectly >> from a change years ago in how far in advance IERS and DoD were able >> to update

Re: [LEAPSECS] GPS is getting the leap second

Steve Allen wrote: > According to > http://cruisersnet.net/civil-global-positioning-system-service-interface-committee-future-leap-second-scheduled/ > yesterday the USAF started telling the GPS constellation about the > upcoming leap second, so receivers are beginning to demonstrate > reactions to

[LEAPSECS] NTP installer 4.2.8p7 for Windows is available

Hi all, just want to let you know that version 4.2.8p7 of NTP installer for Windows is now available: https://www.meinbergglobal.com/english/sw/ntp.htm#ntp_stable NTP v4.2.8p7 has been published 2016-04-26. It provides some security patches and some other enhancements. See:

Re: [LEAPSECS] [updated] Bulletin C 51: No leap second in June 2016, but new leap second file

Martin Burnicki wrote: > The International Earth rotation Service (IERS) has just published > bulletin C 51, announcing that *no* leap second will be introduced at > the end of June 2016: > ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat > > The IERS now also makes a leap sec

Re: [LEAPSECS] embedded data loggers?

Rob Seaman wrote: > Don’t know if this got through using my new email address. > > Have been rummaging around looking at Arduino and/or Raspberry Pi hacks, > but the former seems under-powered to run a full NTP instance and the > latter is not real-time. If you want a cheap solution then maybe

[LEAPSECS] Bulletin C 51: No leap second in June 2016, but new leap second file

and thus the OS kernel with the current TAI/UTC offset, which is helpful for applications working with TAI. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burni...@meinberg.de Phone: +49 (0)5281 9309-14 Fax: +49 (0)5281 9309-30 Lange Wand 9, 3

[LEAPSECS] Admins should check expiration date of leap second file

. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burni...@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ü

Re: [LEAPSECS] leap second festivities?

Poul-Henning Kamp wrote: In message 5593eb55.6090...@meinberg.de, Martin Burnicki writes: The maximum offset with the linear smear was almost three times larger than with the cosine smear. I think there is a different reason why they switched to the linear smear. I fear that test

Re: [LEAPSECS] Did John Oliver just save the leap-second ?

paragraphs on the Google states: Google does not offer an external NTP service that advertises smeared leap seconds. So I had assumed smearing Google servers were only visible from within their cloud services. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH Co

Re: [LEAPSECS] leap second festivities?

://bugs.ntp.org/show_bug.cgi?id=2830 Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH Co. KG Email: martin.burni...@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

Re: [LEAPSECS] leap second festivities?

-216.239.32.15.png We have also monitored time.windows.com, and the result is really bad: http://people.ntp.org/burnicki/leap-second-2015-06-30/time.windows.com-23.99.222.162.png Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH Co. KG Email: martin.burni...@meinberg.de

Re: [LEAPSECS] 2-hour leap smear in Japan

hours only. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH Co. KG Email: martin.burni...@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

Re: [LEAPSECS] W1K GPS rollover for some time servers

to work correctly, and the manufacturer of the GPS puck is to blame, and the TymServe guys don't even know if the GPS puck will show up with some other bug at some time. Of course it's also a shame that the TymServe manufacturer just says the device is out of support. Martin -- Martin Burnicki

Re: [LEAPSECS] My FOSDEM slides

michael.deckers via LEAPSECS wrote: On 2015-03-03 21:05, Martin Burnicki wrote about negative leap seconds: In the 7 year interval where no leap second was required/scheduled I heard several people saying we might have needed a negative leap second. Fortunately

Re: [LEAPSECS] My FOSDEM slides

Joseph Gwinn wrote: On Tue, 03 Mar 2015 21:56:42 +0100, Martin Burnicki wrote: Now in 4.2.8 the leap second code has been reworked and cleaned up, and a very quick look at the source code seems to indicate that this might work again. At least there's code which passes the announcement flag

Re: [LEAPSECS] My FOSDEM slides

to that. Hm, the question is if existing receivers could handle what they figure out, and I wonder if existing WWVB receivers check the sign of DUT1 to determine if an upcoming leap second is +1 or -1. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH Co. KG Email

[LEAPSECS] FW: Rescheduled: Leap seconds webinar - 10 March 2015

Title: Rescheduled: Leap seconds webinar - 10 March 2015 The Sciencewise webinar on ‘Leap seconds’ with Paul Broadbent, which had been originally scheduled for Wednesday 5 November 2014, has now been rescheduled.Martin Burnicki-

Re: [LEAPSECS] My FOSDEM slides

Joseph Gwinn wrote: On Thu, 26 Feb 2015 15:09:01 +0100, Martin Burnicki wrote: Hi folks, I've been asked off list to make the slides of my presentation at FOSDEM 2015 in Brussels available and post the download link on this list. So here it is: https://fosdem.org/2015/schedule/event

Re: [LEAPSECS] My FOSDEM slides

between xntp3.5f, xntp3-5.86.5, ntp-4.0, ntp-4.1.{0,1,2}, and ntp-4.2.0. These older releases are still running out there, too. And don't forget NTPv3 - bet lots of those still run. Once people get a system to work, they don't tend to go fixing things that ain't broke. Yep. Martin -- Martin

[LEAPSECS] My FOSDEM slides

. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH Co. KG Email: martin.burni...@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

Re: [LEAPSECS] The leap second, deep space and how we keep time -Brooks

? So similarly, if there are faulty DNS or DHCP servers around, should these services be abolished instead of fixing the source of the problem? ;-) Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH Co. KG Email: martin.burni...@meinberg.de Phone: +49 (0)5281 9309-14 Fax

Re: [LEAPSECS] Bulletin C and all that

Harlan, Harlan Stenn wrote: Yes, there have been bugs (and shortcomings, or at least trade-offs) with leapsecond propagation in the NTP codebase over the decades. Upgrading software is a good thing. That can be ancient release + patches or current supported software that has patches. Please

Re: [LEAPSECS] Bulletin C and all that

Tom Van Baak wrote: The truncated week numbers are a good source for potential errors I agree, but... If the current week number is off by more than +-127 then this is ambiguous. No, it's not ambiguous, it was just a Motorola bug. The wrap is in the spec and there's no problem with that.

Re: [LEAPSECS] Bulletin C and all that

the new leap second code in ntpd 4.2.8 should be able to handle this correctly, if I have understood Juergen Perlinger correctly who wrote this code. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH Co. KG Email: martin.burni...@meinberg.de Phone: +49 (0)5281 9309

Re: [LEAPSECS] Bulletin C and all that

. If the current week number is off by more than +-127 then this is ambiguous. This has rolled over several time in the period where no leap second had been scheduled for 7 years, and all the time the 8 bit week number of the last recent leap second was broadcast. Martin -- Martin Burnicki

Re: [LEAPSECS] stale leap second information

Brooks Harris wrote: IERS publishes this - Its up to date (includes 2014-07-01) as of today as I access it (2015-01-12). http://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat I'm not sure when it was updated, maybe with their Bullitin C announcement.

Re: [LEAPSECS] stale leap second information

Tom Van Baak wrote: If would really be good if there was one authoritative soure for this, and that there was a uniform format. Ideally there would be multiple ways to access it, via text and binary for different architectures. The might be thought of as a UTC Metadata API, from which various

Re: [LEAPSECS] stale leap second information

Tom Van Baak wrote: Or use this 40-line text file instead: http://hpiers.obspm.fr/iers/bul/bulc/Leap_Second.dat The one is nice because it includes a File expires on 31 December 2015 notice. This in not an optimal solution, yet, since parsing a string like this can be error prone. The

Re: [LEAPSECS] Improvements since 2012

Folks, originally I wrote this email about 9 hours ago, but sent it using a different email address which is not subscribed to the list. So apparingly the first email was blocked, and I'm sending it once more. Ask Bjørn Hansen wrote: Steve Allen s...@ucolick.org wrote: [...] NTP and the

Re: [LEAPSECS] the big artillery

Warner, Warner Losh wrote: On Oct 31, 2014, at 4:17 AM, Martin Burnicki martin.burni...@meinberg.de wrote: Magnus Danielson wrote: On 10/31/2014 02:49 AM, Sanjeev Gupta wrote: Give it a new name, please. Independent of what the fundamental unit is. TAI and UTC already exists

[LEAPSECS] Next leap second approaching ... ;-)

Next leap second approaching ... ;-) http://xkcd.com/162/ Martin -- Martin Burnicki MEINBERG Funkuhren GmbH Co. KG Email: martin.burni...@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