> >> 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). Can you explain why you think this is a good things, since it seems to be a bad thing to me. > Sanity-check: this is NOT a multi-CPU system, right ? As stated before, both are > 1Ghz single-CPU systems running -stable, although I'm sure John is capable of a answering this on his own. :) > We now have three options left: > hardclock interrupt starvation This is Bruce's hypothesis, right? > 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.) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
