1550 - Accelerating Simulations Using Efficient Modeling Techniques

Session 1550
Accelerating Simulations Using

Efficient Modeling Techniques
R&D Solutions for Commercial
and Defense Networks
CONFIDENTIAL RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any
CONFIDENTIAL format
RESTRICTED
ACCESS:
This information
may notTechnologies,
be disclosed, copied,
or transmitted in any
without the
prior written
consent of OPNET
Inc.
format without
the
priorOPNET
written Technologies,
consent of OPNET
2007
Inc. Technologies, Inc.
2010 OPNET Technologies, Inc.
1550 Accelerating Simulations Using Efficient Modeling Techniques
Session Goals
Learn the basics of factors affecting efficiency of Modeler
simulation through a combination of lectures and labs
Learn and practice Modeler efficiency techniques and
methodologies to identify causes of performance problems
Topics include
z Kernel
types, compiler settings and other environmental factors

z Efficiency techniques
z Profiling programs
z General programming practices
z Tradeoffs
z Advanced efficiency techniques to reduce memory
z OPNET data structures, algorithms and memory API
z Wireless modeling efficiency
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.
Agenda
Introduction
Simulation Optimization Goals
z Session organization: from the Simple to the Complex
z
Environment efficiency: the Low Hanging Fruit

Lab1: Using Development vs. Optimized Kernel
Programming Efficiency
z Data Structures & Algorithms
Lab2: Routing Protocol Profiling
z Discrete Event Simulation Kernel Efficiency
z Memory Efficiency
Lab3: Memory Statistics
z
Modeling Efficiency
Trading Accuracy for Speed

z Using Global Space and Memory Sharing
z Lazy Evaluation
z Overloading Information Exchange
Lab 4: Operating Protocols Efficiently
z
Take-Away Points

Faster
z Reduce
wall-clock time
z Increase events/second
Tighter
z Less
memory
z Less chance of using swap space
z Better performance scaling with size of model
Cleaner
z Easier
to maintain
Valid
z Modeling
results accurate according to assumptions
Time Space / Fidelity Trade-Offs

z Choose
what is more important
Simulation Methodology (from 1572)
Start
Understanding the
system
Understanding your
goals for the
simulation
Choosing aspects
to be modeled
Defining input and

output
No
Specifying the
system model
Choosing input and

running simulations
System results
accurate?
Yes
Results
sufficiently
detailed?
No
Results
statistically
useful?
No
Abstraction vs. Fidelity

End
What Takes Time in a

Discrete Event Simulation?
Model Code
z Process
models
z Pipeline stages
z External files
DES Kernel Services

z Kernel
User Models
Procedures: ima, pk, sar, list,
etc.
z Time spent in kernel procedures is
dictated by model code
DES Kernel Engine

z Event
management
z Dispatching interrupts
z Handling packet send/receive
Operating System
z Memory
paging/swapping
DES Kernel
Services
DES Kernel
Engine
OS
Simulation Models
Simulation Methods
z Discrete
event simulation (DES) models and engine

Hybrid
z Flow Analysis models and engine
DES models
z Open
source C/C++ code

z Determine protocol behavior including data + control plane
z Utilize DES kernel to run simulations
z Capture detailed component/network behavior
Understand efficient modeling techniques to operate and design DES

protocol models
Optimize Everything!
Easy
Efficient environment
Efficient simulation kernel
Efficient compilation
Efficient model representation
Efficient configuration of protocols
Efficient code
z Data
Difficult
structures
z Algorithms
z Efficient Kernel Procedures
z Model design and abstraction
What Gains Should You Expect

Pareto Principle: 80/20 rule
z 80%
of time/memory/etc. in 20% of code

z Optimize most time/memory-consuming code first
Gains vary enormously depending on technique

z Most
result in small improvement (1-5% overall speed or memory)

z A few result in big speed or memory improvement
Replace use of inappropriate data structure or algorithm
Achievable by trimming unnecessary computations (precision issues)
Agenda
Introduction

z Session Organization: from the Simple to the Complex
z
Environment efficiency: the Low Hanging Fruit

z Data Structures & Algorithms
z Memory Efficiency
z
Modeling Efficiency

z Lazy Evaluation
z
Take-Away Points
10
Efficient Environment
Faster hardware
z Multi-Core
processor machines
More memory: Eliminates swapping

Less CPU contention
z Eliminate
other activities: No complex screen savers

z No OPNET GUI
Run simulation from command-line or OPNET Console
z Or minimal GUI
Prevent speed and memory graphs
from being displayed
Reduce frequency of
simulation progress updates
11
Efficient Environment:
Concurrent Simulations
Modern CPUs have more than one microprocessor core
z Execute
a simulation run on each core

z Distribute simulations runs to different hosts
OPNET Preference configuration:

z Allow
Simulations on Multiple Hosts: TRUE

z Distributed Simulation Hosts:
<hostname (localhost)>::<number of CPU cores>
Need separate Simulation Run-Time license for each concurrent run

z Site
Simulation Runtime License covers unlimited number of concurrent runs
12
Efficient Simulation Kernel

Development Kernel
z Model
development/debugging
z OPNET Simulation Debugger (ODB)
z Profiling capability in Kernel Procedures
Optimized Kernel
z No
ODB, tracing, or KP profiling

z Typically 50-100% faster than Development Kernel
z Use for production simulation after development
Parallel Kernel
z Use
only with multi-threaded models
OPNET Preference kernel_type
13
Efficient Compilation
Use compiler optimizations
z Configuration
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 FAQs
Compile without OPNET function call stack info

z FCS:
Error reporting overhead for

quickly debugging problems
z Increases speed by 30-50%
z comp_trace_info preference
z Default is disabled when compiling
for optimized kernel
<<<
*
*
*
*
*
*
*
Program Fault >>>

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
Block
Count 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_main
4)
1
1106 sim_main
5)
1
2706 sim_ev_loop
6)
186302
501 sim_obj_qps_intrpt
7)
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 ()
14
LAB 1:
Simulation Kernel Performance
Assess baseline simulation performance
Explore OPNET development environment configuration
Capability of environment + simulation kernel + compiler
Compare debug and optimized kernels
Run multiple simulations concurrently
15
LAB 1 Summary:
Simulation Kernel Performance
Use Optimized Kernel
z 2x
speed improvement for simplest simulation

z Use unless debugging problem
Remove function stack trace information for speed

Reduce frequency of progress update
16
Agenda
Introduction

z
Environment Efficiency: the Low Hanging Fruit

z
Data Structures & Algorithms

z Memory Efficiency
z
Modeling Efficiency

z Lazy Evaluation
z
Take-Away Points
17
Solve Problems Before Dealing with Efficiency:

Code Optimization Methodology
1.
2.
3.
4.
5.
6.
7.
8.
Understand the perceived problem

Define the abstract problem
Design the solution
Implement a prototype
Verify correctness
Benchmark prototype
Identify optimization candidate
Optimize/redesign code
Repeat as necessary
18
Profiling Program Execution

Objective: to shorten execution time
Find hot spots accurately by code instrumentation
z Function
timing data
z Number of times function called
Use commercially-available software

z IBM
Rational Quantify, compilers profiler (prof, gprof, Microsoft Profiler)
OPNET built-in profiler

z Relies
on FIN/FOUT/FRET macros in user code

z PROFILE_SECTION macros
z Results not precisebut accurate for finding bottlenecks
z Kernel procedures only profiled if using development kernel
Optimized kernel shows only user model functions
z More details in upcoming lab
Question: how to improve inefficiency uncovered by profiling ?

19
Complexity Analysis
Big-O notation
Way to quantify performance and compare different algorithms
z O(1)
O(log n) O(n) O(n2) O(2n)

z Worst-case order of growth
z By inspection of solution
z Basic understanding of problem and solution
z Quick comparison of different approaches
Example: What is order of growth of this code?

for (i = 0; i < n; i++) {
if (array [i] == x)
return (true);
}
return (false);
20
Comparing Data Structures

Array (vector)
z Contiguous
sequence of items
z Fixed number
z Direct access by index
Access: O(1)
Insert: O(N)
Delete: O(N)
Double Linked List

z Non-contiguous
sequence of items
z Variable number
z Indirect access starting from beginning/end
Access: O(N)
Insert: O(1)
Delete: O(1)
21
Searching Algorithms
Problem: Find a particular value in a collection of elements
Sequential search
z Works
for any data structure (array, list, etc.)
z O(n)
Binary search
z Requires
ordered array/vector
z O(log n) on average
z Standard implementations
z Not appropriate for linked lists (no direct element access)
22
Searching Algorithms (cont.)

Tree search
z O(log
n)
z Insert/delete O(height of tree) O(log n)
z OPNET API
#include <prg_mapping.h>
z Example in OPNET Models
wireless_lan/wlan_mac.pr.m
23
Searching Algorithms (cont.)

Hash table search
index = hash_function (item key);
z O(1)
access/insertion
index
z Hash function on key
z Memory overhead
z Hashing overhead
z Collisions
z OPNET API
#include <prg_string_hash_funcs.h>
#include <prg_bin_hash.h>
z Example in OPNET Models
ip/ip_cmn_rte_table.ex.c
24
OPNET API Data Structures
API Package
prg_vector
prg_list
Data Structure
Search
Insert /
Delete
resizable array
O(n)
O(n)
linked list
O(n)
O(1)
prg_mapping
balanced tree
O(log n) O(log n)
prg_string_hash
hash table
(string keys)
O(1)
O(1)
prg_bin_hash
hash table
(fixed length
keys)
O(1)
O(1)
25
LAB 2:
Improving Code Efficiency
Routing protocol model
Identify bottlenecks using the OPNET Profiler
Apply different efficiency techniques
26
LAB 2 Summary:
Reworking Code for Efficiency
OPNET Simulation Profiler identifies inefficiencies in design
Redesign with more efficient algorithms and data structures
z 76%
faster with hash table search over sequential search

z 86,944 events/second vs. 49,573 events/second
27
Agenda
Introduction

z

z

z Memory Efficiency
z
Modeling Efficiency

z Lazy Evaluation
z
Take-Away Points
28
Efficiency of Packet Field APIs

Common operations on a packet
z Field
access
z Field types
z Transferring
Access by name: op_pk_nfd_ (pkptr, <name>,

Access by index: op_pk_fd_ (pkptr, <index>,
_nfd_
& Safe if <name> not present
& Independent of field order
' Cost of string comparison
inside KP
_fd_
' Need knowledge of index
' Dependent on field order
& Faster access
29
Packet Fields vs. Structs

Two ways of representing data items in packet
z Individual
field for each item

z One structure field with corresponding C/C++ structure
struct {
int src, dst, prio;
}
Individual packet fields

& More modular
& Automatic display in ODB
' Slower access to data
Fields of a C/C++ structure

& More compact representation
' Require display proc for ODB
)Require copy/delete/print procs
& Faster access to data
30
Field Get vs. Access for Structure Fields

_Get to extract data from packet
z Container
packet internals updated to reflect extraction

z op_pk_(n)fd_get KPs for fields of type structure
_Access to modify data in-line

z
op_pk_(n)fd_access_ptr KP for fields of type structure
z No
update needed for container packet internals

z Useful to read/modify data in packet
z Packet sharing: make private
Potential structure data update
z Faster
_Access_Read_Only to peek at data inside packet

z
op_pk_(n)fd_access_read_only_ptr KP for fields of type structure
z No
update for packet internals nor packet sharing

z Fastest
31
Type-Specific Packet Field Access

Generic KPs to set/get packet fields
z
op_pk_(n)fd_get/set()
z Variable
number or types of arguments

z No compiler help with bad calls
Likely to cause aborts at runtime due to type mismatch
z Deprecated APIs
Strongly Typed KPs

z
op_pk_(n)fd_get/set_<type>()
<type>: dbl,info,int32,int64,objid,pkid,pkt,ptr,str
E.g.
z
z
op_pk_fd_get_dbl (Packet *, int index, double * val_ptr)

op_pk_nfd_set_int32 (Packet *, const char * field, int val)
z Bad
arguments reported when compiling the model

z Field type mismatch reported as simulation warning, not crash
z Faster than generic versions
32
Efficient Event State

Associating information with events
Pre-10.0: Must use Interface Control Information (ICI)
Set:
Get:
Ici * op_ici_install (Ici * ici_ptr)

Ici * op_ev_ici (Evhandle)
10.0+: Allows arbitrary C/C++ state structure

Set:
Get:
void * op_ev_state_install (void * state_ptr, void*

print_proc)
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
33
Agenda
Introduction

z

z

z Memory Efficiency
z
Modeling Efficiency

z Lazy Evaluation
z
Take-Away Points
34
Reducing Memory Usage

Paging/swapping
z Insufficient
physical memory for active tasks

z Temporarily transfer physical memory contents to disk
z Disk is slow
z Swapping dramatically decreases performance of simulations
Memory and performance

z Using
less memory improves performance

Less paging faster code
z Memory is slower than CPU
Less frequent memory access faster code
35
Identifying Memory Problems

Check high memory utilization
z Out-of-memory
error
z Look/listen for swapping
z Watch with tools
Memory monitoring tools

z MS
Windows
Windows Task Manager
Performance Monitor (perfmon)
z UNIX
top
z OPNET Memory Tools
36
Dynamically Allocating Memory

C/C++ library calls
malloc/calloc/free
z new/delete
z
BEWARE: Memory fragmentation is possible with repeated allocations/deallocations
OPNET Memory
z Three
classes
Pooled
Categorized
General
z APIs
op_prg_pmo (and prg_pmo) API package
op_prg_cmo (and prg_cmo) API package
op_prg_mem (and prg_mem) API package
37
OPNET Memory API

Pooled
z Fixed
size objects
z Allocate contiguous blocks
Categorized
z Variable
size objects
z Grouping of logically related memory allocations
Statistics per category
General
z Best
used for transient memory
38
OPNET Pooled Memory API

Fixed-sized objects
z Simulations
typically use fixed-sized objects

z Allocate blocks of struct objects
Efficient
z Quickly
allocate/deallocate objects
vs.
39
OPNET Memory Preferences

Preferences to disable memory management optimizations for
detailed memory usage studies
z 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
memory
8-byte overhead per memory object

Disabling memory management
z OPNET
preference mem_optimize = false

z Find leaks with third-party memory debugging tools
IBM Rational Purify
Valgrind
40
OPNET Built-In Memory Statistics

Relies on using OPNET memory API
Detailed memory use statistics
Reports dynamically allocated memory use only
41
LAB 3:
Memory Statistics
OPNETs built-in memory utilization profiler
z Memory
Statistics
z Memory Source Tracing
Interpret output results

See utility of OPNET memory API for analysis/debugging
42
LAB 3 Summary:
Memory Statistics
Finding memory leaks easy in OPNET
z Memory
Utilization graph
z Memory Statistics table
z Memory Source Tracing function call stacks
43
Structure Optimization
struct OPNETWORK_Session {
int
int
char
int
double
numAttendees;
dayOfWeek;
topic [128];
isFull;
priority;
};
sizeof (struct OPNETWORK_Session)?
44
Structure Optimization (cont.)

struct OPNETWORK_Session {
int
int
char
numAttendees;
dayOfWeek;
topic [128];
int
isFull;
double
priority;
- 4 bytes
- 4 bytes
- 128 bytes
- 4 bytes
- 8 bytes
};
sizeof (struct OPNETWORK_Session)?

z 4 + 4 + 128 + 8 + 4 = 148 bytes?
45
Optimized Structure
Sub-byte struct members
z struct
OPNETWORK_Session_Optimal {
double
priority;
char *
topic;
unsigned char numAttendees;
unsigned int dayOfWeek : 3;
unsigned int isFull : 1;
- 8 bytes
- 4 bytes
- 1 byte
- 3 bits
- 1 bit
};
z sizeof
(struct OPNETWORK_Optimal)?
double
char *
+ 4 + 1 + 3/8 + 1/8 = 14 bytes 16 bytes
46
prg_string_const()
Alternative to dynamic memory
Not deallocated
z Uniqueuses hashing
z String comparison easier
z
From ip_qos_support.ex.c
class_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;
}
47
Caching Information
Trade space for time
z Eliminate
redundant computation of similar information

z Require space to store computed values
Issues to consider
z Cost
of computation vs. cost of maintaining cache

Duration of validity
Ease of invalidating/updating cache
z Cost of cache access
z Memory increase due to cache
48
Good OPNET Candidates for Caching

Mapping between object IDs and hierarchical names
z Constant
throughout the simulation
op_ima_obj_hname_get()
z op_id_from_name()
z
Topology relationships
z
Neighbors discovered thru op_topo_* KPs
Model attributes
z May
z
or may not be constant during a simulation
op_ima_obj_attr_get_*()
49
Caching Data in Object State

Can store custom state structure with most OPNET objects
op_ima_obj_state_set (Objid obj, void * state)
z void * op_ima_obj_state_get (Objid obj)
z
Efficient access
Useful to cache pipeline stage information in rx/tx channels
z 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 object

z Requires
good coordination between models
50
Attributes You Should Not Cache

Typically, built-in attributes modified by the simulation kernel
should not be cached
z 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
condition attribute
Determines status of a link/node as failed/live
51
TMM Caching Example

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

Attenuation cached for <rect 5><rect 1><freq>
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
Example
z tmm_longley_rice.ex.c
52
Agenda
Introduction

z

z

z Memory Efficiency
z
Modeling Efficiency

z Lazy Evaluation
z
Take-Away Points
53
Three-Step Process
Identify Modeling Problem
z Define
purpose of model and analysis
Understand Efficiency / Compromises

z Optimize
model based on desired answer to question

z Do not simulate everything
Implementation Methods
z Design
code according to compromises
54
Low-Hanging-Fruit:
Remove Overhead
Component Overhead
z Remove/shutdown
unused IP interfaces
z Remove un-connected nodes (except standalone servers)
Reduces memory required by a simulation
z Remove unwanted protocol components from node models (Modeler only)
Results Overhead
z Do
not collect unwanted statistics

z Use bucketized collection mode instead of collecting all values
z Disable unwanted reports
Reduces number of hard-disk writing
Reduces amount of data stored in memory
55
Balancing Fidelity vs. Speed

Fidelity and Simulation Performance
z Typically,
higher fidelity => longer/larger simulation

z Very detailed modeling requires more computationally heavier events,
packets, etc.
Reduction in fidelity
z Can
generate valid results in less time

z Let problem focus dictate fidelity of analysis
E.g. Application-level analysis can tolerate link-layer abstractions
56
Modeling Abstractions
Abstraction: useful simplification of a real-world process
z To
be useful, an abstraction must behave like the original process
Types of abstraction commonly used in OPNET

z Network
abstraction
z Traffic abstraction
z Protocol abstraction
Control plane abstraction
Data plane abstraction
Statistical abstraction
Emulation
57
Network Abstraction:
Modeling the Internet
Internet as an IP/ATM/FrameRelay cloud
Abstract a cluster of routers / switches
z Characterize cloud by latency/loss
z One routing table for entire cloud
z Use for end-to-end application performance studies
z
Trade-Offs
Routing/security polices cannot be deployed in complete detail
z No failure modeling in a cloud
z
58
Network Abstraction:
Aggregation
Server Farm as a LAN node
Abstract a cluster of servers/workstation connected to a LAN segment
z Characterize farm by MAC access delay/switching speed
z One protocol stack for all component nodes
z
Trade-Offs
MAC contention delays may be inaccurate for shared segments
z Not possible to model for all technologies
z
59
Traffic Abstraction
Traffic representation in OPNET
Traffic Type
OPNET Representation
Packet Level Traffic Explicit Traffic
Aggregated Traffic
Traffic Flows
Device/Link Loads (Background Traffic)
Choice of representation depends on modeling purpose

z Packet
by packet
End-to-end delays, protocol details, segmentation effects
z Aggregated traffic
Capacity planning, steady-state routing analysis
60
Hybrid Traffic
Traffic Demands can be set to a mix
&More accurate than analytics
alone
&Faster than discrete
'Does not model all protocol
dynamics like feedback, flow
control, congestion control
and policing
61
Hybrid Traffic TDMA Satellite Example

Blue is 100% explicit
Red is 1% explicit
'Did not model oversubscription of satellite at 9m 0s.
62
Protocol Abstraction:
Signaling Plane
Signaling Plane
Used by connection oriented protocols for resource reservation

z Timers to model outages and topology changes
z Uses control plane information for exchanging signaling messages
z Memory required for connection management
z
OPNET model examples

SAAL in ATM networks
z SIP for VoIP networks
z RSVP for MPLS networks
z
How to abstract
Delays to model connection setup

z 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
z
Trade-Offs
z
Cannot capture transient behavior
63
Control Plane
Control Plane
z Model routing traffic, path-computation, tables/databases
z Model policies for filtering and altering routing information
z Handles failure/recovery situations
OPNET model examples
Circuit switch
z Frame Relay
z OSPF
z
How to abstract
z
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-Offs
Cannot capture routing convergence times
z May not capture all routing policies
z
64
Data Plane
Simulation world
Not required to follow physical path

z 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.
z
Available in following models
ATMATM Sim Efficiency: Enabled

z Frame Relay - FR Sim Efficiency Mode
z Transport ProtocolsDirect Delivery
z
Trade-Offs
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, ...
z
65
Statistical Abstraction
Capture the statistics of a quasi-deterministic process
zA
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 abstraction

z 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
66
Statistical AbstractionAn Example

Smart MAC
z Characterize
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
67
Operational Efficiency:
Use Pre-Computed Data
Use pre-computed data from other simulations or empirical sources
IP forwarding table import from Flow Analysis/DES
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
z
UMTS pre-computes antenna gain and pathloss

Computed for all UE Node_b communication pairs
z Antenna gain is a function of transmission direction and path loss is a function of
distance
z They are re-computed if distance threshold is crossed
z Trade-offs - May be inaccurate if threshold value is very high
z
Receiver Groups
68
Use of Global State

Omniscient Simulation
z Information
about all nodes/links are accessible to all other nodes

z 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

z Global
table for IP to MAC address resolution

z Does not generate ARP requests/responses
z Controlled 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 resolution
Example: TDMA Radio Slot Plan

Simplifies process model and increases simulation speed
' Does not simulate failure to receive slot plan
&
69
Lazy Evaluation
Delay work until result is needed
z Minimal
or zero loss of accuracy

z Avoid work at regular intervals
z Avoid work results of which will never be used
&Increases simulation speed
70
Lazy Evaluation Example

Routing table aging
z Routing
table or LS database entries are aged over time

z 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 database
z Search on every database operation for earliest expiry element
Scan database periodically
' May not control memory usage
z Used by OLSR
71
LAB 4:
Operating Protocols Efficiently
Take an IP network and increase its simulation speed and reduce
memory using some of the model efficiency techniques
z No
code changes this time

z Few changes affect network fidelity
z Understand the trade-offs
72
LAB 4 Summary:
Operating Protocols Efficiently
Increased Simulation efficiency using three efficiency methods
Eliminated OSPF control traffic after 260 seconds
z
170% Improvement in speed
Eliminated routing table computations using pre-computed data

z
270 % Improvement in speed
Eliminated overhead in node models

z
z

28% Reduction in memory usage
Reduced overhead with pre-computed routing

z
73
Documentation References
OPNET Modeler Online Documentation
z Modeling
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)

z Methodologies
and Case Studies

Optimizing Performance of Discrete Event Simulations
Big O Notation
(http://en.wikipedia.org/wiki/Big_O_notation)
74
Related OPNETWORK Sessions

1501 Introduction to Process Modeling Methodology
1502 Debugging Simulation ModelsIntroduction
1530 Modeling Custom Wireless EffectsIntroduction
1580 Modeling Custom Wireless EffectsAdvanced
1376 Introduction to Importing and Modeling Network Traffic
75
Take-Away Points
Easy
Efficient environment
Efficient simulation kernel
Efficient compilation
Efficient model representation
Efficient configuration of protocols
Efficient code
z Data
Difficult
structures
z Algorithms
z Efficient kernel procedure use
z Model design and abstraction
76
Take-Away Points
Top 5 model efficiency techniques
z Reduce/eliminate
control traffic for stable networks

z Use pre-computed data
z Remove extraneous overheads
z Lazy evaluate periodic activities
z Use global state
Redesign models based on efficient algorithms

z Target
code to desired analysis
77
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.
78
Appendix:
Standard Models for Different Kernels
Kernel combinations
Sequential
Parallel
Development
Optimized
32 bit address
64 bit address
Different object files produced for different kernel types
bgp.dev32.i0.pr.obj or bgp.opt64.s1.pr.o
z <filename>.<kernel_type>.<arch_type>. <file_type>.<file_extn>
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
z
Repositories shipped with model library for sequential kernel
{Development, Optimized} kernel on {32-bit, 64-bit} for {Windows, Linux}

z All repositories are named stdmod and placed in <opnet_dir>/models/std/base
z Reduces simulation loading time
z Does not include code of your custom models
z
79
Appendix:
Recommended comp_flags_optim Settings
Windows
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}
z
Linux
z
GCC (comp_prog: comp_gcc)

-O2
MS reference
z
http://msdn.microsoft.com/en-us/library/fwkeyyhe.aspx
80
Appendix: SMART MAC Capabilities

Contention based medium
Packet transmissions undergo backoff due to
contention from shared medium
z 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
z
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
81
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
z
Elapsed time
Real time ratio
82
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
83

1550 - Accelerating Simulations Using Efficient Modeling Techniques

Uploaded by

Copyright:

Available Formats

You might also like

1550 - Accelerating Simulations Using Efficient Modeling Techniques

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

1550 - Accelerating Simulations Using Efficient Modeling Techniques

Uploaded by

Copyright:

Available Formats

Session 1550

Accelerating Simulations Using

1550 Accelerating Simulations Using Efficient Modeling Techniques

types, compiler settings and other environmental factors

1550 Accelerating Simulations Using Efficient Modeling Techniques

Environment efficiency: the Low Hanging Fruit

Trading Accuracy for Speed

1550 Accelerating Simulations Using Efficient Modeling Techniques

Simulation Optimization Goals

results accurate according to assumptions

Time Space / Fidelity Trade-Offs

what is more important

1550 Accelerating Simulations Using Efficient Modeling Techniques

Simulation Methodology (from 1572)

Defining input and

Choosing input and

Abstraction vs. Fidelity

1550 Accelerating Simulations Using Efficient Modeling Techniques

What Takes Time in a

DES Kernel Services

Procedures: ima, pk, sar, list,

DES Kernel Engine

1550 Accelerating Simulations Using Efficient Modeling Techniques

event simulation (DES) models and engine

source C/C++ code

Understand efficient modeling techniques to operate and design DES

1550 Accelerating Simulations Using Efficient Modeling Techniques

1550 Accelerating Simulations Using Efficient Modeling Techniques

What Gains Should You Expect

of time/memory/etc. in 20% of code

Gains vary enormously depending on technique

result in small improvement (1-5% overall speed or memory)

1550 Accelerating Simulations Using Efficient Modeling Techniques

Simulation Optimization Goals

Environment efficiency: the Low Hanging Fruit

Trading Accuracy for Speed

1550 Accelerating Simulations Using Efficient Modeling Techniques

More memory: Eliminates swapping

other activities: No complex screen savers

1550 Accelerating Simulations Using Efficient Modeling Techniques

a simulation run on each core

OPNET Preference configuration:

Simulations on Multiple Hosts: TRUE

Need separate Simulation Run-Time license for each concurrent run

Simulation Runtime License covers unlimited number of concurrent runs

1550 Accelerating Simulations Using Efficient Modeling Techniques

Efficient Simulation Kernel

ODB, tracing, or KP profiling

only with multi-threaded models

OPNET Preference kernel_type

1550 Accelerating Simulations Using Efficient Modeling Techniques

using OPNET preferences

Compile without OPNET function call stack info

Error reporting overhead for

Program Fault >>>

* Function call stack: (builds down)

1550 Accelerating Simulations Using Efficient Modeling Techniques

1550 Accelerating Simulations Using Efficient Modeling Techniques

op_pk_fd_get_dbl (Packet , int index, double val_ptr)