Cloudflare Time Services(cloudflare.com) |
Cloudflare Time Services(cloudflare.com) |
Sponsoring servers in pool.ntp.org wouldn't support Cloudflare's goal(s).
That's a lot of power, and a lot of responsibility. If there was an internal breach at CloudFlare, a sizeable chunk of the modern web would be in danger.
Though I find it almost equally commendable how much effort they put into applying their infrastructure know-how into making IPFS, Ethereum etc. accessible lately, and with that help pave a way for a more decentralized internet again.
The internet is supposed to be distributed. If the NTP pool admins go nuts, have a fight etc, I'm glad there is an alternative. You can generally specify multiple sources, this would be a new source.
And it's always the BS "they're evil" argument - when the posters contribute nothing themselves to progress.
Frustrating indeed.
What's the value over just building your own stratum 1 source? (Shameless plug: https://github.com/jrockway/beaglebone-gps-clock/blob/master...)
The advantage of this is that it runs on Cloudflare's network, where your cloud provider surely has a fast connection to the nearest edge.
The advantage for this is if you are running servers in production, this is easier to set up.
Edit: dropped their address in my NTP config, and the Cloudflare server I got is a stratum 3. Don't see many of those about now, generally pool.ntp.org returns a mix of stratum 1 and 2 servers at least for the UK. Guess it's not too surprising if they're getting time from a handful of third-party stratum 1 servers and then distributing it to their edge nodes though.
Most telecoms applications use an ePRTC source which tends to be implemented as a GPS/GLONASS/Galileo redundant frequency source, plus a local rubidium source or cesium reference. High-end telecoms applications use a hydrogen maser.
You can't stuff that over an unmanaged network and get the performance you need. Hardware needs to support it hop-to-hop.
That was my point. Also if you're inside one of Cloudflare's many POPs, this could, in theory, be provided.
1. Server: Connect over TCP. For every byte sent, responds back with that system's time in microsceonds.
2. Client: Select a few peers, one at a time: connect over TCP, send a byte and note the round-trip time, halve it to get an approximation of the timepoint that the value was sent to you at, compute delta from current system clock; repeat 20 times, discard first 5 values; exclude outliers (+/- 1 standard deviation) and average to compute the offset, then repeat for the next host, etc until you get some change to make
It worked out and kept the required precision among the collection of nodes required for Ceph to work well.
I can’t imagine any application where the more accurate isn’t preferred. And 10 secs seems like quite a bit imho
You cut off the important bit. Roughtime servers sign their responses, so you can be sure you aren't getting a malicious time response (or if you do, you can penalize that server).
Per google [0]: "With only two servers, the client can end up with proof that something is wrong, but no idea what the correct time is. But with half a dozen or more independent servers, the client will end up with chain of proof of any server's misbehaviour, signed by several others, and (presumably) enough accurate replies to establish what the correct time is."
I think it'd be nice to have some middleware hooking into the build process that curls every link at a depth of 1 to ensure that HTTP 400/500 error codes aren't returned.
Has this designer never seen an actual clock?
It has 12 evenly distributed lines, which are commonly used to represent the numbers on an analog clock.
It has an hour hand, a minute hand, and a second hand.
The only thing I can see that seems even a little off is that the hour hand seems slightly past the 1 mark, whereas the minute hand being on ~54 suggests it might want to be slightly before.
It seems very clock-like to me..
What gives you such a visceral reaction to it?
Given that it's so easy to mix up (I had to stare at it to be sure), I'm guessing the parent commenter got frustrated with it. ️
That said, I don't imagine they could screw up NTP too badly, except, of course, logging and tracking users.
I hope they don't smear leap seconds like Google, or do any of a number of other dumb things simply because they're big enough to get away with it:
https://www.theregister.co.uk/2016/12/02/google_public_ntp_s...
Not to mention their bait-and-switch billing practice should be the only thing anyone is talking about when it comes to CloudFlare.
What Cloudflare offers the community is cool, but the world at large should be prepared for them to evaporate at any time (or, more likely, to be acquired by someone not as benevolent).
Another example would be governmental capture of some chunk of the current NTP admins or something.
An organization, by its nature, is vulnerable to some potential single point of failure. Low probability, sure, but having a competing organization ready to step in can actually help keep that probability low by keeping the focus on.
PTP does support unicast messaging, but it is not meant to be used as a public service. There are two major problems: It's not stateless and it has a huge traffic amplification, which could be easily exploited for DoS attacks.
In PTP the problem is in the synchronization protocol itself. A master in the unicast mode is basically a programmable packet generator. It sends sync/announce messages at a rate and duration specified by its slaves, and the address can be spoofed.
