Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 9 May 2003 14:20:03 +0000 (UTC)
From:      "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>
To:        Junwen Lai <lai@CS.Princeton.EDU>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: microuptime() went backwards.
Message-ID:  <Pine.BSF.4.53.0305091407090.650@e0-0.zab2.int.zabbadoz.net>
In-Reply-To: <Pine.LNX.4.44.0305081610480.29779-100000@opus.CS.Princeton.EDU>
References:  <Pine.LNX.4.44.0305081610480.29779-100000@opus.CS.Princeton.EDU>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 8 May 2003, Junwen Lai wrote:


> > May  8 20:01:51 FeliX /kernel: microuptime() went backwards (39515.922679 -> 15.898650)

> this happens when you change the system time, either by running "time"
> explicitly or using something like ntptime. Not a big deal, just ignore
> it.

I still can reproduce it by doing heavy disk IO, eg. nightly backups
to my amanda server. This happens w/ and w/o ntpd running (external
clock connected).
Suggestions from other PRs with apm etc. didn't help. Someone said
it's because of the VIA chipset but changing the motherboard is not a
solution.

The time I first saw it was the first time of greater moves around
filesystems after I turned softupdates on.

Further more - before I had the external clock - I had times the next
morning in the range from yesterday eve to the day high noon.
I still sometimes have probs with nightly periodic scripts running
twice :(

At the moment this is a 4.7-STABLE box. I will update to 5-CURRENT
once I find the time and see. I haven't checked the peace of code
around thos messages there nbut at least someone removed or changed
the 'microuptime() went backwards' log messages from what I could see.

One last note: the problem here is that when logging kern.* to syslog
the microuptime() went backwards warnings may produce a huge amount of
log data (up to 50MB) and thus will also add some more disc IO so this
may make the situation even worse. I didn't rebuild may latest kernels
with some rate limiting for those logs included. I may help to exclude
the '(39515.922679 -> 15.898650)' from logging so syslog can aggregate
the messages.

For more information you may check the ml archives and search (closed)
PRs on the topic.

-- 
Greetings

Bjoern A. Zeeb				bzeeb at Zabbadoz dot NeT
56 69 73 69 74				http://www.zabbadoz.net/



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.53.0305091407090.650>