Bugzilla – Bug 912
modeling processing delays
Last modified: 2016-04-07 15:09:44 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.
*** Bug 1605 has been marked as a duplicate of this bug. ***