From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 08:05:59 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F82516A4CE for ; Thu, 11 Dec 2003 08:05:59 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD7BA43D09 for ; Thu, 11 Dec 2003 08:05:57 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id DAA13493; Fri, 12 Dec 2003 03:05:50 +1100 Date: Fri, 12 Dec 2003 03:05:49 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Andy Farkas In-Reply-To: <20031211234620.O15896@hewey.af.speednet.com.au> Message-ID: <20031212025254.F12425@gamplex.bde.org> References: <20031211041048.B4201-100000@mail.chesapeake.net> <20031211234620.O15896@hewey.af.speednet.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Jeff Roberson cc: current@freebsd.org Subject: Re: ULE and current. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2003 16:05:59 -0000 On Fri, 12 Dec 2003, Andy Farkas wrote: > Bruce Evans wrote: > > [about systat and top] > > Neither; they have different bugs :-). top actually seems to be > > bug-free here, except it intentionally displays percentages that add > > up to a multiple of 100%. This seems to be best. You just have to > > get used to the percentages in the CPU stat line being scaled and the > > others not being scaled. > > So the almost-bug in top(1) is that some CPU percentages are scaled and > some are not scaled? Yes. It's probably more of a documentation bug. > ps. You mentioned "jitter". Thats why I 'sleep 120' in the above tests. > It tends to take about that long for top(1) to settle down. Why is that > so? As all top watchers know, %WCPU and especially %CPU take a while to ramp up with SCHED_4BSD. That's just how the algorithm works. I don't really understand SCHED_ULE, but think it has more jitter in the percentages because it fakes them based on what it is doing based on much less history than SCHED_4BSD (so they are closer to the transient %[W]CPU than the long-term averages). Bruce