[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [ns] issues on ErrorModel AGAIN!
I am not sure why the code for inserting random delay after dropping a packet
is there. But it turns out that the test suites for executing that code are
three, test-suite-session.tcl, test-suite-mixmode.tcl, and test-suite-srm.tcl.
And they want to call the queue resume function after some random delay
whose average is the transmission delay after dropping some specified
packets. In these three test scenario files, they set the packet type to
drop by using the command "drop-packet" when they set the drop-target
with the null agent. I guess that this code is just for their experiments. I
am not sure why. Is there anybody who knows why??
But normally when packets are delivered over target which is a neigbor
after the error module decides whether or not the packets will have errors.
So, other test suites are not affected by this code at all.
-jahn
> -----Original Message-----
> From: Hong Bin Liao [mailto:hbl@msrchina.research.microsoft.com]
> Sent: Wednesday, July 11, 2001 10:22 AM
> To: jahn-isi
> Cc: NS-2, USERS (E-mail)
> Subject: RE: [ns] issues on ErrorModel AGAIN!
>
>
> Hi,
> Sorry if the problem I stated is not so clear.
>
> the queue in ns-2 is resumed after a packet is transmitted, i.e.
> after txtime() in delay.h (8. * hdr_cmn::access(p)->size() /
> bandwidth_). However, after an error model is inserted before the link
> module, it will drop packet after detecting it is corrupted. Then, the
> error module try to schedule the handler to resume the queue after
> Random::uniform(8.0 * ch->size() / bandwidth_) seconds, that means a
> corrupted packet will trigger the queue resume handler earlier than a
> correct packet. In the other word, a corrupted packet will take less
> bandwidth than a correct packet.
>
> Hongbin
> 07/11/2001
>
> > -----Original Message-----
> > From: jahn-isi [mailto:jahn@ISI.EDU]
> > Sent: Wednesday, July 11, 2001 1:48 AM
> > To: Hong Bin Liao
> > Subject: RE: [ns] issues on ErrorModel AGAIN!
> >
> >
> > I am not sure that I can understand your stated problem.
> > -jahn
> >
> > -----Original Message-----
> > From: Hong Bin Liao [mailto:hbl@msrchina.research.microsoft.com]
> > Sent: Tuesday, July 10, 2001 11:53 AM
> > To: jahn-isi
> > Cc: NS-2, USERS (E-mail)
> > Subject: RE: [ns] issues on ErrorModel AGAIN!
> >
> >
> > In the NS-2 implementation, error model is insert before the queue
> > module or the link module. For the insertion before the link
> > module, if
> > a corrupted packet is immediately dropped and the resume
> > handler of this
> > packet are invoked after a random period between 0 to (PacketSize/BW).
> > This means a corrupted packet consumes less bandwidth than a correct
> > packet. There is also another fatal issue for time continuous error
> > model, since a corrupted packet takes less flight time than a correct
> > packet, it cause more burst error than error model with bit, byte, etc
> > as the error unit.
> >
> > -hongbin
> >
> > > -----Original Message-----
> > > From: jahn-isi [mailto:jahn@ISI.EDU]
> > > Sent: Saturday, July 07, 2001 5:21 AM
> > > To: Hong Bin Liao
> > > Cc: ns-users@ISI.EDU
> > > Subject: RE: [ns] issues on ErrorModel AGAIN!
> > >
> > >
> > > I am not sure why there is a delay before notifying the packet
> > > corruption to the module called the error model.
> > >
> > > But, corrupted packets are immediately sent to the specified target
> > > (which is a neigbor node's link layer or the next low layer
> > > in wireless networks)
> > > without any delay after scheduing the notification event
> > > with some arbitrary
> > > delay.
> > >
> > > You can see this flow by using a gdb debugger.
> > > -jahn
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: owner-ns-users@ISI.EDU
> > > [mailto:owner-ns-users@ISI.EDU]On Behalf Of Hong Bin Liao
> > > Sent: Friday, July 06, 2001 6:01 PM
> > > To: NS-2, USERS (E-mail)
> > > Subject: [ns] issues on ErrorModel AGAIN!
> > >
> > >
> > > Hi, Folks
> > > I sent the following letter several days before. I got no answer
> > > for it. IMHO, it's very fatal issue on the correctness of
> > model of the
> > > systems. Could anyone give me answer of it?
> > >
> > > Hi, folks
> > > after reading the source code of errmodel.cc, I wonder why the
> > > resume handler should be delayed for a random period between 0 to
> > > (PacketSize/BW). why not this packet with error is delayed
> > > for a period
> > > (PacketSize/BW)?
> > > The former cause more burst error when error unit is bit, byte
> > > or time (in two/multi state error model).
> > >
> > >
> > > HongBin L.
> > > 07/06/2001
> > >
> > >
> >
>