[ndnSIM] Memory Usage in ndnSIM and NFD
poschdaniel2 at gmail.com
Mon Feb 23 22:57:15 PST 2015
thank you for the clarification. I will work with smaller Content Stores
to avoid getting into trouble, at least for now.
On 02/23/2015 08:57 PM, Alex Afanasyev wrote:
>> On Feb 23, 2015, at 1:00 AM, Daniel Posch <poschdaniel2 at gmail.com> wrote:
>> I have a question regarding the memory usage in ndnSIM2.0 as I run in to memory troubles with my simulations. Currently I simulate networks with the size of 100-200 nodes per simulation. Using ndnSIM1.0 this was no problem as the payload of Data Packets could be set to "virtual", so just an integer coded the size of the payload. Due the fact that much more memory is required in ndnSIM2.0 and through the connection to the NFD, I assume that the payload is now really stored in the memory? Is this assumption correct? If so, I think this leads to problems simulating larger networks even on very powerful hardware.
>> Could someone explain in detail what "parts" of the Interest/Data packets are really physically stored in memory? How do the new/old Content Store(s) store Data Packets? Is a copy of each packet stored in each Content Store, or is a single copy shared among several Content Stores?
> Hi Daniel,
> Yes, this currently is a limitation of ndnSIM 2.0: data packets carry "real" payload that uses real memory allocation, which could lead to issues with large scenario/large content store sizes. The use of virtual payload in data packets was our goal initially, but we have paused the effort given the complexity involved (unfortunately, NS-3 does not follow STL container/iterator interfaces, which complicates the matter). If you have time, we would really appreciate if you could look into that.
> The primary objective for the 2.0 release was to unify codebase of ndnSIM with the latest developments of real NDN forwarder (NFD), ensure correctness (= same behavior as NFD), and provide base/play ground for forwarding strategy development. We are not there yet, but we also want to enable simulating real applications, not just see behavior of dummy traffic generator (Consumer* and Producer classes). We have not (yet) fully optimized for cache evaluation, we just unfortunately have very limited resources to achieve all the goals.
> As for optimizations. Virtual payload of data packet could be one of these. Sharing the same Ptr<Packet> in caches between simulated nodes is another good avenue for optimizations which can bring benefits for more types of simulations (e.g., virtual payload will not work for simulation of real applications). Some memory and performance gain can also be achieved by utilizing tcmalloc, an alternative memory allocator (http://gperftools.googlecode.com/git/doc/tcmalloc.html).
More information about the ndnSIM