Re: Queuing Delay in ns?

[Bin Mo <mob@cs.rpi.edu>]

Hi, Kai:

If you read delay.h, you'll find txtime() compute transmit time according
to packet size and bandwidth.

The LinkDelay schedule the QueueHandler to resume queue after the
txtime(), and this implements the queue delay.

Bin


On Wed, 1 Dec 1999, K Sun wrote:

> Hello,
>     After I read something about Delay Link and queue, I find there is 
> almost no queue delay in ns.
> I suspect it is really in accordance with the real situaiton. However, 
> first, I am not sure of my understanding here.
> 
>     I feel the block state on queue is very good. However, I could not 
> find its real effect. Normally, we just use "Delay Link" as the link 
> type. If so, there 
> ...
> 		p = deque();
> 		if (p != 0) {
> 			blocked_ = 1;     
> 
> /* HERE the queue is in blocked state */
> 
> 			target_->recv(p, &qh_);
> 		}
> ...
> 
> 
> However target_->recv(p, &qh_) is call the function below at once.
> target_ is just LinkDelay!
> 
> void LinkDelay::recv(Packet* p, Handler* h)
> {
> 	double txt = txtime(p);
> 	Scheduler& s = Scheduler::instance();
> 	if (dynamic_) {
> 		Event* e = (Event*)p;
> 		e->time_= txt + delay_;
> 		itq_->enque(p); // for convinience, use a queue to store packets in transit
> 		s.schedule(this, p, txt + delay_);
> 	} else {
> 		s.schedule(target_, p, txt + delay_);
> 	}
> 	s.schedule(h, &intr_, txt); 
> 
> /* HERE the queue is unblocked */
> 
> So, the period of the queue delay should be just the period that 
> computer completes several commands. So, in my trace file, it looks all 
> packets enque and deque at the "same" time. Sometime, I hope there 
> is some queuing delay that really exists in the real network.
> 
> I think it should be not like the real situation. At least, in real 
> situation, queue delay should has something to do with the packet size.
> 
> I am not sure of what I think. 
> 
> I hope more comments and instruction about queuing delay in ns.
> 
> thanks in advance!
> 
> Sun Kai 
> 
>