David Dyer-Bennet
Patron
- Joined
- Jul 13, 2013
- Messages
- 286
Like, um, dozens of other people all over the net, I'm having NTP issues. The clock on my NAS sometimes drifts (and then this starts causing trouble with git repositories shared from there, or otherwise becomes noticeable). I've seen these issues off and on for years, by the way.
This is on my home network. FreeNAS is sometimes exhibiting clock drift, and on examination it seems to be that it never manages to initialize a relationship with any server. However, Windows and Linux boxes on the same LAN, behind the same very minimal firewall (on an ordinary ASUS AC-3200 home router), all track NTP just fine, and furthermore if I disable ntpd, then using ntpdate on the FreeNAS box also works (this seems to me to show that it's definitely not anything blocking the packet path between my FreeNAS box and the Internet for NTP).
I've read around a bit, and I have put in place (last night, so it's had many hours to init) the kern.timecounter.hardware change recommended (after verifying it was valid on my hardware. (It was originally TSC, before I changed it.)
While the clock has not drifted that I can see by eyeball comparison since then, ntpq does seem to be telling me that NTP is NOT happy.
As I understand that, it says it is trying to initialize with all 4 servers it picked, but it has never (in nearly 12 hours) managed to ever reach any of them. Pings to them work fine, it's not a basic network connectivity issue.
I'm still using the default NTP server config, 0.us.pool.ntp.org through 3.us.pool.ntp.org.
So, any ideas for my particular case? And...why are we still seeing people having NTP problems on FreeNAS in particular so many years after it became a visible issue?
This is on my home network. FreeNAS is sometimes exhibiting clock drift, and on examination it seems to be that it never manages to initialize a relationship with any server. However, Windows and Linux boxes on the same LAN, behind the same very minimal firewall (on an ordinary ASUS AC-3200 home router), all track NTP just fine, and furthermore if I disable ntpd, then using ntpdate on the FreeNAS box also works (this seems to me to show that it's definitely not anything blocking the packet path between my FreeNAS box and the Internet for NTP).
I've read around a bit, and I have put in place (last night, so it's had many hours to init) the kern.timecounter.hardware change recommended (after verifying it was valid on my hardware. (It was originally TSC, before I changed it.)
Code:
fsfs% sysctl kern.timecounter.choice kern.timecounter.choice: ACPI-safe(850) HPET(950) i8254(0) TSC-low(1000) dummy(-1000000) fsfs% sysctl kern.timecounter.hardware kern.timecounter.hardware: HPET
While the clock has not drifted that I can see by eyeball comparison since then, ntpq does seem to be telling me that NTP is NOT happy.
Code:
fsfs% ntpq -pwn remote refid st t when poll reach delay offset jitter ============================================================================== 45.79.192.248 .INIT. 16 u - 1024 0 0.000 +0.000 0.000 45.33.84.208 .INIT. 16 u - 1024 0 0.000 +0.000 0.000 154.16.245.246 .INIT. 16 u - 1024 0 0.000 +0.000 0.000 108.61.73.244 .INIT. 16 u - 1024 0 0.000 +0.000 0.000 fsfs%
As I understand that, it says it is trying to initialize with all 4 servers it picked, but it has never (in nearly 12 hours) managed to ever reach any of them. Pings to them work fine, it's not a basic network connectivity issue.
I'm still using the default NTP server config, 0.us.pool.ntp.org through 3.us.pool.ntp.org.
So, any ideas for my particular case? And...why are we still seeing people having NTP problems on FreeNAS in particular so many years after it became a visible issue?