Re: [6tsch] simulation for random schedule allocation

Xavier Vilajosana Guillen <xvilajosana@eecs.berkeley.edu> Wed, 26 June 2013 16:33 UTC

Return-Path: <xvilajosana@berkeley.edu>
X-Original-To: 6tsch@ietfa.amsl.com
Delivered-To: 6tsch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0CE621F9F19 for <6tsch@ietfa.amsl.com>; Wed, 26 Jun 2013 09:33:06 -0700 (PDT)
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=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6i2C+z7uKvWO for <6tsch@ietfa.amsl.com>; Wed, 26 Jun 2013 09:33:06 -0700 (PDT)
Received: from mail-ie0-x242.google.com (mail-ie0-x242.google.com [IPv6:2607:f8b0:4001:c03::242]) by ietfa.amsl.com (Postfix) with ESMTP id 20FBB21F9DBB for <6tsch@ietf.org>; Wed, 26 Jun 2013 09:33:05 -0700 (PDT)
Received: by mail-ie0-f194.google.com with SMTP id 9so10102724iec.1 for <6tsch@ietf.org>; Wed, 26 Jun 2013 09:33:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=Pfte0IUDpOufIXCHVKw6qKqibywhHarprbOSXwkP4/8=; b=oM+phgh0oM/dUxQG5isSpOoxN4C1cinhO5IBl4POivT0LgMPUk1ZBxc7nljgxfQaGU KAuMxdJBb5k4l3Q8RnrVGZiwbhjTQkIcIH2bXSuuRp8d2DudyUBOMNejUVxWVABNqYH3 wKBLDlOVrrAaPrplHzjeGnHvatr4fVRtTfnPUVl6UOk2XdFL7B178nUL+98ja42dWMrY yMPcP1XJvNMoIrDE3Myi5ma9wDmAD89Z/0e+9dp7yv28iA9J+B1OMMHz+D1GLXsAD1r+ 2ixpQmXd867VokrgaLMOMmKwY+pCe3uaBe+sjOlWhexkFzwYOj3d+fZa9DXEZKIQRltj f7yw==
MIME-Version: 1.0
X-Received: by 10.42.92.129 with SMTP id t1mr2705073icm.37.1372264385621; Wed, 26 Jun 2013 09:33:05 -0700 (PDT)
Received: by 10.65.14.231 with HTTP; Wed, 26 Jun 2013 09:33:05 -0700 (PDT)
In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B12D2691A@tgxml338.toshiba.local>
References: <CALEMV4b27w3=hCkovP1JpQwQnN_jcu98hGPtjT349LhFBPb0XQ@mail.gmail.com> <674F70E5F2BE564CB06B6901FD3DD78B12D2691A@tgxml338.toshiba.local>
Date: Wed, 26 Jun 2013 09:33:05 -0700
Message-ID: <CALEMV4Zbqjd66Msot7cr45oFtG60zFFgUkAfPMLCq17zYR+ejw@mail.gmail.com>
From: Xavier Vilajosana Guillen <xvilajosana@eecs.berkeley.edu>
To: yoshihiro.ohba@toshiba.co.jp
Content-Type: multipart/alternative; boundary="90e6ba6147fe3e4b3704e011334e"
X-Gm-Message-State: ALoCoQlG7YRLel9OBttGd9KS2yFbU+Ezf2h5kgS83ksrHa94voIF+gdmC6ffatiS/u0BjWMp9nVo
Cc: "6tsch@ietf.org" <6tsch@ietf.org>
Subject: Re: [6tsch] simulation for random schedule allocation
X-BeenThere: 6tsch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: xvilajosana@eecs.berkeley.edu
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:6tsch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>
List-Post: <mailto:6tsch@ietf.org>
List-Help: <mailto:6tsch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:6tsch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jun 2013 16:33:07 -0000

Hi Yoshihiro,

you are right, the formulation of the sentence is not correct. Should be:

“Topology: Random, where each node requests a random number of neighbours
between 2 and 10.”

this means that each node when created requests a number of neighbors
between 2 and 10, meaning that other nodes when are created also request
that number of neighbours and therefore a node can have more than 10
neighbours, because other nodes selected it as a neighbour. From the
simulation results I see that nodes have between 5 and 11 neighbours
usually.

However, from the numbers you point, 28 represents the number of allocated
links (number of allocated cells in the schedule) to its neighbours, there
might be more than one link to a neighbour in that case.
regards,
Xavi

Xavi


On Wed, Jun 26, 2013 at 7:28 AM, <yoshihiro.ohba@toshiba.co.jp> wrote:

>  Hi Xavi,****
>
> ** **
>
> Thank you very much for the simulation.****
>
> ** **
>
> I am trying to understand the simulation model from your description and
> the result.****
>
> ** **
>
> “Topology: Random, where each node has a random number of neighbors
> between 2 and 10.”****
>
> ** **
>
> “****
>
> ************************ requesting 1 links****
>
> Node,Allocated Links,Collisions,Percentage****
>
> 0,28,0,0.0****
>
> “****
>
> ** **
>
> In the above result, does Node 0 actually have 28 neighbors?****
>
> ** **
>
> Regards,****
>
> Yoshihiro Ohba****
>
> ** **
>
> *From:* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *On Behalf
> Of *Xavier Vilajosana Guillen
> *Sent:* Wednesday, June 26, 2013 3:46 AM
> *To:* 6tsch@ietf.org
>
> *Subject:* [6tsch] simulation for random schedule allocation****
>
> ** **
>
>
> ****
>
> Hi all,
>
> I prepared a little simulation to see how random schedule allocation
> behaves. (I have the code in Java in case someone is interested)
>
> here there are some details (everything can be tuned in case someone wants
> to point me to a special case)
>
> Network: 50 nodes
>
> Topology: Random, where each node has a random number of neighbors between
> 2 and 10.
>
> Each node requests a link to each of its neighbors. This is done from 1 to
> 10 times (i.e 10 tests, the first requesting 1 link to each neighbour, the
> second 2, etc.. up to 10 links to each of the neighbors, can be configured)
>
> The slotframe is 101 slots and 16 channels.
>
> The simulation prints statistics for the test (and the collisions if we
> are interested.)****
>
> I used pseudo random generator from the java language assuming it provides
> uniform or almost uniform distribution.****
>
> The allocation counter counts both the number of links allocated as tx and
> the number of links allocated as rx due to a neighbour allocating a link to
> the actual node. The percentage is the % of collisions w.r.t the allocated
> links. ****
>
> Worst case is around 11% when allocating 10 links to each neighbour in
> that 50 node network.****
>
> I can play more on it but I wanted to share that initial results.****
>
> please see attached file for the results.****
>
> regards,****
>
> Xavi****
>