MiXiM Heap Problem in RadioStateAnalogueModel?
Patrick Wenz
I am currently working on my thesis about Pocket Switched Networking
using OMNet++ and the MiXiM framework (omnetpp-4.1b2 and MiXiM 1.1). I
decided not to implement a transport protocol but to directly send
messages whenever nodes do encounter. All my models are based on the
BaseNetwork example that comes with MiXiM. To deliver a large amount
of messages in a short time i increased the MAC bitrate to about 1TB/s
and decreased my message size to about 50b. (Worst case was 300msgs at
a time.) This was necessary because of my mobility simulation
granularity with an update time of 0.5s which causes a lot of
simulation based connect/disconnect events and thus short node contact
times. My simulation was supposed to just push messages over the ether
once two nodes encounter, MAC layer and Phy Layer are out of scope yet
the simulations is supposed to be extensible and usable in later
works.
The Problem: Running with about 100 mobile nodes and some
infrastructure my simulation kept allocating memory until it ran out
of memory. I stopped it at about 13G of RAM. First i thought i did not
clean up correctly but profiling with valgrind and memcheck revealed
that i neither forgot messages nor was there a leak at the end of the
run. I then checked the simulation using valgrinds massif heap
profiler (with stack profiling activated) which revealed that the
problem wasn't _directly_ related to my doings. Deep down in an
untouched dungeon of code the Phy layer kept writing RSAM receive
entries which grew and grew. I append the peak for detailed
information and call stack.
My question: Why does this memory accumulate? Isn't it supposed the be
cleaned up by the PhyUtils' cleanUpUntil function? My current solution
to the problem is a seperate NIC model which excludes the MAC layer
and just directly access the channel using a mutilated Phy layer.
Works fine for me (37M avg on x86 and 47M avg on amd64 per run) as
these are out of scope anyway but what about reusability?
This is the peak massif result of a shorter run of my sim on amd64:
--------------------------------------------------------------------------------
n time(i) total(B) useful-heap(B) extra-heap(B)
stacks(B)
--------------------------------------------------------------------------------
48 5,626,509,396,045 3,366,362,712 2,353,229,232
1,013,130,776 2,704
69.90% (2,353,229,232B) (heap allocation functions) malloc/new/new[],
--alloc-fns, etc.
->68.70% (2,312,545,040B) 0x4EFAFB1:
__gnu_cxx::new_allocator<std::_List_node<RadioStateAnalogueModel::ListEntry>
>::allocate(unsigned long, void const*) (new_allocator.h:89)
| ->68.70% (2,312,545,040B) 0x4EFA2F0:
std::_List_base<RadioStateAnalogueModel::ListEntry,
std::allocator<RadioStateAnalogueModel::ListEntry> >::_M_get_node()
(stl_list.h:316)
| ->68.70% (2,312,545,040B) 0x4EF8F45:
std::list<RadioStateAnalogueModel::ListEntry,
std::allocator<RadioStateAnalogueModel::ListEntry>
>::_M_create_node(RadioStateAnalogueModel::ListEntry const&)
(stl_list.h:461)
| ->68.70% (2,312,545,040B) 0x4EF7A9D:
std::list<RadioStateAnalogueModel::ListEntry,
std::allocator<RadioStateAnalogueModel::ListEntry>
>::_M_insert(std::_List_iterator<RadioStateAnalogueModel::ListEntry>,
RadioStateAnalogueModel::ListEntry const&) (stl_list.h:1407)
| ->68.70% (2,312,545,040B) 0x4EF64B8:
std::list<RadioStateAnalogueModel::ListEntry,
std::allocator<RadioStateAnalogueModel::ListEntry>
>::push_back(RadioStateAnalogueModel::ListEntry const&) (stl_list.h:
920)
| ->68.70% (2,312,533,040B) 0x4EF53A0:
RadioStateAnalogueModel::writeRecvEntry(SimTime, double) (PhyUtils.h:
211)
| | ->68.70% (2,312,533,040B) 0x4EF5B01:
Radio::makeRSAMEntry(SimTime, int) (PhyUtils.h:463)
| | ->34.35% (1,156,266,520B) 0x4EF5843:
Radio::switchTo(int, SimTime) (PhyUtils.h:374)
| | | ->34.35% (1,156,266,520B) 0x4EF3D11:
BasePhyLayer::setRadioState(int) (BasePhyLayer.cc:671)
| | | ->17.17% (578,133,480B) 0x52005EC:
CSMAMacLayer::handleSelfMsg(cMessage*) (CSMAMacLayer.cc:166)
| | | | ->17.17% (578,133,480B) 0x4EEF32A:
BaseLayer::handleMessage(cMessage*) (BaseLayer.cc:76)
| | | | ->17.17% (578,133,480B) 0x5AC12F5:
cSimulation::doOneEvent(cSimpleModule*) (csimulation.cc:632)
| | | | ->17.17% (578,133,480B) 0x547E7E5:
Cmdenv::simulate() (cmdenv.cc:405)
| | | | ->17.17% (578,133,480B) 0x547E1C0:
Cmdenv::run() (cmdenv.cc:274)
| | | | ->17.17% (578,133,480B) 0x56EDE62:
EnvirBase::run(int, char**, cConfiguration*) (envirbase.cc:230)
| | | | ->17.17% (578,133,480B) 0x56EA87C:
setupUserInterface(int, char**) (startup.cc:234)
| | | | ->17.17% (578,133,480B) 0x56EB869:
main (main.cc:39)
| | | |
| | | ->17.17% (578,133,040B) 0x5200889:
CSMAMacLayer::handleLowerControl(cMessage*) (CSMAMacLayer.cc:211)
| | | ->17.17% (578,133,040B) 0x4EEF44D:
BaseLayer::handleMessage(cMessage*) (BaseLayer.cc:85)
| | | ->17.17% (578,133,040B) 0x5AC12F5:
cSimulation::doOneEvent(cSimpleModule*) (csimulation.cc:632)
| | | ->17.17% (578,133,040B) 0x547E7E5:
Cmdenv::simulate() (cmdenv.cc:405)
| | | ->17.17% (578,133,040B) 0x547E1C0:
Cmdenv::run() (cmdenv.cc:274)
| | | ->17.17% (578,133,040B) 0x56EDE62:
EnvirBase::run(int, char**, cConfiguration*) (envirbase.cc:230)
| | | ->17.17% (578,133,040B) 0x56EA87C:
setupUserInterface(int, char**) (startup.cc:234)
| | | ->17.17% (578,133,040B) 0x56EB869:
main (main.cc:39)
| | |
| | ->34.35% (1,156,266,520B) 0x4EF5A47:
Radio::endSwitch(SimTime) (PhyUtils.h:431)
| | ->34.35% (1,156,266,520B) 0x4EF3BD7:
BasePhyLayer::finishRadioSwitching() (BasePhyLayer.cc:659)
| | ->34.35% (1,156,266,520B) 0x4EF3D70:
BasePhyLayer::setRadioState(int) (BasePhyLayer.cc:682)
| | ->17.17% (578,133,480B) 0x52005EC:
CSMAMacLayer::handleSelfMsg(cMessage*) (CSMAMacLayer.cc:166)
| | | ->17.17% (578,133,480B) 0x4EEF32A:
BaseLayer::handleMessage(cMessage*) (BaseLayer.cc:76)
| | | ->17.17% (578,133,480B) 0x5AC12F5:
cSimulation::doOneEvent(cSimpleModule*) (csimulation.cc:632)
| | | ->17.17% (578,133,480B) 0x547E7E5:
Cmdenv::simulate() (cmdenv.cc:405)
| | | ->17.17% (578,133,480B) 0x547E1C0:
Cmdenv::run() (cmdenv.cc:274)
| | | ->17.17% (578,133,480B) 0x56EDE62:
EnvirBase::run(int, char**, cConfiguration*) (envirbase.cc:230)
| | | ->17.17% (578,133,480B) 0x56EA87C:
setupUserInterface(int, char**) (startup.cc:234)
| | | ->17.17% (578,133,480B) 0x56EB869:
main (main.cc:39)
| | |
| | ->17.17% (578,133,040B) 0x5200889:
CSMAMacLayer::handleLowerControl(cMessage*) (CSMAMacLayer.cc:211)
| | ->17.17% (578,133,040B) 0x4EEF44D:
BaseLayer::handleMessage(cMessage*) (BaseLayer.cc:85)
| | ->17.17% (578,133,040B) 0x5AC12F5:
cSimulation::doOneEvent(cSimpleModule*) (csimulation.cc:632)
| | ->17.17% (578,133,040B) 0x547E7E5:
Cmdenv::simulate() (cmdenv.cc:405)
| | ->17.17% (578,133,040B) 0x547E1C0:
Cmdenv::run() (cmdenv.cc:274)
| | ->17.17% (578,133,040B) 0x56EDE62:
EnvirBase::run(int, char**, cConfiguration*) (envirbase.cc:230)
| | ->17.17% (578,133,040B) 0x56EA87C:
setupUserInterface(int, char**) (startup.cc:234)
| | ->17.17% (578,133,040B) 0x56EB869:
main (main.cc:39)
| |
| ->00.00% (12,000B) in 1+ places, all below ms_print's
threshold (01.00%)
|
->01.21% (40,684,192B) in 665 places, all below massif's threshold
(01.00%)
Best regards, Patrick.
Karl Wessel
thanks for reporting this! We were able to reproduce it and will take a
look at what caused this.
Thanks,
Karl
Patrick Wenz schrieb:
Karl Wessel
the increase in memory consumptions happened because we call
"cleanupUntil" only at the end of received AirFrames. Therefore if a
host never receives an AirFrame but constantly switches the radio
(because it sends AirFrames) the RSAM history keeps building up and is
never cleaned.
We fixed it in the current version of the repository.
Thanks again for reporting this (especially with the amount of details
you provided).
Regards,
Karl
Karl Wessel schrieb:
Patrick Wenz
Regards, Patrick.
On 18 Mrz., 12:27, Karl Wessel <wessel.k...@googlemail.com> wrote:
> Hi,
>
> the increase in memory consumptions happened because we call
> "cleanupUntil" only at the end of received AirFrames. Therefore if a
> host never receives an AirFrame but constantly switches the radio
> (because it sends AirFrames) the RSAM history keeps building up and is
> never cleaned.
>
> We fixed it in the current version of the repository.
> Thanks again for reporting this (especially with the amount of details
> you provided).
>
> Regards,
> Karl
>
> Karl Wessel schrieb:
>
> > Hi,
>
> > thanks for reporting this! We were able to reproduce it and will take
> > a look at what caused this.
>
> > Thanks,
> > Karl
>
> > Patrick Wenz schrieb:
> >> Hi everyone, this is Patrick from Germany.
>
> >> I am currently working on my thesis about Pocket Switched Networking
> >> using OMNet++ and theMiXiMframework (omnetpp-4.1b2 andMiXiM1.1). I
> >> decided not to implement a transport protocol but to directly send
> >> messages whenever nodes do encounter. All my models are based on the
> >> BaseNetwork example that comes withMiXiM. To deliver a large amount
> >> 69.90% (2,353,229,232B) (heapallocation functions) malloc/new/new[],