From owner-freebsd-questions@FreeBSD.ORG Tue Sep 13 17:24:57 2011 Return-Path: Delivered-To: questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 761C8106566B for ; Tue, 13 Sep 2011 17:24:57 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout028.mac.com (asmtpout028.mac.com [17.148.16.103]) by mx1.freebsd.org (Postfix) with ESMTP id 5A65B8FC1A for ; Tue, 13 Sep 2011 17:24:57 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp028.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LRH00ACZ1PJR250@asmtp028.mac.com> for questions@freebsd.org; Tue, 13 Sep 2011 10:24:57 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-09-13_06:2011-09-13, 2011-09-13, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1109130195 From: Chuck Swiger In-reply-to: <201109131649.KAA00227@lariat.net> Date: Tue, 13 Sep 2011 10:24:55 -0700 Message-id: <80A6E751-9A62-4E58-A0DD-707B39C006DB@mac.com> References: <201109122350.RAA21916@lariat.net> <201109130443.WAA23650@lariat.net> <201109131021.EAA26090@lariat.net> <20110913151650.GF9801@dan.emsphone.com> <201109131649.KAA00227@lariat.net> To: Brett Glass X-Mailer: Apple Mail (2.1084) Cc: FreeBSD Questions List Subject: Re: Negative ping times with FreeBSD 8.1-RELEASE on older Celeron system X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 17:24:57 -0000 [ ...combining two emails... ] On Sep 13, 2011, at 9:49 AM, Brett Glass wrote: > If that's indeed the case, the kernel must be doing the math wrong. While there have undoubtedly have been kernel bugs with timekeeping (and there may be more still present), it's not uncommon for hardware issues to cause one or more of the available time sources to be broken. On a good day, the clock source is broken obviously enough that the kernel notices it during testing during boot and gives it a negative quality score. Other times, the clock becomes broken only after the box suspends and resumes from an ACPI S# state, or does frequency changes for power/thermal management, etc. > Ironically, it was the kernel that selected the ACPI timer, scoring it higher > than the timestamp counter as a clock source. Perhaps code should be added to > ensure that the timer is not chosen if it rolls over in less than a second, > since this clearly leads to imprecision and missed rollovers. The kernel attempts to notice problems when it probes for the various clocks during boot (ie, dev/acpica/acpi_hpet.c, dev/acpica/acpi_timer.c, etc); for ACPI, see acpi_timer_probe() & acpi_timer_test(). Regards, -- -Chuck