Okay, data point.
I brought up my KA630 emulator, running my 1.4T derivative.
Single-user.
I then ntpdate-synced to my house chime (which is stratum 2 at the
moment), slept for one hour, and re-ntpdated. There was drift, and it
was in the missed-interrupt direction. There was nothing at all
running to compete with anything.
# ps ax
PID TT STAT TIME COMMAND
0 ?? DLs 0:00.01 (swapper)
1 ?? Is 0:00.17 init -s
2 ?? DL 0:00.02 (pagedaemon)
3 ?? DL 0:00.28 (reaper)
4 ?? DL 0:00.20 (ioflush)
5 g0 Ss 0:03.46 -sh
25 g0 R+ 0:02.40 ps -ax
# ntpdate 10.0.1.1; sleep 3600; ntpdate 10.0.1.1
13 Dec 20:23:18 ntpdate[22]: signal_no_reset: signal 14 had flags 2
13 Dec 20:23:20 ntpdate[22]: step time server 10.0.1.1 offset 1.151316 sec
13 Dec 21:23:35 ntpdate[24]: signal_no_reset: signal 14 had flags 2
13 Dec 21:24:15 ntpdate[24]: step time server 10.0.1.1 offset 40.470697 sec
#
It does take human-perceptible time to run something like ntpdate or
ps (note that the delay between the second timestamp and the third is
more than one hour). But 40 seconds? That's more than I can ascribe
to command start delay, especially since I did another ntpdate while
composing this mail and
# ntpdate 10.0.1.1
13 Dec 23:01:14 ntpdate[26]: signal_no_reset: signal 14 had flags 2
13 Dec 23:02:11 ntpdate[26]: step time server 10.0.1.1 offset 57.165556 sec
#
both the amount of drift and the time it had to drift over were larger.
That's 40.47 seconds in 1:00:15, 57.17 seconds in 1:36:59; solving
40.47 = 3615 a + b
57.17 = 5819 a + b
gives me a=.007577132486... and b=13.0786660617....
I find it interesting that b is so large. Perhaps I should take more
measurements. But I'm more interested in eliminating the drift than in
figuring out its details.
I'll have to investigate more.
In my Copious Spare Time, of course. :-/
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B