1550_Accelerating Simulations Using Efficient Modeling Techniques

CONFIDENTIAL RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.

2007 OPNET Technologies, Inc.

Accelerating Simulations UsingEfficient Modeling Techniques

R&D Solutions for Commercialand Defense Networks

Session 1550

CONFIDENTIAL RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.

2010 OPNET Technologies, Inc.

21550 Accelerating Simulations Using Efficient Modeling Techniques

CONFIDENTIAL RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc. 2010 OPNET Technologies, Inc.

Session Goals

Learn the basics of factors affecting efficiency of Modeler simulation through a combination of lectures and labsLearn and practice Modeler efficiency techniques and

methodologies to identify causes of performance problems Topics includezKernel types, compiler settings and other environmental factorsz Efficiency techniquesz Profiling programszGeneral programming practicesz TradeoffszAdvanced efficiency techniques to reduce memoryzOPNET data structures, algorithms and memory APIzWireless modeling efficiency



Agenda

Introductionz Simulation Optimization Goalsz Session organization: from the Simple to the Complex

Environment efficiency: the Low Hanging Fruitz Lab1: Using Development vs. Optimized Kernel Programming Efficiency

z Data Structures & Algorithms Lab2: Routing Protocol Profiling

z Discrete Event Simulation Kernel Efficiencyz Memory Efficiency Lab3: Memory Statistics

Modeling Efficiencyz Trading Accuracy for Speedz Using Global Space and Memory Sharingz Lazy Evaluationz Overloading Information Exchange Lab 4: Operating Protocols Efficiently

Take-Away Points



Simulation Optimization Goals

FasterzReduce wall-clock timez Increase events/secondTighterz Less memoryz Less chance of using swap spacezBetter performance scaling with size of modelCleanerz Easier to maintainValidzModeling results accurate according to assumptionsTime Space / Fidelity Trade-OffszChoose what is more important



Simulation Methodology (from 1572)

Yes

End

Start

Results statistically

useful?

No

NoResults

sufficiently detailed?

Choosing input andrunning simulations

System results accurate?

Defining input and output

Specifying the system model

No

Choosing aspectsto be modeled

Understanding your goals for the

simulation

Understanding the system

Abstraction vs. Fidelity



What Takes Time in aDiscrete Event Simulation?

Model Codez Process modelsz Pipeline stagesz External filesDES Kernel ServiceszKernel Procedures: ima, pk, sar, list,

etc.z Time spent in kernel procedures is

dictated by model codeDES Kernel Enginez Event managementzDispatching interruptszHandling packet send/receiveOperating SystemzMemory paging/swapping

DES Kernel Engine

DES Kernel Services

User Models

OS



Simulation Models

Simulation MethodszDiscrete event simulation (DES) models and engine Hybrid

z Flow Analysis models and engineDES modelszOpen source C/C++ codezDetermine protocol behavior including data + control planezUtilize DES kernel to run simulationszCapture detailed component/network behaviorUnderstand efficient modeling techniques to operate and design DES

protocol models



Optimize Everything!

Efficient environmentEfficient simulation kernelEfficient compilation

Efficient model representation

Efficient configuration of protocols

Efficient codezData structureszAlgorithmsz Efficient Kernel ProcedureszModel design and abstraction

Easy

Difficult



What Gains Should You Expect

Pareto Principle: 80/20 rulez 80% of time/memory/etc. in 20% of codezOptimize most time/memory-consuming code firstGains vary enormously depending on techniquezMost result in small improvement (1-5% overall speed or memory)zA few result in big speed or memory improvement Replace use of inappropriate data structure or algorithm Achievable by trimming unnecessary computations (precision issues)

10



Agenda

Introductionz Simulation Optimization Goalsz Session Organization: from the Simple to the Complex

Environment efficiency: the Low Hanging Fruitz Lab1: Using Development vs. Optimized Kernel Programming Efficiency

z Data Structures & Algorithms Lab2: Routing Protocol Profiling



Take-Away Points

11



Efficient Environment

Faster hardwarezMulti-Core processor machines

More memory: Eliminates swappingLess CPU contentionz Eliminate other activities: No complex screen saverszNo OPNET GUI Run simulation from command-line or OPNET Console

zOr minimal GUI Prevent speed and memory graphs

from being displayed Reduce frequency of

simulation progress updates

12



Efficient Environment:Concurrent Simulations

Modern CPUs have more than one microprocessor corez Execute a simulation run on each corezDistribute simulations runs to different hostsOPNET Preference configuration:zAllow Simulations on Multiple Hosts: TRUEzDistributed Simulation Hosts: ::

Need separate Simulation Run-Time license for each concurrent runz Site Simulation Runtime License covers unlimited number of concurrent runs

13



Efficient Simulation Kernel

Development KernelzModel development/debuggingzOPNET Simulation Debugger (ODB)z Profiling capability in Kernel ProceduresOptimized KernelzNo ODB, tracing, or KP profilingz Typically 50-100% faster than Development KernelzUse for production simulation after developmentParallel KernelzUse only with multi-threaded modelsOPNET Preference kernel_type

14



Efficient Compilation

Use compiler optimizationszConfiguration using OPNET preferences comp_prog selects compiler comp_flags_devel for development kernel comp_flags_optim for optimized kernel

z See Appendix for compiler flags or OPNET FAQsCompile without OPNET function call stack infoz FCS: Error reporting overhead for

quickly debugging problemsz Increases speed by 30-50%z comp_trace_info preferencezDefault is disabled when compiling

for optimized kernel

>* Time: 22:09:29 Thu Aug 10 2007* Product: modeler* Program: op_runsim (Version 14.0.A PL0 Build 6020)* System: Windows NT 5.0 Build 2195* Package: process (mpls_mgr) at module (top.Imported Network.DDORTMCR7302.ip)* Function: mpls_mgr_forward_packet_on_interface ()* Error: program abort Invalid Memory Access

T (100.004), EV (299165), MOD (top.Imported Network.DDORTMCR7302.ip)

* Function call stack: (builds down)------------------------------------------------------------

Call BlockCount Line# Function

------------------------------------------------------------0) 1 152 0x09254d0e [name not available]1) 1 2211 0x00004c00 [name not available]2) 1 1358 0x0000c400 [name not available]3) 1 291 m3_main4) 1 1106 sim_main5) 1 2706 sim_ev_loop6) 186302 501 sim_obj_qps_intrpt7) 53920 14 ip_rte_central_cpu [ip_central_cpu_wait -> check_next]8) 26878 366 ip_rte_central_cpu_send_packet (pkptr)9) 26878 2386 ip_rte_packet_send (module_data_ptr, pkptr, intf_ici_fds)

10) 38923 727 op_pro_invoke (pro_handle, argmem_ptr)11) 202 21 mpls_mgr [wait -> wait : default / mpls_mgr_packet_process]12) 154 1110 mpls_mgr_packet_process ()

15



LAB 1:Simulation Kernel Performance

Assess baseline simulation performanceExplore OPNET development environment configurationCapability of environment + simulation kernel + compilerCompare debug and optimized kernelsRun multiple simulations concurrently

16



LAB 1 Summary:Simulation Kernel Performance

Use Optimized Kernelz 2x speed improvement for simplest simulationzUse unless debugging problemRemove function stack trace information for speedReduce frequency of progress update

17



Agenda


Environment Efficiency: the Low Hanging Fruitz Lab1: Using Development vs. Optimized Kernel

Programming Efficiencyz Data Structures & Algorithms Lab2: Routing Protocol Profiling



Take-Away Points

18



Solve Problems Before Dealing with Efficiency:Code Optimization Methodology

1. Understand the perceived problem2. Define the abstract problem3. Design the solution4. Implement a prototype5. Verify correctness6. Benchmark prototype7. Identify optimization candidate8. Optimize/redesign code

Repeat as necessary

19



Profiling Program Execution

Objective: to shorten execution timeFind hot spots accurately by code instrumentationz Function timing datazNumber of times function calledUse commercially-available softwarez IBM Rational Quantify, compilers profiler (prof, gprof, Microsoft Profiler)OPNET built-in profilerzRelies on FIN/FOUT/FRET macros in user codez PROFILE_SECTION macroszResults not precisebut accurate for finding bottleneckszKernel procedures only profiled if using development kernel Optimized kernel shows only user model functions

zMore details in upcoming labQuestion: how to improve inefficiency uncovered by profiling ?

20



Complexity Analysis

Big-O notationWay to quantify performance and compare different algorithmszO(1) O(log n) O(n) O(n2) O(2n)zWorst-case order of growthzBy inspection of solutionzBasic understanding of problem and solutionzQuick comparison of different approachesExample: What is order of growth of this code?

for (i = 0; i < n; i++) {

if (array [i] == x)

return (true);

}

return (false);

21



Comparing Data Structures

Array (vector)zContiguous sequence of itemsz Fixed numberzDirect access by index

Double Linked ListzNon-contiguous sequence of itemszVariable numberz Indirect access starting from beginning/end

Access: O(1)Insert: O(N)Delete: O(N)

Access: O(N)Insert: O(1)Delete: O(1)

22



Searching Algorithms

Problem: Find a particular value in a collection of elements

Sequential searchzWorks for any data structure (array, list, etc.)zO(n)Binary searchzRequires ordered array/vectorzO(log n) on averagez Standard implementationszNot appropriate for linked lists (no direct element access)

23



Searching Algorithms (cont.)

Tree searchzO(log n)z Insert/delete O(height of tree) O(log n)zOPNET API#include

z Example in OPNET Models wireless_lan/wlan_mac.pr.m

*

*

*

24



Searching Algorithms (cont.)

Hash table searchindex = hash_function (item key);

zO(1) access/insertionzHash function on keyzMemory overheadzHashing overheadzCollisionszOPNET API#include #include

z Example in OPNET Models ip/ip_cmn_rte_table.ex.c

*index

25



OPNET API Data Structures

API Package Data Structure SearchInsert /Delete

prg_vector resizable array O(n) O(n)

prg_list linked list O(n) O(1)

prg_mapping balanced tree O(log n) O(log n)

prg_string_hashhash table

(string keys)O(1) O(1)

prg_bin_hashhash table

(fixed length keys)

O(1) O(1)

26



LAB 2:Improving Code Efficiency

Routing protocol model Identify bottlenecks using the OPNET ProfilerApply different efficiency techniques

27



LAB 2 Summary:Reworking Code for Efficiency

OPNET Simulation Profiler identifies inefficiencies in designRedesign with more efficient algorithms and data structuresz 76% faster with hash table search over sequential searchz 86,944 events/second vs. 49,573 events/second

28



Agenda






Take-Away Points

29



Efficiency of Packet Field APIs

Common operations on a packetzField accesszField typeszTransferringAccess by name: op_pk_nfd_ (pkptr, , Access by index: op_pk_fd_ (pkptr, ,

_nfd_& Safe if not present& Independent of field order' Cost of string comparison

inside KP

_fd_' Need knowledge of index' Dependent on field order& Faster access

30



Packet Fields vs. Structs

Two ways of representing data items in packetz Individual field for each itemzOne structure field with corresponding C/C++ structure

struct {int src, dst, prio;

}+

Fields of a C/C++ structure&More compact representation' Require display proc for ODB)Require copy/delete/print procs& Faster access to data

Individual packet fields&More modular& Automatic display in ODB

' Slower access to data

31



Field Get vs. Access for Structure Fields

_Get to extract data from packetzContainer packet internals updated to reflect extractionz op_pk_(n)fd_get KPs for fields of type structure_Access to modify data in-linez op_pk_(n)fd_access_ptr KP for fields of type structurezNo update needed for container packet internalszUseful to read/modify data in packetz Packet sharing: make private Potential structure data update

z Faster_Access_Read_Only to peek at data inside packetz op_pk_(n)fd_access_read_only_ptr KP for fields of type structurezNo update for packet internals nor packet sharingz Fastest

32



Type-Specific Packet Field Access

Generic KPs to set/get packet fieldsz op_pk_(n)fd_get/set()zVariable number or types of argumentszNo compiler help with bad calls Likely to cause aborts at runtime due to type mismatch

zDeprecated APIsStrongly Typed KPsz op_pk_(n)fd_get/set_() : dbl,info,int32,int64,objid,pkid,pkt,ptr,str E.g.

z op_pk_fd_get_dbl (Packet *, int index, double * val_ptr)

z op_pk_nfd_set_int32 (Packet *, const char * field, int val)

zBad arguments reported when compiling the modelz Field type mismatch reported as simulation warning, not crashz Faster than generic versions

33



Efficient Event State

Associating information with eventsPre-10.0: Must use Interface Control Information (ICI)

Set: Ici * op_ici_install (Ici * ici_ptr)Get: Ici * op_ev_ici (Evhandle)

10.0+: Allows arbitrary C/C++ state structureSet: void * op_ev_state_install (void * state_ptr, void*

print_proc)Get: void * op_ev_state (Evhandle)

ICI&More modular' Slower access to data& Automatic display in ODB' Cannot view ICI internals

in source debugger

C/C++ structure&More compact representation& Faster access to data' Only display pointer in ODB& Easier to manipulate in source

debugger

34



Agenda






Take-Away Points

35



Reducing Memory Usage

Paging/swappingz Insufficient physical memory for active tasksz Temporarily transfer physical memory contents to diskzDisk is slowz Swapping dramatically decreases performance of simulationsMemory and performancezUsing less memory improves performance Less paging faster code

zMemory is slower than CPU Less frequent memory access faster code

36



Identifying Memory Problems

Check high memory utilizationzOut-of-memory errorz Look/listen for swapping zWatch with toolsMemory monitoring toolszMS Windows Windows Task Manager Performance Monitor (perfmon)

zUNIX top

zOPNET Memory Tools

37



Dynamically Allocating Memory

C/C++ library callsz malloc/calloc/freez new/delete BEWARE: Memory fragmentation is possible with repeated allocations/de-

allocations

OPNET Memoryz Three classes Pooled Categorized General

zAPIs op_prg_pmo (and prg_pmo) API package op_prg_cmo (and prg_cmo) API package op_prg_mem (and prg_mem) API package

38



OPNET Memory API

Pooledz Fixed size objectszAllocate contiguous blocks

CategorizedzVariable size objectszGrouping of logically related memory allocations Statistics per category

GeneralzBest used for transient memory

39



Fixed-sized objectsz Simulations typically use fixed-sized objectszAllocate blocks of struct objectsEfficientzQuickly allocate/deallocate objects

OPNET Pooled Memory API

vs.

40



OPNET Memory Preferences

Preferences to disable memory management optimizations for detailed memory usage studiesz mem_opt.compact_pools If TRUE, may share same blocks for pools of the same size

z mem_opt.pool_small_blocks If TRUE, use Pooled Memory for small blocks of dynamically allocated

memory8-byte overhead per memory objectDisabling memory managementzOPNET preference mem_optimize = falsez Find leaks with third-party memory debugging tools IBM Rational Purify Valgrind

41



OPNET Built-In Memory Statistics

Relies on using OPNET memory APIDetailed memory use statisticsReports dynamically allocated memory use only

42



LAB 3:Memory Statistics

OPNETs built-in memory utilization profilerzMemory StatisticszMemory Source Tracing Interpret output resultsSee utility of OPNET memory API for analysis/debugging

43



LAB 3 Summary:Memory Statistics

Finding memory leaks easy in OPNETzMemory Utilization graphzMemory Statistics tablezMemory Source Tracing function call stacks

44



Structure Optimization

struct OPNETWORK_Session {int numAttendees;

int dayOfWeek;

char topic [128];

int isFull;

double priority;

};

sizeof (struct OPNETWORK_Session)?

45



struct OPNETWORK_Session {int numAttendees; - 4 bytesint dayOfWeek; - 4 byteschar topic [128]; - 128 bytesint isFull; - 4 bytesdouble priority; - 8 bytes

};

sizeof (struct OPNETWORK_Session)?z4 + 4 + 128 + 8 + 4 = 148 bytes?

Structure Optimization (cont.)

46



Optimized Structure

Sub-byte struct membersz struct OPNETWORK_Session_Optimal {

double priority; - 8 byteschar * topic; - 4 bytesunsigned char numAttendees; - 1 byteunsigned int dayOfWeek : 3; - 3 bitsunsigned int isFull : 1; - 1 bit

};

z sizeof (struct OPNETWORK_Optimal)?

8 + 4 + 1 + 3/8 + 1/8 = 14 bytes 16 bytes

doublechar *

47



prg_string_const()

Alternative to dynamic memoryz Not deallocatedz Uniqueuses hashingz String comparison easier

From ip_qos_support.ex.cclass_map_ptr->class_name =(char *) prg_string_const (class_map_name);

if ((pkt_info->class_name != OPC_NIL) &&

(class_map.class_name != OPC_NIL)){if (pkt_info->class_name == class_map.class_name)

match_found = OPC_TRUE;}

48



Caching Information

Trade space for timez Eliminate redundant computation of similar informationzRequire space to store computed values Issues to considerzCost of computation vs. cost of maintaining cache Duration of validity Ease of invalidating/updating cache

zCost of cache accesszMemory increase due to cache

49



Good OPNET Candidates for Caching

Mapping between object IDs and hierarchical nameszConstant throughout the simulationz op_ima_obj_hname_get()z op_id_from_name()

Topology relationshipsz Neighbors discovered thru op_topo_* KPsModel attributeszMay or may not be constant during a simulationz op_ima_obj_attr_get_*()

50



Caching Data in Object State

Can store custom state structure with most OPNET objectsz op_ima_obj_state_set (Objid obj, void * state)z void * op_ima_obj_state_get (Objid obj)

Efficient accessUseful to cache pipeline stage information in rx/tx channelsz Example from standard models: dra_rxgroup.ps.c sets rx channel state for signal lock dra_power.ps.c gets state and checks/sets signal lock dra_ecc.ps.c gets state and resets signal lock

Danger: only one state per objectzRequires good coordination between models

51



Attributes You Should Not Cache

Typically, built-in attributes modified by the simulation kernel should not be cachedz Position attributes op_ima_obj_pos_get: obtain lat/long/alt and X/Y/Z coordinates op_ima_obj_attr_get/set: individual position attributes

z x position, y position, altitude

z condition attribute Determines status of a link/node as failed/live

52



TMM Caching Example

Terrain divided into 6 rectangles:z The first time T1 communicates with R1 or R2 Attenuation cached for

z Each time T1 communicates with R1 or R2 Cached attenuation calculation is used

z If R3 moves from rectangle 3 to rectangle 1 Communication between T1 and R3 uses cached attenuation

Examplez tmm_longley_rice.ex.c

53



Agenda






Take-Away Points

54



Three-Step Process

Identify Modeling ProblemzDefine purpose of model and analysisUnderstand Efficiency / CompromiseszOptimize model based on desired answer to questionzDo not simulate everything Implementation MethodszDesign code according to compromises

55



Low-Hanging-Fruit:Remove Overhead

Component OverheadzRemove/shutdown unused IP interfaceszRemove un-connected nodes (except standalone servers) Reduces memory required by a simulation

zRemove unwanted protocol components from node models (Modeler only)Results OverheadzDo not collect unwanted statistics zUse bucketized collection mode instead of collecting all valueszDisable unwanted reports Reduces number of hard-disk writing Reduces amount of data stored in memory

56



Balancing Fidelity vs. Speed

Fidelity and Simulation Performancez Typically, higher fidelity => longer/larger simulationzVery detailed modeling requires more computationally heavier events,

packets, etc.Reduction in fidelityzCan generate valid results in less timez Let problem focus dictate fidelity of analysis E.g. Application-level analysis can tolerate link-layer abstractions

57



Modeling Abstractions

Abstraction: useful simplification of a real-world processz To be useful, an abstraction must behave like the original process

Types of abstraction commonly used in OPNETzNetwork abstractionz Traffic abstractionz Protocol abstraction Control plane abstraction Data plane abstraction Statistical abstraction Emulation

58



Network Abstraction:Modeling the Internet

Internet as an IP/ATM/FrameRelay cloudz Abstract a cluster of routers / switchesz Characterize cloud by latency/lossz One routing table for entire cloudz Use for end-to-end application performance studies

Trade-Offsz Routing/security polices cannot be deployed in complete detailz No failure modeling in a cloud

59



Network Abstraction:Aggregation

Server Farm as a LAN nodez Abstract a cluster of servers/workstation connected to a LAN segmentz Characterize farm by MAC access delay/switching speedz One protocol stack for all component nodes

Trade-Offsz MAC contention delays may be inaccurate for shared segmentsz Not possible to model for all technologies

60



Traffic Abstraction

Traffic representation in OPNET

Choice of representation depends on modeling purposez Packet by packet End-to-end delays, protocol details, segmentation effects

zAggregated traffic Capacity planning, steady-state routing analysis

Traffic Type OPNET RepresentationPacket Level Traffic Explicit Traffic

Aggregated Traffic Traffic FlowsDevice/Link Loads (Background Traffic)

61



Hybrid Traffic

&More accurate than analytics alone&Faster than discrete'Does not model all protocol

dynamics like feedback, flow control, congestion control and policing

Traffic Demands can be set to a mix

62



Hybrid Traffic TDMA Satellite Example

Blue is 100% explicitRed is 1% explicit'Did not model oversubscription of satellite at 9m 0s.

63



Protocol Abstraction:Signaling Plane

Signaling Planez Used by connection oriented protocols for resource reservationz Timers to model outages and topology changesz Uses control plane information for exchanging signaling messagesz Memory required for connection managementOPNET model examplesz SAAL in ATM networksz SIP for VoIP networksz RSVP for MPLS networksHow to abstractz Delays to model connection setupz Simplify signaling protocol (SETUP, CONFIRM)z Signal using global topology knowledge (if abstracting control plane)z Examples of signaling layer abstractions in OPNET SS7 in circuit switch networks ILMI in ATM

Trade-Offsz Cannot capture transient behavior

64



Protocol Abstraction:Control Plane

Control PlanezModel routing traffic, path-computation, tables/databaseszModel policies for filtering and altering routing informationzHandles failure/recovery situations

OPNET model examplesz Circuit switchz Frame Relayz OSPF

How to abstractz Use of centralized graph accessible to all nodes Construct with prg_djk or op_topo packages

z Stop control traffic after a certain simulation duration Trade-Offsz Cannot capture routing convergence times z May not capture all routing policies

65



Protocol Abstraction:Data Plane

Simulation worldz Not required to follow physical pathz Direct transfer packet between any two modules op_pk_deliver Kernel Procedures By-pass pipeline stages & network transmission/propagation

z Well-known link-level behavior Delay, error rate, etc.

Available in following modelsz ATMATM Sim Efficiency: Enabledz Frame Relay - FR Sim Efficiency Modez Transport ProtocolsDirect DeliveryTrade-Offsz Cannot model physical layer effects Path-loss, interference,

z Cannot collect link/channel statistics Throughput, utilization, error rate,

z Cannot model influence on other packets Queuing, congestion, flow control back-offs, ...

66



Statistical Abstraction

Capture the statistics of a quasi-deterministic processzA version of random backoff in a medium access protocol Assume p: probability of successful transmission in any slot In case of failure, slot range doubles, tx slot chosen uniformly from range Find distribution of number of slots to successful transmission I computed Prob (slot k) = (1/2n)p(1-p)n, where n = LowerInt(log2k)

z Instead of modeling collision detection, retrial etc, sample the distribution

Some processes can only be modeled via statistical abstractionz Fading in a multi-carrier radio transmission with Doppler effect Doppler effect leads to time-correlation Time correlation can be captured via Markov chain This techniques has been used in WiMAX PHY modeling

67



Statistical AbstractionAn Example

Smart MACzCharacterize MAC operation in a table Packets arrive Perform a table lookup to obtain delay/loss Drop or deliver to destination node after delays

z Table should account for Delaysretransmission, back-off, propagation Lossescollision, buffer overflow

68



Operational Efficiency:Use Pre-Computed Data

Use pre-computed data from other simulations or empirical sources IP forwarding table import from Flow Analysis/DESz Use forwarding table reports previously generated Entire routing information available at beginning of simulation

z Trade-offs No control traffic Cannot react to topology changes Uses a single snapshot

UMTS pre-computes antenna gain and pathlossz Computed for all UE Node_b communication pairsz Antenna gain is a function of transmission direction and path loss is a function of

distancez They are re-computed if distance threshold is crossedz Trade-offs - May be inaccurate if threshold value is very highReceiver Groups

69



Use of Global State

Omniscient Simulationz Information about all nodes/links are accessible to all other nodesz Store large/repetitive data in a global areahighly efficient when copies of

these data structures have to be made in many nodes

Example: ARP Resolution zGlobal table for IP to MAC address resolutionzDoes not generate ARP requests/responseszControlled by ARP Sim Efficiency attribute& Increases simulation speed and eliminates memory required by ARP cache of

each node' Does not model ARP traffic and also time taken for resolutionExample: TDMA Radio Slot Plan & Simplifies process model and increases simulation speed' Does not simulate failure to receive slot plan

70



Lazy Evaluation

Delay work until result is neededzMinimal or zero loss of accuracyzAvoid work at regular intervalszAvoid work results of which will never be used&Increases simulation speed

71



Lazy Evaluation Example

Routing table agingzRouting table or LS database entries are aged over timez Each element expiry need not be an interrupt z Possible lazy approaches to clean expired entries Maintain variable with earliest expiry time in a database and purge expired

element(s) on a subsequent operation on the databasez Search on every database operation for earliest expiry element

Scan database periodically ' May not control memory usage

zUsed by OLSR

72



LAB 4:Operating Protocols Efficiently

Take an IP network and increase its simulation speed and reduce memory using some of the model efficiency techniqueszNo code changes this timez Few changes affect network fidelityzUnderstand the trade-offs

73



LAB 4 Summary:Operating Protocols Efficiently

Increased Simulation efficiency using three efficiency methodsEliminated OSPF control traffic after 260 seconds

z 170% Improvement in speedEliminated routing table computations using pre-computed data

z 270 % Improvement in speed

Eliminated overhead in node modelsz 21% Improvement in speedz 28% Reduction in memory usage

Reduced overhead with pre-computed routingz 300% Improvement in speed

74



Documentation References

OPNET Modeler Online DocumentationzModeling Concepts Reference Manual Communication Mechanisms

z Programmers Reference Manuals Kernel Procedures API Reference Manual Data Structures and Algorithms API Reference Manual

z External Interfaces Reference Manual Simulation Execution

z OPNET Simulation Debugger (ODB)OPNET Support Center (http://www.opnet.com/support)zMethodologies and Case Studies Optimizing Performance of Discrete Event Simulations

Big O Notation (http://en.wikipedia.org/wiki/Big_O_notation)

75



Related OPNETWORK Sessions

1501 Introduction to Process Modeling Methodology1502 Debugging Simulation ModelsIntroduction1530 Modeling Custom Wireless EffectsIntroduction1580 Modeling Custom Wireless EffectsAdvanced

1376 Introduction to Importing and Modeling Network Traffic

76



Take-Away Points

Efficient environmentEfficient simulation kernelEfficient compilation

Efficient model representation

Efficient configuration of protocols

Efficient codezData structureszAlgorithmsz Efficient kernel procedure usezModel design and abstraction

Easy

Difficult

77



Take-Away Points

Top 5 model efficiency techniqueszReduce/eliminate control traffic for stable networkszUse pre-computed datazRemove extraneous overheadsz Lazy evaluate periodic activitieszUse global stateRedesign models based on efficient algorithmsz Target code to desired analysis

78



Appendix:Big O Notation (intro from Wikipedia)

Also known as Landau notation, Bachmann-Landau notation and asymptotic notation. Describes the limiting behavior of a function when the argument tends towards infinity,

usually in terms of simpler functions. Allows simplification of functions in order to concentrate on their growth rates: different functions with the same growth rate may be represented using the same O notation. Used in the analysis of algorithms to describe an algorithms usage of computational

resources: the worst case or average case running time or memory usage of an algorithm is often expressed as a function of the length of its input using big O notation. This allows algorithm designers to predict the behavior of their algorithms and to determine which of multiple algorithms to use, in a way that is independent of computer architecture or speed. Because Big O notation discards multiplicative constants on the running time, and ignores

efficiency for low input sizes, it does not always reveal the fastest algorithm in practice or for practically-sized data sets. But the approach is still very effective for comparing the scalability of various algorithms as input sizes become large. A description of a function in terms of big O notation usually only provides an upper

bound on the growth rate of the function. Associated with big O notation are several related notations, using the symbols o, , ,

and , to describe other kinds of bounds on asymptotic growth rates.

79



Appendix:Standard Models for Different Kernels

Kernel combinations

Different object files produced for different kernel typesz bgp.dev32.i0.pr.obj or bgp.opt64.s1.pr.oz ... . kernel_type: one from kernel combinations (dev32, opt64 ) arch_type: machine architecture (i0: Windows; i1: Linux) file_type: process model (pr), pipeline stage (ps) file_extn: object file, c file

Repositories shipped with model library for sequential kernel z {Development, Optimized} kernel on {32-bit, 64-bit} for {Windows, Linux}z All repositories are named stdmod and placed in /models/std/basez Reduces simulation loading timez Does not include code of your custom models

SequentialParallel

32 bit address

64 bit addressDevelopment

Optimized

80



Appendix:Recommended comp_flags_optim Settings

Windowsz MS Visual C++ 6.0 Professional (comp_prog: comp_msvc) /G6 /Ox /Ob2

z MS Visual C++ .NET/2005,2008 Professional (comp_prog: comp_msvc) /G7 /Ox /Ob2

z Target CPU Optimizations: /G{1,2,3,4,5,6,7}

Linuxz GCC (comp_prog: comp_gcc) -O2

MS referencez http://msdn.microsoft.com/en-us/library/fwkeyyhe.aspx

81



Appendix: SMART MAC Capabilities

Contention based mediumz Packet transmissions undergo backoff due to

contention from shared mediumz Resultant MAC throughput Obtained by contention table lookup Number of contenders computed by

SMART MAC for every packet Table values can be collected from

empirical/theoretical/simulation sources

Mobility Nodes can be mobile and hence number of

contenders can change Re-compute number of reachable nodes based

on transmission range

Hidden Node Collision Detection Interference from nodes outside transmission

range

82



Appendix: SMART MAC Mobile Network Test

Topology: random Mobility: All nodes converge to the same point Number of nodes: 100 Simulation duration: 90 minutes Validation measures:

z Application Throughput Performance measure:

z Elapsed timez Real time ratio

83



Appendix: SMART MAC Mobile Network Test Performance Gain

SMART MAC simulation speed compared to WLAN z 100% faster

SMART MAC simulation speed compared to real time z 100% faster than real time

1550_Accelerating Simulations Using Efficient Modeling Techniques

Documents

Transcript of 1550_Accelerating Simulations Using Efficient Modeling Techniques