Date: Tue, 5 Feb 2002 12:04:45 -0700 From: Nate Williams <nate@yogotech.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: nate@yogotech.com (Nate Williams), John Polstra <jdp@polstra.com>, hackers@FreeBSD.ORG Subject: Re: A question about timecounters Message-ID: <15456.11469.659090.290513@caddis.yogotech.com> In-Reply-To: <91784.1012935449@critter.freebsd.dk> References: <15456.10702.319710.952387@caddis.yogotech.com> <91784.1012935449@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
> >> >> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15456.11469.659090.290513>