You won’t be having the same problem that was described in this thread, because this issue was resolved many months ago, (you’re replying to a 5 month old thread) and did in fact turn out to be that some users firewalls/routers or ISP’s were blocking ntp connections with a source port of 123.
Anyway, it sounds like you have one or more “bad” ntp servers that are messing up your time. When the time goes wrong, run the following command:
ntpq -c opeers
This will list which ntp servers are currently being used, which is the preferred, what time differences there may be between them, etc. Here is an example when I ran it on my system:
osmc@rpi2:~$ ntpq -c opeers
remote local st t when poll reach delay offset disp
==============================================================================
*skarabrae.draxi 10.0.87.251 2 u - 128 377 34.152 0.373 5.699
+slunce.swelter. 10.0.87.251 3 u 36 128 377 32.687 0.729 6.843
+intek-m.tv 10.0.87.251 2 u 83 128 377 71.064 0.110 8.679
-alvo.fungus.at 10.0.87.251 3 u 26 128 377 25.983 -17.607 6.878
EDIT: Use
ntpq -c peers
instead - this will give the actual IP addresses of the peers.
What we can see here is that one of the ntp servers is giving bad time that is 17 seconds out, but the other three are within a fraction of a second of each other. The minus sign means before alvo.fungus.at means that the server is being ignored because it is too far out of sync with the other servers, however if you can only reach one or two servers then ntpd has no way of knowing which servers are correct - only by correlation between three or more servers can it get any idea which have the correct time if some are incorrect.
Another command you can check the output of is:
ntptime
Here is what mine currently says:
osmc@rpi2:~$ ntptime
ntp_gettime() returns code 0 (OK)
time d9db2b3d.853d5314 Wed, Oct 28 2015 11:08:45.520, (.520467111),
maximum error 307484 us, estimated error 976 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
modes 0x0 (),
offset 138.575 us, frequency -3.763 ppm, interval 1 s,
maximum error 307484 us, estimated error 976 us,
status 0x2001 (PLL,NANO),
time constant 7, precision 0.001 us, tolerance 500 ppm,
If you can paste the output of those two commands when the time is out that may provide some clues.
There is no command to “fix” the time as such - ntpd is running constantly in the background making small adjustments so the time is only going to be wrong if it is getting bad time information from one of the ntp servers.
