Date: Mon, 22 Sep 2014 21:05:38 +0400 From: Maxim V FIlimonov <che@bein.link> To: Ganbold Tsagaankhuu <ganbold@gmail.com> Cc: freebsd-arm <freebsd-arm@freebsd.org>, Ian Lepore <ian@freebsd.org> Subject: Re: FreeBSD-11.0-CURRENT on ARM: performance and load average Message-ID: <2629767.V12UkVKH9N@quad> In-Reply-To: <CAGtf9xNcjrfK4E8jDWhMgXeaF5c49HADgfHVTef_f8ZT-yjoMg@mail.gmail.com> References: <7351653.A2UeEk9AA3@quad> <8990779.WPLHzDdnAo@quad> <CAGtf9xNcjrfK4E8jDWhMgXeaF5c49HADgfHVTef_f8ZT-yjoMg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 22 September 2014 09:45:57 Ganbold Tsagaankhuu wrote: > Max, Dmitry, > > On Mon, Sep 22, 2014 at 2:33 AM, Maxim V FIlimonov <che@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@cubie:~ # ntpdate time.nist.gov > > > > 21 Sep 13:04:55 ntpdate[2236]: adjust time server 24.56.178.140 offset > > > > -0.117727 sec > > > > root@cubie:~ # ntpdate time.nist.gov > > > > 21 Sep 13:04:57 ntpdate[2237]: adjust time server 24.56.178.140 offset > > > > -0.117018 sec > > > > root@cubie:~ # ntpdate time.nist.gov > > > > 21 Sep 13:05:00 ntpdate[2238]: adjust time server 24.56.178.140 offset > > > > -0.116026 sec > > > > root@cubie:~ # ntpdate time.nist.gov > > > > 21 Sep 13:05:08 ntpdate[2241]: adjust time server 24.56.178.140 offset > > > > -0.111525 sec > > > > root@cubie:~ # ntpdate time.nist.gov > > > > 21 Sep 13:05:26 ntpdate[2242]: adjust time server 24.56.178.140 offset > > > > -0.103121 sec > > > > root@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@cubie:~ # ntpdate pool.ntp.org > > 21 Sep 22:24:56 ntpdate[660]: step time server 85.21.78.23 offset > > 7525.060549 > > sec > > root@cubie:~ # ntpdate pool.ntp.org > > 21 Sep 22:25:03 ntpdate[661]: adjust time server 95.213.132.250 offset > > -0.014318 sec > > root@cubie:~ # ntpdate pool.ntp.org > > 21 Sep 22:25:07 ntpdate[662]: adjust time server 31.131.249.19 offset > > -0.010051 > > sec > > root@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@cubie:~ # ntpdate pool.ntp.org > > 21 Sep 22:28:36 ntpdate[664]: adjust time server 95.213.132.250 offset > > 0.004790 > > sec > > root@cubie:~ # ntpdate pool.ntp.org > > 21 Sep 22:28:41 ntpdate[665]: adjust time server 31.131.249.19 offset > > 0.005558 > > sec > > root@cubie:~ # ntpdate pool.ntp.org > > 21 Sep 22:28:43 ntpdate[666]: adjust time server 31.131.249.19 offset > > 0.003983 > > sec > > root@cubie:~ # ntpdate pool.ntp.org > > 21 Sep 22:28:45 ntpdate[667]: adjust time server 31.131.249.19 offset > > -0.000497 > > sec > > root@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@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@quad:~]$ > > [22:32:15] 0 [che@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@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@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. > > Here's what I got after applying the below patch: root@cubie:~ # sysctl kern.eventtimer.periodic kern.eventtimer.periodic: 0 root@cubie:~ # uptime 8:29PM up 2 mins, 1 user, load averages: 0.52, 0.31, 0.13 Please note that I switched kern.eventtimer.periodic off beforehand. I experimented a bit with uptime: it never showed me more than 0.2, and with ntpdate/date: the time isn't running faster than it should. So your patch really works which is great. > 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@bein.link > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" -- wbr, Maxim Filimonov che@bein.link
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2629767.V12UkVKH9N>