Date: Tue, 18 Jul 2017 08:58:52 -0600 From: Ian Lepore <ian@freebsd.org> To: Bruce Evans <brde@optusnet.com.au> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r320901 - in head/sys: amd64/amd64 isa x86/isa Message-ID: <1500389932.22314.151.camel@freebsd.org> In-Reply-To: <20170718153823.K1105@besplex.bde.org> References: <201707120242.v6C2gvDB026199@repo.freebsd.org> <20170712224803.G1991@besplex.bde.org> <1500308973.22314.89.camel@freebsd.org> <20170718153823.K1105@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2017-07-18 at 18:08 +1000, Bruce Evans wrote: > On Mon, 17 Jul 2017, Ian Lepore wrote: > > > On Thu, 2017-07-13 at 01:42 +1000, Bruce Evans wrote: > >> On Wed, 12 Jul 2017, Ian Lepore wrote: > >> > >>> Log: > [...] > > I could barely read the reply, due to corruption of whitespace to > spaces > and \xa0. Formatting fixed, except all tabs are corrupted to spaces, > and there are extra blank lines after quotes. > My mail client broke two updates ago. I think nobody who works on gui apps does plain-text email anymore; if html mail looks good they're done. ::sigh:: > > > [lots of stuff about locking and accurate time-setting] > > Good idea. > > My inittodr() waits for the seconds register to change. This > increases > boot time by an average of 0.5 seconds, but is needed to get a result > that is not out of date by an average of 0.5 seconds. After the > seconds > register changes, the window for reading the other registers is > almost > 1 second, but the reads must complete in a few microseconds anyway > else > the result is still too out of date. Debugging printf()s show that > the reads usually complete in 10-50 usec with low latency (faster on > old systems with faster ISA buses). > I was considering adding a tunable to do that for people who don't mind the extra time to boot/wakeup. It's interesting that you label an error of a few microseconds as "too out of date", I was thinking that reducing the average error from .5s to .005s was good enough. The .005s number comes from an idea of using a callout that begins as soon as interrupts are available that checks for rtc rollover every 10ms, with the hopes that it can catch the rollover between the time callouts start working and rootfs mount time when inittodr() gets called. If it can catch the rollover happening in that window, it can latch the monotonic clock and then use that at inittodr() time to calculate the fractional part of the time. Even if it doesn't catch the rollover in that time, it at least has a measurement that sets a floor value for the fractional part, reducing the error to something less than .5s. I have no idea yet how much time elapses between interrupts coming online and the first inittodr() call on a typical modern x86 system. For all my arm systems with nfsroot it's several seconds. If it averages a few milliseconds on x86 systems, it isn't useful enough to justify the extra work. If it's typically half a second or more it probably is worth it. > Accuracy for reading is not very important because accuracy for > writing > is very low (1-2 seconds). My resettodr() only writes if the > difference > is more than 2 seconds. > The gross inaccuracy when writing is fixable now. I'm not worried about the microsecond inaccuracies of accessing the hardware, what I want to fix is the fact that clock_settime() may get called at x.995 and will record the time as x.0. Because settime is now called from a task thread, any clock driver is free to sleep as needed to set the clock hardware in a way that aligns its second rollover with kernel time. Not efficient, but easy to do. Even better, most rtc hardware has unused storage. Sometimes in the form of battery-backed ram, sometimes in the form of things like alarm registers that aren't used for anything and a driver can tuck away values in them for its own use. If clock_settime() stores the fractional part of the second in such a location, clock_gettime() can use it to remove all of the inaccuracy that otherwise happens when the fraction is discarded. If even a single bit is available the error is cut in half. If a byte is available it drops to ~40ms. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1500389932.22314.151.camel>