Date: Sun, 27 Mar 2016 06:49:40 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Bruce Evans <brde@optusnet.com.au>, John Baldwin <jhb@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, "'rstone@freebsd.org'" <rstone@freebsd.org> Subject: Re: svn commit: r297039 - head/sys/x86/x86 Message-ID: <20160327051601.S2318@besplex.bde.org> In-Reply-To: <20160326174210.GU1741@kib.kiev.ua> References: <201603181948.u2IJmndg063765@repo.freebsd.org> <1866602.Bp7VFd5f42@ralph.baldwin.cx> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 26 Mar 2016, Konstantin Belousov wrote: > On Sat, Mar 26, 2016 at 03:17:43AM +1100, Bruce Evans wrote: >> This uses the i8254. > Well, this is the part which I do not like most. It is ridiculous > to calibrate relatively high-quality CPU oscillator with 8245 timer, > which often fed from separate, low-quality crystal which currently > selected by cost and exists only for legacy purposes. At least I haven't seen a single (hardware) system since I started measuring this 15-20 yeas ago on which the i8524 is not fed from the same clock as the TSC. Normally there is a PLL that can derives hundreds of different frequencies from the same clock. One is fed to the i8254, one to the ACPI timer and one to the CPU clock/TSC. > some hypervisors start offering modes where old ISA peripherals > are not emulated, and I suspect that hardware would start do the > same. Quite possible, some variants of SoCs already do this. Bug in these hypervisors. A slow clock like the i8254 is much easier to emulate than a fast one. It is impossible to emulate real time on a non-real-time system anyway, so almost all calibration code is likely to break in inverse proportion to its accuracy on real hardware. > More, we do not have any hooks to recalibrate our thought about > TSC frequency during normal runtime. Often, system does have very > precise measurement of the timecounter drift due to ntp/ptp. cpu_tick_calibrate() does exactly this (if the ticker is the TSC). My version has a precise (~1-10 usec) measurement of the timecounter drift relative to the RTC (or vice-versa). This is used some time after exit from ddb to fix up the timecounter. This depends on RTC seconds interrupts being perfectly periodic with low (or at least measurable) latency. This should be used to fix up the timecounter after suspend/ resume. An error of 1-10 usec is good enough for an ntpd server, but the current ACPI error in resume is not good enough for an nptd client. >> xdel() is a specialized version of i8254 DELAY() >> with getit() inline. It returns the initial and final values of the It can use any readable timer, but only the i8254 is easy to use and available on all (non-broken) x86 systems. Just the ifdefs/configuratation to use another timer would be very complicated. Using the cputicker or timecounter read functions doesn't quite work because these functions have unknown internals which might involve unusable timing or lockimg. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160327051601.S2318>