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]
