On Jul 2, 2012, at 7:19 PM, Rodrick Brown rodrick.br...@gmail.com wrote:
People are acting as if Netflix is part of some critical service they stream
movies for Christ sake. Some acceptable level of loss is fine for 99.99% of
Netflix's user base just like cable, electricity and running
On Mon, Jul 02, 2012 at 09:13:42AM -0700, Michael Thomas wrote:
My centos 6/64 running 3.0 seemed to weather it too. I'm not quite
clear on what I should be looking for to classify it as being broken though.
The problems I saw were related to programs that use futex(2) (Java, MySQL,
Chromium,
+--
| On 2012-07-03 17:27:14, Matthew Palmer wrote:
|
| The problems I saw were related to programs that use futex(2) (Java, MySQL,
| Chromium, in my personal experience) chewing up lots of CPU because the
| futex system
Steven Bellovin s...@cs.columbia.edu writes:
See
http://landslidecoding.blogspot.com/2012/07/linuxs-leap-second-deadlocks.html
Maybe we should stop wrenching the poor system time back and forth. We
no longer add or subtract daylight savings time (or timezones) to the
kernel time, why do we do
DST is a time-zone specific phenomenon.
Leap seconds are changes to the actual core time. UTC moves with leap seconds.
It doesn't move with DST or other timezone weirdnesses.
The system clock needs to be UTC, not UTC ± some offset stuck somewhere that
keeps some form of running tally of the
On (2012-07-03 01:54 -0700), Wolfgang S. Rupprecht wrote:
kernel time, why do we do it with leapseconds? We should really move
the leapseconds correction into the display routines like DST and
Yes. TAI time natively and presentation uses leap lookup tables to convert
to UTC.
Unixtime is not
Jimmy Hess mysi...@gmail.com wrote:
Someone should write a dastardly system clock daemon to cause the
insertion of frequent spurious positive leap seconds, followed by the
spurious insertion of negative leap seconds.
For testing purposes... any application which crashes under such a
Wolfgang S. Rupprecht wolfgang.ruppre...@gmail.com wrote:
I wonder why the system's internal time isn't run that way.
For compatibility with software that does time calculations without using
the crappy libc time API.
Tony.
--
f.anthony.n.finch d...@dotat.at http://dotat.at/
Humber, Thames,
-Original Message-
From: James Downs [mailto:e...@egon.cc]
On Jul 2, 2012, at 7:19 PM, Rodrick Brown wrote:
People are acting as if Netflix is part of some critical service
they
stream movies for Christ sake. Some acceptable level of loss is fine
for 99.99% of Netflix's user
On 7/3/12 01:54 , Wolfgang S. Rupprecht wrote:
Steven Bellovin s...@cs.columbia.edu writes:
See
http://landslidecoding.blogspot.com/2012/07/linuxs-leap-second-deadlocks.html
Maybe we should stop wrenching the poor system time back and forth. We
no longer add or subtract daylight savings
On Tue, 03 Jul 2012 12:31:03 +0300, Saku Ytti said:
Yes. TAI time natively and presentation uses leap lookup tables to convert
to UTC.
On the other hand, how many subtle bugs will we introduce when we break
code that currently assumes the system clock is UTC, not TAI?
pgpY3qNIz37lt.pgp
On (2012-07-03 10:33 -0400), valdis.kletni...@vt.edu wrote:
On the other hand, how many subtle bugs will we introduce when we break
code that currently assumes the system clock is UTC, not TAI?
Progress has non zero cost :)
--
++ytti
On Tue, 03 Jul 2012 07:02:33 -0700, Joel jaeggli said:
Apps are buggy sounds like a really poor excuse for doing so.
When the published API has been the system clock is in UTC for some 3
decades, I hardly think it's acceptable to call apps buggy for assuming that
the system clock is in fact
James Downs wrote:
For Netflix (and all other similar
services) downtime is money and money is downtime. There is a
quantifiable cost for customer acquisition and a quantifiable churn
during each minute of downtime. Mature organizations actually calculate
and track this. The trick is to
On Jul 3, 2012, at 6:11 AM, Dan Golding wrote:
Also, I don't think there is an acceptable level of downtime for water.
Neither do water utilities.
I remember a certain conversation I had with a web-developer. We were talking
about zero downtime releases. He thought it was acceptable if the
On 7/3/12 07:51 , valdis.kletni...@vt.edu wrote:
On Tue, 03 Jul 2012 07:02:33 -0700, Joel jaeggli said:
Apps are buggy sounds like a really poor excuse for doing so.
When the published API has been the system clock is in UTC for some 3
decades, I hardly think it's acceptable to call apps
-- Forwarded message --
From: shawn wilson ag4ve...@gmail.com
Date: Jul 3, 2012 11:33 AM
Subject: Re: F-ckin Leap Seconds, how do they work?
To: Joel jaeggli joe...@bogus.com
I agree with TAI. Epoch is supposed to be an unsigned long int starting
~1970 (there are are 4 epochs
On Jul 3, 2012, at 9:11 AM, Dan Golding dgold...@ragingwire.com wrote:
-Original Message-
From: James Downs [mailto:e...@egon.cc]
On Jul 2, 2012, at 7:19 PM, Rodrick Brown wrote:
People are acting as if Netflix is part of some critical service
they
stream movies for Christ
On Jul 3, 2012, at 10:58 AM, Ryan Malayter malay...@gmail.com wrote:
James Downs wrote:
For Netflix (and all other similar
services) downtime is money and money is downtime. There is a
quantifiable cost for customer acquisition and a quantifiable churn
during each minute of downtime. Mature
On Tue, 3 Jul 2012, Rodrick Brown wrote:
face when implementing BCP today. I doubt Amazon gave much thought to
multiple site outages and clients not being able to dynamically redeploy
their engines because of inaccessibility from ELB.
Considering there's a grand total of -one- tool in the
On Tue, 03 Jul 2012 11:35:00 -0400, shawn wilson said:
and makes it really unreliable - GPS time is *not* earth time and we rely
on that skew for everything. To that point, I hate to think how many
missile tests it took them to figure that one out :)
Actually, GPS time is pretty ugly
Once upon a time, valdis.kletni...@vt.edu valdis.kletni...@vt.edu said:
Actually, GPS time is pretty ugly mathematically, as it has to make
relativistic corrections for time dilation due to speed of the satellites
and for gravity-well dilation (which are in opposite directions).
That's how GPS
On Mon, 2 Jul 2012, Greg D. Moore wrote:
As for pulling the plug to test stuff. I recall a demo at Netapps in the
early 00's. They were talking about their fault tolerance and how great it
was. So I walked up to their demo array and said, So, it shouldn't be a
problem if I pulled this drive
On Mon, 2 Jul 2012, david raistrick wrote:
On Mon, 2 Jul 2012, James Downs wrote:
back-plane / control-plane was unable to cope with the requests. Netflix
uses Amazon's ELB to balance the traffic and no back-plane meant they were
unable to reconfigure it to route around the problem.
On Jul 3, 2012, at 7:39 AM, Saku Ytti wrote:
On (2012-07-03 10:33 -0400), valdis.kletni...@vt.edu wrote:
On the other hand, how many subtle bugs will we introduce when we break
code that currently assumes the system clock is UTC, not TAI?
Progress has non zero cost :)
--
++ytti
On 6/29/12 8:22 PM, Joe Blanchard wrote:
Seems that they are unreachable at the moment. Called and theres a recorded
message stating they are aware of an issue, no details.
I didn't see anyone post this yet, so here's Amazon's summary of events:
http://aws.amazon.com/message/67457/
- Original Message -
From: Steven Bellovin s...@cs.columbia.edu
Subject: Re: FYI Netflix is down
On Jul 2, 2012, at 3:43 PM, Greg D. Moore wrote:
At 03:08 PM 7/2/2012, George Herbert wrote:
If folks have not read it, I would suggest reading Normal Accidents
by Charles Perrow.
On (2012-07-03 10:11 -0700), Owen DeLong wrote:
Trading one known set of bugs for a (probably) larger set of unknown bugs is
not my definition of progress. Cost without progress is harmful and should be
avoided.
Leap bugs are NOT known. Most people have no idea unixtime is not
monotonically
it actually appears that skywire has a suballocation for that block,
http://www.robtex.com/ip/208.88.11.111.html#whois
#
# The following results may also be obtained via:
# http://whois.arin.net http://www.robtex.com/dns/whois.arin.net.html
/rest/nets;q=208.88.11.111
and upon further investigation, it seems like there might be an actual
organization using a host with that IP...
http://www.robtex.com/dns/chatwithus.net.html#shared
On Tue, Jul 3, 2012 at 2:27 PM, Kyle Creyts kyle.cre...@gmail.com wrote:
it actually appears that skywire has a suballocation
On 03/07/2012 18:59, Saku Ytti wrote:
Leap bugs are NOT known. Most people have no idea unixtime is not
monotonically increasing.
I had no idea myself until sunday, I had assumed we really go 59 - 60 -
00, but we go 59 - 59 - 00. So 59.1 can happen before or after 59.2.
To me this is
On (2012-07-03 19:33 +0100), Nick Hilliard wrote:
Google's approach to this is interesting:
http://googleblog.blogspot.ie/2011/09/time-technology-and-leaping-seconds.html
Yes. I'm sure this is good enough for most people, most people don't need
precise time but virtually everyone needs
God damn that's a horrid piece of shit web site. You have to disable security
and permit remote code execution or it does not work.
What a crock!
---
() ascii ribbon campaign against html e-mail
/\ www.asciiribbon.org
-Original Message-
From: Nick Hilliard
- Original Message -
From: Wolfgang S. Rupprecht wolfgang.ruppre...@gmail.com
Maybe we should stop wrenching the poor system time back and forth. We
no longer add or subtract daylight savings time (or timezones) to the
kernel time, why do we do it with leapseconds? We should really
On Jul 3, 2012, at 10:38 AM, Jay Ashworth j...@baylink.com wrote:
- Original Message -
From: Steven Bellovin s...@cs.columbia.edu
Subject: Re: FYI Netflix is down
On Jul 2, 2012, at 3:43 PM, Greg D. Moore wrote:
At 03:08 PM 7/2/2012, George Herbert wrote:
If folks have not
- Original Message -
From: Owen DeLong o...@delong.com
DST is a time-zone specific phenomenon.
Nobody said *anything* about DST; that's a complete red herring to
discussions of leap seconds.
Leap seconds are changes to the actual core time. UTC moves with leap
seconds.
Correct.
- Original Message -
From: valdis kletnieks valdis.kletni...@vt.edu
When the published API has been the system clock is in UTC for some 3
decades, I hardly think it's acceptable to call apps buggy for assuming that
the system clock is in fact using UTC and breaking if you switch it to
Nick Hilliard n...@foobar.org wrote:
Well, yeah, it's not obvious that a minute can have anywhere between 59 and
62 seconds.
No a minute cannot have 62 seconds. That is an old documentation bug which
has been fixed.
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html
Tony.
--
Maybe we should stop wrenching the poor system time back and forth. We
no longer add or subtract daylight savings time (or timezones) to the
kernel time, why do we do it with leapseconds? We should really move
the leapseconds correction into the display routines like DST and
timezones
On Jul 3, 2012, at 10:59 AM, Saku Ytti wrote:
On (2012-07-03 10:11 -0700), Owen DeLong wrote:
Trading one known set of bugs for a (probably) larger set of unknown bugs is
not my definition of progress. Cost without progress is harmful and should
be avoided.
Leap bugs are NOT known.
Jon Lewis wrote:
It seems like if you're going to outsource your mission critical
infrastructure to cloud you should probably pick at least 2
unrelated cloud providers and if at all possible, not outsource the
systems that balance/direct traffic...and if you're really serious
about it, have
And I forgot: They made a mistake and missed their intentions of a
solar day year 1900 when defining the atomic second. Off by 2s in 100
years.
-p
The system clock needs to be UTC, not UTC ± some offset stuck
somewhere that keeps some form of running tally of the current leap
second offset since the epoch.
Nope. UTC *includes* leap seconds already. It's UT1 that does not.
Are you suggesting that NTP timekeeping should be based
On (2012-07-03 12:46 -0700), Owen DeLong wrote:
If you don't know that time is not monotonically increasing, then that only
becomes a software bug when you codify your own ignorance into software you
write.
If only all software could be ordered from you Owen, but in practice this
is not
The system clock needs to be UTC, not UTC =C2=B1 some offset stuck
somewhere that keeps some form of running tally of the current leap
second offset since the epoch.
Nope. UTC *includes* leap seconds already. It's UT1 that does not.
Are you suggesting that NTP timekeeping
UTC doesn't move backwards (it goes 59 - 60 - 00)
or
58 - 00
--P
- Original Message -
From: Keith Medcalf kmedc...@dessus.com
Are you suggesting that NTP timekeeping should be based on UT1?
The system clock should be based on UT1 and should be monotonically
increasing since this matches the common concept of time. Calculations
done with this
(source http://physics.nist.gov/cuu/Units/second.html )
Unit of time (second) Abbreviations: CGPM, CIPM, BIPM
The unit of time, the second, was defined originally as the fraction
1/86 400
of the mean solar day. The exact definition of mean solar day was left to
astronomical theories.
On Tue, Jul 03, 2012 at 09:49:40PM +0200, Peter Lothberg wrote:
I leave the computer kernels out of this for a second..:-)
We have a timescale that runs at constant speed forward it's named
TAI, it is based on the definition on the atomic second.
Notice that in inertial frame dragging
In a message written on Tue, Jul 03, 2012 at 10:47:52PM +0200, Eugen Leitl
wrote:
Notice that in inertial frame dragging context it's provably
impossible to synchronize oscillators. Luckily, Earth has
negligible frame dragging, for the kind of accuracy we
currently need.
I think everyone on
On Tue, 03 Jul 2012 21:49:40, Peter Lothberg said:
Leapseconds can be both positive and negative, but up to now, the
earth has only slowed down, so we have added seconds.
That's what many people believe, but it's not exactly right. Leap seconds
are added for the exact same reason leap days
UTC and time is defined as part of the SI system and ITU etc, so we
just need to implement the time system correct. If you try to invent
your own way, there are surprises we don;t need to re-explore..
On Tue, 03 Jul 2012 21:49:40, Peter Lothberg said:
Leapseconds can be both positive and
- Original Message -
From: Leo Bicknell bickn...@ufp.org
I'd even take off by a second but didn't crash, over crashed.
You would, but lots of people would not, and that's not the contract made
by the API definition.
If you want to run a Google-patched NTP server and talk to it, you're
Owen DeLong o...@delong.com wrote:
Since we have a tradition of measuring diurnal and other repetitive
cycles (days) based on the rotation of the earth, we end up with fudge
factors to make that line up with months from time to time. (leap
seconds).
That is not what leap seconds are.
Leap
Peter Lothberg r...@stupi.se wrote:
We have a NTP server on Earth (say Washington-DC) and Vint has
extended the Internet to planet Mars, can we use NTP?
No. http://fanf.livejournal.com/116480.html
Tony.
--
f.anthony.n.finch d...@dotat.at http://dotat.at/
Rockall: Cyclonic, becoming
Peter Lothberg r...@stupi.se wrote:
As the definition of a atomic second is 9192631770 complete
oscillations of cesium 133 between enery level 3 and 4, everyone can
make a second in their lab, that's TAI.
No, TAI isn't based on the SI second you realise in your lab. It's the SI
second
valdis.kletni...@vt.edu valdis.kletni...@vt.edu wrote:
Leap seconds are added for the exact same reason leap days are - the
earth's rotation isn't a clean multiple of the year.
No leap seconds have nothing to do with years.
Tony.
--
f.anthony.n.finch d...@dotat.at http://dotat.at/
Rockall:
Peter Lothberg r...@stupi.se wrote:
And I forgot: They made a mistake and missed their intentions of a
solar day year 1900 when defining the atomic second. Off by 2s in 100
years.
No that is not correct, or at least it's nowhere near as simple as that.
The atomic second was matched to the
On Jul 3, 2012, at 5:06 PM, Peter Lothberg wrote:
On one of my BSD boxes. /usr/src/share/zoneinfo/leapseconds, I see no
-
No, but they're allowed; see Figure 9 of RFC 5905:
LI Leap Indicator (leap): 2-bit integer warning of an impending leap
second to be inserted or deleted in the
Leap seconds are to align the artificial and very stable atomic timescale
with the irregular and slowing rotation of the earth.
You are assuming facts not in evidence. The rotation is merely irregular
within the capabilities of our scheme of measurement, calculation, and
observation. Once
Keith Medcalf kmedc...@dessus.com wrote:
You are assuming facts not in evidence. The rotation is merely
irregular within the capabilities of our scheme of measurement,
calculation, and observation.
There is LOTS of evidence that the earth's rotation is irregular. VLBI,
laser ranging of the
On Tue, Jul 03, 2012 at 11:33:22PM +0100, Tony Finch wrote:
Keith Medcalf kmedc...@dessus.com wrote:
You are assuming facts not in evidence. The rotation is merely
irregular within the capabilities of our scheme of measurement,
calculation, and observation.
There is LOTS of evidence
Tony Finch fa...@hermes.cam.ac.uk wrote:
Keith Medcalf kmedc...@dessus.com wrote:
You are assuming facts not in evidence. The rotation is merely
irregular within the capabilities of our scheme of measurement,
calculation, and observation.
There is LOTS of evidence that the earth's
On 7/3/2012 2:35 PM, Tony Finch wrote:
Peter Lothberg r...@stupi.se wrote:
As the definition of a atomic second is 9192631770 complete
oscillations of cesium 133 between enery level 3 and 4, everyone can
make a second in their lab, that's TAI.
No, TAI isn't based on the SI second you realise
Keith Medcalf kmedc...@dessus.com wrote:
What you mean is that it is subject to periodicities and forces which
you do not understand, and that within your limited perception, this
ignorance is taken as irregularity. Just because the system
encompasses rules and properties beyond your
Vadim Antonov a...@kotovnik.com wrote:
But in theory, if you can get the technical wrinkles worked out, you can
derive the same frequency standard in your lab with a single instrument.
(One more issue is that non-relativistic time is not only the frequency of
oscillators, but also a
On Jul 3, 2012, at 1:08 PM, Keith Medcalf wrote:
The system clock needs to be UTC, not UTC ± some offset stuck
somewhere that keeps some form of running tally of the current leap
second offset since the epoch.
Nope. UTC *includes* leap seconds already. It's UT1 that does not.
Are
On Jul 3, 2012, at 1:09 PM, Saku Ytti wrote:
On (2012-07-03 12:46 -0700), Owen DeLong wrote:
If you don't know that time is not monotonically increasing, then that only
becomes a software bug when you codify your own ignorance into software you
write.
If only all software could be
Tony Finch dot at dotat.at wrote
No that is not correct, or at least it's nowhere near as simple as that.
The atomic second was matched to the second of ephemeris time, and that
was based on Newcomb's tables of the sun, which in effect used the average
length of the second from the 1800s.
Once upon a time, Owen DeLong o...@delong.com said:
UTC (and the system clock) should not move backwards, but, rather they repeat
second 59. UTC goes 58-59-00 most of the time, but during a leap second, it
should go 58-59-59-00). It's not so much going backwards as dropping a
chime.
That
Also, I don't think there is an acceptable level of downtime for
water.
coming soon to a planet near you
randy
On Jul 3, 2012, at 1:54 PM, valdis.kletni...@vt.edu wrote:
On Tue, 03 Jul 2012 21:49:40, Peter Lothberg said:
Leapseconds can be both positive and negative, but up to now, the
earth has only slowed down, so we have added seconds.
That's what many people believe, but it's not exactly
On Tue, Jul 3, 2012 at 5:24 PM, Tony Finch d...@dotat.at wrote:
Leap seconds are to align the artificial and very stable atomic timescale
with the irregular and slowing rotation of the earth.
What do you want to use for a clock? It is convenient (if provincial) for
me to use the sky as the
On 7/3/2012 4:15 PM, Tony Finch wrote:
Vadim Antonov a...@kotovnik.com wrote:
But in theory, if you can get the technical wrinkles worked out, you can
derive the same frequency standard in your lab with a single instrument.
(One more issue is that non-relativistic time is not only the
On 2012 Jul 3, at 18:13, Vadim Antonov wrote:
PS. I would vote for using TAI instead of UTC as the
non-relativistic time base in computer systems.
A problem with the use of TAI is that the BIPM and CCTF (who make
TAI) expressed strongly that they do not want it used as a system
time in document
On 7/3/2012 6:28 PM, Steve Allen wrote:
On 2012 Jul 3, at 18:13, Vadim Antonov wrote:
PS. I would vote for using TAI instead of UTC as the
non-relativistic time base in computer systems.
A problem with the use of TAI is that the BIPM and CCTF (who make
TAI) expressed strongly that they do not
came for the meme, stayed for the epic rant on time.
thanks for making my holiday start awesome.
-chris
On 7/3/12, Vadim Antonov a...@kotovnik.com wrote:
There's always a possibility of using pseudo-TAI internally by
reconstructing it from UTC. This is not the best solution (because it
requires systems to have long-term memory of past leap seconds, or
How about, instead of requiring systems to
No, it really shouldn't.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Owen DeLong o...@delong.com wrote:
On Jul 3, 2012, at 1:09 PM, Saku Ytti wrote:
On (2012-07-03 12:46 -0700), Owen DeLong wrote:
If you don't know that time is not monotonically increasing, then
On Tue, Jul 3, 2012 at 4:48 PM, Owen DeLong o...@delong.com wrote:
Most people operate on the assumption that there are 86400*365.25 seconds per
year overall and that every day is 86,400 seconds. UTC matches that common
conception of time. UT1 does not because UT1 monotonically
On Tue, Jul 3, 2012 at 11:15 PM, George Herbert
george.herb...@gmail.com wrote:
It's not a butthead thing to do to assert that the Internet's
stability in this matter now outweighs an arbitrary and abstract
argument among timekeepers. We matter more than they do, now. If
they want to keep a
On Tue, Jul 03, 2012 at 11:33:35PM -0400, Tyler Haske wrote:
4 years. These things are supposed to be synced to a NTP source
anyway.
Easiest solution is just remove leap second functionality from
mainline code, and make it something you have to special-compile for.
Please reconcile
On Tue, Jul 3, 2012 at 11:59 PM, Majdi S. Abbas m...@latt.net wrote:
On Tue, Jul 03, 2012 at 11:33:35PM -0400, Tyler Haske wrote:
4 years. These things are supposed to be synced to a NTP source
anyway.
Easiest solution is just remove leap second functionality from
mainline code, and make it
On Tue, Jul 03, 2012 at 04:53:32PM -0700, Owen DeLong wrote:
UTC (and the system clock) should not move backwards, but, rather they repeat
second 59. UTC goes 58-59-00 most of the time, but during a leap second, it
should go 58-59-59-00). It's not so much going backwards as dropping a
chime.
On 7/3/2012 1:53 PM, Owen DeLong wrote:
UTC (and the system clock) should not move backwards, but, rather they repeat
second 59. UTC goes 58-59-00 most of the time, but during a leap second, it
should go 58-59-59-00). It's not so much going backwards as dropping a chime.
If they do that,
On 2012 Jul 3, at 21:29, Paul Graydon wrote:
http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat
Which is simply reiterating an older version of the regulatory
document that specifies how UTC shall be done
http://www.itu.int/rec/R-REC-TF.460/en
On paper it is a scheme that will work for 1000
86 matches
Mail list logo
