Felix Miata wrote:
Yeah, although it's not such a bad idea to have one system sync'ed to the pool, and the rest sync'ed to that system.
Exactly what I'm trying to do
because
I have a STB running Linux that when configured to use a public pool always fails to sync. When setting it up to a specific public server like time.nist.gov or time.mit.edu it randomly works or not. It seems to work no more than about once or twice a day, but typically needs rebooting multiple times a day to avoid catching video output corruption while attempting to record from it. When it fails on reboot it gets a 1999 date and 00:00 UTC time setting. I was hoping a local server would somehow be more reliable.
When I set the STB to sync to the local hostname or IP of my local NTP, it always fails, and the output of 'tcpdump -n -i etho port 123' never sees anything incoming from the STB, while it is showing 140.99.51.114.123, which I would think my router should be blocking. Or could that be an IP via us.pool.ntp.org?
I have no idea how the STB actually gets the date from the internet. It has no ntp command, no ntpd command, no tcpdump command, and no /etc/ntp.conf. A ntp server URL is fed into the GUI UI if auto sync from internet is selected.
It would appear the problem is with the STB. Point another computer at your local server to verify it's working. I expect it is. With NTP, there are two ways it can operate. Either a computer can request the time or the server can multicast. If using the first method, you should see the requests and responses on UDP port 123. I use Wireshark to monitor the network and it works quite well. It's curious that the STB is missing the ntp stuff. Who built it? What distro? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org