Observing dropped packets during simulation

1,112 views
Skip to first unread message

Dorice Diane Ngueguia

unread,
Feb 4, 2010, 6:24:35 AM2/4/10
to ns-3-...@googlegroups.com
Hi,

I my simulation, I would like to observ packet loss due to dropping at the server node. A part from received packets, the ascci trace file shows but packet enqueuing, dequeuing and dropping at the transmission queue. I would like to also see incoming (and not only outgoing)  packets that are dropped when the device can not receive them.

What should I do please.

Tanks

Dorice.

Mathieu Lacage

unread,
Feb 9, 2010, 9:23:12 AM2/9/10
to ns-3-...@googlegroups.com
On Thu, Feb 4, 2010 at 12:24 PM, Dorice Diane Ngueguia
<doric...@gmail.com> wrote:
> I my simulation, I would like to observ packet loss due to dropping at the
> server node. A part from received packets, the ascci trace file shows but
> packet enqueuing, dequeuing and dropping at the transmission queue. I would
> like to also see incoming (and not only outgoing)  packets that are dropped
> when the device can not receive them.

I assume that you are using wifi. If so, you can look at
YansWifiHelper::EnableAscii and modify it to connect to the PhyRxDrop
event source, just like it connects to RxOk.

Mathieu
--
Mathieu Lacage <mathieu...@gmail.com>

Dorice Diane Ngueguia

unread,
Feb 10, 2010, 5:10:58 AM2/10/10
to ns-3-...@googlegroups.com
Tank you for your interest

I am not using wifi, my server is a csma node. So I have add these lines in my CsmaHelper::EnableAscii function :

oss << "/NodeList/" << nodeid << "/DeviceList/" << deviceid << "/$ns3::CsmaNetDevice/PhyRxDrop";
Config::Connect (oss.str (), MakeBoundCallback (&CsmaHelper::AsciiRxDropEvent, &os));

Of course I have written the AsciiRxDropEvent function for the callback

void
CsmaHelper::AsciiRxDropEvent (std::ostream *os, std::string path, Ptr<const Packet> packet)
{
  *os << "d1 " << Simulator::Now ().GetSeconds () << " ";
  *os << path << " " << *packet << std::endl;
}

I don't see "d1" lines in my ascii trace file, thought I am sure packets are being dropped

I have also tried to read the csma-net-device code. It seems to me as if packets dropping events are recorded only when a packet is dropped due to error model or when the device's receive side is disabled. I would like to record packet dropping due to device queue overflow

Are my impressions right ? If so, what should I then do ?

Tank you very much


--
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To post to this group, send email to ns-3-...@googlegroups.com.
To unsubscribe from this group, send email to ns-3-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ns-3-users?hl=en.


Mathieu Lacage

unread,
Feb 10, 2010, 6:35:05 AM2/10/10
to ns-3-...@googlegroups.com
On Wed, Feb 10, 2010 at 11:10 AM, Dorice Diane Ngueguia
<doric...@gmail.com> wrote:

> oss << "/NodeList/" << nodeid << "/DeviceList/" << deviceid <<
> "/$ns3::CsmaNetDevice/PhyRxDrop";
> Config::Connect (oss.str (), MakeBoundCallback
> (&CsmaHelper::AsciiRxDropEvent, &os));
>
> Of course I have written the AsciiRxDropEvent function for the callback
>
> void
> CsmaHelper::AsciiRxDropEvent (std::ostream *os, std::string path, Ptr<const
> Packet> packet)
> {
>   *os << "d1 " << Simulator::Now ().GetSeconds () << " ";
>   *os << path << " " << *packet << std::endl;
> }

the above looks right.

> I don't see "d1" lines in my ascii trace file, thought I am sure packets are
> being dropped
>
> I have also tried to read the csma-net-device code. It seems to me as if
> packets dropping events are recorded only when a packet is dropped due to
> error model or when the device's receive side is disabled. I would like to
> record packet dropping due to device queue overflow

I do not believe that there is a rx device queue in the csma device
so, you can't record these events since they don't exit. You could
record tx queue overflows with MacTxDrop but I guess you already do
this.

Dorice Diane Ngueguia

unread,
Feb 10, 2010, 9:18:12 AM2/10/10
to ns-3-...@googlegroups.com
You are right, there is no rx device queue. My problem is that my server needs some few seconds to handle a received packet, before it can read the next one. I have tried to use a vector to buffer the received packets. The idea is to continue receiving packets and buffering them while the server is busy. When it becomes idle, it then peeks the next buffered packet from the vector and deal with it. This does not work, because execution is sequential. I observ that packets are not being received while the server is busy, and that the server can not work while receiving packets.

I am thinking about adding a rx queue to my csma device, so that packets could be received simultanously as their processing is going on. But I am afraid of the difficulty.

Is it feasible ? Or what do you think of the idea ?

Dorice

cra...@ee.washington.edu

unread,
Feb 10, 2010, 2:33:11 PM2/10/10
to ns-3-...@googlegroups.com
> I would like to record packet dropping due to device queue overflow
>
> Are my impressions right ? If so, what should I then do ?
>
> Tank you very much

In the csma device, the PhyRxDrop trace is hit if 1) the device is not
enabled; 2) the error model suggests to; or 3) there is a CRC error on the
packet.

There is no queue on the receive side of the csma device. The device queue
you see in the code is a transmit queue.

If you want to see packet dropping due to overflows on a receive queue, you
will have to add one.

-- Craig


cra...@ee.washington.edu

unread,
Feb 10, 2010, 2:57:03 PM2/10/10
to ns-3-...@googlegroups.com

Adding a receive queue to the csma device should be easy enough.  Just duplicate the code in the transmit path.

 

The higher level goal of (apparently) simulating a busy server is going to be trickier.  You can probably hack it up fairly easily by adding a couple of csma device function calls (I’m faking being busy – queue packets; and I’m no longer faking being busy – dequeue existing and stop queueing new packets) that your server can make, but it would take more effort to make it work in a way where I wouldn’t be embarrassed to share the code.

 

The bigger question is, “what exactly are you trying to simulate and what relation does your simulation have to any real system”?  I mean, can you draw any valid conclusions about how a real system will behave from your simulation that queues packets in what would be an ISR in a real system.  I have my doubts.

Chris Dennett

unread,
Feb 11, 2010, 9:55:51 AM2/11/10
to ns-3-...@googlegroups.com
Couldn't you intercept transmit events as they are generated,
increment the event execution time if required, and drop events if
they are too late (rather than blocking their addition) as well?

Krishay

unread,
Nov 21, 2017, 12:35:42 AM11/21/17
to ns-3-users
i want drop packets in point to point based on queuesize
please help me
Reply all
Reply to author
Forward
0 new messages