Date: Wed, 17 Apr 2002 00:18:09 -0700
From: Terry Lambert <tlambert2@mindspring.com>
To: Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc: arch@freebsd.org
Subject: Re: get{bin,micro,nano}[up]time() - what precision ?
Message-ID: <3CBD21B1.2767EE59@mindspring.com>
References: <63898.1018933981@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp wrote: > In message <3CBB6252.6BAA4E90@mindspring.com>, Terry Lambert writes: > >SPARC had a 4uS resolution in ~1990; it did this by having a > >hardware clock of very high resolution, and a low update > >frequency, from which a delta was maintained in software, > >rather than by having an update requirement for a full > >timecounter like structure. > > As usual: Please don't pay attention to Terry, he is talking > without checking his facts and appearantly doesn't even know > that FreeBSD is way ahead of the pack when it comes to time > keeping code. I dislike increased imprecision. I understand wanting to limit the timecounter update frequency to some upper bound, regardless of the actual hardware clock frequency, since it would mean that the overhead would increase linearly with the hardware clock frequency. Getting the current time is a procedural operation, and so it need not depend on a hardware interrupt operation, if a certain resolution is required. This leaves work which has to occur at the hard timer interrupt frequency. There's really no reason to lose clock granularity merely because the timecounter state structure update frequency is lower than the desired granularity. Let me reemphasize that I do not think that 1uS accuracy for clock granularity is unreasonable 100uS to 60uS were required for smooth game flow in code I wrote, where the active number of computer opponents at any given time was permitted to vary. For statistical kernel profiling on multi-gigahertz processors, where, when the timer interrupt fires, you record the timer firing interval has being completely within the arc specified by the symbol less than or equal to the current program counter, I think that it's impossible to get accurate results without a hardware clock interrupt frequency that is sufficiently close to the real CPU clock frequency (e.g. in the range of 128 instructions is near the limit, I think, for small functions, though for most profiling it's probably overkill). Also let me point out again, that SunOS 4.1.3 decoupled the clock granularity from the hardware interrupt granularity, using a soft timer. Now this won't work with high resolution timers, such as those used with the SVR4 HRT facility (SVID III(RT)), or select(2) timeouts (per my application from my previous posting). If you are going to decouple the hardware clock interrupt frequency from the timer granularity, without losing timer granularity (timer firings *must* be coupled to events), then you have to deal with the fact that the current FreeBSD implementation of timecounter state update doesn't scale very well as the frequency goes up, or the hardware clock frequency nears the CPU frequency. I understood that this was the motivation for your posting, in the first place, though I do not understand the need to scale the number of timecounter state buckets above two or three instances (the current tuning on this to avoid console messages seems excessive, to me). By adopting the SunOS approach, clamping the timecounter state update frequency to some divisor of the hardware clock interrupt frequency *would not necessarily mean losing clock resolution*, which you suggested might be an acceptable outcome of the clamping. It is at least (1) statistically more accurate than a direct reference to a timecounter which is guaranteed to be updated, and (2) it is monotonically increasing, so there is an *average* of a higher resolution. In fact, the TSC timecounter code uses an apprach very similar to this already, and substitutes reading the current cycle counter for a weighted average based calculation derived from the number of times the time was the same in the last set of interrupts. So what does this leave us? It leaves us with timer problems for timeouts, etc., which will also lose resolution. If they don't lose resolution... well, the traversal of the timer lists, which are arbitrarily long, is non-deterministic, and will most likely take much more time than simply updating the timecounter state -- an update whose slope is at least linear and deterministic. How do we avoid losing timer resolution at the same time, then? I would suggest that we learn from Mohit Aron and Peter Druschel of Rice University (I've suggested this before), and implement Soft Timers: http://citeseer.nj.nec.com/aron99soft.html Note that these are only part of a whole solution. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CBD21B1.2767EE59>