Dan, There are many factors that may be contributing to the latency spikes you are seeing. Most don't have anything to do with emane and are likely related to your host system. Your avgTimedEventLatencyRatio plot shows average ratios that seem to indicate a possible issue with container scheduling. Typically you would want to see very low averages (close to 0) and very little deviation among nodes. Our goal when configuring an emulation testbed is to configure an environment that allows emulator instances to operate on an over-the-air packet at as close to the same time as possible.
We have spent a fair amount of time tuning our emulation servers (LXC host systems) to achieve that goal. We don't run X on our servers, we disable all unneeded services and we usually assign one or more dedicated cores to each container running emane. The number of cores per container can increase based on whatever else is executing in the container. Some of our large scale network emulations trade fidelity for node count and assign more than one container per dedicated CPU. This type of tuning in not needed by all. It depends are how satisfied you are with the resulting emulation fidelity and whether or not the radio models in use have tight timing constraints. As a first step, if you are generating high traffic loads, you may benefit from trying the emane develop branch. See Pull 34 [1] which added functionality to short circuit timer logic for enforcing transmit data rates. After that I would try assigning a dedicated core to each container. [1] https://github.com/adjacentlink/emane/pull/34 -- Steven Galgano Adjacent Link LLC www.adjacentlink.com On 11/03/2015 11:05 AM, Dan O'Keeffe wrote: > Hey Kaushik, > Thanks for your reply. My emulator deployment is on a single large > machine with 32 cores. I'm running the latest version of CORE/EMANE > (core 4.8, EMANE 0.92). My experiment consists of 25 nodes arranged in a > 5x5 grid, some of which are running java services that communicate with > each other over tcp. There is no mobility. > > Given you think it unlikely the mac protocol is the problem, I guess I > would like to understand if there are any other clues, and in particular > whether my machine is overloaded. I've attached some plots from one of > my experiments showing (i) the 'avgTimedEventLatencyRatio' for each nem, > gathered from emanesh, (ii) the cpu utilization on each core (gathered > using dstat), and (ii) the latencies I see in my experiment. The x-axis > for each shows time in MM:SS. > > I don't see any obvious correlation between spikes in > utilization/avgTimedEventLatencyRatio and spikes in the latency I > observe for my experiment, but given the cpu utilization + > avgTimedEventLatencyRatio plots, would you say my machine is overloaded? > Is there any other emanesh statistic that would be worth plotting (I can > do that quite easily). > > Also, is it normal to see such a variation in avgTimedEventLatencyRatio > for different nodes (e.g. the min is just over 0.5, the max is at around > 2.5). Or does this just depend on how much traffic a particular node > must handle? > > Thanks, > Dan > > >> >> Dan, the CSMA protocol within EMANE for the 80211abg model is a >> behavioral implementation since the actual protocol can not be >> implemented given the timing constraints. >> >> I do not think the high delays are related to the contention window >> implementation. >> >> Providing additional information about your test (emulator deployment, >> traffic load, configuration files, etc.) may provide insight into what >> you are seeing. >> >> >> Kaushik B. Patel >> Adjacent Link LLC >> >> >> On 10/29/2015 11:10 AM, Dan O'Keeffe wrote: >>> Hello, >>> I notice on the EMANE wiki the following statement in regard to EMANE's >>> 802.11 implementation: >>> >>> "The emulation of unicast does not replicate exponential growth of the >>> contention window as a result of detected failures." >>> >>> Could someone elaborate on why this is the case? Is it complex to >>> implement for some reason, or is there some problem with the exponential >>> backoff that leads to poor performance? >>> >>> The reason I ask is that sporadically I see very high delays for >>> individual packets in an experiment I'm running (e.g. 20s), and I'm >>> wondering whether this could be a contributing factor. >>> >>> Thanks, >>> Dan >>> _______________________________________________ >>> emane-users mailing list >>> [email protected] >>> http://pf.itd.nrl.navy.mil/mailman/listinfo/emane-users >>> >> >> >> ------------------------------ >> >> _______________________________________________ >> emane-users mailing list >> [email protected] >> http://pf.itd.nrl.navy.mil/mailman/listinfo/emane-users >> >> >> End of emane-users Digest, Vol 68, Issue 8 >> ****************************************** >> > > > _______________________________________________ > emane-users mailing list > [email protected] > http://pf.itd.nrl.navy.mil/mailman/listinfo/emane-users > _______________________________________________ emane-users mailing list [email protected] http://pf.itd.nrl.navy.mil/mailman/listinfo/emane-users
