FreeBSD-11.0-CURRENT on ARM: performance and load average

Sun Sep 21 18:34:03 UTC 2014

On Sunday 21 September 2014 07:56:01 Ian Lepore wrote:
> On Sun, 2014-09-21 at 13:06 +0400, Maxim V FIlimonov wrote:
> > 
> > root at cubie:~ # ntpdate time.nist.gov
> > 21 Sep 13:04:55 ntpdate[2236]: adjust time server 24.56.178.140 offset
> > -0.117727 sec
> > root at cubie:~ # ntpdate time.nist.gov
> > 21 Sep 13:04:57 ntpdate[2237]: adjust time server 24.56.178.140 offset
> > -0.117018 sec
> > root at cubie:~ # ntpdate time.nist.gov
> > 21 Sep 13:05:00 ntpdate[2238]: adjust time server 24.56.178.140 offset
> > -0.116026 sec
> > root at cubie:~ # ntpdate time.nist.gov
> > 21 Sep 13:05:08 ntpdate[2241]: adjust time server 24.56.178.140 offset
> > -0.111525 sec
> > root at cubie:~ # ntpdate time.nist.gov
> > 21 Sep 13:05:26 ntpdate[2242]: adjust time server 24.56.178.140 offset
> > -0.103121 sec
> > root at cubie:~ # ntpdate time.nist.gov
> > 21 Sep 13:05:34 ntpdate[2243]: adjust time server 24.56.178.140 offset
> > -0.099055 sec
> > 
> > So as you could notice, the offset doesn't change much.
> 
> No, quite to the contrary, the time is changing rapidly -- it moved
> about 19 milliseconds in 39 seconds, or roughly a millisecond every two
> seconds.  That's an error rate of 500 parts per million, which is huge.
> However, it's not off by a factor of 16, so that's a bit confusing.
> 

Let me not agree with you. As you might have noticed, the time has the same 
offset no matter what exatc timeout I made before actually getting the time 
from the NTP pool. Here's another example of what I'm speaking about:

root at cubie:~ # ntpdate pool.ntp.org
21 Sep 22:24:56 ntpdate[660]: step time server 85.21.78.23 offset 7525.060549 
sec
root at cubie:~ # ntpdate pool.ntp.org
21 Sep 22:25:03 ntpdate[661]: adjust time server 95.213.132.250 offset 
-0.014318 sec
root at cubie:~ # ntpdate pool.ntp.org
21 Sep 22:25:07 ntpdate[662]: adjust time server 31.131.249.19 offset -0.010051 
sec
root at cubie:~ # ntpdate pool.ntp.org
21 Sep 22:25:24 ntpdate[663]: adjust time server 95.213.132.250 offset 
-0.005744 sec

You could notice that the offset changes a bit, and sometimes it can even 
decrease.
Here's one more example: I ran ntpdate some times in a row, then waited for 
about a minute:

root at cubie:~ # ntpdate pool.ntp.org
21 Sep 22:28:36 ntpdate[664]: adjust time server 95.213.132.250 offset 0.004790 
sec
root at cubie:~ # ntpdate pool.ntp.org
21 Sep 22:28:41 ntpdate[665]: adjust time server 31.131.249.19 offset 0.005558 
sec
root at cubie:~ # ntpdate pool.ntp.org
21 Sep 22:28:43 ntpdate[666]: adjust time server 31.131.249.19 offset 0.003983 
sec
root at cubie:~ # ntpdate pool.ntp.org
21 Sep 22:28:45 ntpdate[667]: adjust time server 31.131.249.19 offset -0.000497 
sec
root at cubie:~ # ntpdate pool.ntp.org
21 Sep 22:29:24 ntpdate[668]: adjust time server 31.131.249.19 offset 0.003195 
sec

If what I understood about what you said was right, the offset would increase, 
wouldn't it? This time it is approximately the same no matter what the time 
gap between two ntpdate's is.

Furthermore, here's what my PC says on ntpdate:

[22:32:07] 0 [che at quad:~]$ sudo ntpdate pool.ntp.org
21 Sep 22:32:11 ntpdate[40593]: signal_no_reset: signal 14 had flags 40
21 Sep 22:32:15 ntpdate[40593]: adjust time server 85.21.78.23 offset 0.008892 
sec
[22:32:15] 0 [che at quad:~]$ 
[22:32:15] 0 [che at quad:~]$ sudo ntpdate pool.ntp.org
21 Sep 22:32:18 ntpdate[40595]: signal_no_reset: signal 14 had flags 40
21 Sep 22:32:23 ntpdate[40595]: adjust time server 85.21.78.23 offset 0.007959 
sec
[22:32:23] 0 [che at quad:~]$ sudo ntpdate pool.ntp.org
21 Sep 22:32:25 ntpdate[40597]: signal_no_reset: signal 14 had flags 40
21 Sep 22:32:30 ntpdate[40597]: adjust time server 85.21.78.23 offset 0.004498 
sec
[22:32:30] 0 [che at quad:~]$ sudo ntpdate pool.ntp.org
21 Sep 22:32:45 ntpdate[40599]: signal_no_reset: signal 14 had flags 40
21 Sep 22:32:49 ntpdate[40599]: adjust time server 85.21.78.23 offset -0.005016 
sec

See, the offset differs much more (note the last try, it changed its sign) yet 
it's about the same value as on my cubieboard.

> BTW, time.nist.gov is not one server, it's a pool just like pool.ntp.org
> (we run one of the time.nist.gov server installations out of our
> building at $work).  I think it probably worked for you because of some
> sort of dns caching effect, because you clearly kept getting the same
> server each time.
> 
> -- Ian
-- 
wbr, Maxim Filimonov
che at bein.link