From owner-freebsd-arm@FreeBSD.ORG Sun Sep 21 18:34:03 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F460D89; Sun, 21 Sep 2014 18:34:03 +0000 (UTC) Received: from mail.bein.link (bein.link [37.252.124.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8B5A6947; Sun, 21 Sep 2014 18:34:02 +0000 (UTC) Received: from quad.localnet (home.bein.link [172.16.32.6]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bein.link (Postfix) with ESMTPS id A0A501AF373; Sun, 21 Sep 2014 18:33:58 +0000 (UTC) From: Maxim V FIlimonov To: Ian Lepore Subject: Re: FreeBSD-11.0-CURRENT on ARM: performance and load average Date: Sun, 21 Sep 2014 22:33:58 +0400 Message-ID: <8990779.WPLHzDdnAo@quad> User-Agent: KMail/4.12.5 (FreeBSD/10.0-RELEASE-p8; KDE/4.12.5; amd64; ; ) In-Reply-To: <1411307761.66615.166.camel@revolution.hippie.lan> References: <7351653.A2UeEk9AA3@quad> <16223180.9Q4Ic3raYi@quad> <1411307761.66615.166.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Sep 2014 18:34:03 -0000 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. > 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