Once upon a time, Mike Hammett na...@ics-il.net 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 leap
-
From: Chris Adams c...@cmadams.net
To: nanog@nanog.org
Sent: Wednesday, July 1, 2015 1:17:06 PM
Subject: Re: REMINDER: LEAP SECOND
Once upon a time, Mike Hammett na...@ics-il.net 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
On Wed, Jul 1, 2015 at 3:17 PM, Chris Adams c...@cmadams.net wrote:
Once upon a time, Mike Hammett na...@ics-il.net 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
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 baldur.nordd...@gmail.com wrote:
On 19 June 2015 at 23:58, Harlan Stenn
On Wed, Jul 1, 2015 at 10:17 AM, Mike Hammett na...@ics-il.net 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
guilherme.ganas...@persistelecom.com.br
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
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 11:15 AM, Michel Luczak fr...@shrd.fr 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?
Apparently 6.27 was the safe version to have (no
Once upon a time, Rubens Kuhl rube...@gmail.com 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
: Wednesday, July 1, 2015 1:20:30 PM
Subject: Re: REMINDER: LEAP SECOND
On Wed, Jul 1, 2015 at 3:17 PM, Chris Adams c...@cmadams.net wrote:
Once upon a time, Mike Hammett na...@ics-il.net said:
v5 is 2.4, v6 3.3.5
Don't know why a 3.3.5 kernel would have deadlocked; don't think
: Re: REMINDER: LEAP SECOND
Once upon a time, Rubens Kuhl rube...@gmail.com 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
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
Exchange
http://www.midwest-ix.com
- Original Message -
From: Harlan Stenn st...@ntp.org
To: Mike Hammett na...@ics-il.net
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 affected the CCR
* Stefan Schlesinger s...@ono.at
On 25 Jun 2015, at 03:14, Damian Menscher via NANOG nanog@nanog.org 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't published the patch
Damian Menscher via NANOG nanog@nanog.org 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.
--
On 25 Jun 2015, at 03:14, Damian Menscher via NANOG nanog@nanog.org 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
On Wed, Jun 24, 2015 at 9:48 PM, Stefan Schlesinger s...@ono.at wrote:
On 25 Jun 2015, at 03:14, Damian Menscher via NANOG nanog@nanog.org
wrote:
http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html
comes dangerously close to your modest proposal.
I wonder
* Harlan Stenn st...@ntp.org
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
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
Philip Homburg pch-na...@u-1.phicoh.com 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
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 st...@ntp.org wrote:
Matthew Huff
In your letter dated Wed, 24 Jun 2015 08:33:14 +0200 you wrote:
Leap years and DST ladjustments have never caused us any major
issues. It seems these code paths are well tested and work fine.
I seem to remember that they were not tested that well on a certain brand of
mobile devices a few years
Once upon a time, Gary E. Miller g...@rellim.com 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
In your letter dated Wed, 24 Jun 2015 14:05:34 +0100 you wrote:
Philip Homburg pch-na...@u-1.phicoh.com 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,
On 06/24/2015 12:44 PM, Matthew Huff wrote:
It looks like the safest thing for us to do is to keep our NTP
servers running and deal with any crashes/issues. That's better than
having to deal with FINRA.
For what it's worth, Red Hat pushed updates to NTP and to TZDATA. You
might want to check
On Mon, Jun 22, 2015 at 7:17 AM, shawn wilson ag4ve...@gmail.com 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
On Wed, Jun 24, 2015 at 08:33:14AM +0200, Tore Anderson wrote:
Leap years and DST ladjustments have never caused us any major
issues. It seems these code paths are well tested and work fine.
I've seen quite a few people that for whatever reason insist
on running systems in local time
Once upon a time, Majdi S. Abbas m...@latt.net said:
Total and utter carnage is a bit of a stretch. Linux hosts
that ran applications dependant on nanosleeps needed reboots. Note
that this wasn't an issue in 2009, because the poorly tested change in
question hadn't yet been made to
* Majdi S. Abbas
On Wed, Jun 24, 2015 at 08:33:14AM +0200, Tore Anderson wrote:
Leap years and DST ladjustments have never caused us any major
issues. It seems these code paths are well tested and work fine.
I've seen quite a few people that for whatever reason insist
on running
: Re: REMINDER: LEAP SECOND
* 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
* 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 second to
Does anyone know what the latest that we can run our NTP servers and not
distribute the LEAP_SECOND flag to the NTP clients?
On Jun 24, 2015, at 2:33 PM, Tore Anderson t...@fud.no wrote:
* Majdi S. Abbas
On Wed, Jun 24, 2015 at 08:33:14AM +0200, Tore Anderson wrote:
Leap years and DST
| 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
not distribute
* 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 open
* Matthew Huff
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.
That was why I proposed to ntpdate on your (upstream-free since the
29th) NTP server(s) sometime on the 30th.
Yo Tore!
On Wed, 24 Jun 2015 21:57:28 +0200
Tore Anderson t...@fud.no wrote:
If you run your own straum-1 servers, can't you just opt not to
configure leapfile?
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
On Jun 22, 2015, at 7:06 PM, Harlan Stenn st...@ntp.org 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:
On Jun 23, 2015, at 1:23 PM, shawn wilson ag4ve...@gmail.com 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
On Jun 23, 2015 6:26 AM, Nick Hilliard n...@foobar.org wrote:
Blocking NTP at the NTP edge will probably work fine for most situations.
Bear in mind that your NTP edge is not necessarily the same as your
network
edge. E.g. you might have internal GPS / radio sources which could
On 23/06/2015 18:23, shawn wilson wrote:
NTP causes jumps - not skews, right?
this is implementation dependent. For normal clock differences on ntpd,
if you start it with the -x parameter, it will always slew and never step.
If you start ntpd without the -x parameter, if the calculated correct
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
Harlan,
Why should your head explode? Possibly you’re overthinking the problem. And
there is no reason (or simple way I can envision) to test my plan, as you
advise, in advance. I will just block NTP in my border router temporarily. No
need to make a mountain out of this molehill. Cisco, and
Harlan,
Help me understand why there is a serious risk of going back in time. I
acknowledge that there is a remote chance of a backstep, but the probability
seems very low.
Suppose I disable my NTP service five minutes before a positive leap second
occurs, so that no server in my network can
This stuff can make my head explode.
When a leap second is added, like on 30 June 2015 at the last second of
the day, POSIX insists that the day still have 86400 seconds in it.
This makes the day longer by one second, so time has to either slow down
or move backwards.
The dumb way to do this is
On 23/06/2015 10:25, Mel Beckman wrote:
Why should your head explode? Possibly you’re overthinking the problem.
The problems don't relate to Harlan overthinking the problem. They relate
to developers underthinking the problem and assuming that all clocks are
monotonic and that certain rules
- Original Message -
From: Harlan Stenn st...@ntp.org
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
Yo Jay!
On Tue, 23 Jun 2015 22:02:50 -0400 (EDT)
Jay Ashworth j...@baylink.com wrote:
- Original Message -
From: Harlan Stenn st...@ntp.org
You misunderstand the problem. :) The problem is not clock skips
backward one second, because most of the time that's not what
shawn wilson writes:
On Jun 23, 2015 6:26 AM, Nick Hilliard n...@foobar.org wrote:
Blocking NTP at the NTP edge will probably work fine for most situations.
Bear in mind that your NTP edge is not necessarily the same as your
network
edge. E.g. you might have internal GPS / radio
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.
Having 61 seconds in a minute or 86401 seconds in a day is a different story.
On Jun 23, 2015, at 8:37 PM, Harlan Stenn st...@ntp.org wrote:
Tony Finch writes:
Harlan Stenn st...@ntp.org wrote:
It's a problem with POSIX, not UTC.
UTC is monotonic.
The problems are that UTC is unpredictable, and it breaks the standard
labelling of points in time that was used for hundreds (arguably
thousands) of years before 1972.
You
On 6/19/15 2:58 PM, Harlan Stenn wrote:
Bad idea.
When restarting ntpd your clocks will likely be off by a second, which
will cause a backward step, which will force the problem you claim to be
avoiding.
There are plenty of ways to solve this problem, and you just get to
choose what you want
Doug Barton writes:
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
On 6/19/15 2:58 PM, Harlan Stenn wrote:
Bad idea.
When restarting ntpd your clocks will likely be off by a second,
which will cause a backward step, which will force the problem you
claim to be avoiding.
There
On Mon, Jun 22, 2015 at 8:44 AM, Stephane Bortzmeyer bortzme...@nic.fr
wrote:
On Mon, Jun 22, 2015 at 12:38:28PM +,
Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net wrote
a message of 17 lines which said:
So we need a new center of the universe and switch to stardate and
thus solve the
I do feel sorry for you unix/linux users having a problem in year 2038
fortunately I get another ~ 8 years... my Amiga
gets its first big problem in 2046 ;-)
http://web.archive.org/web/19981203142814/http://www.amiga.com/092098-y2k.html
alan
PS if i get to see the 2078 issue I'll be old
Harlan Stenn st...@ntp.org wrote:
It's a problem with POSIX, not UTC.
UTC is monotonic.
The problems are that UTC is unpredictable, and it breaks the standard
labelling of points in time that was used for hundreds (arguably
thousands) of years before 1972.
Tony.
--
f.anthony.n.finch
On 22 Jun 2015, at 12:27 , Stephane Bortzmeyer bortzme...@nic.fr wrote:
On Mon, Jun 22, 2015 at 01:15:41PM +0100,
Tony Finch d...@dotat.at wrote
a message of 15 lines which said:
The problems are that UTC is unpredictable,
That's because the earth rotation is unpredictable. Any time
On Mon, Jun 22, 2015 at 01:15:41PM +0100,
Tony Finch d...@dotat.at wrote
a message of 15 lines which said:
The problems are that UTC is unpredictable,
That's because the earth rotation is unpredictable. Any time based on
this buggy planet's movements will be unpredictable. Let's patch it
On Mon, Jun 22, 2015 at 12:38:28PM +,
Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net wrote
a message of 17 lines which said:
So we need a new center of the universe and switch to stardate and
thus solve the 32bit UNIX time problem for real this time?
Or simply use TAI which is the
Stephane Bortzmeyer bortzme...@nic.fr wrote:
That's because the earth rotation is unpredictable. Any time based on
this buggy planet's movements will be unpredictable. Let's patch it
now!
http://mm.icann.org/pipermail/tz/2015-May/022280.html
On (2015-06-22 14:44 +0200), Stephane Bortzmeyer wrote:
Or simply use TAI which is the obvious time reference for Internet
devices. Using UTC in routers is madness. Routers and Internet servers
should use TAI internally and use UTC only when communicating with
humans (the inferior life form
shawn wilson ag4ve...@gmail.com 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.
That's how UTC worked in the 1960s.
ftp://maia.usno.navy.mil/ser7/tai-utc.dat
It causes problems
we can just turn the internet off for an hour until the dust settles.
On Mon, Jun 22, 2015, 08:29 Stephane Bortzmeyer bortzme...@nic.fr wrote:
On Mon, Jun 22, 2015 at 01:15:41PM +0100,
Tony Finch d...@dotat.at wrote
a message of 15 lines which said:
The problems are that UTC is unpredictable,
That's because the earth rotation is unpredictable. Any time
- Original Message -
From: Jimmy Hess mysi...@gmail.com
On Sun, Jun 21, 2015 at 1:06 AM, valdis.kletni...@vt.edu wrote:
On Sat, 20 Jun 2015 19:06:29 -0400, Jay Ashworth said:
[snip]
I'll let the perpetrator, Richard Stallman, explain. It was a
kerfluffle
regarding whether
On Sun, Jun 21, 2015 at 1:06 AM, valdis.kletni...@vt.edu wrote:
On Sat, 20 Jun 2015 19:06:29 -0400, Jay Ashworth said:
[snip]
I'll let the perpetrator, Richard Stallman, explain. It was a kerfluffle
regarding whether /bin/du should use units of 1,000 or 1024.
On Sat, 20 Jun 2015 19:06:29 -0400, Jay Ashworth said:
- Original Message -
From: Valdis Kletnieks valdis.kletni...@vt.edu
I wonder how many of us are old enough to remember what that environment
variable *used* to be called before political correctness became
important.
There
Mel Beckman writes:
Harlan,
This is cisco's recommended workaround, the ultimate conclusion of an exhau=
stive study of all Cisco firmware and after detailed post mortem analysis o=
f two previous Leap seconds:
https://tools.cisco.com/bugsearch/bug/CSCut33302
Fair enough. And I've been
On (2015-06-19 21:53 +), Harlan Stenn wrote:
It's a problem with POSIX, not UTC.
UTC is monotonic.
You're right. Hopefully POSIX will become monotonic next year, by removal of
leaps from UTC.
--
++ytti
- Original Message -
- use the posix-right timezone files
What; not posixly-correct?
Cheers,
-- jr ':-)' a
--
Jay R. Ashworth Baylink j...@baylink.com
Designer The Things I Think RFC 2100
Ashworth
On Sat 2015-06-20T10:48:17 +0300, Saku Ytti hath writ:
You're right. Hopefully POSIX will become monotonic next year, by removal of
leaps from UTC.
Probably not. The ITU-R has outlined four methods for this issue, see
shawn wilson writes:
... I mean letting computers figure out slower earth rotation on the
fly would seem more accurate than leap seconds anyway. And then all of
us who do earthly things and would like simpler libraries could live
in peace.
Really? Have you looked in to those calculations,
On Jun 19, 2015 2:05 PM, Saku Ytti s...@ytti.fi wrote:
On (2015-06-19 13:06 -0400), Jay Ashworth wrote:
Hey,
The IERS will be adding a second to time again on my birthday;
2015-06-30T23:59:60
Hopefully this is last leap second we'll ever see. Non-monotonic time is
an
abomination and
On Sat, Jun 20, 2015, 14:16 Harlan Stenn st...@ntp.org wrote:
shawn wilson writes:
... I mean letting computers figure out slower earth rotation on the
fly would seem more accurate than leap seconds anyway. And then all of
us who do earthly things and would like simpler libraries could
On Sat, 20 Jun 2015 11:32:53 -0400, Jay Ashworth said:
- Original Message -
- use the posix-right timezone files
What; not posixly-correct?
I wonder how many of us are old enough to remember what that environment
variable *used* to be called before political correctness became
- Original Message -
From: Valdis Kletnieks valdis.kletni...@vt.edu
On Sat, 20 Jun 2015 11:32:53 -0400, Jay Ashworth said:
- Original Message -
- use the posix-right timezone files
What; not posixly-correct?
I wonder how many of us are old enough to remember what
On 19 June 2015 at 23:58, Harlan Stenn st...@ntp.org wrote:
Bad idea.
When restarting ntpd your clocks will likely be off by a second, which
will cause a backward step, which will force the problem you claim to be
avoiding.
If you are afraid that your routers will crash due to the
Baldur Norddahl writes:
On 19 June 2015 at 23:58, Harlan Stenn st...@ntp.org wrote:
Bad idea.
When restarting ntpd your clocks will likely be off by a second, which
will cause a backward step, which will force the problem you claim to be
avoiding.
If you are afraid that your
Bad idea.
When restarting ntpd your clocks will likely be off by a second, which
will cause a backward step, which will force the problem you claim to be
avoiding.
There are plenty of ways to solve this problem, and you just get to
choose what you want to risk/pay.
--
Harlan Stenn st...@ntp.org
Saku Ytti writes:
Hopefully this is last leap second we'll ever see. Non-monotonic time
is an abomination and very very few programs measuring passage of time
are correct. Even those which are, usually are not portable, most
languages do not even offer monotonic time in standard libraries.
Harlan,
This is cisco's recommended workaround, the ultimate conclusion of an
exhaustive study of all Cisco firmware and after detailed post mortem analysis
of two previous Leap seconds:
https://tools.cisco.com/bugsearch/bug/CSCut33302
GSS Leap second update
CSCut33302
Description
Symptom:
On (2015-06-19 13:06 -0400), Jay Ashworth wrote:
Hey,
The IERS will be adding a second to time again on my birthday;
2015-06-30T23:59:60
Hopefully this is last leap second we'll ever see. Non-monotonic time is an
abomination and very very few programs measuring passage of time are correct.
So you need to wait one more second before you may pop the bottle? :)
On Fri, June 19, 2015 7:06 pm, Jay Ashworth wrote:
The IERS will be adding a second to time again on my birthday;
2015-06-30T23:59:59
2015-06-30T23:59:60
2015-07-01T00:00:00
Have fun, everyone. :-)
Cheers,
-- jra
Subject: REMINDER: LEAP SECOND Date: Fri, Jun 19, 2015 at 01:06:22PM -0400
Quoting Jay Ashworth (j...@baylink.com):
The IERS will be adding a second to time again on my birthday;
This time around there are a number of Vendor C devices that will fail
in spectacular ways if not upgraded with a
The universal workaround is to simply disable NTP on your devices sometime on
Leap-Second eave. This will let the clocks free-run over the one-second push,
an event of which they will be blissfully ignorant. When you re-enable NTP
after The Leap, normal, non-destructive, NTP convergence will
On Fri, Jun 19, 2015 at 06:29:34PM +, Mel Beckman wrote:
The universal workaround is to simply disable NTP on your devices sometime
on Leap-Second eave. This will let the clocks free-run over the one-second
push, an event of which they will be blissfully ignorant. When you re-enable
NTP
I'm pretty sure University College, London (UCL) had a 360/195 on the
net in the late 1970s. I remember it had open login to I guess it was
TSO? I'd play with it but couldn't really figure out anything
interesting to do lacking all documentation and by and large
motivation other than it was kind
Barney Wolff bar...@databus.com wrote:
On Sun, Jan 25, 2015 at 06:42:51PM -0500, TR Shaw wrote:
That made the transformers smaller/cooler and more efficient. I seem to
remember a 195 as well but maybe it
is just CRS.
Google says the 360/195 did exist. But my baby was the 360/95,
where the
On Sun, Jan 25, 2015 at 06:42:51PM -0500, TR Shaw wrote:
That made the transformers smaller/cooler and more efficient. I seem to
remember a 195 as well but maybe it is just CRS.
Google says the 360/195 did exist. But my baby was the 360/95,
where the first megabyte of memory was flat-film
I think devices would likely be fine, unless they're concerned with reconciling
a leap-second updated ntp source and one that's not. Who wins?
For most NTPs I would guess they're slaves to whatever feed and just 'believe'
whatever they're told. (Sounds like a security hole waiting for high
Hi,
Java had some issues with 100% CPU usage when NTP was running during
the additional second in 2012.
http://blog.wpkg.org/2012/07/01/java-leap-second-bug-30-june-1-july-2012-fix/
Google did something different to get the extra second in:
In article 201501251019290550.005c0...@smtp.24cl.home you write:
I've always wondered why this is such a big issue, and why it's done
as it is.
A lot of people don't think the current approach is so great.
In UNIX, for instance, time is measured as the number of seconds
since the UNIX epoch.
On 01/25/2015 10:15 AM, valdis.kletni...@vt.edu wrote:
It shares another problem - that doing calculations across a boundary is
difficult. If you have a recurring timer that pops at 23:58:30 on June 30,
and you want another one in 2 minutes. do you want a timer that the next pop
is at 00:00:30
On Sun, Jan 25, 2015 at 02:24:52PM -0800, Stephen Satchell wrote:
Today's computers don't use clocks derived from 50- or 60-hertz
power-line frequency. The last computer I remember seeing with such a
clock was the IBM System/360. The System/370 used a motor-generator set
for the power
On 25 Jan 2015 17:29:25 +, John Levine said:
It shares with time zones the problem that you cannot tell what
the UNIX timestamp will be for a particular future time. If
you want to have something happen at, say, July 2 2025 at 12:00 UTC
you can guess what the timstamp for that will be,
the quote from the GNU coreutils manpages on Date Input Formats:
Our units of temporal measurement, from seconds on up to months, are so
complicated, asymmetrical and disjunctive so as to make coherent mental
reckoning in time all but impossible. Indeed, had some tyrannical god contrived
to
On 1/25/2015 at 9:37 AM Jay Ashworth wrote:
|This June 30th, 235959UTC will be followed immediately by 235960UTC.
|
|What will /your/ devices do?
=
I've always wondered why this is such a big issue, and why it's done
as it is.
In UNIX, for instance, time is measured as the number
On Jan 25, 2015, at 6:06 PM, Barney Wolff bar...@databus.com wrote:
On Sun, Jan 25, 2015 at 02:24:52PM -0800, Stephen Satchell wrote:
Today's computers don't use clocks derived from 50- or 60-hertz
power-line frequency. The last computer I remember seeing with such a
clock was the IBM
I spoke on time hacking and ntp 3 years ago at shmoocon.
On Jan 25, 2015 12:28 PM, Ken Chase m...@sizone.org wrote:
I think devices would likely be fine, unless they're concerned with
reconciling
a leap-second updated ntp source and one that's not. Who wins?
For most NTPs I would guess
98 matches
Mail list logo
