Date: Mon, 15 Feb 2010 20:33:27 +0000 From: David Malone <dwmalone@maths.tcd.ie> To: Jeremy Chadwick <freebsd@jdc.parodius.com> Cc: Torfinn Ingolfsen <torfinn.ingolfsen@broadpark.no>, freebsd-stable@freebsd.org Subject: Re: ntpd struggling to keep up - how to fix? Message-ID: <20100215203327.GA28078@walton.maths.tcd.ie> In-Reply-To: <20100212194604.GA73961@icarus.home.lan> References: <20100211190652.6a66c618.torfinn.ingolfsen@broadpark.no> <20100211192515.GB13854@icarus.home.lan> <20100212132947.eb2af3d0.torfinn.ingolfsen@broadpark.no> <20100212131117.GA51905@icarus.home.lan> <20100212174452.2140cd72.torfinn.ingolfsen@broadpark.no> <20100212194604.GA73961@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Feb 12, 2010 at 11:46:04AM -0800, Jeremy Chadwick wrote: > Technical footnote: I wish I understood 1) the difference between > ACPI-safe and ACPI-fast, and 2) how the system or OS "ranks" the > timecounters (the higher the value in parenthesis, supposedly the more > accurate/preferred it is). Xin, do you happen to know how this works? 1) When you read the ACPI timing register, you should get a sensible answer. However on some (most?) hardware, you can read the register and get it half way through an update. When the kernel finds the ACPI timer, it tries reading it a few times in a row, and checks the results look good - if they do, you get ACPI-fast. If it catches a half-updated register, then you get ACPI-slow, which reads the register multiple times in an effort to avoid the problem. 2) The ranking of timers is essentially hard wired, though for some times it is adjusted in some way. For example, the ranking of the TSC may be reduced if it looks like an SMP system. I believe the ranking was originally intended to be a measure of how fast the counter could be read, but things have turned out to be complicated by difficult hardware. David.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100215203327.GA28078>