X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-0.5 required=5.0 tests=AWL,BAYES_50,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org To: cygwin AT cygwin DOT com From: Andrew DeFaria Subject: Re: uptime not reporting CPU usage on Windows 7 (Possibly only when running in VMWare) Date: Sat, 01 Jan 2011 11:51:32 -0500 Lines: 98 Message-ID: References: <4D1CA8C0 DOT 9020806 AT redhat DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9pre) Gecko/20100821 Lightning/1.0b2 Lanikai/3.1.3pre In-Reply-To: X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On 01/01/2011 09:08 AM, Andy Koppe wrote: > On 31 December 2010 18:22, Andrew DeFaria wrote: >> I do not imply the devs are ignorant - just busy perhaps. > Good. If you'd also contemplated the possibility that the current > state was deliberately decided on as the least bad solution, While I did eventually "get it" it does not follow that I was happy with it or that I didn't think it could be done better. > you might > have written your complaint in more temperate language. You mean like your responses? ;-) >> Any other negative things are things you're making up in >> your own mind. > It shouldn't be such a surprise that words can be read differently > than they were intended if they're not chosen carefully. And it also should not be such a surprise that if you're not sure of the intent you could first assume it isn't malicious and if you think it is then ask for clarification instead of running with your assumptions of mal intent as if you know the intent more than the original speaker! IMHO *that* would fall under the confines of temperance! >>> Well, if you take the 0% at face value even though you know the >>> machine is doing something, you're being rather silly. >> There is absolutely no reason to assume that 0% doesn't mean 0%. Yeah sure >> you can do some measurements and the like and pretty quickly come to the >> realization that 0% doesn't really mean 0%? > If you can't accept that 0% is easier to recognise as fake than > current load, we'll just have to agree to disagree. Finally! I agreed to disagree about 2 posts ago... Glad to see you've made it here... >> But really, why are your fighting me on this? > Yeah, I'm wondering that myself. > >> Why not simply make it better or at least make it something >> that nobody could mistake for simply a machine is not busy? > Because it's not that simple. Removing /proc/loadavg would be nice, > but would break any stuff that expects it to be there. I didn't suggest this. > Changing to > out-of-range values would also make some sense, but would break stuff > that depends on the values being in range. Since 0's "in range" it's not really a leap to assume that apps would view it as "this machine's not busy at all". I mean as a human I "get it" when I see 0 consistently when I *know*, by looking at other measures such as TaskMgr/Process Explorer, that the machine is indeed busy. I can, as a human, make that judgment call that 0's in this case must mean that Cygwin's uptime isn't reporting load average correctly possibly due to some challenges on Windows. But to a script or other app this would probably not be detected and instead the script or app will simply assume that 0 means not busy. IMHO it would be far better to report -1 and have the script or app fail to call attention to the fact that 0 does not mean not busy in the Cygwin/Windows case. > If you want to contribute something more than opinions to this thread, > you could go and trawl the mail archives for why the 0/0/0 solution > was chosen. According to the changelog, it was added in 2002. Perhaps > things have changed since then. Actually I came here looking for a solution, which Cyrille Lefevre has already provided me. I wouldn't mind contributing however if this is the level of professional discourse I should expect I think I'll just use what I have and move onward. >>> Also, load information is in >>> fact already available from /proc/stat. Here's how to interpret it: >>> http://www.linuxhowtos.org/System/procstat.htm. That's what 'top' uses >>> as well. >> Great, well then couldn't uptime (and top, etc.) use that? > As I'm sure you've read in the description, the numbers in the file > are aggregates since system startup. (On Cygwin, they're in > microseconds.) > > A percentage calculated directly from that obviously isn't what you > asked for, and it would become near-constant pretty quickly, so it > would be no use for seeing how your system is currently doing. > > 'top' obtains the current load by calculating the differences between > successive /proc/stat readings. That's why it pauses for a second > before starting to display data. Pausing like that is not an option > for the /proc/loadavg driver, because programs expect reads from that > file to return immediately. > > Here's an idea though that might provide a sufficiently useful > /proc/loadavg without having a background process polling the > performance counters. Read the counters whenever /proc/loadavg or > /proc/stat is read, and keep the readings for the last fifteen minutes > in a buffer, while discarding readings that are needlessly close > together. Use those readings to calculate the 1min/5min/15min > averages. > > Obviously the averages will be rubbish if /proc/loadavg hasn't been > read for a while, but the more often it's read, the better it gets. In > particular, if you just left 'top' running, you'd get increasingly > precise values. > > (Disclaimer: I'm not going to implement that.) > > Andy > -- Andrew DeFaria Suicide is the most sincere form of self-criticism. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple