Looks all also good. Wondering how you could end up with three NTP server not working.
Would be interesting that after rebooting next time you post ntpq - c peers to check if you get “better” working NTP server.
Last login: Thu Dec 24 11:11:48 2015 from 192.168.1.104
osmc@osmc:~$ ntpq -c peers
remote refid st t when poll reach delay offset jittervodka.sublink.O .INIT. 16 u - 64 0 0.000 0.000 0.000
192.71.245.44 .INIT. 16 u - 64 0 0.000 0.000 0.000
kraken2.bilink. .INIT. 16 u - 64 0 0.000 0.000 0.000
mini.blesmrt.ne .INIT. 16 u - 64 0 0.000 0.000 0.000
osmc@osmc:~$
This is after a general upgrade and a reboot, plus i have changed the ethernet cable to be sure
And now the date log of journalctl it’s correct too 
osmc@osmc:~$ sudo journalctl -u ntp
– Logs begin at Thu 2015-12-24 11:48:30 CET, end at Thu 2015-12-24 11:53:11 CET
Dec 24 11:48:45 osmc ntpd[432]: ntpd 4.2.6p5@1.2349-o Wed Oct 28 20:37:00 UTC 20
Dec 24 11:48:45 osmc ntpd[435]: proto: precision = 0.781 usec
Dec 24 11:48:45 osmc ntp[424]: Starting NTP server: ntpd.
Dec 24 11:48:45 osmc ntpd[435]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
Dec 24 11:48:45 osmc ntpd[435]: Listen and drop on 1 v6wildcard :: UDP 123
Dec 24 11:48:45 osmc ntpd[435]: Listen normally on 2 lo 127.0.0.1 UDP 123
Dec 24 11:48:45 osmc ntpd[435]: Listen normally on 3 eth0 192.168.1.131 UDP 123
Dec 24 11:48:45 osmc ntpd[435]: Listen normally on 4 lo ::1 UDP 123
Dec 24 11:48:45 osmc ntpd[435]: peers refreshed
Dec 24 11:48:45 osmc ntpd[435]: Listening on routing socket on fd #21 for interf
lines 1-11/11 (END)
In the moment you don’t have any useable NTP servers. But you might need to give them a bit time to syncronize.
Crosscheck in 10 minutes, if all of them still show “16 u” then you definetly have a network problem.
Either it could be that your provider is blocking NTP packages or you just have a bad connection.
If successful it should look like this
` remote refid st t when poll reach delay offset jitter
*218.189.210.3 137.189.4.10 2 u 2 64 1 4.933 -0.034 0.163
218.189.210.4 137.189.4.10 2 u 6 64 1 4.934 -0.043 0.059
`
Nope, always 16 u response… how can i check if my provider blocks NTP packages?should i check
123 port on router?
Actually NTP uses UDP port 123, while you can check with telnet the communication on port 123 it’s not ensured that NTP works.
If you want to check in detail whats going on you could install tcpdump and run tcpdump udp port 123
But I first would check why you get so strange NTP server, as in your earlier post one seemed to have been in Italy while the otherone was in the US.
Maybe try to hard code some servers like change sudo nano /etc/ntp.conf to
#server 0.debian.pool.ntp.org iburst
#server 1.debian.pool.ntp.org iburst
#server 2.debian.pool.ntp.org iburst
#server 3.debian.pool.ntp.org iburst
server 217.79.179.106 iburst
server 129.70.132.36 iburst
server ntp0.fau.de iburst
server 0.fr.pool.ntp.org iburst
In the meantime i’m checking mine router settings and i discovered that NTP don’t synchronize at all either with mine router
Ok, good indication that your ISP is messing with the NTP protocol.
Actually as one server in your original list was working maybe hardcode that one and try again.
On the other hand as OSMC uses the alternative with http-time you also can survive without NTP working
Yes, i heard of http-time feature in the lasts updates, can you confirm me 2015.11-2 is the last OSMC released?
Yes, that is the latest version (new one to come in the next couple of days). But http-time is already in since quite a while. And it is working as you can see you have the right time.
Anyhow experiment a bit with the servers, would be nice to have also a working NTP
In the meantime (although should be unuseful) I’ve requested PUBLIC IP to my ISP.
we’ll see if resolve…
Found this address (10.45.233.193) to add in the router’s NTP servers and finally seems to synchronize 
Than either add that IP also to ntp.conf as the only server