Cloudflare Time

[Grisu]

I would really like to know what accuracy means for a router, ms, s, min, hour, day???
We often seen routers nev

 

[Swistheater]

Exactly it’s BS, time is a timestamp pulse, to set your local time, depending on the interval it can touch your lan as little as once a month.
And DDOS? your router drops those packets. Again I don’t see ANY real world use for us prosumers, other than “because we can”

I guess you are right, it is not like your router could suffer from an ntp amplification attack.

 

[dosborne]

They just released a new NTP service at time.cloudflare.com

It's really fast and reliable.

If it was just released, how could anyone possibly know if it is reliable. By definition, something new is not reliable.

 

[netmik3]

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

 

[sfx2000]

Consider Google public time... they're all stratum 1

time1.google.com
time2.google.com
time3.google.com
time4.google.com

Thanks for the tip on cloudflare...

 

[Swistheater]

Cloudflare's really trying to mimick google.

 

[heysoundude]

Cloudflare's really trying to mimick google.

a little bit of healthy competition is good, especially in the case of the behemoth the Alphabet companies are.

 

[heysoundude]

I would really like to know what accuracy means for a router, ms, s, min, hour, day???
We often seen routers nev

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...

 

[RMerlin]

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.

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]

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

 

[RMerlin]

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..

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]

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.

Every aspect of this post is pure fantasy.

 

[Grisu]

Every aspect of this post is pure fantasy.

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]

Every aspect of this post is pure fantasy.

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]

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?

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]

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...

May I suggest to spend more time learning and less time spreading misinformation.

 

[sfx2000]

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

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.

 

[sfx2000]

Every aspect of this post is pure fantasy.

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]

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...

And absolutely none of that has anything to do with the date and time being set by NTP.

 

[sfx2000]

And absolutely none of that has anything to do with the date and time being set by NTP.

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...