Delay

Asked by Falk on 2010-01-21

Hi,

the available delay evaluation obviously captures the transmission delay. I want to analyse, if certain QoS requirements are fulfilled, so I need the delay of the upper layers (transmission delay + queuing delay) on per packet basis.

The problem is, this seems to collide with the "isAccepting" concept.
So do I have to insert a Queue FU, which stores input time and then evaluate this information on receiver side?
Where is the best place to put that?

Or can anyone think of a more elegant solution?

BR,
Falk

Question information

Language:
English Edit question
Status:
Solved
For:
openWNS WiFiMAC Edit question
Assignee:
No assignee Edit question
Solved by:
Falk
Solved:
2010-01-22
Last query:
2010-01-22
Last reply:
2010-01-22
Sebastian Max (smx-comnets) said : #1

Dear Falk,

> the available delay evaluation obviously captures the transmission
> delay. I want to analyse, if certain QoS requirements are fulfilled,
> so I need the delay of the upper layers (transmission delay + queuing
> delay) on per packet basis.

There are several different delay probes in the WiFiMAC, and also in the
layers above:

* The traffic generator has several probes, among them the
traffic.endToEnd.packet.incoming.delay, which should be exactly what you
need. Try to add the following to your config.py:

from openwns.evaluation import *
sourceName = 'traffic.endToEnd.packet.incoming.delay'
node = openwns.evaluation.createSourceNode(sim, sourceName)
node.appendChildren(PDF(name = sourceName,
                        description = 'end to end packet delay [s]',
                        minXValue = 0.0,
                        maxXValue = maxPacketDelay,
                        resolution = delayResolution))

More can be found in modules/loadgen/constanze/PyConfig/constanze/evaluation

* The wifimac.e2e.packet.incoming.delay measures the e2e delay at the
upper convergence of the wifimac:

sourceName = 'wifimac.e2e.packet.incoming.delay'
node = openwns.evaluation.createSourceNode(sim, sourceName)
node.appendChildren(....) [same as above]

This probe includes the WiFiMAC queing delay as well as the medium
access delay.

If you only need the mean/stddev, it might be good to use "Moments"
sinks instead of "PDF" sinks, these require much less storage. If you
really need reliable PDFs of the delay (i.e. including an error margin),
you should consider using the "DLRE"-sink. (see e.g.
modules/wifimac/PyConfig/wifimac/evaluation/default.py)

BR,
Sebastian

Falk (kingsnoopy) said : #2

Hi,

thanks for the answer. I already found the "e2e.packet.incoming.delay" and the "e2e.packet.outgoing.delay".

I am wondering, why the delay does not increase to infinity when a simulation runs with offered traffic above saturation throughput?

BR,
Falk

Sebastian Max (smx-comnets) said : #3

Hi Falk,

> I am wondering, why the delay does not increase to infinity when a
> simulation runs with offered traffic above saturation throughput?

Because the (incoming-) probe measures the delay only for packets that
have arrived at the destination.

BR,
Sebastian

Mohammad Siddique (mms-hbc) said : #4

Sebastian Max wrote:
> Question #98209 on openWNS WiFiMAC changed:
> https://answers.launchpad.net/openwns-wifimac/+question/98209
>
> Sebastian Max proposed the following answer:
> Hi Falk,
>
>
>>I am wondering, why the delay does not increase to infinity when a
>>simulation runs with offered traffic above saturation throughput?
>
>
> Because the (incoming-) probe measures the delay only for packets that
> have arrived at the destination.
>

And because (i guess) you have WIFIMAC fixed buffer size in the
configuration which limits the queuing delay.

Consider a scenario where you have only one flow (BS->STA) and
saturation traffic. (Access collisions are not there).

You can expect delay per packet increases up to infinity if you have
infinite buffer size and run the simulation for infinite time
(theoretically).

You can play with following two parameters in this case

1. buffer size
2. simulation time

--
Kind regards,
M Siddique

Sebastian Max (smx-comnets) said : #5

>> Because the (incoming-) probe measures the delay only for packets that
>> have arrived at the destination.

> And because (i guess) you have WIFIMAC fixed buffer size in the
> configuration which limits the queuing delay.

Oh, of course, I forgot to mention this. Fixed buffer + saturation
throughput means dropped packets, which will not be counted in the delay
probe. The maximum delay is thus limited to (maximum head of queue
delay) * (queue size in packets).

I think Maciej has implemented an infinite buffer - I don't know if it
is part of the openWNS (yet) and if you really want to use it.

Falk (kingsnoopy) said : #6

Thanks!
I will find the Buffer and generate additional output for the number of packet drops -> another QoS requirement.