Message from discussion Mixim and 802.15.4: why packet loss increase with the number of retransmissions?
Received: by 10.52.95.110 with SMTP id dj14mr11113993vdb.8.1329959802394;
Wed, 22 Feb 2012 17:16:42 -0800 (PST)
Received: by 10.220.208.90 with SMTP id gb26ls1247268vcb.4.gmail; Wed, 22 Feb
2012 17:16:39 -0800 (PST)
Received: by 10.52.74.4 with SMTP id p4mr3553335vdv.15.1329959799153; Wed, 22
Feb 2012 17:16:39 -0800 (PST)
Authentication-Results: ls.google.com; spf=pass (google.com: domain of
barze...@gmail.com designates internal as permitted sender)
Received: by t30g2000vbx.googlegroups.com with HTTP; Wed, 22 Feb 2012 17:16:39
Date: Wed, 22 Feb 2012 17:16:39 -0800 (PST)
X-HTTP-UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.11
(KHTML, like Gecko) Chrome/17.0.963.56 Safari/535.11,gzip(gfe)
Subject: Re: Mixim and 802.15.4: why packet loss increase with the number of retransmissions?
From: cirom <barze...@gmail.com>
To: omnetpp <email@example.com>
Content-Type: text/plain; charset=UTF-8
Maybe I found the solution to the problem but I would like a
To apply an interference-type Log Normal Shadowing I put in the file
config.xml only model LogNormalShadowing. I do it?
Or I have to put in the file config.xml the two models
LogNormalShadowing and SimplePathlossModel together?
Also what values =E2=80=8B=E2=80=8BI set to do a simulation near to reality=
Thank you so much.
On 22 Feb, 16:00, cirom <barze...@gmail.com> wrote:
> Can anyone help me?
> On 21 Feb, 13:46, cirom <barze...@gmail.com> wrote:
> > Sorry, you're right I'm wrong. Dropped packets are right.
> > I have experienced that increasing maximum number of transmissions,
> > the packet loss(calculated as (1-AckRecieved/TotalPackeSent))
> > increases too. Becasue for instance: taken the case of simulations
> > with maximum number of transmission equal to 10, the numer of ack
> > received is less than the case with maximum numer of transmission
> > equal to 1. Which could be the bug? I cannot figure it out
> > Thank you.
> > On 21 Feb, 12:02, Laura Marie Feeney <lmfee...@sics.se> wrote:
> > > It should never be the case that a frame is dropped before it reaches
> > > the maximum number of retransmissions, regardless of the buffer size.
> > > Once a frame is the head-of-line frame, it should run to completion
> > > (either success or failure).
> > > What output do you see that makes you think that frames are dropped
> > > without being correctly retransmitted?
> > > Laura
> > > On 02/21/12 11:45, cirom wrote:
> > > > Thank you for reply.
> > > > To increase the MAC buffer size does not fix the problem.
> > > > The strange thing is that I get the expected behavior only with
> > > > standard deviation is between 35dB and 45dB ( which in reality are
> > > > values too high).
> > > > What other parameter can i go to change to achieve the best results=
> > > > And maybe a problem of synchronization between the nodes? It often
> > > > happens that the files are dropped before they reach maximum number=
> > > > retransmission.
> > > > Thank you.
> > > > On 21 Feb, 06:58, Michael<michael.lin...@informatik.tu-chemnitz.de>
> > > > wrote:
> > > >> The mac for the Ieee802154Narrow example is CSMA802154 (src/module=
> > > >> mac/CSMA802154.ned) which extends csma-mac (src/modules/mac/csma.n=
> > > >> here is the queue length variable defined:
> > > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0double queueLength =3D default(1=
> > > >> In the omnetpp.ini of Ieee802154Narrow example you find multiple
> > > >> configurations where this variable is set:
> > > >> **.mac.queueLength =3D 100
> > > >> Hope this helps ;)