From owner-svn-src-all@freebsd.org Sun Mar 27 18:44:39 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6A53ADF055; Sun, 27 Mar 2016 18:44:39 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 6D6471F05; Sun, 27 Mar 2016 18:44:39 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id E33E24FAE8; Sun, 27 Mar 2016 18:44:36 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id u2RIiZDv087749; Sun, 27 Mar 2016 18:44:35 GMT (envelope-from phk@phk.freebsd.dk) To: Bruce Evans cc: Konstantin Belousov , John Baldwin , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, "'rstone@freebsd.org'" Subject: Re: svn commit: r297039 - head/sys/x86/x86 In-reply-to: <20160328033624.N850@besplex.bde.org> From: "Poul-Henning Kamp" References: <20160323075842.GX1741@kib.kiev.ua> <2922763.uITxoCVqGR@ralph.baldwin.cx> <20160324090917.GC1741@kib.kiev.ua> <20160325010649.H898@besplex.bde.org> <20160324162447.GD1741@kib.kiev.ua> <20160325060901.N2059@besplex.bde.org> <20160325084902.GH1741@kib.kiev.ua> <20160326021219.X911@besplex.bde.org> <20160326174210.GU1741@kib.kiev.ua> <20160327051601.S2318@besplex.bde.org> <20160327130706.GA1741@kib.kiev.ua> <20160328033624.N850@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <87747.1459104274.1@critter.freebsd.dk> Date: Sun, 27 Mar 2016 18:44:35 +0000 Message-ID: <87748.1459104275@critter.freebsd.dk> X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2016 18:44:40 -0000 -------- In message <20160328033624.N850@besplex.bde.org>, Bruce Evans writes: >Of course the details are machine-dependent. My oldest system on which I >discovered PLL-like behaviour was from late 1997. The PLL might not have >been in standard bus chips then. It had a K5 (?) running at 233 MHz. >The ratio of the TSC to the i8254 was precisely 196. Which means the PLL probably was 49:3 from the 14.31818 MHz xtal to 233.8636 MHz CPU frequncy. >Newer systems have much higher resolution so the ratios are rarely integers. PLL's in EMI-spec'ed environments are never unity ratio because that would needlessly add to the EMI trouble. >It should be, but isn't in practice. The RTC was only expected to be better than the other timers, in the very long run - weeks to years. In particular, most of the RTC xtals run 20-40K hotter than their turn-over point ~23C, so they keep awful time while the system is running. (The 32.768kHz xtals are designed for wristwatches where you body-temperature keeps them at stable temperature. Don't take your wrist-watch off at night if you want it to precise.) >The i8254 is supposed >to run at precisely 1193182 Hz but usually has an inaccuracy of 10-50 Hz. 50PPM is a very common crystal spec, that would be +/- 60Hz. (merging emails here) >> A very important and relevant detail here is that the *only* >> clock/counter which has a standardized frequency *is* the i8254 >> counter. > >Not even the ACPI timer? Not that I'm aware of. In most cases it runs at 14.31818 MHz, but I've seen it as low as 1MHz and as high as 25 MHz. >> The RTC *crystal* may not even exist, [...] > >It can give a precision of 1/32K seconds fairly easily (but with lots of >overhead) by interrupting at 32 KHz. 1KHz is sometimes used for profiling. Only if the 32.768 kHz RTC xtal exists. These days silicon oscillators are gaining ground in that segment. > Jitter is what I'm most worried about for virtual systems. > Jitter is quite good for a hardware RTC. [...] > Its hardware jitter is insignificant compared with the jitter > from interrupt latency. If interrupts are involved their latency+jitter will overshadow any other noise source, if nothing else because of the quantization to clock/bus frequencies. Jitter on the raw xtal is in picoseconds if not femtoseconds, as it needs to be when you PLL it up to GHz. >> Usually the errors will be magnificient, so a trivial sanity-check will >> catch them. Don't leave home without it. > >But then you have the problem of handling them. There might be just 1 >timecounter source that is emulated correctly, but you don't know which >it is. There might be none. Indeed: One clock or three, never two. John R. Vig's famous tutorial is the ultimate collection of wisdom about care and feeding of quartz: http://www.ieee-uffc.org/frequency-control/learning-vig-tut.asp Highly recommended. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.