Bugzilla – Bug 2987
Invoking of Switch to OFF events, which should actually be canceled in WifiRadioEnergyModel
Last modified: 2018-11-11 09:37:05 EST
Created attachment 3176 [details]
This function calculates for how long device can stay in the new state (such as TX) and schedules new event to switch it off. Previous event is cancelled, but it remains in memory.
As a result, it creates a lot of events and can easily consume gigabytes of memory even for small Wi-Fi networks.
The solution is to call Remove instead of Cancel, even though it may consume more CPU time (and it will probably consume *less* because insertion of new events and rebalancing the tree is faster when the tree is smaller).
It may be worth trying to add less events, for example not scheduling at the beginning of TX if it is known that there is enough energy to finish transmission, but that requires more complex interactions between PHY and energy model.
Proposed patch is attached.
Hi Alexander, I am not sure this is really a Wi-Fi bug, since you are mainly touching the eventid class.
I have added ::Remove to EventId, but call it from WifiRadioEnergyModel::HandleEnergyChanged
Yes, but maybe this would need to be called at other places. You can also split your patch, and add dependency in Bugzilla.
In the WifiRadioEnergyModel class, a private member variable called m_switchToOffEvent is defined that stores the state change to OFF event after the maximum time that the radio can stay in the new state based on its remaining energy.
It is clear that with any change, the previous event stored in the variable must be canceled and the new event calculated based on the new state is to be replaced.
The main problem is that the previous event stored in the variable is invoked despite canceling. (The process of canceling an event appears to work properly but not in the backend)
The invoking of those events, which should actually be canceled, has very significant consequences, such as inaccurate calculation of total energy consumption and remaining energy, because, regardless of the network conditions, the very first change of status, which is the change of state from IDLE to TX, leads to early OFF. It's like every device stays in the TX state after its first change until it turns off.
There are other consequences that need not be mentioned.
So the main problem before the energy consumption of the events that remain in memory is the invoking of events that must actually be canceled and it should be noted that as I said, the process of canceling and removing of the event appears to work properly, that is, by writing the Remove function for the EvendId class (which in fact does not need to be written, because Simulator::Remove (const EventId & id) do the same) the problem is not resolved. (Has been tested)
These problems are clear by tracing and testing the wifi-sleep example.