Delay

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

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

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

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

>> 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.

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