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
Apologies if you are on multiple lists and see multiple copies of this
email.
-
The next DNS-OARC Fall Workshop will take place in Montreal on Oct 3rd
and 4th, the weekend before NANOG65. DNS-OARC is requesting proposals
for presentations, with a preference for DNSSEC work. We are
Red Hat recomend update tzdate, this rpm is just for timezones right ? If i
won't update it we will have some problem ?
-Mensagem original-
De: Mark Milhollan [mailto:m...@pixelgate.net]
Enviada em: quarta-feira, 24 de junho de 2015 09:19
Para: Leonardo Oliveira Ortiz
Assunto: Re: RES
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
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
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
In your letter dated Wed, 24 Jun 2015 14:05:34 +0100 you wrote:
>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 form
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 z
Once upon a time, Majdi S. Abbas 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 the Linux
* 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 run
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 wrote:
>
> * Majdi S. Abbas
>
>> On Wed, Jun 24, 2015 at 08:33:14AM +0200, Tore Anderson wrote:
>>> Leap years and DST ladj
* 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
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 according to the
r
* 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
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, but to be 100% safe
* 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. T
Yo Tore!
On Wed, 24 Jun 2015 21:57:28 +0200
Tore Anderson 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
GPS, co
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 showing the l
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 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
20 matches
Mail list logo
