Lab Manual For Session 1527: Accelerating Wireless Simulations Using Scalability Techniques

1527 Accelerating Wireless Simulations Using Scalability Techniques
Lab Manual for Session 1527: Accelerating Wireless Simulations Using Scalability Techniques
Lab 1: Using a ast !n"ironment
The purpose of this lab is to introduce you to the network model used throughout this session and to illustrate the speed difference between the development and execution environments. A simple radio node model is provided (1527_base). t includes a packet generator and a sink! both of which maintain statistics on the number of packets generated"received and the time of generation"reception. There is no explicit antenna module! which will cause the simulation to act as if an isotropic antenna was present. The move module contains a process model that will randomly move the node by an average of #$ meters in latitude and longitude every %$$ seconds.
The min frequency attributes for the transmitter and receiver channels are promoted. They will be specified in derived node models.
CONFIDENTIAL INFORMATION: DO NOT DISCLOSE, FORWARD, DISTRIBUTE, SHARE, OR MAKE COPIES OF THIS DOCUMENT IN WHOLE OR IN PART. Copyrigh !""# OPNET T$%h&o'ogi$(, I&%.
P)g$ * o+ !,
Three such derived node models (1527_30Mhz! 1527_60Mhz! and 1527_90Mhz) have been created with! respectively! minimum fre&uencies of '$! ($! and )$ *+,. The channel bandwidth is set to -#*+,. n this way! there is no fre&uency overlap among the derived node models. .ach node broadcasts %$$$/byte packets at the rate of ($ packets per hour! randomly distributed in time. Baseline: development environment %. 0tart Modeler by double/clicking on the *odeler icon on the desktop. The 123.T *odeler %%.$ application launches and displays its splash screen. -. 1pen the 1527 pro4ect as follows a. 0elect the File " !en" menu. The !en dialog box appears with a Model direc#ories$ tree on the left and a list of files on the right. b. 5ouble/click on 1527 to open the pro4ect. 6ou should see a colorful scenario named 'fre& with a scattering of red cell phones! antennas! and humvee icons! representing the three kinds of derived node models.
'. 2ress %#rl&'hif#&( to run the simulation with the current settings.
P)g$ ! o+ !,
The 0imulation 0e&uence dialog box will eventually show you the simulation progress and the speed of the simulation (your actual speed will depend on the hardware).
7. 1nce the simulation completes! write down the following information8 a. Total number of events899999999999999999999999 b. Average 0peed8999999999999999999999999999999events"sec c. :urrent 0peed8999999999999999999999999999999events"sec d. .lapsed Time89999999999999min.999999999999999sec. #. :lose the dialog box when you are done reviewing it. 6ou can view the speed of your simulation by selecting 5.0 " 1pen 5.0 ;og to launch the log browser.
P)g$ - o+ !,
and clicking under *essage to display the log entry
(. :lose the ;og .ntry $ and the ;og <rowser when you are done reviewing the speed. ;et=s now do the same with a faster environment. 6ou are going to switch to the faster optimi,ed kernel.
P)g$ # o+ !,
Switching to a faster production environment Optimized Kernel >. :lick on the %onfi)ure*(un +iscre#e ,ven# 'imula#ion button ( The %onfi)ure*(un +,' dialog box appears. ) in the -ro.ec# ,di#or.
:urrently the simulation se&uence is set to force the kernel type to development! regardless of the setting of the kernel_type preference. ;et=s switch to forcing the kernel to optimi,ed. ?. :lick on the 'imula#ion /ernel$ popup and change the value to !#imized
). :lick on the ,0ecu#ion* 1dvanced* %om!ila#ion vertical tab to show the various compilation options.
P)g$ . o+ !,
%$. 0et the 2nclude func#ion s#ac3 #race informa#ion in recom!iled models to 4o. This is e&uivalent to changing the comp_trace_info preference to @A;0.! but only for this simulation without affecting the environment database or other simulations.
%%. :lick on (un to start the simulation. %-. 1nce the simulation completes! review the speed information. a. Total number of events899999999999999999999999 b. Average 0peed8999999999999999999999999999999events"sec c. :urrent 0peed8999999999999999999999999999999events"sec d. .lapsed Time89999999999999min.999999999999999sec. %'. :lose the simulation dialog box. 6ou can also open the 5.0 log to review the speed information 3ote that because of the short simulation duration! the average speed is not yet a good representation of the simulation speed. As you can see in the 0imulation 0peed graph! the :urrent 0peed graph has reached a fairly steady rate while the Average 0peed graph is moving towards that asymptotic value. The longer you run the simulation! the closer the Average will be to the :urrent value. %7. :lose the simulation dialog box. 6ou can also open the 5.0 log to review the speed information %#. ;eave the pro4ect open. 6ou will continue to use it in the next lab. n this case the speed difference is actually not that great. 0ome simulations can run more than twice as fast using the optimi,ed settings. <ut this example has models doing very little and the bulk of the
P)g$ / o+ !,
time that is spent in the simulation (copying packets! going through the pipeline stage architecture) is really spent in portions of the simulation kernels that are about the same speed in both versions. The more complex your models! the higher the speed difference you are likely to encounter. @or example! the following are some speed figures using standard models.
The second value (TAB."@A;0.) denotes the value of the comp9trace9info preference. #onclusion 6ou have seen how to switch between a production (fast) and a development (less fast) environment. Bse the latter while you are developing or debugging your models! use the former once the models are deemed complete and you are gathering simulation data.
!$% & LA' 1
P)g$ 0 o+ !,
Lab 2: %ynamically (e)ucing (ecei"er *rou+s

n this lab! you are going to compare the speed of a wireless simulation using different versions of the closure and channel match pipeline stages. n the previous lab you ran the simulation in development and optimi,ed mode! but what was this simulation really doingC .ach node was broadcasting %$$$/byte packets ($ times per hour! randomly distributed in time. <ecause this is using the default pipeline stages! each broadcast was trying to reach all other receiver channels. <ut what is happening for a lot of these attemptsC The three derived models are set up to have no fre&uency overlap. 0o transmissions from an instance of one model can only be received by instances of the same model. 0o instead of trying all receiver channels every time! let=s filter these out. There are two primary places to do that filtering8 %. The receiver group pipeline stage -. The channel match pipeline stage n the receiver group! you would need to access the channel minimum fre&uency and bandwidth attributes for the transmitter and receiver channels and use that information to accept or re4ect the pair. The default receiver group pipeline stage does not pay attention to fre&uency or bandwidth attributes. n the channel match! you let the standard computation take place and! if it fails! you 4ust remove the failed receiver channel from the receiver group. <oth are valid. n this lab you will do the latter but feel free to try the former on your own (not during this session). Dropping receiver channels failing the channel match pipeline stage %. *ake a local copy of the default pipeline stage a. 0elect File " b. n the !en" -4,781190918models8s#d folder by clicking on the ( ) to the !en dialog box! change the Files of #y!e8 popup to -i!eline '#a)e 5% code6
c. n the tree view! expand the left of it
d. :lick on the :ireless subdirectory e. 5ouble/click on the dra_chanma#ch entry in the @iles list
P)g$ 1 o+ !,
f. 0elect File " 'ave 1s" g. :hange the File name$ to lab2_dra_chanma#ch h. 0croll the Model direc#ories$ tree display to the top i. 0elect the o!_models directory to indicate where the file should be saved (by default it is saved where the original was located) 4. :lick on 'ave -. *odify the local copy a. :hange the function name from dra_chanma#ch_m# to lab2_dra_chanma#ch_m# (The 9mt suffix indicates that the pipeline stage can be executed in parallel using a parallel kernel. t has no effect in a se&uential execution.) b. ;ook for the code testing for non/overlapping bands and update it as follows (add the bold text)
if ((tx_freq > rx_freq + rx_bw) || (tx_freq + tx_bw < rx_freq)) { Objid tx_ch_objid, rx_ch_objid; op_td_set_int (pkptr, O !_"#$_%$_&$"!'_("$")(, O !_"#$_%$_&$"!'_*+,O%-). /* Get the transmitter and receiver channels object ID from packets D! */ tx_ch_objid " op_td_#et_int $pkptr, O%&_ D!_'!_ (_&)_O*+ID,; rx_ch_objid " op_td_#et_int $pkptr, O%&_ D!_'!_'(_&)_O*+ID,; /* 'emove the receiver channel from the transmitter channel rx#ro-p */ op_radio_txch_rxch_remove $tx_ch_objid, rx_ch_objid,; /O)" 0
f the fre&uency bands do not overlap! remove the receiver channel from the transmitter=s receiver group. The change takes effect once the current transmission is over. '. 0ave the modified code 7. :ompile the pipeline stage with the corresponding toolbar button ( compilation status dialog box ). This should display a
a. f the compilation fails! review the code changes mentioned above and repeat the compilation.
P)g$ , o+ !,
b. 1nce the compilation succeeds! close the compilation status dialog box and the lab-9dra9chanmatch.ps.c notepad. #. *ake the 2ro4ect editor active by clicking on it (. 5ouble/click on one of the mobile nodes to open the associated node model
>. *odify the channel match pipeline stage a. Aight/click on the ra_#0 radio transmitter module and select ,di# 1##ribu#es
P)g$ *" o+ !,
b. :lick on the value of the chanma#ch model attribute to bring up a popup of possible pipeline stages. c. 0elect lab2_dra_chanma#ch.
d. :lick
/ to accept the attribute change
e. 0elect File " 'ave to save the attribute change and close the node editor. ?. Aeturn to the %#-> pro4ect window. ). 6ou could 4ust run the simulation again! but you are going to use a different scenario to be able to compare some statistic between executions. %$. 0elect 'cenarios " +u!lica#e 'cenario" %%. 0et the 'cenario name to chanma#ch
P)g$ ** o+ !,
%-. :lick 1D %'. 2ress %#rl&'hif#&( to run the simulation for the new scenario %7. 1nce the simulation completes! write down the following information8 a. Total number of events899999999999999999999999 b. Average 0peed8999999999999999999999999999999events"sec c. :urrent 0peed8999999999999999999999999999999events"sec d. .lapsed Time89999999999999min.999999999999999sec. %#. :lose the dialog box when you are done reviewing it. 6ou can also see the 5.0 log to review the speed information.
P)g$ *! o+ !,
%(. 0elect +,' " (esul#s " %om!are '#a#is#ics"
P)g$ *- o+ !,
%>. :lick on Elobal .T. 5elay (msec) under the Elobal 0tatistics area.
%?. *ake sure that the pop ups are set to 1verlaid 0tatistics! All 0cenarios! and As s! then click 0how
P)g$ *# o+ !,
The two graphs are exactly identical! which is why you don=t see a red graph. 6ou can check the other statistics if you want (by selecting 0tacked 0tatistics). %). :lose the %om!are (esul#s dialog box -$. :lose the Elobal .T. 5elay (msec) graph (and any other statistics you might have displayed). Fhen asked to hide or delete the graph! click on +ele#e
0peedwise! things are a bit better! aren=t theyC 3ow a transmitter channel only tries all channels once. After that! subse&uent transmissions from that channel will have a receiver group only containing receiver channels with matching fre&uency. :an this dynamic receiver group trimming be used elsewhereC :ertainly. Fhat happens before the channel matchC The closure stage! where the simulation figures out if a signal can actually reach the receiver channel. 0o you could do 4ust the same as for the channel match. f the closure stage fails! remove the receiver channel from the receiver group of the transmitter channel. <ut dealing with the closure stage is a bit trickier. :hanging a channel fre&uency is something that is explicitly done in some model code. 0o it is easy to make sure that such code also resets the channel receiver group appropriately if the fre&uencies are changed. 3ote that you can add a receiver channel to all receiver groups simply using op_radio_txc1_rxc1_add (O !_O23*#_),*4-%($5, <rxc1ob6id>) 1n the other hand! closure is based on the positions of the endpoints. These positions can be explicitly changed by model code or implicitly by the kernel using tra4ectories! vectors! etc. 0o it can be a lot harder to know when to reset or increase a receiver group. 1ther pipeline stages that would be good candidates are the power stage (drop stuff that is too weak to affect other transmissions and to generate a valid packet) or the antenna gain stages (eliminate packets where the gain is going to be too small for directional antennas). #onclusion This illustrates the impact of using dynamic receiver groups to reduce the amount of computations performed during a radio transmission. The same techni&ue can be used in various other pipeline stages.
!$% & LA' 2
P)g$ *. o+ !,
Lab ,: #aching -ith a -ireless )omain

n this lab you are going to use a Fireless 5omain model to further reduce the amount of work performed by the simulation. The various mobile nodes are changing their positions every %$$ seconds! and broadcasting messages an average of once a minute. 0o this means that typically a node will communicate times with matching ob4ects between moves. @urthermore the moves are not that big! representing humans walking around (folks moving at about #$ meters in latitude and longitude per %$$ seconds in not too friendly terrain ). 0o the closure! power loss! and propagation delay computations between two positions are likely to be &uite similar. .ventually nodes will have moved enough that data needs to be recomputed. <ut this depends on the expected precision of the power loss and the propagation delay. n other words! it=s possible to create a cache for the transmission pipeline stage results! which 4ust happens to be what the Fireless 5omain models are for. A wireless domain is used to divide some domain into clusters! so that values computed between two clusters can be reused later on. 1ne approach is to consider the domain as a physical entity (a geographic area) and divide it into some grid so that any node in a cell of the grid can use previously computed data. There are two examples of such wireless domain models in the 123.T 0tandard *odel ;ibrary. Another approach! which you are going to implement in this lab! is to consider the domain as a logical entity. .ach node is its own logical cluster! and the wireless domain is used to cache the pipeline stage computations between pairs of nodes (well! really pairs of channels). The first time a node communicates with another! that information will be cached to be reused in later communications. Fhen the nodes update their positions! they will decide if they have moved enough to consider flushing the part of the cache related to them. Using reference model f you want to skip the coding part in this lab! do the following %. 0elect File " !en -. :hange the File of #y!e$ popup to ;ireless +omain Model (last entry in the menu) '. 5ouble/click on :d1527_ref 7. 0elect File " 'ave 1s" #. 0ave the model as :d1527. 6ou will be asked if you should overwrite the existing model.
P)g$ */ o+ !,
(. :lick
/ to overwrite the incomplete model.
>. 3ow skip to Using a wireless domain instance to speed things up
P)g$ *0 o+ !,
Defining the Wireless Domain model %. 0elect File " !en -. :hange the File of #y!e$ popup to ;ireless +omain Model (last entry in the menu) '. 5ouble/click on :d1527
This wireless domain model is partly defined. 6ou are going to implement three of the re&uired callbacks. <ut first let=s review the state of the model. The built/in attributes have been left with their default values. 3ote that the 313. setting for the chanma#ch! closure! and !ro!del model attributes does 31T mean the same thing as a 313. value in a wireless transmitter or receiver module. n this case! it means that the wireless domain does not provide its own pipeline stages to replace settings on transmitter modules associated with the wireless domain.
P)g$ *1 o+ !,
7. :lick on the +efine" button to open the Model 1##ribu#es dialog box
#. 1ne attribute (Mobile Model) is defined. *ake sure it is selected and click on the ,di# -ro!er#ies button
.ach wireless domain instance will only cache information for a specific node model! since we know that the models have non/overlapping fre&uency bands. (. :lick %ancel twice to close the Attribute and *odel Attributes dialog boxes without changing their contents.
P)g$ *, o+ !,
>. :lick on the ,di# ;ireless +omain <eader =loc3 (
) toolbar button.
The wireless domain uses a sparse -5 array. This will allow fast (constant/time) access to any cached value (two array indirections)! but at the cost of additional memory usage. The bigger the network! the larger the amount of memory being used. nitially the sparse array has all of its GaddrH values set to 12:93 ;. Actual data elements will be added as successful communications are established between a transmitter and receiver channel. ?. :lick %#rl&; (or select File " %lose) to close the +eader <lock window
P)g$ !" o+ !,
). 3ow click on ,di# ;ireless +omain 2ni# %allbac3 (
) toolbar button
This callback has already been written. t performs the following tasks8 a. terate through the mobile nodes looking for the ones with the matching model! setting up the :ireless domain attribute on the transmitter and receiver channels b. Allocate the domain state (the sparse array) and set up the arrays of pointers for the appropriate channel 5s %$. :lose the editor when you are done reviewing the init callback. The membership! info get! and info set callbacks remain to be defined. o The membership callback is invoked by the simulation kernel when a transmission starts to check if a given transmitter"receiver module is considered part of the wireless domain area of coverage! and if so to obtain an appropriate cluster id (the wireless domain model defines what=s a cluster id). The info get callback is invoked by the kernel before the closure pipeline stage. This allows the wireless domain to retrieve any available values from its cache to skip pipeline stage invocations.
P)g$ !* o+ !,
The info set callback is invoked by the kernel to allow the wireless domain to cache newly computed pipeline stage values. This will be invoked after the closure! channel match! propagation delay! and antenna gain pipeline stages.
%%. *embership :allback a. :lick on the ,di# ;ireless +omain Membershi! %allbac3 ( ) toolbar button
As mentioned earlier! the cluster id is defined and understood by the wireless domain. t is an opa&ue value for the kernel! which only passes it to the various callbacks. ts purpose is to provide an appropriate fast reference to cached information. n this case! the cache information is organi,ed around the channel 5s. Accessing a cache value means knowing the transmitter and receiver channel 5s involved in a communication. 0o the cluster 5 is simply the channel 5. b. Add the following line between the @ 3 and @A.T statements *id_ptr " $.im _/cl-ster_Id,channel_id; c. 0elect File " 'ave to close the editor and apply the changes.
P)g$ !! o+ !,
%-. nfo Eet :allback a. :lick on the ,di# ;ireless +omain 2nfo >e# %allbac3 ( ) toolbar button
Eiven a transmitter (xmit9cluster9id) and a receiver (rcvr9cluster9id)! this callback is responsible for figuring out if there is some cached data and if so to return that cached data to the kernel. n this example! it means i. Bse the transmitter 5 as an index in the first dimension of the -5 sparse array. ii. Bse the receiver 5 as an index in the second dimension of the -5 sparse array for the transmitter 5 entry iii. :heck if the array element is 12:93 ; (not cached) or an actual data element. f the latter! copy that data element into the kernel/provided info9ptr argument. The callback also provides a continuation9ptr argument that can be used to store a reference to some cache data structure for faster access in a subse&uent info set callback. n this example! we are going to use the continuation9ptr to store the address of the -5 sparse array
P)g$ !- o+ !,
cell that was found to contain an 12:93 ; element! so that the info set callback can create that element. b. Bncomment the code between lines %#/%> and -#/7> by deleting the 7if 8 and 7endif statements. c. :ode review the changes. d. 0elect File " 'ave to close the editor and apply the changes. %'. nfo 0et :allback a. :lick on the ,di# ;ireless +omain 2nfo 'e# %allbac3 ( ) toolbar button
This callback is invoked by the simulation kernel after each appropriate pipeline stage of a radio transmission @ a cache get callback was invoked and some data was not present. n this case! initially no data is cached. 0o the first time a transmission is attempted between a transmitter channel and a receiver channel! the cache get will return 12:93 ;! and the 7 pipeline stage invocations for the transmission between the channels will cause info set callbacks. ;ater transmissions will get the cached data.
P)g$ !# o+ !,
0o what needs to be done is i. :heck if there is already a caching element. ii. f not! create one iii. Bpdate the caching element with the data provided by the simulation kernel. b. Bncomment the code between lines %7/%# and -#/7# by deleting the 7if 8 and 7endif statements. c. :ode review the changes. d. 0elect File " 'ave to save the changes to close the editor and apply the changes. %7. :ompile the now complete model using the %om!ile ;ireless +omain Model ( button. %#. :lose the compilation status dialog box and the Fireless 5omain *odel. Using a wireless domain instance to speed things up %. *ake the 1527 pro4ect active -. 0elect 'cenarios " +u!lica#e 'cenario" '. 0et the new scenario name to 1:d 7. 1pen the b.ec# -ale##e ( ) ) toolbar
#. 0elect the :d1527 wireless domain ob4ect in the ob4ect palette (. :lick anywhere in the 2ro4ect area and drag to define a rectangle. >. :lick again to complete the rectangle. 1nce the definition is complete the rectangle switches to a blue outline. Aight click to end the operation. f the wireless domain were physically/based! the rectangle would be used to define the geographic area of interest. <ut because the example used in this session is logical! the actual rectangle is only useful to set the attribute of the wireless domain. The wireless domain is now set to cache the transmission information between transmitters and receivers of instances of the %#->9'$*+, node model (default value of the *obile *odel attribute of the model). ?. +it %#rl&'hif#&( to run the simulation ). 1nce the simulation completes! write down the following information8 a. Total number of events899999999999999999999999 b. Average 0peed8999999999999999999999999999999events"sec c. :urrent 0peed8999999999999999999999999999999events"sec d. .lapsed Time89999999999999min.999999999999999sec.
P)g$ !. o+ !,
+ow does this compare with the information obtained at the end of ;ab -C %$. :lose the dialog box when you are done reviewing it. 6ou can also open the 5.0 log to see the speed information. %%. As for ;ab -! select +,' " (esul#s " %om!are '#a#is#ics" %-. :hoose Elobal Throughput (bits"sec) and click 0how
%'. Things look &uite similar! but there is a difference. f you ,oom in the area shown above! here is the difference8
P)g$ !/ o+ !,
Fhy some differenceC Aemember that each node moves a little bit every now and then. The wireless domain caches the information generated from the first transmission between two nodes. f the nodes= closure was feasible at the time of the first transmission any latter transmissions will use that same data. <ut in reality the nodes might have moved in such a way that later transmissions are no longer possible. 0o while the simulations in labs % and - would not have achieved the transmissions (thus lower throughput at that time)! lab ' is incorrectly allowing some transmission to take place. The longer the simulation! or the bigger the nodes= moves! the higher the imprecision. To eliminate the issue! you would have to improve the Imovement= process model used in each mobile node so that the wireless domain cached information is flushed out once the node has moved enough. %7. :lose and delete the various statistics windows. Using wireless domain instances to speed things up even more
2utting one wireless domain instance took care of caching some transmission information for only one third of the nodes. 0o let=s cache information for all the nodes using more wireless domain and see the overall impact. %. n the pro4ect editor! place two more wireless domain instances and right click to end the operation.
-. 0et the *obile *odel attribute of one of these new instances to 1527_60M<z
P)g$ !0 o+ !,
a. Aight click on the blue rectangle (that can be tricky. 1ne easier way is to right/click on an ob4ect that overlaps the rectangle. This will bring up a menu showing the various elements where the cursor clicked! including the wireless domain ob4ect.)
b. n the 1##ribu#es dialog box! click on the Mobile Model attribute ?alue to change the default %#->9'$*+, to 1527_60M<z.
c. :lick
/ to accept the change.
'. 0et the *obile *odel attribute of the last wireless domain instance to 1527_90M<z. 7. Aun the simulation and write down the usual information Total number of events89999999999999999999999 Average 0peed899999999999999999999999999999events"sec :urrent 0peed899999999999999999999999999999events"sec .lapsed Time8999999999999min.999999999999999sec.
P)g$ !1 o+ !,
#. :lose the dialog box when you are done reviewing it. 6ou can also open the 5.0 log to review the results. #onclusion n this lab you have been introduced to the potential of wireless domains. They provide a convenient mechanism to cache some transmission information so that the simulation kernel can perform transmissions faster. Fireless domains are useful if some of the transmission pipeline stages involve complex computations that are not likely to change much if any between transmissions. The idea is to trade space (the cache) for time (the computation) to allow faster simulations. <ut this will only provide you with speed gains if you don=t have to spend too much time maintaining the cache or if you can use the cached information multiple times before updates.
!$% & LA' ,
P)g$ !, o+ !,

Lab Manual For Session 1527: Accelerating Wireless Simulations Using Scalability Techniques

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Lab Manual For Session 1527: Accelerating Wireless Simulations Using Scalability Techniques

Transféré par

Droits d'auteur :

Formats disponibles

1527 Accelerating Wireless Simulations Using Scalability Techniques

1527 Accelerating Wireless Simulations Using Scalability Techniques

1527 Accelerating Wireless Simulations Using Scalability Techniques

1527 Accelerating Wireless Simulations Using Scalability Techniques

and clicking under *essage to display the log entry

1527 Accelerating Wireless Simulations Using Scalability Techniques

1527 Accelerating Wireless Simulations Using Scalability Techniques

1527 Accelerating Wireless Simulations Using Scalability Techniques

1527 Accelerating Wireless Simulations Using Scalability Techniques

Lab 2: %ynamically (e)ucing (ecei"er *rou+s

c. n the tree view! expand the left of it

1527 Accelerating Wireless Simulations Using Scalability Techniques

1527 Accelerating Wireless Simulations Using Scalability Techniques

1527 Accelerating Wireless Simulations Using Scalability Techniques

/ to accept the attribute change

1527 Accelerating Wireless Simulations Using Scalability Techniques

1527 Accelerating Wireless Simulations Using Scalability Techniques

%(. 0elect +,' " (esul#s " %om!are '#a#is#ics"

1527 Accelerating Wireless Simulations Using Scalability Techniques

1527 Accelerating Wireless Simulations Using Scalability Techniques

1527 Accelerating Wireless Simulations Using Scalability Techniques

Lab ,: #aching -ith a -ireless )omain

1527 Accelerating Wireless Simulations Using Scalability Techniques

/ to overwrite the incomplete model.

>. 3ow skip to Using a wireless domain instance to speed things up

1527 Accelerating Wireless Simulations Using Scalability Techniques

1527 Accelerating Wireless Simulations Using Scalability Techniques

1527 Accelerating Wireless Simulations Using Scalability Techniques

>. :lick on the ,di# ;ireless +omain <eader =loc3 (

1527 Accelerating Wireless Simulations Using Scalability Techniques

). 3ow click on ,di# ;ireless +omain 2ni# %allbac3 (

1527 Accelerating Wireless Simulations Using Scalability Techniques

1527 Accelerating Wireless Simulations Using Scalability Techniques

1527 Accelerating Wireless Simulations Using Scalability Techniques

1527 Accelerating Wireless Simulations Using Scalability Techniques

1527 Accelerating Wireless Simulations Using Scalability Techniques

1527 Accelerating Wireless Simulations Using Scalability Techniques

1527 Accelerating Wireless Simulations Using Scalability Techniques

/ to accept the change.

1527 Accelerating Wireless Simulations Using Scalability Techniques

Vous aimerez peut-être aussi