Thanks for the answer.
well, as I said I can print two other values from the drop-tail.cc which are:
q_-length() - it contains the number of packets sitting in a drop-tail queue
qlim_ - a limit of the queue (which can be set in a TCL script)
From these two values I can see that packets start dropping however they
didn't reach the queue-limit and one more packet can be enqueued.
If I change the condition
(q_-length() + 1) = qlim_
to
(q_-length() + 1) qlim_
everything seems to be fine. I was just wondering if is a real bug or my
misunderstanding of ns-2 logic.
Best regards,
Dmitry Sinelnikov
Wednesday, April 16, 2008, 12:23:40 PM, you wrote:
IM try to print this u will be able to see in the aodv.cc code
IM print the variable ifqueue-length()
IM which will tell the number of packets in the droptail queue... hope this is
IM useful for u..
IM Imranullah Mohammed.
IM On Wed, Apr 16, 2008 at 1:20 PM, Дмитрий Синельников [EMAIL PROTECTED]
IM wrote:
Hi All,
Did anyone have a chance to count the number of packets
sitting in a drop-tail queue precisely?
I have the latest ns v.2.33 and faced the following issue:
I was running simple script with the following topology
node - router1 router2 - receiver
where the link type between routers was set to DropTail
and queue limit was set to 16 packets
set rout_link [$ns duplex-link $r1 $r2 $bw_rout $delay_rout
DropTail]
$ns queue-limit $r1 $r2 16
I enabled trace-all' traces and then parsed the output
file with the simple awk script. The idea was to see the
time-dependent built of the bottleneck queue. As a result the
number of packets in a queue never reached its limit of 16 and
packets started dropping when queue built was equal to 15
packets instead of 16 as it should be.
I took a look at the
void DropTail::enque(Packet* p)
function which is implemented in the
\ns-2.33\queue\drop-tail.cc,
file and found that one of the conditions to enable packet drop
mechanism is not quite correct (from my viewpoint):
if ( + (q_-length() + 1) = qlim_ +)
Here q_-length() is the current number of packets sitting
in a queue and qlim_ is a queue-limit (which is 16). This
explains why the packet-drop started at 15 packets: 15 + 1
is equal to 16 thus a packet is dropped. It can be 'cured'
easily by exchanging = with .
Link queue is pretty old and one of the basic features
in ns. So the question is:
Is it a real bug and nobody ever tried to count the number
of packets sitting in a queue precisely or it is kinda
specific logic of ns queue management?
I understand that it is a minor bug but I just wanted to know
someone's opinion concerning this issue.
Best regards,
Dmitry Sinelnikov
--
Best regards,
Дмитрийmailto:[EMAIL PROTECTED]
