New answers tagged

0

The answer was given by mboehn. To clarify more: See the document he mentioned. Especially the last lines: The pool scheme is configured using one or more pool commands with DNS names indicating the pool from which to draw. The pool command can be used more than once; duplicate servers are detected and discarded. In principle, it is possible to ...


0

I had to contact the IT because the GPO domain was enforcing the NTP server. They allowed the changes in some of our pcs and now everything is working fine.


0

For the correct way to do it, configure your NTP servers to four or more different (pool) public peers plus a pair of local GPS appliances. Poorly behaving outliers will be discarded. Contrast to a wrong way to do it, configuring an undisciplined local clock. You can see how much it drifts without help, probably quite a bit over a few days. It will be ...


15

I see some confusion going on in the answers here. 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". It isn't actually estimating its own dispersion at all. Instead, the value it's printing is the value called "root dispersion" (rootdisp) in ...


5

According to the this cisco documentation, "dispersion, reported in seconds, is the maximum clock time difference that was ever observed between the local clock and server clock". With ntp servers that are not totally broken, a high dispersion should never occur. The only feasible scenario is when your client inits ntp and so far has only its local clock ...


11

Just a partial answer for "What is dispersion?": A typical NTP round trip: client | | server t1 |------->| t2 t3 |<-------| t4 This yields two values, offset (the time difference between client and server), and the delay (essential the network travel time) with the following formulas: offset= ((t4 - t3) + (t1 - t2)) / 2 delay = ...


5

Your dispersion and skew are enormous, there is a very large offset from the local clock to that peer. You should compare the offsets with the local date and set the clock manually. Get ntpd running and show ntpq -p from a host using all of the peers. It will select the better ones.


2

gpsd is running as nobody, and so doesn't have privilege to read /dev/ttyUSB0, which is exactly what it's complaining about. If you add the nobody user to the group uucp, that should fix things, but it's not recommended. Or you can change the modes on /dev/ttyUSB0 to be 666, which is slightly less dreadful. Best of all would be to edit the gpsd startup ...


0

It seems to me that you are asking how to have Linux have a split-brain clock: one that never step-changes but can be wrong, for the kernel, and one that is right but may step-change, for everything else. Sadly, Linux doesn't support this idea, and it would take a lot of work to make it do so. In your situation, things I think you can do to improve matters ...



Top 50 recent answers are included