Bugzilla – Bug 912
modeling processing delays
Last modified: 2016-04-07 15:09:44 EDT
This enhancement request originated during the discussion of bug 737. Here is the relevant part of the discussion:
...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.
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.
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
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.
After some thoughts I definitely agree on adding an (adjustable) interrupt
latency with some meaningful default numbers to wifi low mac.
*** Bug 1605 has been marked as a duplicate of this bug. ***