Re: [P2PSIP] How to describe the processing power

"Bruce Lowekamp" <bbl@lowekamp.net> Thu, 13 November 2008 16:30 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4443E28C1FE; Thu, 13 Nov 2008 08:30:17 -0800 (PST)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37A153A67AC for <ietf@core3.amsl.com>; Thu, 13 Nov 2008 08:13:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0BQNhzeCqiB for <ietf@core3.amsl.com>; Thu, 13 Nov 2008 08:13:43 -0800 (PST)
Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by core3.amsl.com (Postfix) with ESMTP id 3296528C194 for <ietf@ietf.org>; Thu, 13 Nov 2008 08:13:43 -0800 (PST)
Received: by wa-out-1112.google.com with SMTP id n4so505578wag.5 for <ietf@ietf.org>; Thu, 13 Nov 2008 08:13:43 -0800 (PST)
Received: by 10.114.197.10 with SMTP id u10mr6919085waf.96.1226592823307; Thu, 13 Nov 2008 08:13:43 -0800 (PST)
Received: by 10.114.92.9 with HTTP; Thu, 13 Nov 2008 08:13:43 -0800 (PST)
Message-ID: <bc023dcd0811130813uacea8a2nba7f0adef3f7c740@mail.gmail.com>
Date: Thu, 13 Nov 2008 11:13:43 -0500
From: Bruce Lowekamp <bbl@lowekamp.net>
To: Roni Even <ron.even.tlv@gmail.com>
Subject: Re: [P2PSIP] How to describe the processing power
In-Reply-To: <491c3b64.1701d00a.3406.6d02@mx.google.com>
MIME-Version: 1.0
Content-Disposition: inline
References: <2D06DE445C2ADE44890118C3F449B9631FA33658@NASANEXMB12.na.qualcomm.com> <004a01c9453c$d76eb1c0$0c0ca40a@china.huawei.com> <491c3b64.1701d00a.3406.6d02@mx.google.com>
X-Mailman-Approved-At: Thu, 13 Nov 2008 08:30:11 -0800
Cc: Song Haibin <melodysong@huawei.com>, "Das, Saumitra" <saumitra@qualcomm.com>, p2psip@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

There are still a lot of open research questions for metrics like
this, but I think it's fine to include something like that in
diagnostics.  What you really want is something like max messages
forwarded per second and then current load as a factor of that, which
would factor in both cpu load and network load.  But in general,
things like that are really hard to compute, which is why what ends up
being reported is utilization and maybe capacity if it can be
measured.

I think the most important characteristic for metrics to be reported
via diagnostics is that they be well-defined and possible to measure,
so an implementer knows how to measure what is being requested and the
user knows what it means.

Also need to make sure whatever diagnostics are defined leverage
existing stuff whenever possible.  A lot of thought has gone into
existing stuff through groups like IPPM, so coming up with new ways to
measure network performance probably isn't going to be worthwhile.

Bruce


On Thu, Nov 13, 2008 at 9:34 AM, Roni Even <ron.even.tlv@gmail.com> wrote:
> Song Haibin,
>
> Your response " It is also useful in selecting peer for a neighbor table
> entry, when there are multiple choices existing and for the overlay
> management to collect the overall status of the overlay."  does also address
> Bruce question. My view is that the pure CPU power or CPU current usage are
> good but the question is if they are relevant for the decision  since the
> user may limit the amount of resources it wants to allocate for the p2p
> application. This may be based on percentage from the link or number of
> connections.
>
>
>
> Roni Even
>
>
>
> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of
> Song Haibin
> Sent: Thursday, November 13, 2008 5:07 AM
> To: 'Das, Saumitra'; p2psip@ietf.org
> Cc: ietf@ietf.org
> Subject: Re: [P2PSIP] How to describe the processing power
>
>
>
> Dear Das,
>
>
>
> See inline.
>
>
>
> ________________________________
>
> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of
> Das, Saumitra
> Sent: Wednesday, November 12, 2008 5:12 PM
> To: p2psip@ietf.org
> Cc: ietf@ietf.org
> Subject: Re: [P2PSIP] How to describe the processing power
>
>
>
> Dear Song,
>
>
>
>    Processing power would be more informational in terms of CPU load. A good
> example of what would be useful would be to look at the comon monitoring
> tool (http://summer.cs.princeton.edu/status/) for the planetlab testbed. It
> uses the following metrics for selecting nodes based on CPU and I have found
> such selection to be very useful in determining the performance of a slice
> on the machine.
>
>
>
> [Song] It is also useful in selecting peer for a neighbor table entry, when
> there are multiple choices existing and for the overlay management to
> collect the overall status of the overlay.
>
>
>
>
>
> From the comon site, these are some metrics that may be useful
>
>
>
> "CPU Speed
> Busy CPU
> Sys CPU
> Free CPU
> These fields give some insight into the CPU behavior of the node. The CPU
> Speed is just the speed of the processor in gigahertz. The Busy CPU field
> gives the % of time the CPU is utilized, and the Sys CPU field specifies
> what percentage of time the CPU is spending in the OS. Both of these values
> are the maximum values over the past 5 minutes. The Free CPU indicates how
> much of the CPU a spin-loop was able to obtain, giving some insight into how
> much of the node's CPU a new slice would receive."
>
>
>
> We could define these fields and leave it optional as to whether all of them
> are required. i.e. running a spin-loop may be expensive for some devices.
>
>
>
> [Song] This is helpful. I'm very glad to see this monitoring tool in the
> planetlab testbed. If it works well in the planet lab, we may have it
> included in the diagnostics draft after discussion. I also see other useful
> metrics for other parameters in the page
> (http://summer.cs.princeton.edu/status/).
>
>
>
>
>
>
>
>
>
> Best,
>
> Saumitra
>
>
>
> www.saumitra.info
>
>
>
> Date: Tue, 11 Nov 2008 15:12:21 +0800
>
> From: Song Haibin <melodysong@huawei.com>
>
> Subject: [P2PSIP] How to describe the processing power
>
> To: p2psip@ietf.org
>
> Message-ID: <003e01c943cc$d6e2b1a0$0c0ca40a@china.huawei.com>
>
> Content-Type: text/plain; charset=us-ascii
>
>
>
> Dear all,
>
>
>
> In p2psip diagnostics draft
>
> http://tools.ietf.org/id/draft-zheng-p2psip-diagnose-03.txt
>
> , we have some doubt about how to describe one of the diagnostic
>
> information: processing power. We propose to use the unit of MIPS to
> describe it. However, the Max number of connections may be another choice.
>
> Do you have any good suggestions?
>
>
>
>
>
> Best Regards,
>
> Song Haibin
>
> Email: melodysong@huawei.com
>
> Skype: alexsonghw
>
>
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www.ietf.org/mailman/listinfo/p2psip
>
>
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf