From owner-freebsd-arch Mon Apr 15 10:15: 8 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id F205B37B404 for ; Mon, 15 Apr 2002 10:15:03 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g3FHEvYu054343 for ; Mon, 15 Apr 2002 19:14:57 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: arch@freebsd.org Subject: get{bin,micro,nano}[up]time() - what precision ? From: Poul-Henning Kamp Date: Mon, 15 Apr 2002 19:14:57 +0200 Message-ID: <54342.1018890897@critter.freebsd.dk> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I'm soliciting input from users of the get*time() family of functions in the kernel on what the minimal desirable precision is. Currently they return a timestamp which is no more than 1/HZ out of date. For contemporary values of HZ, that seems to be adequate. As people increase HZ to above 10000, it starts to cost more to update timecounters every tick, and the question naturally arises: what is the target resolution for get*time() functions ? Would anybody get in trouble if the precision never got better than 10msec, even for higher HZ ? If so, would 1msec be an acceptable limit ? -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Apr 15 10:46:44 2002 Delivered-To: freebsd-arch@freebsd.org Received: from herbelot.dyndns.org (d013.dhcp212-198-27.noos.fr [212.198.27.13]) by hub.freebsd.org (Postfix) with ESMTP id B739437B405; Mon, 15 Apr 2002 10:46:34 -0700 (PDT) Received: from herbelot.com (tulipe.herbelot.nom [192.168.1.5]) by herbelot.dyndns.org (8.9.3/8.9.3) with ESMTP id TAA19437; Mon, 15 Apr 2002 19:46:32 +0200 (CEST) (envelope-from thierry@herbelot.com) Message-ID: <3CBB11F8.451D28AB@herbelot.com> Date: Mon, 15 Apr 2002 19:46:32 +0200 From: Thierry Herbelot X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: arch@FreeBSD.ORG Subject: Re: get{bin,micro,nano}[up]time() - what precision ? References: <54342.1018890897@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > > I'm soliciting input from users of the get*time() family of functions > in the kernel on what the minimal desirable precision is. > > Currently they return a timestamp which is no more than 1/HZ out > of date. For contemporary values of HZ, that seems to be adequate. > > As people increase HZ to above 10000, it starts to cost more to > update timecounters every tick, and the question naturally arises: > what is the target resolution for get*time() functions ? > > Would anybody get in trouble if the precision never got better > than 10msec, even for higher HZ ? > > If so, would 1msec be an acceptable limit ? Hello, I am investigating a "centralized clock" appliance, where a number of FreeBSD PCs would spit out a more or less precise date on the Ethernet. The goal would be : all FreeBSD PCs will run NTP, with a local GPS clock, and will peer with the other PCs in order to be hardened against the loss of a GPS box. The FreeBSD PCs only run some kind of endless loop, copying the local, "precise relative to UTC" time on Ethernet packets, sent approximatively once every msec. Thus, I would like to be able to read the local time at 2000Hz to (max) 5000Hz, with the correlative precision. Thus, 1msec seems to be a little short on precision. Cheers TfH > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Apr 15 10:53:57 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 556E337B41D for ; Mon, 15 Apr 2002 10:53:52 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g3FHrkYu055065; Mon, 15 Apr 2002 19:53:46 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Thierry Herbelot Cc: arch@FreeBSD.ORG Subject: Re: get{bin,micro,nano}[up]time() - what precision ? In-Reply-To: Your message of "Mon, 15 Apr 2002 19:46:32 +0200." <3CBB11F8.451D28AB@herbelot.com> Date: Mon, 15 Apr 2002 19:53:46 +0200 Message-ID: <55064.1018893226@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <3CBB11F8.451D28AB@herbelot.com>, Thierry Herbelot writes: >Thus, I would like to be able to read the local time at 2000Hz to (max) >5000Hz, with the correlative precision. Thus, 1msec seems to be a little >short on precision. You will still have the full precision functions {bin,nano,micro}[up]time(), but they are a tad slower to access. -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Apr 15 11:20:20 2002 Delivered-To: freebsd-arch@freebsd.org Received: from herbelot.dyndns.org (d013.dhcp212-198-27.noos.fr [212.198.27.13]) by hub.freebsd.org (Postfix) with ESMTP id F18C837B405 for ; Mon, 15 Apr 2002 11:20:16 -0700 (PDT) Received: from herbelot.com (tulipe.herbelot.nom [192.168.1.5]) by herbelot.dyndns.org (8.9.3/8.9.3) with ESMTP id UAA19495; Mon, 15 Apr 2002 20:20:04 +0200 (CEST) (envelope-from thierry@herbelot.com) Message-ID: <3CBB19D3.B8B06917@herbelot.com> Date: Mon, 15 Apr 2002 20:20:03 +0200 From: Thierry Herbelot X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: arch@FreeBSD.ORG Subject: Re: get{bin,micro,nano}[up]time() - what precision ? References: <55064.1018893226@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > > You will still have the full precision functions {bin,nano,micro}[up]time(), > but they are a tad slower to access. > fine, thanks TfH To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Apr 15 16:29:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id 2203A37B405; Mon, 15 Apr 2002 16:29:53 -0700 (PDT) Received: from pool0600.cvx21-bradley.dialup.earthlink.net ([209.179.194.90] helo=mindspring.com) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16xFux-0004ba-00; Mon, 15 Apr 2002 16:29:52 -0700 Message-ID: <3CBB6252.6BAA4E90@mindspring.com> Date: Mon, 15 Apr 2002 16:29:22 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: arch@freebsd.org Subject: Re: get{bin,micro,nano}[up]time() - what precision ? References: <54342.1018890897@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > I'm soliciting input from users of the get*time() family of functions > in the kernel on what the minimal desirable precision is. > > Currently they return a timestamp which is no more than 1/HZ out > of date. For contemporary values of HZ, that seems to be adequate. > > As people increase HZ to above 10000, it starts to cost more to > update timecounters every tick, and the question naturally arises: > what is the target resolution for get*time() functions ? > > Would anybody get in trouble if the precision never got better > than 10msec, even for higher HZ ? > > If so, would 1msec be an acceptable limit ? 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. I used this for a 100uS select(2) timeout for pacing in a game, at one point in time. It's probably worth considering Sun's SunOS 4.1.3 approach for FreeBSD. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Apr 15 22:13:17 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 7909837B416 for ; Mon, 15 Apr 2002 22:13:14 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g3G5D1Yu063899; Tue, 16 Apr 2002 07:13:06 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Terry Lambert Cc: arch@freebsd.org Subject: Re: get{bin,micro,nano}[up]time() - what precision ? In-Reply-To: Your message of "Mon, 15 Apr 2002 16:29:22 PDT." <3CBB6252.6BAA4E90@mindspring.com> Date: Tue, 16 Apr 2002 07:13:01 +0200 Message-ID: <63898.1018933981@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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. -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Apr 17 0:19:21 2002 Delivered-To: freebsd-arch@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id CFF1F37B41B for ; Wed, 17 Apr 2002 00:19:14 -0700 (PDT) Received: from pool0116.cvx21-bradley.dialup.earthlink.net ([209.179.192.116] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16xjib-0007ik-00; Wed, 17 Apr 2002 00:19:05 -0700 Message-ID: <3CBD21B1.2767EE59@mindspring.com> Date: Wed, 17 Apr 2002 00:18:09 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: arch@freebsd.org Subject: Re: get{bin,micro,nano}[up]time() - what precision ? References: <63898.1018933981@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 From owner-freebsd-arch Wed Apr 17 3:36: 0 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id A674237B404 for ; Wed, 17 Apr 2002 03:35:57 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g3HAZhlX013141; Wed, 17 Apr 2002 12:35:49 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Terry Lambert Cc: arch@freebsd.org Subject: Re: get{bin,micro,nano}[up]time() - what precision ? In-Reply-To: Your message of "Wed, 17 Apr 2002 00:18:09 PDT." <3CBD21B1.2767EE59@mindspring.com> Date: Wed, 17 Apr 2002 12:35:43 +0200 Message-ID: <13140.1019039743@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <3CBD21B1.2767EE59@mindspring.com>, Terry Lambert writes: >Poul-Henning Kamp wrote: >> 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, I hope everybody else who knows our kernel is having as good a laugh as I am about Terry ? Terry: Here is a clue for you: You manage to not even get close to the topic at hand in your email. And no, I am not going to explain it to you. -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Apr 17 3:47:51 2002 Delivered-To: freebsd-arch@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id 6BEDB37B404 for ; Wed, 17 Apr 2002 03:47:40 -0700 (PDT) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.6/8.11.6) id g3HAkZZ32677; Wed, 17 Apr 2002 12:46:35 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200204171046.g3HAkZZ32677@zibbi.icomtek.csir.co.za> Subject: Re: get{bin,micro,nano}[up]time() - what precision ? In-Reply-To: <3CBD21B1.2767EE59@mindspring.com> from Terry Lambert at "Apr 17, 2002 00:18:09 am" To: tlambert2@mindspring.com (Terry Lambert) Date: Wed, 17 Apr 2002 12:46:35 +0200 (SAT) Cc: phk@critter.freebsd.dk (Poul-Henning Kamp), arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > 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. ... Uhm Terry, aren't you mixing up get{bin,micro,nano}[up]time() with {micro,nano}[up]time()? The last set gives you up to the machine's capability precision. That can be 1ns or better depending on the machine. Both sets are available for use in the kernel John -- John Hay -- John.Hay@icomtek.csir.co.za / jhay@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Apr 18 6:27:52 2002 Delivered-To: freebsd-arch@freebsd.org Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id 838AC37B41C for ; Thu, 18 Apr 2002 06:27:46 -0700 (PDT) Received: from pool0042.cvx22-bradley.dialup.earthlink.net ([209.179.198.42] helo=mindspring.com) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16yBw0-0005ty-00; Thu, 18 Apr 2002 06:26:49 -0700 Message-ID: <3CBEC97B.40AFD6ED@mindspring.com> Date: Thu, 18 Apr 2002 06:26:19 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: John Hay Cc: Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: get{bin,micro,nano}[up]time() - what precision ? References: <200204171046.g3HAkZZ32677@zibbi.icomtek.csir.co.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG John Hay wrote: > Uhm Terry, aren't you mixing up get{bin,micro,nano}[up]time() with > {micro,nano}[up]time()? The last set gives you up to the machine's > capability precision. That can be 1ns or better depending on the > machine. Both sets are available for use in the kernel Not really. The time resolution in the kernel is not really relevent for the number one use in user space, which is logging. I built a "zero system call" gettimeofday(2) and time(3) using double mapped pages for the timecounter state for the 8254 and the Pentium TSC, based on Poul's code. Limiting the resolution on these limits the accounting granularity to approximately one quantum, even when the operations per request can be handled in significantly less than one quantum. If you look at the TSC code, using the data from the last interrupt, and using the timecounter "calibration" data, along with a current reading of the cycle counter, the reading of the current cycle counter is functionally equivalent to the SunOS 4.1.3 approach, except that it has a real value, instead of a statistical value, to do the job. Personally, I'm more concerned with the clamping as it relates to things requiring timestamps in the kernel -- not intervals. The proposed changes seem (to me) to be damaging to profiling. The original complaint by Poul was: ] I'm soliciting input from users of the get*time() family of functions ] in the kernel on what the minimal desirable precision is. ] ] Currently they return a timestamp which is no more than 1/HZ out ] of date. For contemporary values of HZ, that seems to be adequate. ] ] As people increase HZ to above 10000, it starts to cost more to ] update timecounters every tick, and the question naturally arises: ] what is the target resolution for get*time() functions ? This was not the question which naturally arose, for me. The question which arose for me was "Why the limear relationship between timecounter update frequency, cost, and resloution?". I'm not complaining about the work Poul has done on the time counter code in FreeBSD; if he hadn't perservered, we would all still be seeing "timecounter moved backwards" console messages. I'm sure we would all buy him a beer for fixing that problem (8-)). But I do question the assumption of a linear relationship being impossible to overcome by any means other than a decreased update resolution. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Apr 18 6:36:46 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (esplanaden.cybercity.dk [212.242.40.114]) by hub.freebsd.org (Postfix) with ESMTP id C9E1337B404 for ; Thu, 18 Apr 2002 06:36:43 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g3IDaOeb003972; Thu, 18 Apr 2002 15:36:24 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Terry Lambert Cc: John Hay , arch@FreeBSD.ORG Subject: Re: get{bin,micro,nano}[up]time() - what precision ? In-Reply-To: Your message of "Thu, 18 Apr 2002 06:26:19 PDT." <3CBEC97B.40AFD6ED@mindspring.com> Date: Thu, 18 Apr 2002 15:36:24 +0200 Message-ID: <3971.1019136984@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG You are so cute when you back-paddle Terry :-) This is _still_ not what we are talking about. Poul-Henning -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Apr 18 8:45:59 2002 Delivered-To: freebsd-arch@freebsd.org Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id E914737B404 for ; Thu, 18 Apr 2002 08:45:55 -0700 (PDT) Received: from pool0237.cvx22-bradley.dialup.earthlink.net ([209.179.198.237] helo=mindspring.com) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16yE63-00063n-00; Thu, 18 Apr 2002 08:45:19 -0700 Message-ID: <3CBEE9EF.80400659@mindspring.com> Date: Thu, 18 Apr 2002 08:44:47 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: John Hay , arch@FreeBSD.ORG Subject: Re: get{bin,micro,nano}[up]time() - what precision ? References: <3971.1019136984@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > You are so cute when you back-paddle Terry :-) I'm not back-peddling; if you had not ripped out two of my paragraphs in your initial "jump-in-Terry's-face", that would be obvious to everyone. > This is _still_ not what we are talking about. So instead of trying to be Mr. Myserioso, why don't you say what you are talking about in plain English. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Apr 18 8:46:47 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (esplanaden.cybercity.dk [212.242.40.114]) by hub.freebsd.org (Postfix) with ESMTP id C044F37B416 for ; Thu, 18 Apr 2002 08:46:39 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g3IFkTeb005895; Thu, 18 Apr 2002 17:46:30 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Terry Lambert Cc: John Hay , arch@FreeBSD.ORG Subject: Re: get{bin,micro,nano}[up]time() - what precision ? In-Reply-To: Your message of "Thu, 18 Apr 2002 08:44:47 PDT." <3CBEE9EF.80400659@mindspring.com> Date: Thu, 18 Apr 2002 17:46:29 +0200 Message-ID: <5894.1019144789@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <3CBEE9EF.80400659@mindspring.com>, Terry Lambert writes: >Poul-Henning Kamp wrote: >> This is _still_ not what we are talking about. > >So instead of trying to be Mr. Myserioso, why don't you >say what you are talking about in plain English. Go back and read my initial email :-) -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Apr 18 20:49:32 2002 Delivered-To: freebsd-arch@freebsd.org Received: from hotmail.com (oe49.pav0.hotmail.com [64.4.32.129]) by hub.freebsd.org (Postfix) with ESMTP id BC82D37B416 for ; Thu, 18 Apr 2002 20:49:29 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 18 Apr 2002 20:49:24 -0700 X-Originating-IP: [210.74.136.33] From: "kai ouyang" To: Subject: How to avoid the screen information from kernel? Date: Fri, 19 Apr 2002 11:49:23 +0800 MIME-Version: 1.0 X-Mailer: MSN Explorer 7.00.0021.1900 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0000_01C1E798.3FCEB080" Message-ID: X-OriginalArrivalTime: 19 Apr 2002 03:49:24.0597 (UTC) FILETIME=[32585250:01C1E755] Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ------=_NextPart_001_0000_01C1E798.3FCEB080 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi everyone, I want to know all screen information from kernel. How can I do that? Thanks. Best Regards Ouyang Kai=B4=D3=CD=F8=D5=BE=B5=C3=B5=BD=B8=FC=B6=E0=D0=C5=CF=A2=A1=A3M= SN Explorer =C3=E2=B7=D1=CF=C2=D4=D8:http://explorer.msn.com/lccn ------=_NextPart_001_0000_01C1E798.3FCEB080 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi everyone,
  I want to know all screen information from kernel. How c= an I do that?
  Thanks.
Best Regards
  Ouyang Kai


=B4=D3= =CD=F8=D5=BE=B5=C3=B5=BD=B8=FC=B6=E0=D0=C5=CF=A2=A1=A3MSN Explorer =C3=E2= =B7=D1=CF=C2=D4=D8=A3=BAhttp://e= xplorer.msn.com/lccn

------=_NextPart_001_0000_01C1E798.3FCEB080-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Apr 18 22:27:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id C9F8E37B419 for ; Thu, 18 Apr 2002 22:27:20 -0700 (PDT) Received: from pool0201.cvx22-bradley.dialup.earthlink.net ([209.179.198.201] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 16yQvW-0001SS-00; Thu, 18 Apr 2002 22:27:19 -0700 Message-ID: <3CBFAA97.E9AE7FA5@mindspring.com> Date: Thu, 18 Apr 2002 22:26:47 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: kai ouyang Cc: arch@FreeBSD.ORG Subject: Re: How to avoid the screen information from kernel? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG kai ouyang wrote: > > I want to know all screen information from kernel. How can I do that? I guess the subject is right and the message body is wrong? Stopping all boot information from displaying to the console is generally a matter of redefining the console as some place to which a display or serial terminal is not attached. The problem with this is that you lose all information at runtime which would normally indicate boot status, etc.. A lot of people who are using FreeBSD as the basis for their embedded systems work want to "hide" the fact that they are using FreeBSD. This is actually a mistake, for the most part, since customers really want feedback on what's happening with the box. At a past employer, I went on site to a customer facility, and for debugging purposes, enabled console messages: my employer had demanded that engineering disable boot messages to hide the underlying OS, against the recommendations of almost every engineer. One of the reasons they had to pay for me to be on site was the lack of diagnostic information meaningful to an engineer trying to fix the problem. Engineers don't know from version numbers, particularly when they are magic marketing numbers, and the release process builds something that can't be recreated from the source tree... the information shown by the UI is incredibly useless as anything but eye-candy. The customer requested -- very strongly -- that I leave the boot information visible for them when I left, and that, further, I enable it on all of our other product they had at their site. Without this, the first indication you got that the box wasn't dead was when the Tigon II card LEDs went off after having their firmware loaded, and then a "login:" prompt on the console some time after that. With a BIOS check of a huge amount of memory, the delay was considerable (the BIOS messages did not get sent to the console, either), and so there was almost no feedback to the customer that the box was working until it was actually performing the function for which it was intended. IMO, it *MAY* be useful to limit the boot time messages to failure only message, *yet still log* the messages as if they had been sent to the console. At least that way, you could get feedback. This would require a substantial reworking of the kernel print mechanism: the mechanism itself, and each instance of its use would require modification, to add a class designation parameter, so that you could "filter" classes of console messages to be displayed on the hard console (the serial port or video card or LCD display) and the soft console (the log that shows up in /var/log and in dmesg). Linux does this already. Unless such a change came from FreeBSD proper, IMO, it would be more trouble, in terms of additional maintenance overhead, to do this to "your FreeBSD derived product", than simply kicking out the messages as they currently appear. It's just not worth the hackery required... particularly for a serial console, where without initialization, the serial console output is not going to be intelligible. If you wanted to change every printf in the FreeBSD kernel to add class information, well, I'd actually be for that, assuming that you came up with a reasonable message classification system that was easy for future kernel hackers to follow. We would probably have to move "printf( ...)" into something like "kprintf( KPC_DEFAULT, ...)" to ensure that the transition could occur smoothly. It's *certainly* worth a custom/modified BIOS that prints POST information to the serial console, for things like motherboards placed in rack-mount enclosures, at least: feeback to the user that things are proceeding normally is invaluable (though the Super Micro serial BIOS POST hack leaves the console escape sequenced into color-on-same-color text, which is bad). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message