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>
--
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.
> 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.
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
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.