X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,T_TO_NO_BRKTS_FREEMAIL
X-Spam-Check-By:	sourceware.org
MIME-Version:	1.0
In-Reply-To:	<ifnm2m$6vr$1@dough.gmane.org>
References:	<ifhu4n$kl5$1 AT dough DOT gmane DOT org> <4D1CA8C0 DOT 9020806 AT redhat DOT com> <ifim7c$6df$1 AT dough DOT gmane DOT org> <AANLkTi=+Ps6YkQcvRMOcOCFpJEo_ZQHvMb1A2qS=M90e AT mail DOT gmail DOT com> <ifj4h8$5q4$1 AT dough DOT gmane DOT org> <AANLkTimQzaxEOqyUVr6REL_xFsqYYYZ_HbRAhe-DtzsR AT mail DOT gmail DOT com> <ifjgca$n9u$1 AT dough DOT gmane DOT org> <AANLkTimg7zB__vPeJnQJUWf8vRb_O932xTrmf6oDyvy9 AT mail DOT gmail DOT com> <ifkm3h$sf1$1 AT dough DOT gmane DOT org> <AANLkTimtrk5boR8q2iPnFu=_viuJK_nggN=4HauZ4rnw AT mail DOT gmail DOT com> <ifl71d$apr$1 AT dough DOT gmane DOT org> <AANLkTimJAiDp34-Hvzrd2CSdD3RQBzGaw5q6QG1nezm7 AT mail DOT gmail DOT com> <ifnm2m$6vr$1 AT dough DOT gmane DOT org>
Date:	Sun, 2 Jan 2011 08:29:47 +0000
Message-ID:	<AANLkTini3W=MJDrDTb7WrZikw7HRxhH3fySWGjObT1ze@mail.gmail.com>
Subject:	Re: uptime not reporting CPU usage on Windows 7 (Possibly only when running in VMWare)
From:	Andy Koppe <andy DOT koppe AT gmail DOT com>
To:	cygwin AT cygwin DOT com
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Unsubscribe:	<mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
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 1 January 2011 16:51, Andrew DeFaria wrote:
> On 01/01/2011 09:08 AM, Andy Koppe wrote:
>>> 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.

I think removing /proc/loadavg would be a cleaner solution than
-1/-1/-1 though, so I tried that. Unfortunately it makes 'uptime' and
'top' fail, so that's why the dummy implementation is there.

>> =C2=A0Changing 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 Cygwi=
n's
> uptime isn't reporting load average correctly possibly due to some
> challenges on Windows.

Thanks for acknowledging that.

> 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.

Fair point.

> 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 t=
he
> Cygwin/Windows case.

I agree with the aim, but depending on how the number is parsed, the
failure might be non-obvious, for example by causing a wraparound to a
big positive number. And in any case it would result in "Updating
Cygwin broke my script" and "Negative load? Doesn't make sense!"
complaints. Hence I'm not convinced that's a change worth making.

>>>> =C2=A0Also, 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.

Scratch that, I lost sight of the fact that /proc/loadavg is meant to
average the number of active processes rather than utilization
percentage.

The current number of active processes can in fact be worked out from
the results of the undocumented
NtQuerySystemInformation(SystemProcessesAndThreadsInformation,..)
function. That's used in the implementation of /proc/<pid>/status, and
it would involve iterating over all processes and threads, counting
the number of processes that have running or ready threads.

Of course that would still yield the current state only, so a
background process or the approximate aproach outlined above would
still be needed to obtain averages.

Andy

--
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

- Raw text -