[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ns] Link delay, what is it?



Debojyoti Dutta wrote:

> When you set the link delay you set the propagation delay. The
> transmission delay is given by 1/BW and the queuing delay depends on the
> buffer capacity, average queue length and the queueing discipline.
>
> For longer packets, delay will be longer.
>
> Hope this helps
> Debo
>

Thank you very much for your answer.

Propogarion Delay = Distance / (3*10^8 km/s)
As I said, this can be negligible for most cases.

But when I mentioned "processing time" I meant processing time at the
physical layer (not queuing delay), i.e the time transmiter and receiver take
to process the signal at physical layer which may involve Segmentation and
Reassembly, FEC ...  until it can pass the data on to the network layer. This
is a more significant delay than the Propogation Delay.

And I think , this delay is variable with the packet size.  For instance,
FEC requires more time to encode and decode longer packets. The same thing
applies for SAR . And as a result, modeling a fixed link delay does not make
much sense.

Does NS simulate this delay?

Do you have any comments?


>
> On Thu, 7 Jun 2001, Huan Pham wrote:
>
> >
> > Hi NS users,
> >
> > My understand is that the Delay of a packet over a link consists of 4
> > elements:
> >
> > 1 - Queueing Delay
> > 2 - Processing Delay
> > 3 - Propogation Delay (negligible for most scenario, excluding satelite)
> >
> > 4 - Transmission Delay (= packetSize / Bandwidth)
> >
> > My question is, in NS, when we set a delay for a link, what delay we
> > mean here. Of course it not the queueing delay, transmission delay. So I
> > believe it must be a sum of the processing delay and the propogation
> > delay. IS THAT CORRECT? If so, is that value the same for all packets
> > regardless of their packet sizes? It's questionable, as I believe longer
> > packets may require more processing time.
> >
> > Thanks for your reply.
> >
> >