Re: [ntp:questions] Leap second to be introduced in June
Erwan David writes: > Harlan Stenn disait le 01/13/15 que : > > > Martin Burnicki writes: > >> Terje Mathisen wrote: > >>> I hate to admit it, but I'm starting to believe Google's approach, > >>> where they smear the leap second over something like a day, might be > >>> one of the better workarounds. > > > > This won't work for a bunch of folks. Other folks *hate* this approach > > because it means that during this 24-hour period the reported time is > > off by both frequency *and* offset. > > WHat problem withsaying that one minute is between 58 and 62 seconds > long (up to 2 leap seconds can be added or removed), and having timers > able to handle 25:59:60 as a valid date ? Where have you seen that 2 leap seconds can be added or removed? I've only ever seen 1. And if you have support for a timescale that handles 23:59:60 as a valid time on a day with a leapsecond, that's just fine. -- Harlan Stenn http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Harlan Stenn disait le 01/13/15 que : > Martin Burnicki writes: >> Terje Mathisen wrote: >>> I hate to admit it, but I'm starting to believe Google's approach, >>> where they smear the leap second over something like a day, might be >>> one of the better workarounds. > > This won't work for a bunch of folks. Other folks *hate* this approach > because it means that during this 24-hour period the reported time is > off by both frequency *and* offset. WHat problem withsaying that one minute is between 58 and 62 seconds long (up to 2 leap seconds can be added or removed), and having timers able to handle 25:59:60 as a valid date ? -- Les simplifications c'est trop compliqué ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 2015-01-14, Phil W Lee wrote: > brian utterback considered Mon, 12 Jan > 2015 04:29:21 GMT the perfect time to write: > >> >>On 1/11/2015 4:56 PM, Rob wrote: >>> Michael Moroney wrote: If I have a system synchronized with a public NTP source, which is synchronized with an atomic clock that provides leap second info, and I am watching carefully, what will happen when the leap second hits? Will my system suddenly find its clock off by 1 second and slowly drift to the accurate time provided by the NTP server? >>> That depends on what kind of system it is. >>> Carefully designed systems will do the right thing. >>> >> >>Define "the right thing". >> >>To eloaborate, there is no "right thing". There are a whole bunch of >>"things" that are right for some people and not for others. That is the >>very reason that there isn't a right thing, because if there was one >>right thing all the vendors would have fixed their operating systems to >>do it. > > As I understood it, there is a right thing (have a second spanning > 23:59:60 to 00:00:00) but almost no software (or even the time > libraries used in any of the common languages) groks it, so different > systems use different fudges to work around it. That is a translation from seconds to ymdhms. The problem is not there. it is in the UTC seconds. In UTC one second disappears after the leap second, but not before or during. Thus UTC seconds numbering is simply disconinuous (jumps back) . And it is that which is the problem, not the common name Thus one has 1435733999 then a second later 1435734000 then .9 seconds later 1435734000.9 and .1 seconds later 1435734000.0 It is that discontinuity in the utc seconds that causes the trouble. Mill's solution is to simply "stop" the clock during that extra second, so, 1.9 sec after 1435733999 it will be 1435734000.01 and .1 sec later it will be 1435734000.02. Whatever you do you have to loose that second. (Ie he stops time except every time the clock is queried it makes sure that it is later than the time before by a minimal amount. ) HOw you display it in normal language is of course up to you. Now you could have the computer run in TAI and then do the translation in userland software. But of course since most things expect utc seconds, every call to the clock would require you figuring out what the offset from utc to tai is, and subtract that number, making time system calls much slower. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Harlan Stenn writes: > David Taylor writes: > > On 13/01/2015 08:58, Hal Murray wrote: > > [] > > > How often do people working with log files from 2 systems care about > > > fractions of a second? > > I have spoken with enterprise users who have to correlate logging > timestamps between 50-200 (or more) systems in cloud deployments and > have a *horrible* time with that under current schemes. Here's a better example: https://en.wikipedia.org/wiki/Northeast_blackout_of_2003 -- Harlan Stenn http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Martin Burnicki writes: > Terje Mathisen wrote: >> I hate to admit it, but I'm starting to believe Google's approach, >> where they smear the leap second over something like a day, might be >> one of the better workarounds. This won't work for a bunch of folks. Other folks *hate* this approach because it means that during this 24-hour period the reported time is off by both frequency *and* offset. >> It means that any sort of timing done during this time period will be >> off by the smear ratio/frequency offset, i.e. on the order of 1.5e-5 >> or so. GTSAPI timestamps will properly account for this. >> Even for benchmarking runs an error of this magnitude will be down in >> the noise, the remaining problems are for stuff like telescope >> control. For most folks I agree with you. There will be cases where it's not true and I'd expect to see an increasing number of these cases moving forward. >> For distributed logging you have to use the same method for every >> single node, but that is the case today as well. :-( GTSAPI timestamps will, I believe and expect, solve this issue. >> I.e. with one domain smearing and another stepping, the times between >> them will be skewed over the entire smearing period. > > Agreed, and it would be good to know the smear interval, so that > different systems can smear in the same way. That's really an NTPv5 problem, as we've expected everybody to play by the same rules as far as NTP goes, and there are a number of ways this is not true, and I expect the number of cases to increase. NTP needs to know the rules its peers/servers are playing by to avoid instability: - leap smear - TAI or UTC? - expected offset to correct time not yet applied - correction algorithm and specs -- Harlan Stenn http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
David Taylor writes: > On 13/01/2015 08:58, Hal Murray wrote: > [] > > How often do people working with log files from 2 systems care about > > fractions of a second? I have spoken with enterprise users who have to correlate logging timestamps between 50-200 (or more) systems in cloud deployments and have a *horrible* time with that under current schemes. -- Harlan Stenn http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP 4.2.8 for Windows, not branded
Brian Inglis wrote: On 2015-01-12 00:32, Harlan Stenn wrote: Brian Inglis writes: Current OpenSSL version is 1.0.1k since maintenance improved after Heartbleed encouraged LF/CII and others to fund OpenSSL. Which OpenSSL version is currently required? Any way that support of updated OpenSSL versions by ntpd could be improved? You're talking about the windows version, right? Yes, as that appears to have issues using updated releases: On 2015-01-10 11:13, Martin Burnicki wrote: Please note that beside the NTP binaries you also need the openssl DLL in the version against which the binaries have been built, otherwise ntpd fails to start. as I tried to update with previous stable, found this problem, and had to revert. Which previous stable do you mean? ntpd or openSSL? Ntpd does a version check of the openSSL DLL/shared object library when it starts. It compares the version of the library available on the host system at runtime to the version of the library used at compilation time. If I remember correctly then this check accepts only patch levels, i.e. if ntpd has been compiled against openSSL v1.0.1j it will accept all openSSL v1.0.1* versions, e.g. v1.0.1k, but it should refuse to start with openSSL v1.0.0*. Sounds reasonable to me. I've just verified that the ntpd v4.2.8 compiled by me against openSSL 1.0.1j also works if I replace openssl by v1.0.1k. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Harlan Stenn wrote: Marco Marongiu writes: On 12/01/15 06:10, William Unruh wrote: I also admit I do not know how windows impliments leap seconds. I don't have a reference, but I remember that at the time of the latest leap second I read that Windows will half the clock speed at 23:59:59 so that it reaches 00:00:00 at the right time. It pays the price of being wrong for two seconds in order to save the system from a discontinuity. But again, I read it in 2012 somewhere I don't have a reference of, and things may have changed since then. The last I saw the unix kernel implements the leap second over 1 second of time, and the Windows kernel does this over 2 seconds' time. I recall seeing some whitepapers about this but I won't be able to look for a while... A whitepaper and presentation of my observations until 2013 can be found here: http://www.meinbergglobal.com/english/info/#whitepaper See "Technical Aspects of Leap Second Propagation and Evaluation" Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Terje Mathisen wrote: Brian Utterback wrote: On 1/12/2015 6:29 AM, Mike Cook wrote: Not true. That would violate POSIX. There is no "properly implements", or "right thing". Perhaps you're unaware that POSIX isn't the One True Operating System specification. "Properly implements" means it follows the well defined, 40 year old normative specification for handling leap seconds, which requires supporting minutes with 59 or 61 seconds. That's something POSIX doesn't properly implement. Agreed. It is often overlooked that leap seconds were implemented from 1972 and POSIX only saw the light of day in 1988. So POSIX is just plain wrong here IMHO. Of course I am aware that POSIX isn't the one true operating system specification. But it certainly is a specification. And for a very large number of people in the world, POSIX conformity is more important than the UTC specification. I agree that POSIX was wrong, but it is what it is. What is the "right thing to do" if you have two conflicting standards? I hate to admit it, but I'm starting to believe Google's approach, where they smear the leap second over something like a day, might be one of the better workarounds. It means that any sort of timing done during this time period will be off by the smear ratio/frequency offset, i.e. on the order of 1.5e-5 or so. Even for benchmarking runs an error of this magnitude will be down in the noise, the remaining problems are for stuff like telescope control. For distributed logging you have to use the same method for every single node, but that is the case today as well. :-( I.e. with one domain smearing and another stepping, the times between them will be skewed over the entire smearing period. Agreed, and it would be good to know the smear interval, so that different systems can smear in the same way. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Marco Marongiu wrote: On 12/01/15 11:48, Martin Burnicki wrote: Fortunately Dave Hart had some time to have a closer look at this, and fix it for 4.2.6, so unless something has been broken again in the mean time it should be fixed in 4.2.6 and later, and should work correctly. Let me understand: you mean that in 4.2.6 ntpd will slew down the clock by two seconds on systems where you can't notify the kernel? No. This is *only* in the Windows-specific code of ntpd. Summary: 1.) If the OS kernel supports it then ntpd just passes the leap second warning down to the kernel, and the kernel handles it depending on how it has been implemented in the OS type and version. 2.) If the OS kernel doesn't support this then ... 2a.) non-Windows versions 4.2.6 and newer step the OS time back by 1 second at the leap second event time (don't know from top of my head if at the beginning or end of the leap second, would have to check the source code). Ntpd versions prior to 4.2.6 would simply do nothing to handle the leap second. They would just observe a sudden 1 second offset after the leap second, and step the time as usual after some minutes. 2b.) Windows versions after our xmas edition from December 2005 slew the Windows system time over 2 seconds to account for the leap second. Specifically, this is in the official stable NTP code since NTP v4.2.4. If so, does it also mean that it would do the same when you disable the kernel discipline by adding a disable kernel in ntp.conf? If I remember correctly then this code depends on a preprocessor symbol, which means it's compiled with or without support for the kernel API. Not sure what happens if it's compiled for kernel PLL but kernel PLL is disabled at runtime. I'll try to figure this out, though. I'm planning to do some testing soon to verify this. If you shared the results of your testing when you're done, that would be great ;-) Yes, of course. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 13/01/2015 08:58, Hal Murray wrote: [] How often do people working with log files from 2 systems care about fractions of a second? I am comparing log files with a user in another country, where we are looking at errors in satellite data. As there can be many messages per second, using NTP which gets Windows systems down to the 20 ms level or better allows much easier correlation of events. The use of different smearing methods across a leap second would introduce undesirable uncertainties in correlation the events (as used to happen before the second station added NTP). Just one example. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Hal Murray writes: > [Context is google-smear.] > > > For distributed logging you have to use the same method for every single > > node, but that is the case today as well. :-( > > > I.e. with one domain smearing and another stepping, the times between them > > will be skewed over the entire smearing period. > > How often do people working with log files from 2 systems care about > fractions of a second? The General Timestamp API timestamps include a timescale, and this includes a way to put a timestamp into a canonical form. That meeans that one can do arithmetic, compare, and convert timestamps that use arbitrary timescales. This would include timestamps using the Google leap smear, TAI, or UTC (at least). H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
[Context is google-smear.] > For distributed logging you have to use the same method for every single > node, but that is the case today as well. :-( > I.e. with one domain smearing and another stepping, the times between them > will be skewed over the entire smearing period. How often do people working with log files from 2 systems care about fractions of a second? -- These are my opinions. I hate spam. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Brian Utterback wrote: On 1/12/2015 6:29 AM, Mike Cook wrote: Not true. That would violate POSIX. There is no "properly implements", or "right thing". Perhaps you're unaware that POSIX isn't the One True Operating System specification. "Properly implements" means it follows the well defined, 40 year old normative specification for handling leap seconds, which requires supporting minutes with 59 or 61 seconds. That's something POSIX doesn't properly implement. Agreed. It is often overlooked that leap seconds were implemented from 1972 and POSIX only saw the light of day in 1988. So POSIX is just plain wrong here IMHO. Of course I am aware that POSIX isn't the one true operating system specification. But it certainly is a specification. And for a very large number of people in the world, POSIX conformity is more important than the UTC specification. I agree that POSIX was wrong, but it is what it is. What is the "right thing to do" if you have two conflicting standards? I hate to admit it, but I'm starting to believe Google's approach, where they smear the leap second over something like a day, might be one of the better workarounds. It means that any sort of timing done during this time period will be off by the smear ratio/frequency offset, i.e. on the order of 1.5e-5 or so. Even for benchmarking runs an error of this magnitude will be down in the noise, the remaining problems are for stuff like telescope control. For distributed logging you have to use the same method for every single node, but that is the case today as well. :-( I.e. with one domain smearing and another stepping, the times between them will be skewed over the entire smearing period. Terje -- - "almost all programming can be viewed as an exercise in caching" ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
