This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: a way to read the current cpu load from the shell or via acmdline utility in cygwin?


On Thu, 25 Jul 2002, Tony Arnold wrote:

> > I did a google search on "linux top cpu load".  Here's a top
> > from the first match:
> >
> > It took about an hour to make it compile and
> > run under cygwin 1.3.12-2 on Win2k.  The patch is attached.
> >
> > Note: I just compiled and ran the code; I haven't verified
> > the correctness of the output.  It seemed to work without
> > crashing, and the output looked plausible.  I also haven't
> > tested it on any system other than mine (above). Try it at
> > your own risk.
> Thanks for this, it's a good start to getting top working under Cygwin.
> My question is that when you run the Configure script what do give as
> the 'appropriate module' for the machine? I've used 'linux' but I wonder
> if there is a better option, or whether we should invent a Cygwin
> machine definition?

'linux' seemed to work for me.  I've had to comment out some
linux-specific stuff, though (see patch: ), so creating a cygwin
module might be a better long-term solution.

> Secondly, when it runs, I'm not convinced the figures are correct! For
> example, my setiathome process should show almost 100% cpu utilisation,
> but it shows 0%! Is this a refelction of my choice above, or problems
> with the /proc file system infotmation?

As I said, I haven't verified the correctness of the output.  As my
machine is mostly idle, the output looked plausible (compatible with that
of the Win2k Task Manager).  Now that I actually ran an experiment with a
CPU-intensive process, it looks like top downscales utilization by a
factor of 3 (again, on my machine and configuration).

> Hints and tips on this much appreciated.
> Regards, Tony.

The way top calculates CPU percentage is by dividing the accumulated
process time since last check by the wallclock time since last check.  As
far as I can see, the code itself looks correct.  Thus, the blame would
probably lie with either the /proc filesystem entries (particularly
/proc/$PID/stat) or the gettimeofday() implementation/granularity.
I'm sorry I don't have time to investigate further.
      |\      _,,,---,,_
ZZZzz /,`.-'`'    -.  ;-;;,_
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

It took the computational power of three Commodore 64s to fly to the moon.
It takes a 486 to run Windows 95.  Something is wrong here. -- SC sig file

Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]