* 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
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:
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
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%
* 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
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
* 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
21 matches
Mail list logo
