From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 10 21:45:24 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 787E91065672 for ; Mon, 10 Jan 2011 21:45:24 +0000 (UTC) (envelope-from Aaron.Caza@ca.weatherford.com) Received: from mail4.weatherford.com (mail4.weatherford.com [63.97.12.18]) by mx1.freebsd.org (Postfix) with ESMTP id 42B288FC0C for ; Mon, 10 Jan 2011 21:45:23 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.60,303,1291615200"; d="scan'208,217";a="414143514" Received: from usexbh02.wft.root.loc (HELO mail.weatherford.com) ([10.96.113.52]) by mail4.weatherford.com with ESMTP; 10 Jan 2011 15:16:34 -0600 Received: from owa.weatherford.com ([170.133.198.15]) by mail.weatherford.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Jan 2011 15:16:34 -0600 Received: from 032-SN1MPN1-005.032d.mgd.msft.net ([169.254.5.218]) by 032-SN1MMR1-003.032d.mgd.msft.net ([170.133.198.15]) with mapi; Mon, 10 Jan 2011 15:16:34 -0600 From: "Caza, Aaron" To: "freebsd-hackers@freebsd.org" Thread-Topic: Hardclock() not so hard on i386 lately. Thread-Index: AcuxC6f6gNVFj1neRfS16HgvCRsyQQ== Date: Mon, 10 Jan 2011 21:16:33 +0000 Message-ID: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 X-OriginalArrivalTime: 10 Jan 2011 21:16:34.0678 (UTC) FILETIME=[A8E8D960:01CBB10B] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Hardclock() not so hard on i386 lately. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 21:45:24 -0000 Greetings All, I've been experiencing a problem with the hardclock() call not exhibiting t= he same determinism in the FreeBSD 8.1 i386 Stable snapshots since November= . In the October snapshot and previous releases, instrumenting the hardclo= ck() to count ticks and using a kernel thread to print the output, I was se= eing 1024hz with +/- 1 tick jitter . Since November, however, I'm seeing a= lot more jitter - 1016hz-1024hz. To verify if the problem was with the ti= me-keeping or the hardclock(), I modified the hardclock() to raise & lower = a bit on the parallel port every tick and hooked it up to a frequency count= er. With the October release, I'm seeing 1023-1024hz as expected. With th= e FreeBSD 8.2 i386 Jan 2011 snapshot I'm seeing 1016-1024hz. Now, I know between Oct - Nov, the timecounter logic was modified to correc= tly allow for a 1-tick timecounter as prior to this the best it could do is= every other tick; however, I wouldn't think that modifying the timecounter= logic would have any bearing on the hard clock. A diff of kern_clock.c be= twix the two versions doesn't reveal anything useful. Being relatively new= to FreeBSD, I'm not certain where the next place I should be checking is. FYI: This is on an AMD Athlon II X2 235e Processor @ 2.7GHz running the SM= P kernel. Setting kern.smp.disabled=3D1 in /boot/loader.conf did not chang= e the behavior. Anyone got any useful pointers? Thanks in advance, Aaron This message may contain confidential and privileged information. If it has= been sent to you in error, please reply to advise the sender of the error = and then immediately delete it. If you are not the intended recipient, do n= ot read, copy, disclose or otherwise use this message. The sender disclaims= any liability for such unauthorized use. PLEASE NOTE that all incoming e-m= ails sent to Weatherford e-mail accounts will be archived and may be scanne= d by us and/or by external service providers to detect and prevent threats = to our systems, investigate illegal or inappropriate behavior, and/or elimi= nate unsolicited promotional e-mails (spam). This process could result in d= eletion of a legitimate e-mail before it is read by its intended recipient = at our organization. Moreover, based on the scanning results, the full text= of e-mails and attachments may be made available to Weatherford security a= nd other personnel for review and appropriate action. If you have any conce= rns about this process, please contact us at dataprivacy@weatherford.com. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and = protected from disclosure. This message is intended for the individual or entity addressed herein.=20 If you are not the intended recipient, please do not read, copy, use or dis= close this communication to others.=20 Also please notify the sender by replying to this message, and then delete = it from your system.=20 The sender totally disclaims, and will not accept, any responsibility or li= ability for the unauthorized use,=20 or the consequences of any unauthorized use, of this communication or messa= ge.