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

Mon Sep 22 01:45:58 UTC 2014

Max, Dmitry,

On Mon, Sep 22, 2014 at 2:33 AM, Maxim V FIlimonov <che at bein.link> wrote:

> 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.
>


Can you apply following change to timer.c and try again?
Please also check load average using uptime.


Index: timer.c
===================================================================

--- timer.c (revision 271185)
+++ timer.c (working copy)
@@ -72,7 +72,7 @@
 #define TIMER_ENABLE (1<<0)
 #define TIMER_AUTORELOAD (1<<1)
 #define TIMER_OSC24M (1<<2) /* oscillator = 24mhz */
-#define TIMER_PRESCALAR (4<<4) /* prescalar = 16 */
+#define TIMER_PRESCALAR (0<<4) /* prescalar = 1 */

 #define SYS_TIMER_CLKSRC 24000000 /* clock source */

thanks,

Ganbold




>
> > 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
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>
