From owner-freebsd-hackers Tue Feb 5 11: 0:50 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 207AB37B423 for ; Tue, 5 Feb 2002 11:00:42 -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 g15IvTM91786; Tue, 5 Feb 2002 19:57:31 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: nate@yogotech.com (Nate Williams) Cc: John Polstra , hackers@FreeBSD.ORG Subject: Re: A question about timecounters In-Reply-To: Your message of "Tue, 05 Feb 2002 11:51:58 MST." <15456.10702.319710.952387@caddis.yogotech.com> Date: Tue, 05 Feb 2002 19:57:29 +0100 Message-ID: <91784.1012935449@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 <15456.10702.319710.952387@caddis.yogotech.com>, Nate Williams writes: >> >> 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. 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. >> 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. -- 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