From owner-freebsd-hackers Tue Feb 5 11: 4:56 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 1BF1637B404 for ; Tue, 5 Feb 2002 11:04:49 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id MAA04300; Tue, 5 Feb 2002 12:04:46 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g15J4jk68853; Tue, 5 Feb 2002 12:04:45 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15456.11469.659090.290513@caddis.yogotech.com> Date: Tue, 5 Feb 2002 12:04:45 -0700 To: Poul-Henning Kamp Cc: nate@yogotech.com (Nate Williams), John Polstra , hackers@FreeBSD.ORG Subject: Re: A question about timecounters In-Reply-To: <91784.1012935449@critter.freebsd.dk> References: <15456.10702.319710.952387@caddis.yogotech.com> <91784.1012935449@critter.freebsd.dk> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) 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 > >> >> Can you try to MFC rev 1.111 and see if that changes anything ? > >> > > >> >That produced some interesting results. I am still testing under > >> >very heavy network interrupt load. With the change from 1.111, I > >> >still get the microuptime messages about as often. But look how > >> >much larger the reported backwards jumps are: > >> > > >> > microuptime() went backwards (896.225603 -> 888.463636) > >> > microuptime() went backwards (896.225603 -> 888.494440) > >> > microuptime() went backwards (896.225603 -> 888.500875) > >> > microuptime() went backwards (1184.392277 -> 1176.603001) > >> > microuptime() went backwards (1184.392277 -> 1176.603749) > >> > >> (Ok, I'll MFC 1.111) > > > >Huh? It appears that 1.111 makes things worse, not better (larger > >jumps). > > No, 1.111 makes the jumps report more correctly I think. Now, if that ain't a glowing reason to MFC it, I don't know one (I think). :) :) > They will maybe save your meal in less bad cases than yours, but in > yours they just make sure that we don't get invalid number of > microseconds in a timeval, and consequently we get more honest output. How can you verify that this is the case? > >> We now have three options left: > >> hardclock interrupt starvation > > > >This is Bruce's hypothesis, right? > > Also mine for that matter. > > >> scheduling related anomaly wrt to the use of microuptime(). > >> arithmetic overflow because the call to microuptime() gets > >> interrupted for too long. > > > >'Interrupted for too long'. Do you mean 'not interrupted enough', aka > >a long interrupt blockage? (I'm trying to understand here.) > > See my previous email, I just explained it there. I still didn't understand, hence the reason for the question. (The explanation was in the email I originall responded to). I understand the 'overflow' issue, but it would seem to my naive thinking that it would occur only when interrupts are blocked for a period of time, which is the same as hardclock interrupt starvation in my mind. How are issues (1) and (3) above different? Nate ps. I'm just trying to understand, and am *NOT* trying to start a flame-war. :) :) :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message