Instead, the value it's printing is the value called "root dispersion" (rootdisp) in the packet returned by the server, which is an estimate of the total amount of error/variance between that server and the correct time. It isn't actually estimating its own dispersion at all.
#Cdda to hit vs dispersio full#
For starters, ntpclient, at least in -s mode, isn't acting as a full NTP client, it's only sending and receiving one packet, so there's no "last 8 packets received". I see some confusion going on in the answers here. Would switching to chrony change anything in this case?.Could the fault lie on the Ubuntu server side, with an improper ntp.conf? There is nothing special there really.What commands could I run to get more details from the NTP servers?.What is dispersion and what can alter its value?.Remote refid st t when poll reach delay offset jitterġ27.127.1.0. Here's the ntpq -pn output from the Ubuntu 14.04 server: ntpq -pn These are all devices on the same LAN so frankly I am flabbergasted. From the debug output, ntpclient gets "1217163.1" from the NTP server but the max value it supports is absolute(65536). On the BusyBox side however, ntpclient complains with "Dispersion too high". They provided us with 5 in-house NTP server addresses which seem to work great on their own, as far as ntpdate-debian is concerned on the Linux server. This setup has worked great for years, but recently we've hit a roadblock with a new customer. Our dumb terminal client devices run an old version of BusyBox (1.00-rc2) and ntpclient 2010 from Larry Doolittle. We roll out Ubuntu 14.04 servers on isolated networks, running ntpd 4.2.6p5, configured to use multiple NTP servers as provided by customers (no access to ).
0 kommentar(er)
