Well, not quite. a) suddenly the clients see themselves as going too fast. It
will take a while to realise that, and then a while to get their clocks up to
speed, and then a few minutes later they see themselves as going to slow so
the whole palaver goes again. During that time they are out
lars-daniel.we...@gmx.de said:
> So for logging on a webserver (with database and stuff), you'd recommend to
> use Holger's settings?
You are missing the big picture.
The idea is that if you are a company like Google with zillions of database
servers that you want to run on smeared time, you
Miroslav wrote:
> On Wed, Apr 08, 2020 at 02:16:23PM +0200, Lars-Daniel Weber wrote:
>
> > On the manfile to chrony.conf there's also this as a recommendation:
> > > leapsecmode slew
> > > maxslewrate 1000
> > > smoothtime 400 0.001 leaponly
>
> That's what Facebook did on their servers. On a
On Wed, Apr 08, 2020 at 02:16:23PM +0200, Lars-Daniel Weber wrote:
>
> Holger wrote:
> > It's really just a cleaned up default (template) config..
>
> On the manfile to chrony.conf there's also this as a recommendation:
> > leapsecmode slew
> > maxslewrate 1000
> > smoothtime 400 0.001 leaponly
Holger wrote:
> It's really just a cleaned up default (template) config..
On the manfile to chrony.conf there's also this as a recommendation:
> leapsecmode slew
> maxslewrate 1000
> smoothtime 400 0.001 leaponly
https://chrony.tuxfamily.org/doc/3.4/chrony.conf.html
I'll give it a try.
--
On 4/8/20 11:00 AM, Lars-Daniel Weber wrote:
Hey Holger,
Holger wrote:
an important point for you since you're presumably in Germany and
Jawoll, under protection of CoronaSchVO NW.
I already went through the futile attempts to use these servers:
they're all outside Germany, with rather
Hey Holger,
Holger wrote:
> an important point for you since you're presumably in Germany and
Jawoll, under protection of CoronaSchVO NW.
> I already went through the futile attempts to use these servers:
> they're all outside Germany, with rather high latency and quite
> terrible connectivity,
William G. Unruh wrote:
> Yes. That was why Miroslav said it should be the user machine's responsibility
> to smear, not the server's. The server should deliver UTC, and UTC has leap
> seconds
> (ie 23:59:58 goes to 00:00:00 or 23:59:59 goes to 25:59:60 and then to
> 00:00:00.)
> AFAIK there is
William G. Unruh __| Canadian Institute for| Tel: +1(604)822-3273
Physics _|___ Advanced Research _| Fax: +1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology | un...@physics.ubc.ca
Canada V6T 1Z1 | and Gravity __|_ www.theory.physics.ubc.ca/
On Wed, 8 Apr 2020,
Miroslav wrote:
> A leap-smearing server suppresses the leap second bits in its
> responses, but it could happen if the client knew from other time
> sources or tzdata (enabled by leapsectz) that there was a leap second.
So before using a new NTP service, it's needed to do some research.
Or does
Would not using a smeared source for chrony which has implimented smearing
just result in "double smearing" as chrony expects a step discontinuity and
never gets it?
So before 00:00:00 chrony would speed up the clock
iand then discovered that no step arrived at 00:00:00 and find itself 1 sec
On Tue, Apr 07, 2020 at 02:28:14PM +0200, Lars-Daniel Weber wrote:
> Hi there,
>
> some of you might have read this article on Facebook (FB) using chrony:
> https://engineering.fb.com/production-engineering/ntp-service/
>
> FB is providing 5 endpoints for public use:
> time1.facebook.com
>
12 matches
Mail list logo
