Do you have NTP server for your devices?

Worth trying NTS indeed, and report back your experience.

I tried it the other night. The experience wasn’t good for me. Mainly due to lack of NTS servers*. For unknown reason, my test client with dual-stack had problem talking with NTS servers with dual-stack (so I had to revert to IPv4 for my test). Eventually I got them to interact and here came the biggest no-no. Again for unknown reason both the time delay and jitter are much larger than plain old NTP w/o NTS during the short period of my test.

My need for external timerservers only for backup to my primary source which is the satellites. So I disabled NTS for the time being.

*If Cloudflare timeservers work well for you, then they’re ubiquitous. But it gives me the above mentioned issues.

Actually having given this a bit more thought I’m having second thoughts.
Sure MITM attacks could be possible and cause a multitude of issues and attack vectors if the clocks are out of sync, but:

Do we really need to poll public servers each x seconds to verify our devices are in sync with those public servers, having that potential attack vector open?
Rather have local devices poll the time from your router and change the rate at which your router polls the public servers to idk, twice a year to check DST changes.

Or not poll at all, much of what I’ve read go over of how clocks drift but how bad can it really be? We have cheap consumer digital clocks from the 80’s still around that stay accurate within dekaseconds in a year, and for example laptops that has laid somewhere in a basement for the better part of 10 years collecting dust usually have the clocks spot on when fired up if the bios battery has kept the slightest charge…

Now for the sake of having accurate timestamps on logs across devices, sync with a trusted local device instead of a public server.

Or maybe I’m not realizing something here? I just thought there’s a KISS approach.
Sure every machine is unique, but I feel like testing how much my pfsense box actually drifts

To keep my post concise:

The designers behind NTP and NTS are very bright human beings. They’re efficient and secure protocols. No need to worry about computational and network overhead.

It’s good practice to setup a local NTP server and point your devices on LAN to this server. You aren’t helping the world much by this practice but any help is a tiny contribution if you have a very strong sense of morality.

IMO, NTP for home use is mainly for devices without a built-in RTC. Secondly, it’s a very cheap (resource wise) and effective way to keep very accurate time on all your devices.

4 Likes

Aye it’s nothing someone should worry about, but personally never having given this any thought at all but now inspired going down the rabbit-hole of time and synchronization I ordered myself a DS3231 for a potential raspberry pi NTP server just for the sake of why not :slight_smile:

2 Likes

That’s interesting! …the path forward that you’ve chosen. I look forward to your experiment. So remember to post back.

I quickly glimpsed your item’s specs. It says the clock/crystal is 2ppm under room temperature. I take it as a very good component.

I don’t know what’s the specs of my SBC’s crystal. I run my time daemon on it. The daemon estimates that the system clock will drift at a rate of 25ppm if not adjusted against my satellite reference clock. I guess my SBC’s crystal is at least one order worse than your new clock.

The speed of your RTC can be adjusted (I think) with PTP. If it’s not your system clock, it will be adjusting the clock possibly inside your NIC.

PTP is another interesting rabbit hole. Though my understanding is that it’s only meaningful in enterprise environment where you could control all the middle men. It’s a technology to have precise control over delay & jitter along the transmission path.

Router is OpenWRT, it acts as NTP client and server for the rest of the LAN. It gets it’s sync every 4-12 hours (I can’t remember exactly) mainly to pickup DST in a timely manner. DHCP options point clients to the router for NTP, DNS, default gateway etc… I have been underwhelmed by RTC hardware to keep accurate time. In theory the xtal drift numbers sound great, but that is usually a 32 kHz xtal in a circuit that has a trimming resistor where a sloppy QC (nearly all of them) can set the “clock” freq tens of percent off of correct. Since the xtal is so slow, you have to set the xtal rate to many decimals of precision. Even a few seconds off can make log syncing two computers a nightmare of mental adjustments on every line.

For the first time in decades, I had an issue. A rolling power failure caused the Truenas server to reset it’s RTC to a few years in the past. It took me 30 min of troubleshooting weird side effects of unrelated failures before I saw something that mentioned the time being off. Which finally pointed me toward a real problem. The RTC would survive a ‘short term’ power outage, but this one was over 18 hours and the battery died.

I really took for granted that all clocks were always lock-step. So, a hardware clock would have prevented the problem, but I just put a button cell in the motherboard and I’ll deal with it in another decade. As long as the RTCs are sane, all the LAN devices tighten-up every hour or so to the router.

1 Like

All my RTC-less devices have a task at very early on of the boot sequence to sync up their clocks with an external source through NTP. It works well for me. No more dependency hell on a specific order of bringing the devices online, and weird broken services if not.

On button cells. Have to praise Apple for using higher quality parts. All PC OEMs seem not to use better cells by saving maybe 50cents. If you keep and run hardware for 10+ years, it’s real help and I would appreciate one less hassle.

LOL, seriously? You could buy 100 button cells for the cost difference of an Apple product. You could simply use a AA lithium battery pack on any brand and the MB would die of old age before the RTC ever gave up.

The point to my experience was that even a 5-10 year old button cell never showed any sign of a problem until the power was out for 18+ hours. I’d imagine that same button cell would last many years longer on ‘short’ power outages with no apparent issues.

I had zero warning that there would be a RTC failure on an extended outage as opposed to NO issues during a ‘short’ term outage. It hit me like a left hook, because of truenas being opaque about the original problem. I had no hint that it was a ‘clock’ problem … that had caused the 17 other apparent ‘https certificate issues’.

[rant]
Sorry, but you’re going to have a hard time convincing me that Apple hardware isn’t simply 3x as expensive for bottom of the barrel outdated designs with the sole goal of maximizing profits and brand loyalty. If I payed the Apple-tax, I’d surely expect a fresh button cell on the MB as a minimum.
[/rant]

Anyway, the issue is like disk drive bit-rot, the button cell will fail on a long-term power outage with ‘no’ warning and the false warm-and-fuzzy of surviving a typical power cycle will just serve to bolster that false assumption. A device WITH a battery backed clock naturally assumes that the clock will NEVER fail and has no sanity check to prove/disprove this false assertion. As such, it goes brain dead and assumes that “it’s fine” when it powers up 5 years before it had last powered down.

If it had no RTC, then it would be open to a correction, but it HAS a battery-backed RTC, so no provision was made for sanity amongst the perfection of the ‘failure-proof’ hardware.

As an extension of this false assumption, truenas just regurgitated a ‘certificate validation failure’ for every service that tried to listen on a port. At no point did it complain of a years-before-the-expected-current-date issue, or the current-date-preexists-the-certificate, else I would have solved the issue as fast as it takes to reset the bios clock and reboot. Instead, it wasted 30 minutes of my time before I could find ANY indication of a clock problem in the logs. Grrrrowl.

Yeah, I’m a bit salty over this. I’m retired now, but I’ve never in my life failed to report the specific failure reason in an error message, like this. It failed in the BIOS, it failed in truenas and it failed in the hardware design and assumption that hardware won’t ever fail.

How much code does it take to look at the last boot time and check that it’s NOT greater than the ‘current’ time? Not much, and it’s an obvious indication that the hardware-is-flawless assumption is busted. I’ll go kick the dog now, and tell the kids to get off my lawn, mumble-mumble-mumble.

I’m actually no Apple fanatic. Here is not Macrumors forum either. Interesting how people’s interpretation may differ…

Over the years I learned quite a bit from tearing down or looking at teardown of Apple hardware. I build better DIY PCs by learning from Apple hardware. :smiley:

True, but it is something to be aware of, especially if you use a NAS with any sort of authentication mechanism. Most AUTH types have a time component.

situation dependent, i have seen places that needed to sync time every hour. but yes, most often times (pun intended) default is fine.

I have a GPS receiver piping PPS to my firewall. Sub ms time server accuracy haha

Fallback is to a local ham radio guy with a similar setup

I’ve been trying to figure out chromy or NTPSec on it. I’d like to have it encrypted before I share it out to the world again. No MITMs allowed haha

4 Likes

I just sync my pfsense firewall to cloudflare’s NTP server every 4 minutes, it’s accurate enough for my needs.

1 Like

You really shouldn’t do it every 4 minutes. Most NTP servers specify limits such as use of bursting or intelligent bursting. They often rate limit IPs of over an amount so you might just be sending traffic out for no reason. A good safe number is once an hour or higher. After all if your clock is drifting that much in an hour you have other issues

3 Likes

All valid points. I’ll go tweak the polling interval.

1 Like

I’m not sure if you understand what you were saying or had read. I did some research after your response. Surprise surprise. I learned something new about PTP and I believe I could provide you with an interesting feedback. :smiley:

So PTP mostly works and is used like what I mentioned a few posts back. To increase timing precision, some NICs started to add their own hardware clocks some years ago that provide much more accurate timestamps than otherwise possible.

What’s new to me (though I think the possibility existed for about 8 years) is that this very accurate hardware clock on such NICs can be utilized as a reference clock (just like a GPS receiver) independent of its originally intended functionality. The clock itself is left as a free running clock but it’s assumed it’s very accurate.

Such usage scenario is perfect for home environment, that is for whatever reason, you prefer purchasing a NIC over a GPS receiver. I don’t know about the time accuracy you would achieve this way. I would speculate it’s between a very good external NTP server and a GPS receiver.

Anyone going to go down this rabbit hole and share your adventure? BTW, seems an Intel i210 NIC has built-in hardware clock.

To go farther down this tangent, the clock in NICs is used to timestamp packets sent on the network. This is how devices know what order packets should be in or if they have exceeded a time in flight and should be dropped so that buffers don’t overflow. If you want to use this clock for NTP purposes instead of a GPS clock, you could buy an “audio NIC” or something like that which is specifically designed for high-end streaming audio and replaces the typical clock generator with a femto clock or other high end, very temperature stable, low drift clock.

Additionally, The NIC clock is very important for audio streaming over a network. Not just so audio packets go in the correct order, but also so when to play the audio in the packet is correct. If there is jitter in the NIC clock then there is jitter introduced in your audio playback which leads to artifacts. Im sure at one point or another most people here have heard a sudden sharp (but short) high frequency noise in the middle of listening to something. This comes from either a dropped packet or a misordered packet.

The problem I had with hosting my own NTP was getting everything in my house to actually point at it. I had it setup for a while, but I haven’t poked at it for a while and I’m sure everything is back to pointing at whatever default internet servers they were setup with. Definitely a “juice wasn’t worth the squeeze” thing.

Welp my plans evolved a bit, now the 3231 will be only one piece in a clusterfuck that composes of 3 sources for time: GPS, LF radio time signal & a blob of 1 master & 3 slave oscillators (to agree on one value of offline time).

Currently demoing while waiting for components & since I’m not a programmer, I’m trying to learn some C++ that I never really got into in electronics school, but this time I’m actually enjoying it.

I’ll be impressing all the ladies with my redundant high-precicion local timeserver :wink:
EDIT: Oh, and use it to light up my led candle at 18:00 & turn it off at midnight, the built in timer drifts a second or so each day