ntpMerlin Hardware or software

[ColinTaylor]

every WAN connection has an MTU, right? a certain number of bytes per packet, and when that's off, the systems have to negotiate and compromise and speeds are affected by that process.

MTU has nothing to do with the date or time (if that's what you're implying).

...but we probably keep netflix and spotify streaming a little more easily (less buffering) or might actually snag that ebay bid in the last second.

smaller corrections more often: 20 minutes at gigabit speed is quite a lot of "oops" potential. It's a small thing, but I am confident it makes a small, likely imperceptible, difference except in speed and throughput metrics if you care to look deep into the decimal places.

Sorry, nice theory but that's not how the internet (or networking in general) works.

 

[sbsnb]

I am NOT advocating polling a public ntp server every second or fraction of a second

You're advocating increasing NTP server traffic by 2^10 - 2^6 = 2^4 = 16 times. If everybody used maxpoll=6 it would increase the load on the Internet's NTP servers by a factor of 16.

 

[sbsnb]

The drift value continues to climb by an average of 0.0112 ppm per day.

 

[L&LD]

Have you tested with RMerlin 386.4 Alpha 1?

 

[sbsnb]

I haven't. I doubt it's software related. The offset is still hovering around zero, it's just that the hardware clock is slowly getting more out of whack over time. I just don't know what the possible ramifications are. It's mainly just an interesting phenomenon for me to watch rather than a problem.

EDIT - I suppose it could be chrony. I may switch over to ntpd after a while more and see if the same thing happens.

 

[L&LD]

Less than 1% of 1 million parts, per day, isn't something I'd be too concerned about for something that you'll likely replace in a few years (at most).

 

[gattaca]

Typically timesyncing once or twice per day and when you startup works well for 99.99999% of the general public internet. Even things like keberos have tolerances for drift for up to a couple of mins before they halt authentications. Our wonderful spdMerlin tooling exceeds what I had before in every way.

Now before someone starts arguing, yes there are cases where time-drift is uber critical and in most of those cases, they have fully redundant GPS, Cellular, or "other" private time source appliances on site. Stay safe, stay alive. Peace.

 

[sbsnb]

Not so much worried about the accuracy as the change in accuracy. Specifically, what causes a linear degradation in a hardware clock?

 

[L&LD]

Time and entropy. And possibly a software glitch too.

 

[sbsnb]

I was thinking the linearity ruled out entropy as a cause. Of course, that is unless the hardware clock is somehow effectively measuring entropy directly or indirectly.

 

[L&LD]

Can't rule anything out, I believe. Plain old hardware issues are a possibility too.