# EmuCD: An Emulator for Content Dissemination Protocols in Vehicular Networks
## 5 EmuCD in Action
### Barenetal Performance Results  
Regarding hardware, there are two main factors that have an impact on the number of nodes and protocols running in EmuCD: RAM and CPU. RAM limits how many containers/nodes can be launched, largely independent of their activity (whether they have constant network traffic or not). For example 16 GB of memory may be enough to run 200 nodes with protocol A, but only 100 nodes when using protocol B. This can happen for several reasons, two of them being that A's binary is smaller than B's, or protocol B has a larger memory consumption than protocol A.  
Figure 2: Tools of the emulation platform. CPU, on the other hand, can usually limit the emulation in three ways: (1) usage must be under 100% (ideally under 50%) to assure a valid parallelism between containers (e.g., if there are events and position updates every second, when the CPU is under full load, there is no guarantee that every packet transfer and operation that should be performed within each second, really happened as intended or if the CPU did not have time to do everything in that time span); (2) high network activity causes high CPU usage (a network with 50 nodes transferring data simultaneously between each other may have the same CPU usage as 300 nodes in a sparse scenario); (3) the amount of processing done by the protocol/software before/after sending each chunk/block influences CPU usage (a protocol with a simple logic or algorithm allows for EmuCD to run more nodes than a very complex protocol). Across every test and scenario presented in this document, EmuCD was running in an Ubuntu 18.04 virtual machine (VM), with seven dedicated CPU cores at 4.6 GHz and 27 GB of RAM. This section presents the CPU and RAM usage of the VM while running the emulator (disk usage is not discussed, maximum observed read and write speeds during the stress tests were under 100 MB/s, so this aspect only has an impact if it is an old hard disk drive). Profiling shows the emulator booting the containers and the beginning/end of the tests. The CPU and RAM graphs are not restricted to the emulator and its processes, they are for the entire VM: idling and without an emulation running, CPU averaged 0% across all cores and 1 GB of RAM was in use, so the CPU graphs can be considered to be representative of the emulator and its processes, and in the RAM graphs 1 GB must be subtracted from the memory in use. Starting by analyzing just the emulator, without any protocol running on the containers, Figures 3 and 4 show the CPU and RAM usage of 100 nodes, respectively. Regarding CPU, there was a spike starting at 1:19:50 p.m. until 1:20:20 p.m., which corresponded to the required Docker containers being created and booted (hence the corresponding spike in RAM); the small spike 30 s later was due to the emulation start, also noticed by a slight increase in the RAM used. Because the containers were running \"empty\", there was not any CPU usage until 1:24:20 p.m., when the containers were stopped and removed. Memory usage during this test remained steady at 4 GB, which means that 3 GB were used by the emulator's containers and processes, resulting in an average 30 MB per container. The same test with 200 nodes showed 6 GB used by the emulator's containers and processes. Adding the RAM footprint of the tested protocol/software to these 30 MB yielded the RAM usage per container, which could then be multiplied by the number of nodes to find the required amount of RAM. Figures 5 and 6 show the CPU and RAM usage, respectively, of running 100 nodes with BitTorrent disseminating a 50 MB file during an hour of real VANET data mobility. Starting with the CPU analysis, the first spike at 11:40 a.m. corresponded to the nodes being booted and the emulation starting, whereas the last spike at 12:40 p.m. was the emulation ending and the containers shutting down.