Cloudflare Time
- Thread starter Stevens243
- Start date
-
- Tags
- ntp ntp server nts
- Status
Swistheater
Very Senior Member
I guess you are right, it is not like your router could suffer from an ntp amplification attack.
dosborne
Very Senior Member
If it was just released, how could anyone possibly know if it is reliable. By definition, something new is not reliable.
netmik3
Senior Member
If it was just released, how could anyone possibly know if it is reliable. By definition, something new is not reliable.
Cloudflare is reliable by definition
Swistheater
Very Senior Member
Cloudflare's really trying to mimick google.
heysoundude
Part of the Furniture
a little bit of healthy competition is good, especially in the case of the behemoth the Alphabet companies are.
heysoundude
Part of the Furniture
When two computers are talking to each other, to ensure smooth and accurate flow of data between them, their two clocks must agree as to how long the base period of time is (seconds, ms, us, ns) and align to achieve synchronization or as close to it as technically possible.
The less of a ping you have to a time server, the less work the router will have to do to ensure the data moves correctly: offsets eat processing cycles, and that bottlenecks your network connection speed. Same goes on your home network - you'll achieve closer to maximum theoretical speeds (both wired and wirelessly) consistently if you ensure your devices follow the clock pulse transmitted by your router.
This will all get quite interesting once quantum processing is more accessible to consumers...
A 3-5 ms difference in reaching a time server once every 24-36 hours is not gonna have any effect whatsoever on your network performance...
NTP is not something that gets updated constantly. The NTP protocol is designed to evaluate the clock drift, and determine the update frequency based on that drift. It typically stabilizes to one update every 24-36 hours, depending on your ntpd configuration.
NTP is also designed to take into account any latency, making it pointless to pick up "the fastest NTP server".
The way I see it, Cloudflare's post is about a solution to a problem that doesn't even exist in real life.
If latency worries you, then don't throw TLS Into the mix, because that adds latency. And I'm also unsure how TLS will help you set up a clock that is not yet configured, as TLS requires an already accurate clock...
heysoundude
Part of the Furniture
While I don’t wish to cross swords with you, sir, I disagree. A few ms here and there add up, causing leap seconds, minutes...Feb 29th every 4 years. It’s what happens when you average infrequently.
If you’re going to use their DNS, you should reference their clock. Problems will occur otherwise. As the volume of data moved increases, this time reference becomes increasingly important.
Sent from my iPhone using Tapatalk
If you’re going to use their DNS, you should reference their clock. Problems will occur otherwise. As the volume of data moved increases, this time reference becomes increasingly important.
Sent from my iPhone using Tapatalk
As I said, the NTP protocol adjusts based on the connection latency. The end result is you will have the exact same accurate clock regardless of the latency in contacting that time server.
ColinTaylor
Part of the Furniture
Every aspect of this post is pure fantasy.
Grisu
Part of the Furniture
I am very willing to believe you, only thing I dont understand whats the matter with VPN or other security apps and wrong time set to router.
How accurate has it to be to have it running?
Would it be enough lets say 5 min or even a day difference to get it up?
Is there an exact or defined time frame within it would work?
Swistheater
Very Senior Member
No what is fantasy is that the average home user needs to "buyin" to every new aspect of internet in order to enjoy the aspects of the services available to everyone.
Swistheater
Very Senior Member
You should at least have roughly accurate time to prevent discrepancies between protocols you may be using. For example if you are using privacy protocols like DoT. That doesn't mean you need the greatest and or latest servers to do so.
WuTang LAN
Regular Contributor
May I suggest to spend more time learning and less time spreading misinformation.
sfx2000
Part of the Furniture
NTP on something embedded can be fairly accurate in any case...
In the chart below - We're measuring local clock drift vs upstream NTP - and the X value is drift in microseconds - going along the y-axis, this is time, and the crossbar is estimated time based on the local clock - and that's the hard part, and what I've been working on for the last couple of weeks (on OpenWRT using both MIPS (big endian) and ARM)
This is all SW, no PPS input in from GPS - and I've validated my work against a Rubidium Standard time source, e.g Atomic Clock, in my lab
They say if you can't visualize it, then it's really hard to tell... so here's a quick snapshot
In the example above - local time is actually free-wheeling and not corrected, we're just making a query against a calibrated stratum 1 NTP server -
We're fairly precise - I'm at the point where we're measuring drift of the upstream servers, not my stuff..
I need to have stability of +/- 50ppb without GPS - as you can see, I'm getting close.
@thiggins or @RMerlin - there's a number of threads with useful info on NTP, but they're scattered across the forums - wonder if we can condense them either into a single thread, or into a sub-forum under the general forum.
In the chart below - We're measuring local clock drift vs upstream NTP - and the X value is drift in microseconds - going along the y-axis, this is time, and the crossbar is estimated time based on the local clock - and that's the hard part, and what I've been working on for the last couple of weeks (on OpenWRT using both MIPS (big endian) and ARM)
This is all SW, no PPS input in from GPS - and I've validated my work against a Rubidium Standard time source, e.g Atomic Clock, in my lab
Code:
delta-t 6546.37 seconds
delta-o 352.9 useconds
slope 0.0539078 ppm
old frequency -1653728 ( -25.2339 ppm)
new frequency -1650196 ( -25.18 ppm)They say if you can't visualize it, then it's really hard to tell... so here's a quick snapshot
In the example above - local time is actually free-wheeling and not corrected, we're just making a query against a calibrated stratum 1 NTP server -
We're fairly precise - I'm at the point where we're measuring drift of the upstream servers, not my stuff..
I need to have stability of +/- 50ppb without GPS - as you can see, I'm getting close.
@thiggins or @RMerlin - there's a number of threads with useful info on NTP, but they're scattered across the forums - wonder if we can condense them either into a single thread, or into a sub-forum under the general forum.
Last edited:
sfx2000
Part of the Furniture
Not so sure about that - WiFi needs to actually have a fair amount of accuracy, or it stops working... Consider the framing time between the AP and the Client Station, and this is all time division duplex... the client STA and AP need to keep sync'ed or frames start to show up as errors as the start time will drift.
TDD - the AP and Clients need to be aligned and synced - the AP is easy enough, but it's going to be running in it's own perspective of time - the client is going to run off it's host clock, so Beacon keeps things honest between the two - back to the future so to speak.
3G is even more stringent here...
ColinTaylor
Part of the Furniture
And absolutely none of that has anything to do with the date and time being set by NTP.
sfx2000
Part of the Furniture
Be nice - and appreciate that folks work on NTP...
See my above post, and take it into context. If you can do better, please share and show...
- Status
Similar threads
Similar threads