What's new

Cloudflare Time

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
Couple of times - confirmed that Cloudflare does not implement Time Smearing, so it's good with other pool.ntp.org servers...

Google and AWS do smear time, and their Site Reliability Engineers have valid reasons to do this, both for internal and hosted services, so depending on needs...

Don't mix and match - e.g. time.google.com as one server, and time.cloudflare.com (either as a server or pool here) - as there are times where things can get odd...

Google Time will always present itself as a Stratum 1 reference, so NTPd will gravitate towards that first.

CloudFlare servers tend to be stratum 3, so depending on config, they can be good source along with other pools, or use them by themselves, but I caution that the pool right now, from what I see is only two reference ID's - this is likely load balanced like google - but with only two references, that's a bit of a challenge for time geeks - one would want more than two.

Welcome to the cloud - google shows 4 servers - but it's actually many behind a load balancer....

What I would suggest perhaps - if using Google DNS, use Google Time - if one is using CloudFlare DNS, feel free to use CloudFlare Time.

Both approaches are good - but be careful with the time servers - pick one or the other because of the smearing affect during leap seconds, and if you are dependent on hosted servers, check with your provider.

If one wants to host their own stratum 1 server - e.g. a GPS unit with PPS - better not to use Google or AWS as a time reference without understanding the impact there.

I concur with this setup.
 
howdy again, fellers.
Check post #30 of this thread; it's what I said ~4 pages ago. ffs and smh
 
I don't think so - it should be fine as mentioned above - obviously is one is using Cloudflare DNS, one would leverage their load balancing, but if you setup CloudFlare Time as a pool, should be fine - just miss out of the CDN that Cloudflare does.

Keep in mind that CloudFlare Time offers regular NTP services out of the box - for developers, their NTP security options for client development are interesting...

https://developers.cloudflare.com/time-services/nts/

But that is a different discussion as that requires a client that does NTS - and that gets into a deeper discussion about NTPSEC - and kinda like the DNS client* discussion, there's a lot of differences of opinion, so consensus is not present right now...

* DNS Security - DNSSEC, DNSCrypt, DNS over TLS, DNS over HTTPS - you get the picture I hope - same actually applies in the NTP community, and there are smart people and big egos in play, but hey, under the hood, this is what makes the internet work...

Good ideas, good implementations, rough consensus...

Thank you sfx2000.

I tried searching on how to set up CloudFlare Time as a pool, but nothing helpful comes up. Is it possible to do so at this time?
 
Thank you sfx2000.

I tried searching on how to set up CloudFlare Time as a pool, but nothing helpful comes up. Is it possible to do so at this time?

pool time.cloudflare.com iburst

and that is it
 
Duh! (me). :)
i recommend not using pool option
instead do a server option along with a pool server that is stratum 1 like
pool us.pool.ntp.org iburst
server time.cloudflare.com iburst

that way you can benefit from having a stratum 1 pool and the results don't get diluted by having a stratum 3 listed as a pool. a stratum 3 pool will cause your other pools or servers to get diluted.

*edited to reflect better standards*
 
Last edited:
i recommend not using pool option
instead do a server option along with a pool server that is stratum 1 like
pool time.google.com iburst
server time.cloudflare.com iburst

that way you can benefit from having a stratum 1 pool and the results don't get diluted by having a stratum 3 listed as a pool. a stratum 3 pool will cause your other pools or servers to get diluted.

Just remembered though, those shouldn't be used together (time smearing via google), correct?
 
Just remembered though, those shouldn't be used together (time smearing via google), correct?
google isn't a bad ntp. if you are concerned you can do
pool time.nist.gov iburst <---- this can be any stratum 1 pool you know of besides smearing ones
server time.cloudflare.com iburst
 
Last edited:
you are correct especially if you are matching it up against your own local time piece -- like a gps time source.

I'm not using a local GPS time source yet! But the time smearing I'm considering here is the way Google handles leap seconds. :)
 
accuracy would hopefully fix itself provided google allows other servers to sync.

I know what time smearing is. how they take that second and smear it across time v.s putting it at the end.

The issue (as I understand it so far. :) ) is not if Google allows other servers to sync, it is the unpredictable way(s) it may interfere/interact with other NTP servers that don't use Time Smearing that you may have enabled in your 'pool'. :)
 
The issue (as I understand it so far. :) ) is not if Google allows other servers to sync, it is the unpredictable way(s) it may interfere/interact with other NTP servers that don't use Time Smearing that you may have enabled in your 'pool'. :)
exactly and the fact that they are stratus 1 makes ntpd gravitate on them as well. so that time smearing along with, unpredictability, and ntpd being locked on them mostly, not a good mix.
 
Time Smearing is a practice that Google engages in that shouldn't be mixed with other NTP servers that don't do the same, like Cloudflare, for example.

Just want to be clear that Google's practice of Time Smearing is not a negative thing, rather it's a different approach to handle the leap second bump that can cause issues when managing a very large fleet of servers and tightly coupled applications on a global scale.

Leap Seconds do not occur very often, and there is a schedule published as to when they're done.
 
Just want to be clear that Google's practice of Time Smearing is not a negative thing, rather it's a different approach to handle the leap second bump that can cause issues when managing a very large fleet of servers and tightly coupled applications on a global scale.

Leap Seconds do not occur very often, and there is a schedule published as to when they're done.
From my understanding is, it allows the leap second to be passed without even noticing, by slowing down intervals of time.
 
From my understanding is, it allows the leap second to be passed without even noticing, by slowing down intervals of time.

Yep - and there's a couple of camps about that - some would like to hit the speed bump head on and deal with it...

But that can be disruptive to cloud applications when the jump - e.g. back to the future happens. If one is doing transactional things across the cloud and a fleet of servers - that can be a huge problem when processors at running instructions at a billion times per second across a fleet of individual servers all running thousands of containers at any given time.

Some feel that time smearing is not good as this means that time is elastic and can rubber band - which would mean is it trusted?

NTP does some "smearing" just based on the client's adjustment across a number of servers - this is all due to the design and statistical measurement over time to get a local consensus of what time it is - but that's in very small steps...

But that's a general consensus of time across the servers that the client is working with... hence google's big smear (and Amazon perhaps as well) is to slightly adjust time in microseconds over a 24 hour period...

Consider GPS - they don't do Leap Seconds at all - so one already has two points in time to consider - that's why if one is doing GPS and PPS on a local machine, one has to apply the fudge factor to get GPS time aligned to UTC - however, the PPS is is going to be fairly precise on second to second basis, and this can discipline the local NTP daemon much better than just using the NTP upstream servers.

Here's a closing thought...

Segal's Law - "A man with a watch knows what time it is. A man with two watches is never sure."
 
Is this correct? (see attached picture please).

I was hoping "something" would help get rid of that irritating "Reminder: The System time zone is different from your locale setting." message :(
 

Attachments

  • Screen Shot 2019-06-28 at 7.29.30 AM.png
    Screen Shot 2019-06-28 at 7.29.30 AM.png
    131.6 KB · Views: 288
Is this correct? (see attached picture please).

I was hoping "something" would help get rid of that irritating "Reminder: The System time zone is different from your locale setting." message :(
Set the language to match your country. Greece?
To my believe that is the issue.

Verstuurd vanaf mijn SM-T580 met Tapatalk
 
Status
Not open for further replies.

Similar threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top