That bug note indicates all 3.13.* are vulnerable to this, but our 3.13.3 lab
router seemed ok, no reload. Logged:
Dec 31 23:59:59: %IOSXE-5-PLATFORM: R0/0: kernel: Clock: inserting leap second
23:59:60 UTC
But the release notes seem to indicate that bugs:
CSCut82336 ASR1002-X: Handle
We manage a couple of these too, running an affected version. :( I've
applied the suggested workaround, but not the recommended 24h in advance
of the unexpected leap second. I'll find out tomorrow if that mattered.
On Sat, 31 Dec 2016, Richard Hicks wrote:
We had some ASR100
t; +tock.usshc.com .GPS.1 u 87 256 377 26.930 -0.550
>> 0.121
>> *ntp.your.org.CDMA. 1 u 43 256 217 23.3390.544
>> 0.069
>>
>> Our batch system went belly up, but other than that, no other apparent
>> leap second issues.
>&
1 u 87 256 377 26.930 -0.550 0.121
*ntp.your.org.CDMA. 1 u 43 256 217 23.3390.544 0.069
Our batch system went belly up, but other than that, no other apparent leap
second issues.
Matthew Huff | 1 Manhattanville Rd
Director of Operati
went belly up, but other than that, no other apparent leap
second issues.
Matthew Huff | 1 Manhattanville Rd
Director of Operations | Purchase, NY 10577
OTA Management LLC | Phone: 914-460-4039
aim: matthewbhuff | Fax: 914-694-5669
On Sun, Jul 10, 2016 at 3:27 AM, Saku Ytti wrote:
[snip]
> a) use UTC or unix time, and accept that code is broken
[snip]
The Unix time format might be an unsuitable time representation for
applications which require clock precision or time precision within a
few seconds for the purposes of Ti
- Original Message -
> From: "Chris Adams"
> Once upon a time, Patrick W. Gilmore said:
>> But time _DOES_ flow. The seconds count
>> 58, 59, 60, 00, 01, …
>> If you can’t keep up, that’s not UTC’s fault.
[ ... ]
> Leap second handling code
- Original Message -
> From: "Andrew Gallo"
> Looks like we'll have another second in 2016:
> http://www.space.com/33361-leap-second-2016-atomic-clocks.html
"5... 4... 3... 2... 1... Zero!... Happy New Year!"
But only if you're in London. 7pm
On Sun, 10 Jul 2016, Saku Ytti wrote:
On 10 July 2016 at 00:12, wrote:
It doesn't help that the POSIX standard doesn't represent leap seconds
anyplace, so any elapsed time calculation that crosses a leap second
is guaranteed to be wrong
So how can we solve the problem? Immed
On Sun 2016-07-10T11:27:33 +0300, Saku Ytti hath writ:
> So how can we solve the problem? Immediately and long term?
The ITU-R had the question of leap seconds on their agenda for 14
years and did not come up with an answer. Their 2015 decision was to
drop the question and ask an alphabet soup of
On 10 July 2016 at 00:12, wrote:
> It doesn't help that the POSIX standard doesn't represent leap seconds
> anyplace, so any elapsed time calculation that crosses a leap second
> is guaranteed to be wrong
So how can we solve the problem? Immediately and long term?
a) u
to keep it in sync with POSIX/Unix (normal) time.
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of
> valdis.kletni...@vt.edu
> Sent: Saturday, 9 July, 2016 15:12
> To: Saku Ytti
> Cc: NANOG list
> Subject: Re: Leap Second planned for 20
in some languages.
It doesn't help that the POSIX standard doesn't represent leap seconds
anyplace, so any elapsed time calculation that crosses a leap second
is guaranteed to be wrong
pgpZWOH4ajcuy.pgp
Description: PGP signature
On 9 July 2016 at 22:09, wrote:
> well, we've gone through a few of these now...so if it was all okay before
> its likely to be again... exception: any NEW code that
> you are running since last time - THAT hasnt been tested ;-)
In most cases the bugs are not pathological if the elapsed time is
Hi,
> Leap second handling code is not well-tested and is an ultimate corner
> case. There's been debate about abolishing leap seconds; with all the
well, we've gone through a few of these now...so if it was all okay before
its likely to be again... exception: any NEW code that
On 9 July 2016 at 04:39, Patrick W. Gilmore wrote:
Hey,
> But time _DOES_ flow. The seconds count
> 58, 59, 60, 00, 01, …
> If you can’t keep up, that’s not UTC’s fault.
Check the implementation on your PC. This is why code is broken and
people don't even know it's broken. You have to u
Chris Adams :
> Leap seconds are inserted to keep the atomic clocks synced with an
> arbitrary time base (that is guaranteed to vary forever). There's
> nothing magic about having noon UTC meaning the Sun is directly over 0°
> longitude; if we didn't insert leap seconds, it would have drifted
> sl
Once upon a time, Javier J said:
> Unless you are running something that can't handle leap seconds what do you
> really need to prepare for?
The last several leap seconds have exposed weird and hard to predict
bugs in various bits of software. Those previous bugs have (probably)
all been fixed,
g from 59.0 to 0.0 takes two actual seconds).
Both have their pluses and minuses, and IIRC both have exposed software
bugs in the past. The bugs usually get fixed after the leap second, but
the next one always seems to expose new bugs.
Leap second handling code is not well-tested and is an ultima
On Jul 8, 2016, at 7:47 PM, Saku Ytti wrote:
> On 9 July 2016 at 02:27, Jared Mauch wrote:
>> Time is actually harder than it seems. Many bits of software break in
>> unexpected ways. Expect the unexpected.
>
> Aye. How many have written code like this:
>
> start = time();
> do_something();
>
On 7/8/16 4:47 PM, Saku Ytti wrote:
> On 9 July 2016 at 02:27, Jared Mauch wrote:
>> Time is actually harder than it seems. Many bits of software break in
>> unexpected ways. Expect the unexpected.
>
> Aye. How many have written code like this:
>
> start = time();
> do_something();
> elapsed
s what do you
>> really need to prepare for?
>>
>>
>>
>> On Thu, Jul 7, 2016 at 12:59 PM, Andrew Gallo wrote:
>>
>>> Looks like we'll have another second in 2016:
>>> http://www.space.com/33361-leap-second-2016-atomic-clocks.html
>>
On 9 July 2016 at 02:27, Jared Mauch wrote:
> Time is actually harder than it seems. Many bits of software break in
> unexpected ways. Expect the unexpected.
Aye. How many have written code like this:
start = time();
do_something();
elapsed = time() - start;
Virtually all code dealing with pas
do you
> really need to prepare for?
>
>
>
>> On Thu, Jul 7, 2016 at 12:59 PM, Andrew Gallo wrote:
>>
>> Looks like we'll have another second in 2016:
>> http://www.space.com/33361-leap-second-2016-atomic-clocks.html
>>
>>
>> Time to start preparing
>>
>>
have another second in 2016:
http://www.space.com/33361-leap-second-2016-atomic-clocks.html
Time to start preparing
Andrew Gallo <mailto:akg1...@gmail.com>
7 July 2016 at 17:59
Looks like we'll have another second in 2016:
http://www.space.com/33361-leap-second-2016-atomic-clocks.html
Time to start preparing
>
>
> On Thu, Jul 7, 2016 at 12:59 PM, Andrew Gallo > wrote:
>
> > Looks like we'll have another second in 2016:
> > http://www.space.com/33361-leap-second-2016-atomic-clocks.html
> >
> >
> > Time to start preparing
> >
> >
>
> Time to start preparing
Unless you are running something that can't handle leap seconds what do you
really need to prepare for?
On Thu, Jul 7, 2016 at 12:59 PM, Andrew Gallo wrote:
> Looks like we'll have another second in 2016:
> http://www.space.com/33361-leap
Looks like we'll have another second in 2016:
http://www.space.com/33361-leap-second-2016-atomic-clocks.html
Time to start preparing
t Internet Exchange
http://www.midwest-ix.com
- Original Message -
From: "Harlan Stenn"
To: "Mike Hammett"
Cc: nanog@nanog.org
Sent: Wednesday, July 1, 2015 7:43:43 PM
Subject: Re: REMINDER: LEAP SECOND
Mike Hammett writes:
> It looks to have only aff
Mike Hammett writes:
> It looks to have only affected the CCR line and only those running the
> NTP and not the SNTP package.
Any idea what version of NTP or what their configuration looked like?
H
Jimmy Hess writes:
> On Wed, Jul 1, 2015 at 12:38 AM, Mikael Abrahamsson wrote:
> > quickly. Either we should abolish the leap second or we should make leap
> > second adjustments (back and forth) on a monthly basis to exercise the code
> .
>
> See maybe there sho
No, it was a route leak by a colo provider (Axcelx) downstream.
Regards,
Tim Raphael
> On 1 Jul 2015, at 11:37 am, Justin Paine via NANOG wrote:
>
> Any confirmation if the AWS outage was leap second-related?
>
>
> Justin Paine
> Head of Trust & Safet
And just 12.5% of them required TLC. =)
-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of frnk...@iname.com
Sent: Wednesday, July 01, 2015 7:05 AM
To: 'Stefan'
Cc: nanog@nanog.org
Subject: RE: leap second outage
Yes, happened at 7 pm Central
ednesday, July 1, 2015 1:20:30 PM
Subject: Re: REMINDER: LEAP SECOND
On Wed, Jul 1, 2015 at 3:17 PM, Chris Adams wrote:
> Once upon a time, Mike Hammett said:
> > v5 is 2.4, v6 3.3.5
>
> Don't know why a 3.3.5 kernel would have deadlocked; don't think there
>
pecific patches that caused the problem.
>
> I believe the bug from the 2008 leap second was present in kernels in
> 2.4 up through 2.6.26 (although Red Hat at least patched it in their
> older version long-term support kernels).
>
3.3 was listed as buggy in this regard as well.
Rubens
-
From: "Chris Adams"
To: nanog@nanog.org
Sent: Wednesday, July 1, 2015 1:17:06 PM
Subject: Re: REMINDER: LEAP SECOND
Once upon a time, Mike Hammett said:
> v5 is 2.4, v6 3.3.5
Don't know why a 3.3.5 kernel would have deadlocked; don't think there
are any known
Once upon a time, Mike Hammett said:
> v5 is 2.4, v6 3.3.5
Don't know why a 3.3.5 kernel would have deadlocked; don't think there
are any known issues that would cause that, unless there are Mikrotik
specific patches that caused the problem.
I believe the bug from the 2008 le
supposedly vulnerable devices sailed through without a peep.
-Dan
On Wed, 1 Jul 2015, Jay Ashworth wrote:
Here's LWN's piece on the then-upcoming event from last week, presumably
with comments trailing into today.
http://lwn.net/Articles/648313/
How'd it go for everyone? Did the world end?
--- j...@baylink.com wrote:
From: Jay Ashworth
Here's LWN's piece on the then-upcoming event from last week, presumably
with comments trailing into today.
http://lwn.net/Articles/648313/
How'd it go for everyone? Did the world end?
---
Not one
Here's LWN's piece on the then-upcoming event from last week, presumably
with comments trailing into today.
http://lwn.net/Articles/648313/
How'd it go for everyone? Did the world end?
Cheers,
-- jra
--
Jay R. Ashworth Baylink j...@baylink.com
Designer
: REMINDER: LEAP SECOND
Once upon a time, Rubens Kuhl said:
> Not quite. Reported crashes included 6.27, so it's possible that some other
> mitigating factor helped not to crash (like using SNTP instead of NTP,
> although there seems to be people with crashes using SNTP or no SNTP
Once upon a time, Rubens Kuhl said:
> Not quite. Reported crashes included 6.27, so it's possible that some other
> mitigating factor helped not to crash (like using SNTP instead of NTP,
> although there seems to be people with crashes using SNTP or no SNTP/NTP at
> all).
These are running Linux
On Wed, Jul 1, 2015 at 11:15 AM, Michel Luczak wrote:
> > I had problems with Leap Second with mikrotik in versions 6.29.1, 6.28,
> 6.5 and other versions.
> >
> > Configured NTP Client in all of them.
> >
> > Anyone else had this problem?
>
> Apparentl
> I had problems with Leap Second with mikrotik in versions 6.29.1, 6.28, 6.5
> and other versions.
>
> Configured NTP Client in all of them.
>
> Anyone else had this problem?
Apparently 6.27 was the safe version to have (no issues on our CRS and CCR
routers).
Regards, Michel
On Wed, Jul 1, 2015 at 10:17 AM, Mike Hammett wrote:
> It looks to have only affected the CCR line and only those running the NTP
> and not the SNTP package.
>
>
That's Mikrotik's position, but reports of some users contradict their
version (both in the need for NTP and for only affecting CCR lin
ascim"
To: nanog@nanog.org
Sent: Tuesday, June 30, 2015 8:08:28 PM
Subject: Re: REMINDER: LEAP SECOND
I had problems with Leap Second with mikrotik in versions 6.29.1, 6.28, 6.5 and
other versions.
Configured NTP Client in all of them.
Anyone else had this problem?
> On Jun 19
I had problems with Leap Second with mikrotik in versions 6.29.1, 6.28, 6.5 and
other versions.
Configured NTP Client in all of them.
Anyone else had this problem?
> On Jun 19, 2015, at 19:30, Baldur Norddahl wrote:
>
> On 19 June 2015 at 23:58, Harlan Stenn wrote:
>
Any confirmation if the AWS outage was leap second-related?
Justin Paine
Head of Trust & Safety
CloudFlare Inc.
PGP KeyID: 57B6 0114 DE0B 314D
On Tue, Jun 30, 2015 at 8:32 PM, Dovid Bender wrote:
> I read that and that at midnight local time since that's when you have
On Wed, Jul 1, 2015 at 12:38 AM, Mikael Abrahamsson wrote:
> quickly. Either we should abolish the leap second or we should make leap
> second adjustments (back and forth) on a monthly basis to exercise the code.
See maybe there should some day be building codes for
commercially ma
Yes, happened at 7 pm Central (0:oo UTC).
From: Stefan [mailto:netfort...@gmail.com]
Sent: Tuesday, June 30, 2015 10:30 PM
To: frnk...@iname.com
Cc: nanog@nanog.org
Subject: Re: leap second outage
This was supposed to have happened @midnight UTC, right? Meaning that we are
past that
y. Either we should abolish the leap second or we should
> make leap second adjustments (back and forth) on a monthly basis to
> exercise the code.
You could do this, move back on even-numbered months and forward on odd.
Any real adjustment could be done via inhibiting the monthly change
seemed fine after this
sophus utm did this
2015:07:01-00:59:59 cloudsophosvm kernel: [653957.707421] Clock: inserting leap
second 23:59:60 UTC
all seemed fine after this
Colin
y. Either we should abolish the leap second or we should
> make leap second adjustments (back and forth) on a monthly basis to
> exercise the code.
>
> This is a hard sell though...
and it's perversely interesting. It would even be tolerable when the
difference between
s after 10 minutes of uptime. That way you'll run into
any bugs quickly. Either we should abolish the leap second or we should
make leap second adjustments (back and forth) on a monthly basis to
exercise the code.
This is a hard sell though...
--
Mikael Abrahamssonemail: swm...@swm.pp.se
On 15-07-01 00:47, Harlan Stenn wrote:
> What I'm about to say may not be as stupid as it sounds: The problems
> here aren't problems for cases where it's not a problem. It is a
> problem where it *is* a problem.
In fairness, systems should be used to NTP making adjustments to the
system clock
Joe writes:
> A leap sec causing issues. For about 40 years now, there have been
> these leap seconds to no real issue. All of these are "go-forwards"
No, they're all "go-backwards" events. That's no big deal to things
that don't care about monotonic time, or to folks who aren't in
violation of s
tter
Maybe I am wrong, but...
Just my 2¢s
-Joe
On Tue, Jun 30, 2015 at 10:42 PM, Nicholas Suan wrote:
> Correct, the leap second gets inserted at midnight UTC.
>
> "Leap seconds can be introduced in UTC at the end of the months of December
>
> or June, depending on the
Correct, the leap second gets inserted at midnight UTC.
"Leap seconds can be introduced in UTC at the end of the months of December
or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every
six months, either to announce a time step in UTC or to confirm that there
will
No. Some one leaked some routes:
https://mobile.twitter.com/Axcelx/status/616058414746202113
Regards,
Dovid
-Original Message-
From: Justin Paine
Date: Tue, 30 Jun 2015 20:37:06
To:
Cc: Stefan; NANOG;
;
Subject: Re: leap second outage
Any confirmation if the AWS outage was leap
t; are past that event. Under which scenarios should people be concerned about
> midnight local time? Lots of confusing messages flying all over...
> On Jun 30, 2015 10:13 PM, wrote:
>
> > We experienced our first leap second outage -- our SHE (super head end)
> is
> > usi
ote:
> We experienced our first leap second outage -- our SHE (super head end) is
> using (old) Motorola encoders and we lost those video channels. They
> restarted all those encoders to restore service.
>
> Frank
>
>
Regards,
Dovid
This was supposed to have happened @midnight UTC, right? Meaning that we
are past that event. Under which scenarios should people be concerned about
midnight local time? Lots of confusing messages flying all over...
On Jun 30, 2015 10:13 PM, wrote:
> We experienced our first leap second out
We experienced our first leap second outage -- our SHE (super head end) is
using (old) Motorola encoders and we lost those video channels. They
restarted all those encoders to restore service.
Frank
e required config directive is "leapsecmode slew".
There's a nice blog post explaining how this feature, as well as some
other approaches on how to deal with the leap second, work here:
http://developerblog.redhat.com/2015/06/01/five-different-ways-handle-leap-seconds-ntp/
Tore
On Wed, Jun 24, 2015 at 9:48 PM, Stefan Schlesinger wrote:
> > On 25 Jun 2015, at 03:14, Damian Menscher via NANOG
> wrote:
> >
> >
> http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html
> > comes dangerously close to your modest proposal.
>
> I wonder why Google hasn'
> On 25 Jun 2015, at 03:14, Damian Menscher via NANOG wrote:
>
> http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html
> comes dangerously close to your modest proposal.
>
> Damian
I wonder why Google hasn't published the patch yet. Leap smear sounds like the
sane way
Damian Menscher via NANOG wrote:
>
> http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html
> comes dangerously close to your modest proposal.
Also
http://developerblog.redhat.com/2015/06/01/five-different-ways-handle-leap-seconds-ntp/
Tony.
--
f.anthony.n.finchhttp
On Mon, Jun 22, 2015 at 7:17 AM, shawn wilson wrote:
>
> > So, what we should do is make clocks move. 9 slower half of the year
> (and then speed back up) so that we're really in line with earth's
> rotational time. I mean we've got the computers to do it (I think most RTC
> only go down to t
t to check the documentation to see if the updates include sane
handling of the leap second.
(I run CentOS 7.1 and Fedora 20, which is where I saw the updates during
my morning maintenance.)
Once upon a time, Gary E. Miller said:
> Depends on what your Stratum-1 is syncronized to. Some GPS time
> sources pass on the leap indicator to NTP. For example, the SiRF-3
> GPS, connected by way of gpsd, to ntpd will pass on the leap second.
Yep, my ancient old SVeeSix has been sh
ample, the SiRF-3
GPS, connected by way of gpsd, to ntpd will pass on the leap second.
At least in theory. :-)
RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com
(s) sometime on the 30th. That would synchronise its
local clock with an external accurate source, without learning the Leap
Indicator.
> Our plan is to disable our two stratum 1 servers, and our 3 stratum 2
> servers before the leap second turnover, but to be 100% safe we would
> need to
That won't work. Being internally sync'ed isn't good enough for FINRA. All the
machines must be synced to an external accurate source at least once per
trading day.
Our plan is to disable our two stratum 1 servers, and our 3 stratum 2 servers
before the leap second turnover
* Matthew Huff
> I saw that, but it says the bits are set "before 23:59" on the day of
> insertion, but I was hoping that I could shut it down later than
> 23:59:59 of the previous day (8pm EST). The reason is FINRA
> regulations. We have to have the time synced once per trading day
> before the o
m: matthewbhuff | Fax: 914-694-5669
-Original Message-
From: Tore Anderson [mailto:t...@fud.no]
Sent: Wednesday, June 24, 2015 3:07 PM
To: Matthew Huff
Cc: nanog2
Subject: Re: REMINDER: LEAP SECOND
* Matthew Huff
> Does anyone know what the latest that we can run our NTP servers and
&g
* Matthew Huff
> Does anyone know what the latest that we can run our NTP servers and
> not distribute the LEAP_SECOND flag to the NTP clients?
From http://support.ntp.org/bin/view/Support/NTPRelatedDefinitions:
Leap Indicator
This is a two-bit code warning of an impending leap sec
the DST reverse
>> step. It's not nearly as much of a non-issue as you claim.
>
> Read again, and note the word "us". I am describing my and my
> employer's experience with past DST changes and leap years, and those
> have indeed been completely uneventfu
rs, and those
have indeed been completely uneventful.
YMMV.
> > The leap second in 2012 however ... total and utter carnage.
> > Application servers, databases, etc. falling over like dominoes. All
> > hands on deck in the middle of the night to clean up. It took days
> > bef
x27;t yet been made to the Linux kernel.
In 2009, there was a different problem. If the system was under
sufficient kernel-related load (such as disk I/O), the kernel's attempt
to print an informational message that a leap second had been added
caused a kernel deadlock, immediately kill
local time zones struggle with the DST reverse
step. It's not nearly as much of a non-issue as you claim.
> The leap second in 2012 however ... total and utter carnage.
> Application servers, databases, etc. falling over like dominoes. All
> hands on deck in the middle of the night
nd UTC then converting TAI to NTP timestamps is easy except during an
actual leap second. Which is not really a problem.
Unix systems would probably need a few new system calls to accept time in TAI.
File formats like tar are unlikely to matter much: find a consistent way of
encoding time around the l
Philip Homburg wrote:
>
> For UTC the analog approach would be to keep time in TAI internally and
> convert to UTC when required.
This is much less of a solution than you might hope, because most APIs,
protocols, and data formats require UT. (Usually not UTC but a
representation isomorphic to tra
orward for people who for some reason feel attached to representing
the rotation of the earth in civil time is to have a scheme for leap second
just like leap years. For example, insert a leap second every 18 months.
And then revise that scheme once a century to cope unexpect changes in the
earth'
Yes, the clock has to be bad. Been there, done that, especially early Sun x86
servers.
Leap years and DST are both things people and developers are aware of outside
of technology, leap seconds, not so much.
> On Jun 23, 2015, at 11:33 PM, Harlan Stenn wrote:
>
> Matthew Huff writes:
>> A back
o: Re: RES: REMINDER: LEAP SECOND
On Tue, 23 Jun 2015, Leonardo Oliveira Ortiz wrote:
>Guys, if we don't have NTP enable on our Linux we still have problem with leap
>second ??
Without NTP there is no leap second -- you won't even notice it.
/mark
On 24/06/2015 04:33, Harlan Stenn wrote:
> A clock crystal has to be REALLY bad for ntpd to need to step the clock.
or really virtual.
Nick
. It seems these code paths are well tested and work fine.
The leap second in 2012 however ... total and utter carnage.
Application servers, databases, etc. falling over like dominoes. All
hands on deck in the middle of the night to clean up. It took days
before we stopped finding broken stuff.
Matthew Huff writes:
> A backward step is a known issue and something that people are more
> comfortable dealing with as it can happen on any machine with a noisy
> clock crystal.
A clock crystal has to be REALLY bad for ntpd to need to step the clock.
> Having 61 seconds in a minute or 86401 sec
tructure tm, which shall
include at least the following members:
int tm_sec Seconds [0,60]. "
From the Application Usage:
"The range [0,60] for tm_sec allows for the occasional leap second."
From the Rationale:
"The range [0,60] seconds allows for positiv
- Original Message -
> From: "Harlan Stenn"
> > You misunderstand the problem. :) The problem is not "clock skips
> > backward one second," because most of the time that's not what
> > happens. The problem is that most software does not handle it well
> > when the clock ticks ... :59 :60
;> network
>>> edge. E.g. you might have internal GPS / radio sources which could
>>> unexpectedly inject the leap second. The larger the network, the more
>>> likely this is to happen. Most organisations have network fossils and ntp
>>> is an excellent
; edge. E.g. you might have internal GPS / radio sources which could
> > unexpectedly inject the leap second. The larger the network, the more
> > likely this is to happen. Most organisations have network fossils and ntp
> > is an excellent source of these. I.e. systems which work
ted correct time
after slewing is out by > 128ms relative to other ntp servers, then after
900 seconds, it will step to the correct time.
However in the case of leap seconds, if the operating system implements ntp
kernel discipline, then the ntp server will immediately step by the leap
second (forwa
> On Jun 23, 2015, at 1:23 PM, shawn wilson wrote:
>
> NTP causes jumps - not skews, right?
ntpdate jumps, ntpd will try to make small adjustments within a range unless -x
is specified. Many operating systems have -x as a default.
- Jared
hich could
> unexpectedly inject the leap second. The larger the network, the more
> likely this is to happen. Most organisations have network fossils and ntp
> is an excellent source of these. I.e. systems which work away for years
> without any problems before one day accidentally trigger
Guys, if we don't have NTP enable on our Linux we still have problem with leap
second ??
-Mensagem original-
De: NANOG [mailto:nanog-boun...@nanog.org] Em nome de Jared Mauch
Enviada em: terça-feira, 23 de junho de 2015 10:08
Para: Harlan Stenn
Cc: nanog@nanog.org
Assunt
015, at 9:14 AM, Leonardo Oliveira Ortiz
> wrote:
>
> Guys, if we don't have NTP enable on our Linux we still have problem with
> leap second ??
>
>
>
>
> -Mensagem original-
> De: NANOG [mailto:nanog-boun...@nanog.org] Em nome de Jared Mauch
> Env
> On Jun 22, 2015, at 7:06 PM, Harlan Stenn wrote:
>
> Time going backwards is deadly to a number of applications.
>
> But apparently not to applications you care about.
Oh it is a problem, and most handle it very ungracefully, such as dovecot which
just dies:
http://wiki.dovecot.org/TimeMov
l GPS / radio sources which could
unexpectedly inject the leap second. The larger the network, the more
likely this is to happen. Most organisations have network fossils and ntp
is an excellent source of these. I.e. systems which work away for years
without any problems before one day accidental
many other NTP client
gear vendors, recommend this approach, and they’ve published extensive research
on the matter.
-mel
> On Jun 23, 2015, at 12:46 AM, Harlan Stenn wrote:
>
> This stuff can make my head explode.
>
> When a leap second is added, like on 30 June 2015 at the
1 - 100 of 217 matches
Mail list logo
