Linux NTP Server

Mr. C. · 07-09-2008, 12:51 PM

Well, the good news is that you don't have to worry about those values; they are for techno-geeks! :-)

Actually, they are measurements indicating how far your time is away from the server clock. Delays is an average of how long it takes for packet roundtrip (think about this. You ask someone for time... and there is some delay before they even start to answer you. You'd want that to synchronize your own watch). You can measure this with traceroute to the destination host.

Jitter is how "wavy" the answers are over time. One sample might be 4, another 1, and yet another 6. So there is a jitteriness to the measurements, and that is accounted for. Offset I believe is how far apart the reference time and your time are. So the system works to move that to 0.

See this page for explanations: http://www.ntp.org/ntpfaq/NTP-s-trou...RBL-MONITORING

Your stratum 9 LOCAL(1) indicates the clock is using itself. This is probably not what you want. Find a local stratum 2 or 3 nearby you. You traceroute to determine how far away the clock is and how responsive the network. The faster, the more accurate your time will be. Note mine:

Code:

remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+clock.isc.org   .GPS.            1 u  736 1024  377   12.533   -5.270   0.884
+nist1.symmetric .ACTS.           1 u  712 1024  377   12.742   -1.554   3.578
*clock.sjc.he.ne .CDMA.           1 u  931 1024  377   11.210    0.408   1.094
-zorac.sf-bay.or 204.123.2.5      2 u  688 1024  377   21.045  -29.173   1.560

See also:
http://www.ntp.org/ntpfaq/NTP-a-faq.htm

MoschopsUK · 07-09-2008, 03:53 PM

Quote:

Originally Posted by Mr. C.

Offset I believe is how far apart the reference time and your time are. So the system works to move that to 0.

Potentially silly question coming up, then - if this offset is the estimated instantaneous difference between what the client thinks the time is and what the server thinks the time is, once the daemon has finished allowing for signal propagation etc., should the client not change its clock values accordingly, so that the difference is zero? Or is there some value somewhere defined as 'acceptable error'?

As for stratum 9, that fits exactly with the server, and in this particular case I've no need of the time being correct - just identical across the LAN. The LAN will have no access to the internet whatsoever when it's in place; I'm using the time for timestamping in some signal processing code.

Mr. C. · 07-09-2008, 05:54 PM

I see, then no problems.

If I ask you what time it is, you'll give me a time. I have two choices - either adjust my clock to exactly your clock (which may be a forward or backward adjustment), or I can slow down or speed up my clock. It is unacceptable to backward adjust my clock, as that makes timestamps meaningless. And if I advance my clock forward by too much, many things can be negatively affected (builds with source files on remote file systems, timestamps in logs, on files & directories, or in programs such as cron, or anything that relies on values of time).

So we're left with the alternative: that is, to make minuscule adjustments by skewing a little time each period. But there is a lot of uncertainly and irregularity in hardware, the network, power, external clocks, and the measurements themselves. What you end up with is a constantly skewing clock, in the attempt to converge to zero. For most applications, accuracy to with 1/100 of a second is more than sufficient. Any more accuracy require specialized, external clock hardware, regulated power, etc.

For full explanation at the difficulties of all this, spend an evening or two reading David Mills' papers describing how it all works.

MoschopsUK · 07-10-2008, 04:08 AM

Concise, clear and to the point. Brilliant. I did have a good root through the man pages and the top picks on a google NTP search, but they tend to all be very precise instructions on wich keys to press on your keyboard, and not so much about the thinking behind how it all works. Thank you very much for your time; I'm now pretty satisfied that the PCs in question will synchronise.

Quick additional question - I've added version 4 to my ntp.conf files. They now look like this:

Server:

Code:

driftfile /var/lib/ntp/ntp.drift

server 127.127.1.1 version 4
fudge 127.127.1.1 stratum 8 refid iV01

restrict 10.0.0.170 mask 255.255.255.0 nomodify notrap

Client:

Code:

driftfile /var/lib/ntp/ntp.drift

logfile /var/log/ntp.log

server 10.0.0.172 iburst
restrict 10.0.0.172   mask 255.255.255.255 nomodify notrap noquery
restrict 127.0.0.1

Asking ntpq for the version results in the following response on both machines:

Code:

ntpq> ntpversion
NTP version being claimed is 2

Should this read 4? Have I failed to set the correct NTP version?

This isn't a serious issue, I think; the client synchronised quite happily and is demonstrating a low delay value, which is nice.

Mr. C. · 07-10-2008, 11:52 AM

man ntpq

Quote:

ntpversion [ ]
Sets the NTP version number which [= prog-name =] claims
in packets. Defaults to 3, Note that mode 6 control messages (and
modes, for that matter) didn't exist in NTP version 1. There appear to
be no servers left which demand version 1. With no argument, displays
the current NTP version that will be used when communicating with
servers.

Version 2 or version 3 defaults allow interoperability with exisitng clients/servers. If you set to 4, then only other version systems will be able to sync. If a peer / client demands 4, protocol 4 will be used for that per / client.

tmarkwald · 09-25-2008, 09:27 AM

Quote:

Originally Posted by MoschopsUK

Many thanks for that; very helpful. Running out of questions, which is nice.

I check the ntp status every so often, as follows:

Code:

i02:/home/videocap # ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*10.0.0.172      LOCAL(1)         9 u  471  512  377    0.164    5.348   4.053

Rooting through the man page, I see that delay, offset and jitter are described as "and the current estimated delay, offset and dispersion of the peer, all in milliseconds."

What is doesn't explain is what delay, offset and dispersion are. Google is not so helpful here; each page I find them on assumes the reader already knows what they are.

Can someone explain what they are and can I use them to estimate how well synchronised the clocks are? I understand that '*' at the far left is a good thing...

Remote is the first 15 characters of the remote server's name, prefixed by a character that indicates the status of the remote server:

space (reject) The peer is discarded as unreachable, synchronized to this server (synch loop) or outrageous synchronization distance.

x (falsetick) The peer is discarded by the intersection algorithm as a falseticker.

. (excess) The peer is discarded as not among the first ten peers sorted by synchronization distance and so is probably a poor candidate for further consideration.

- (outlyer) The peer is discarded by the clustering algorithm as an outlyer.

+ (candidate) The peer is a survivor and a candidate for the combining algorithm.

# (selected) The peer is a survivor, but not among the first six peers sorted by synchronization distance. If the association is ephemeral, it may be demobilized to conserve resources.

* (peer) The peer has been declared the system peer and lends its variables to the system variables.

o ((pps.peer)) The peer has been declared the system peer and lends its variables to the system variables. However, the actual system synchronization is derived from a pulse-per-second (PPS) signal, either indirectly via the PPS reference clock driver or directly via kernel interface.

Refid is the remote server's current source for time. If this is 0.0.0.0 or something similar, you are not getting time service from the remote server.

St is the remote server's current stratum level. If this is 16, you are not getting time service from the remote server.

When is the number of seconds since a time service reply has been received from the remote server.

Poll is the number of seconds between polls of the remote server.

Reach is an octal bitmap of the results of the last eight polls of the remote server. A value of 377 means that the last eight attempts were successful; a value of 0 means that the last eight attempts were unsuccessful (you are not getting time service from the remote server).
Delay is the number of milliseconds it is taking for NTP packets to make the round-trip from your host to the remote server and back, and is an important factor used by NTP in selecting the "best" server. This is the reason you want to pick servers that are close to you.

Offset is the difference in milliseconds between the clocks in your host and the remote server.

Jitter (or disp) is the "dispersion" in milliseconds of successive time values from the remote server. It is a measure of the stability (time-wise) of the network path to the remote server, and is also an important factor used by NTP in selecting the "best" server.