[procps] Re: C-States handling - new switch?
- From: Jaromir Capik <jcapik@xxxxxxxxxx>
- To: procps@xxxxxxxxxxxxx
- Date: Wed, 08 Feb 2012 09:19:47 -0500 (EST)
> Hi Jaromir,
>
Hi Jim.
> Oops, sorry.
>
np
>
> > I believe that such scenario is possible. Turning the CPU off and
> > on
> > is quite cheap operation and thus can be done very quickly and
> > faster
> > changes can bring more energy savings.
>
> First, you should start using the procps-ng top. He's up to 300%
> faster than top-3.2.8. As a result, I believe you'll find quite
> different results with that delay interval of .25.
As I've noted before ... these results were collected on systems
where I was not allowed to install/modify anything ...
and unfortunately that won't change within 2 days ...
it actually might take years and I'll have to backport
all the changes to the legacy procps (3.2.8) till
the absolute end of life ... That's why I'd like to introduce
procps-ng in Fedora and kill the legacy version asap.
>
> Second, .25 is not a reasonable real-life interval, it just wastes
> cpu cycles.
Maybe, but our users need that in monitoring scripts.
>
> Third, the smaller the interval the fewer elapsed tics will be
> registered per cpu. There is no way to prevent that and there is no
> way to scale those results down given our limitation of tenths of a
> percentage.
>
> By the way, I have a version of top I use locally that gives the
> frequency of memory/cpu updates over to user control. I've limited
> that version to no more often than 1/second. With that kind of
> interval, there is no way to distort cpu percentages and I believe
> all your concerns over percentages would disappear.
>
> Would you like to try it?
Of course :]
>
> Regards,
> Jim
>
Regards,
Jaromir.
Other related posts:
