Hi, I think that it's a normal behavior. The size of a non-drop queue depends on the minimum observed inter-arrival rate and the serving capabilities of the link layer. In your case, it seems that 200 packets offers enough room/space for your incoming packets, given a saturated server, to avoid any packet loss. If you increase you inter-arrival rate by say increasing the rate_ parameter for a CBR traffic you'll notice that you'll have to further increase the size of your drop-tail queue in order to avoid a drop. Increasing a queue size actually protect the flow's packets but also introduces more delay which is bad for interactive/real-time protocols. Anyway, real-world hardware (routers, LAN cards, etc.) doesn't have infinite buffer space.
Hope it helps, Ilyes Gouta. Ethan Giordano wrote: > This is how I am setting the size of a droptail queue: > > $ns queue-limit $n1 $n2 $X > > I am seeing behavior where for 1 <= $X <= ~180 everything works fine. > > If you push X to say 200, then suddenly there are no more packet drops, > and there always appears to be 183-186 packets in the queue. > > What I am trying to simulate is the rule of thumb buffer sizing which is > 2*BandwidthDelayProduct which for high speed links is on the order of > thousands of packets. > > I've been through queue.cc, queue.h, drop-tail.h and drop-tail.cc and > can't figure out what's going on. > > Any thoughts? > > ~Ethan > >
