AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20081105100651.0227bb80@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:exch1.onstor.net
NSV:
SSH:
R:<ed.kwan@onstor.com>,<neilc@onstor.com>,<dl-cstech@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/andys@onstor.net@exch1.onstor.net/INBOX	0	2779531E7C760D4491C96305019FEEB5175BE0B0F2@exch1.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Wed, 5 Nov 2008 10:07:50 -0800
From: Andrew Sharp <andy.sharp@onstor.com>
To: Ed Kwan <ed.kwan@onstor.com>
Cc: Neil Cook <neilc@onstor.com>, dl-cstech <dl-cstech@onstor.com>
Subject: Re: CPU Statistics
Message-ID: <20081105100750.6d267f46@ripper.onstor.net>
In-Reply-To: <2779531E7C760D4491C96305019FEEB5175BE0B0F2@exch1.onstor.net>
References: <2779531E7C760D4491C96305019FEEB5175BE0AF8E@exch1.onstor.net>
	<2779531E7C760D4491C96305019FEEB5175BE0B0F2@exch1.onstor.net>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I don't know about accurate, but certainly not meaningful in any useful
way.  The description you quote is wishful thinking at best.

This is why cpu statistics is being revamped into something meaningful
and possibly even useful in the next release.  The design document for
the engineering work has already been reviewed, so that's something for
our "cpu-watching" customers to look forward to.

Cheers,

a

On Wed, 5 Nov 2008 09:55:45 -0800 Ed Kwan <ed.kwan@onstor.com> wrote:

> I don't think our ldavg is accurate.  Here are my notes on this:
> 
> Roughtly, the load is determined by the amount of time it takes to go
> through the previous 10,000 iterations of eee_poll(), compared to the
> fastest time to it ever took: ldavg = 1 - fastest/current. To me,
> this algorithm is flawed, since we always keep track of the fastest
> time and compare to it. If we have a decreasing load which allows us
> to complete the 10,000 iterations in record times, the "load average"
> will be 0, which give the incorrect impression that the system is
> idle. And when we go back to the same previous load, the "load
> average" will appears higher because we now have a newer and faster
> time to compare to. This is probably why in RichL's case the load
> average got stuck at 0.999 and never goes back down. Some load
> average algorithms use an exponential decay function to decrease the
> weight of a data point with age. Here we don't.
> 
> Also see Andy's email
> http://mailarchive.onstor.net/dl-cstech/2008/07/message/10004
> 
> ________________________________
> From: Neil Cook
> Sent: Wednesday, November 05, 2008 1:29 AM
> To: dl-cstech
> Subject: CPU Statistics
> 
> Hello all,
> 
> I recently had a very interesting conversation with a customer
> regarding CPU Statistics. Below is an extract from out Command
> Reference Guide, Chapter 25. In the documentation we describe that if
> the output of the 'stats show ldavg' is 0.60 then the CPU concerned
> is at 60% utilization, is this correct? From looking around and from
> other emails I found the link below which gives a different story on
> CPU Stats. Personally I've seen CPU stats over 1.0, does this mean we
> can run at more than 100%?
> 
> http://www.teamquest.com/resources/gunther/display/5/
> 
> 
> Stats Show Ldavg
> Synopsis
> stats show ldavg
> 
> Description
> Use the stats show ldavg command to see the amount of load on each
> CPU in the main data path. The stats show ldavg command tracks
> information for the amount of load on each of the following
> processors:
> * The NCPU, which processes transport traffic
> * The ACPU, which processes most of the CIFS and NFS traffic
> * The FP1 and FP2 CPUs, which process file system traffic
> * The FC CPU, which processes SCSI traffic
> 
> Note - The SSC is not in the main data path, so the load on SSC CPUs
> is not displayed. For these processors, the load average displays a
> value between zero (0) and one (1) that indicates how much loaded is
> on each processor. Zero indicates that the processors has no load;
> one indicates that the processor is at full load; and a decimal value
> between 0 and 1 indicates the percentage of load on the processors.
> For example, a value of .60 indicates a 60% load. The stats show
> ldavg command gathers the processor loads by using a polling model.
> Each polling interval is approximately 1 to 2 seconds long. The stats
> show ldavg command is useful for determining which CPUs are more busy
> or less busy for any given user load.
> 
> Example
> In this example, the CPU loads are as follows:
> * The NCPU is at 10% load.
> * The ACPU is at 33.1% load.
> * The FP1 is at 29.2% load.
> * The FP2 is at 30.4% load.
> * The FC is at 12.1% load.
> 
> 
> Regards,
> 
> 
> [cid:image001.jpg@01C93F2C.72B00920]<http://www.onstor.com/>
> Neil Cook
> Senior Technical Support &
> Escalations Engineer
> ONStor, Inc.
> 
> Email: Neil.Cook@ONStor.com
> 
> Web:   http://www.ONStor.com
> 
> EMEA Support Line
> Phone:  +44 (0) 8707 347 448<http://support.onstor.com/>
> Email:   Support@ONStor.com
> Web:     http://Support.ONStor.com
> 
