<<
WebHome
Can ntp be used to keep time accurate to within 10ms ?
Initial analysis
- It seems that a default debian/etch install: aptitude install ntp ntpdate gives a good default configuration that indirectly contacts a large pool of "stratum 1" ntp servers, e.g. icm.edu.pl which seems to have an atomic clock, and that the precision should be sufficient
- ignore ntp-server, ntp-simple
- optionally install ntp-doc
- By installing ntp, the daemon ntpd will automatically be started. Do not try to run ntpdate by hand or with cron, since it should be disabled anyway, since the daemon is running.
- There is a daily cron job installed with the daemon package (ntp), but all it does is rotate the log files (instead of logrotate :P). You can edit /etc/cron.daily/ntp in order to keep a much longer backlog of logs - the default is just the last 7 days.
- The typical polling interval of remote ntp servers appears to be about 15-20 minutes on 3 different machines.
- The absolute offsets were a little less than 10ms for the last 7 days on all 3 machines.
- The ntp algorithm in general seems to be quite intelligent, using heuristic models to overcome various real-time problems such as occasional network congestion, individual server failure, and the hardware characteristics of localhost.
- 2008.10.20 to 2008.10.28 on simulation machine: ntp_offset_20081020_20081028_bell.png:
possible parameters to play with
config files
- /etc/defaults/ntp
- Maybe add -N To the extent permitted by the operating system, run the ntpd at the highest priority. ?
- /etc/ntp.conf
- minpoll, maxpoll - increase frequency of "polling" servers?
- replace server [0123].debian.pool.ntp.org iburst by server [0123].debian.pool.ntp.org iburst minpoll 6 maxpoll 8 = 1 to 4 minutes instead of the default 1 to 17 minutes ?
- this seems to be effective - see below
source files - recompile
- include/ntp.h
- Clock filter algorithm tuning parameters ?
- Selection algorithm tuning parameters ?
- decrease: #define MINDISPERSE .005 /* min dispersion increment */ ?
maxpoll 8 in ntp.conf
statistics on simulation machine: 8 days with maxpoll 10 and 2 days with maxpoll 8
The setting
maxpoll 8 means max polling interval is
,
maxpoll 10 (debian/etch default) means about 16 minutes max polling interval. Two plots of the same data - offsets from the server which at that moment is chosen as the synchronisation server - with different vertical scales:
At each polling interval, several servers are contacted. A complex algorithm is used to choose among these and decide which server is most reliable/precise. In practice, the chosen server can remain stable for many hours or days.
Statistics of these offsets in units of 300 km (a.k.a. 1 ms):
maxpoll |
min |
max |
mean |
s.d. |
rms |
10 |
-4.51 |
7.76 |
-0.42 |
1.55 |
1.61 |
8 |
-21.48 |
7.59 |
-0.88 |
3.23 |
3.34 |
8 exclude 2.4h spike |
-2.70 |
1.93 |
-0.28 |
0.70 |
0.75 |
The third line excludes the 2.4 hour spike from 10.32 days to 10.42 days.
The largest offset during the 2.4h spike was -20.44 ms.
In the interval 8.5 to 9.4 days, some experimentation was going on, so this period should be ignored.
TODO
Does this 10ms limit remain valid during intense simulated telescope usage?
Check that all is OK after aptitude update/upgrade
- Seems fine after upgrade.
--
BoudRoukema - 28 Oct 2008