Return to Summer Projects page.
- 1 Project overview
- 2 Approach
- 3 Deliverables
- 4 Weekly Reports
- 4.1 Community Bonding Period (July 3-July 16)
- 4.2 Week 1 (July 17-July 23)
- 4.3 Week 2 (June 24-July 30)
- 4.4 Week 3 (July 31-August 6)
- 4.5 Week 4 (August 7-August 13)
- 4.6 Week 5 (August 14-August 20)
- 4.7 Week 6 (August 21-August 27)
- 4.8 Week 7 (August 28-September 3)
- 4.9 Wrapping Up (September 4-September 24)
- Project name: High Performance Emulation of Real Devices in ns-3
- Student: Pasquale Imputato
- Mentor: Tommaso Pecorella
- Abstract: The goal of the project is the improvement of the emulation performance of the simulator. The project introduces a device in ns-3 that uses the netmap primitives to process the incoming and outgoing traffic. netmap is a fast packets processing that bypasses the host networking stack and gains direct access to network device. Also, the project introduces a flow control mechanism between the traffic control of ns-3 and the device ring. Finally, the project introduces a performance evaluation of the introduced device in ns-3 in emulation scenarios on real device. The project enables a more accurate evaluation of high level protocols, e.g., Deley Tolerant Networking protocols (DTN), and of the scheduling algorithms in emulated scenarios.
- Documentation: https://github.com/pasquimp/ns-3-dev-git/wiki
- About me: I am a PhD student in Information Technology and Electrical Engineering at University of Naples Federico II
In the first step, the project introduces netmap in ns-3 to gain direct access to network device. netmap allows to bypass the host networking stack and to map the device memory in user space area. This step includes the integration of the netmap headers in ns-3 and the introduction of a new device, i.e., NetmapNetDevice, in the fd-net-device module. Also, the emu-fd-net-device-helper will be extended with the introduction of a new function to set the emulation in netmap mode. This step includes functional testing of the new device by ping a real host connected back-to-back through ethernet.
In the second step, the project introduces a realistic flow control mechanism between the traffic control of ns-3 and the real device ring. Also, the project will introduce support for Byte Queue Limit (BQL) in the new device. The flow control and BQL will be fundamental to keep a backlog in traffic-control where we will evaluate the presence of backlog and the effectiveness of the Active Queue Management algorithms as consequence of the presence of such mechanisms. The support for flow control and BQL will be tested by ping a real host connected back-to-back through ethernet and with presence of traffic load (to saturate the transmission ring capacity).
In the final step, the project will introduce further optimization to gain the performance improvement on real device emulation scenarios. The performance bottleneck will be evaluated with profiler and we expect to improve the incoming phase, e.g., by removing the dynamic memory allocation, and the outgoing phase, e.g., with the transfer of batch of packets to the new device. The final step perform a benchmark of the new device by comparison of the new device with the FdNetDevice in emulation mode in a back-to-back through ethernet scenario of two ns-3 nodes.
By the end of the project, the following will be delivered to the ns-3 fd-net-device module
- the NetmapNetDevice to send and receive packet using the netmap primitives on an emulated real device and its support for flow control and BQL
- EmuFdNetDeviceHelper extension to provide helper functions useful to set the netmap emulation mode
- functional testing of the new device by ping a real host connected back-to-back through ethernet with or without presence of traffic load
- benchmark of the new device: comparison of the new device with the FdNetDevice in standard emulation mode in a real scenario of back-to-back through ethernet of two ns-3 nodes; performance evaluation in term of throughput, rtt, qdisc backlog and dropping.
Due to the short timespan of SOCIS 2017, there will be a single deliverable at the end of the project. However, the developed code and documentation is available at https://github.com/pasquimp/ns-3-dev-git/commits/socis. Anyone is encouraged to comment the code and leave feedbacks.
Finally, to improve the organization of the coding period it has been divided in three phases. Each phase includes test, documentation and gathering of comments from the community. The milestones expected at the end of each phase are
- netmap integration into ns-3
- new device and its helper that uses netmap primitives
- functional testing with the ping example of a real host connected back-to-back through ethernet
- support for flow control and BQL
- functional testing with a ping example with presence of UDP traffic load
- introduction of a example to assess the performance parameters in a back-to-back through ethernet scenario of two ns-3 nodes with UDP and TCP traffic load
- further optimizations
- benchmark of the new device with the introduced example, i.e., comparison of the performance parameters of the new device and the FdNetDevice in emulation mode in a back-to-back through ethernet scenarios of two ns-3 nodes
- refinement of the whole project
Below the detailed report of the activity
Community Bonding Period (July 3-July 16)
During the community bonding period, I communicated with the mentor to refine the project and its schedule. Also, during this period I improved my knowledge of the fd-net-device module and of netmap.
Week 1 (July 17-July 23)
During the first week, I have implemented the extensions in the fd-net-device module and its helpers to support the netmap emulation mode. More specifically, I have
- inserted the check for the netmap installation in the fd-net-device module wscript;
- implemented the requested changes in the FdNetDevice to support its specializations;
- introduced the new device as derived class of the FdNetDevice class;
- introduced an helper function in the EmuFdNetDeviceHelper to set the netmap emulation mode;
- implemented an extension of the raw socket creator to open a netmap fd.
Week 2 (June 24-July 30)
I started the implementation of the methods of the new device. I have
- implemented the method to switch the emulated interface in netmap mode;
- implemented a write method to copy a packet in the netmap transmission ring;
- introduced an example to ping a real host through a real interface in netmap emulated mode.
Week 3 (July 31-August 6)
I implemented the read method of the new device and tested the new device in a back-to-back through ethernet scenario with the introduced ping-example. More specifically, I have
- implemented the read method of the new device;
- tested the new device in a back-to-back through ethernet with the ping example;
- added traffic load to the ping example to support future test;
- provided an initial version of a wiki on how to install netmap and how to use the netmap emulation features in ns-3.
Week 4 (August 7-August 13)
I started the implementation of the flow control support of the new device. I have
- introduced the support for flow control in the new device;
- extended the ping example to support the sampling of the backlog in the queue disc of the ns-3 traffic-control;
- performed a test of the flow control (with the ping example on 100 Mbps back-to-back ethernet) and observed the presence of backlog in the queue disc.
Week 5 (August 14-August 20)
I worked on support for flow control and BQL. More specifically, I
- refined the support for flow control in the new device;
- introduced the support for BQL in the new device;
- introduced a function to read the bytes inflight in the netmap tx ring;
- extended the ping example to support the sampling of the inflight in the tx ring of the new device;
- added a page on the github wiki about the device test.
Week 6 (August 21-August 27)
I worked on the benchmark example and on the BQL support. More specifically, I
- refined the BQL support and the ping example;
- performed other tests on flow control and BQL;
- introduced the benchmark example.
Week 7 (August 28-September 3)
I worked on device optimization and device documentation. I
- optimized the support for multiple receiver rings and implemented a periodic sync of the netmap transmission ring;
- performed a benchmark of the new device with the fd-net-device in emulated mode on a back-to-back ethernet link (by using the fd-netmap-emu-onoff example);
- performed operf profiling client side and server side of the fd-netmap-emu-onoff example with UDP and TCP traffic;
- improved device documentation;
Wrapping Up (September 4-September 24)
During the wrap-up period, I worked to improve the examples, the documentation and the evaluation of the new device. I
- introduced an example to evaluate the maximum transmission rate in pps achievable with the new device at lowest layer
- improved the netmap examples
- improved the documentation of the new device; I added a new section about the evaluation of the device in term of maximum transmission rate in pps.
The pps achievable with the NetmapNetDevice at lowest layer (i.e., the write method) was up to 1.38 Mpps on the e1000e adapter on the i7 cpu at full frequency of 3.8 GHZ. This value is according to netmap results on the Intel e1000e 1 Gbps adapter available in the netmap documentation. The pps provided by socket is in line to the netmap one on this testbed.
We explored the reduction of the cpu frequency to better present the gain provided by netmap on 1 Gbps link. With cpu frequency of 2.5 GHz (set with cpufrequtil) we observed a gain in the pps with netmap of about 10% (netmap achieves 1.38 Mpps while the socket achieves 1.25 Mpps). A further reduction to 2 GHz leads to a gain of about 30 % with netmap (netmap achieves 1.38 Mpps while the socket achieves 1.01 Mpps). These gains (with reduced cpu frequecny and netmap) are partly available in term of received throghput at higher layers (e.g., I evaluated at 2 GHz the received UDP throughput with “fd-netmap-emu-onoff” example of about 700 Mbps for the netmap case and of about 600 Mbps for the socket case).
Some conclusive device notes. The netmap device reproduces in a more realistic manner the outgoing and incoming networking path (thanks to bypass of the host networking stack) and improves the credibility of the network emulation in ns-3. The netmap device allows keeping a backlog in the ns-3 traffic-control (thanks to the flow control and BQL support) where the user can more accurately evaluate the effectiveness of the AQM algorithms. Also, the latency with the netmap device is more realistic (thanks to more realistic queues size). Finally, netmap provides a more efficient ratio in term of pps per cpu frequency and allows a throughput gain also in case of reduced cpu frequecy.
The final codereview is available at https://codereview.appspot.com/330220043/ while the github repository is at https://github.com/pasquimp/ns-3-dev-git/commits/socis