From owner-freebsd-hackers Tue Feb 5 11:55:44 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 7B80337B41F for ; Tue, 5 Feb 2002 11:55:19 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id g15JqBM92663; Tue, 5 Feb 2002 20:52:11 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: John Polstra Cc: hackers@freebsd.org Subject: Re: A question about timecounters In-Reply-To: Your message of "Tue, 05 Feb 2002 11:44:15 PST." <200202051944.g15JiFw04286@vashon.polstra.com> Date: Tue, 05 Feb 2002 20:52:11 +0100 Message-ID: <92661.1012938731@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <200202051944.g15JiFw04286@vashon.polstra.com>, John Polstra writes: >OK, adding the splhigh() around the body of microuptime seems to have >solved the problem. After 45 minutes of running the same test as >before, I haven't gotten a single message. If I get one later, I'll >let you know. Ok, so we know where the bogotism happens, now to identify it... >I don't follow that. As I read the code, the "current" timecounter >is only advanced every second -- not every 1/HZ seconds. Why should >more of them be needed when HZ is large? No, only if you have set tco_method to one, if tco_method is zero (default) we update the timecounter every HZ. >> You didn't say if you ran with standard NTIMECOUNTER right now, >> but 5 would be awfully short time at HZ=10000: 500 usec... > >Well, microseconds aren't what they used to be ... :-) But isn't it >true that the current timecounter only advances every second? I think >I have 5 seconds, not 5/HZ seconds. Depends on your tco_method... Could you try this combination: NTIMECOUNTER = HZ (or even 5 * HZ) tco_method = 0 no splhigh protection for microuptime() ? The reason why tco_method=1 isn't nice is that we loose the ability to use 1/hz precision cached timestamps in the get*() funtions. Btw, regarding the volatile thing: If I do extern volatile struct timecounter *timecounter; microtime() { struct timecounter *tc; tc = timecounter; The compiler complains about loosing the volatile thing. How do I tell it that it is the contents of the "timecounter" pointer which is volatile, but now what it points at ? I don't want the "tc" pointer to be volatile because it obviously isn't. Do I really need to cast it ? tc = (struct timecounter *)timecounter; That looks silly to me... -- 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-hackers" in the body of the message