Bug 912 - modeling processing delays
modeling processing delays
Status: PATCH WANTED
Product: ns-3
Classification: Unclassified
Component: wifi
unspecified
All All
: P5 enhancement
Assigned To: ns-bugs
: feature-request
Depends on:
Blocks: 977
  Show dependency treegraph
 
Reported: 2010-05-14 11:29 UTC by Nicola Baldo
Modified: 2016-04-07 15:09 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nicola Baldo 2010-05-14 11:29:13 UTC
This enhancement request originated during the discussion of bug 737. Here is the relevant part of the discussion:

Pavel wrote:
...none of our models really account for processing delays and all re-transmissions (say forwarding RREQ in AODV) occur simultaneously. Large number of exactly simultaneous transmissions leads to significantly overestimated collision probability and even to wrong protocol operation. Recent example of this behavior was reported to me recently by Kuba Wierusz.

Mathieu wrote:
It seems to me that the problem is not that we need to model processing delays:
we need to model non-deterministic _varying_ processing delays which change
from one station to another, and, potentially, from one packet to another
within the same station, right ? If so, I would support adding a delay in
MacLow when we receive a packet before forwarding it to the upper layers and
making that delay be picked from a RandomVariable with a default value of being
a gaussian distribution centered around 10us with a non-zero value for the
variance. I will ask a collegue what a decent value would be for the
mean/variance to model some PC-class hardware.

Pavel wrote:
Sure you are right that good solution is to start account for processing
delays. But I am very uncomfortable with all ad-hoc solutions in this field.
Why 10 us? Why gaussian (saying nothing about negative delays)? Why "some
PC-class"? Why at wifi/mac-low? What about Ethernet, wimax, and all future
models? 

Mathieu wrote:
Oops, I removed the relevant part from my initial comment: that delay would
model the interrupt latency between the MacLow and the higher-level layers
which is something on the order of 10us on PC-style hardware with a nice RTOS
(and closer to something like 10ms with a standard linux OS but with a very
high variance). And, of course, you need to make that delay non-negative but
that is a detail.

Pavel wrote:
After some thoughts I definitely agree on adding an (adjustable) interrupt
latency with some meaningful default numbers to wifi low mac.
Comment 1 Nicola Baldo 2015-04-01 10:00:12 UTC
*** Bug 1605 has been marked as a duplicate of this bug. ***