1551 LabManual OPNK2004

1551 - Accelerating Simulations with the Parallel Kernel
Lab Manual for Session 1551: Accelerating Simulations with the Parallel Kernel
Lab 1: Behavioral Differences Between Sequential an Parallel !"ecutions
This lab doesnt involve any modeling, per se. You will run the supplied the example model to compare the differences in OPN T !imulation "ebugger #O"$% outputs between the parallel and se&uential simulation 'ernels. You will (eview the code in the models. (un discrete)event simulations of the model twice * once in se&uential mode and once in parallel mode. +ompare the O"$ outputs to see how the 'ernels have different representations of various 'ernel ob,ects such as events, pac'ets, and -+-s, and how the number of events generated by the radio transmission pipeline differs.
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+ !*
Review of the models .. !tart Modeler by double)clic'ing on the /odeler icon on the des'top. The OPN T /odeler ...0 application launches and displays its splash screen. 1. Open the lab1 pro,ect. a. !elect the File 2 Open menu. The Open dialog box appears. b. "ouble)clic' on the lab1 entry in the 3iles4 list. The resulting Pro,ect editor should show you the demo scenario with three nodes named send, rcv1, and rcv2.
You can double)clic' on the nodes and the processor modules to review the associate code. The node behaviors are described below.
P)g$ ! o+ !*
The send node is expected to perform the same operation twice. That operation consists of .. +reating an unformatted pac'et. 1. "isplay the pac'et -" in three forms4 a. 5formatted6 by the 'ernel using op_pk_id_str_get. b. "ecimal display of the raw integer value. c. 7exadecimal display of the raw integer value. 8. +reate and associate an -+- with the pac'et. 9. Print the pac'et using op_pk_print. :. $roadcast the pac'et using a wireless transmission. ;. <enerate and print a random value between 0 and .00. The receiver nodes are simply reacting to received pac'ets. They display the received pac'et -"s using the same three forms as the sender, and then generate a random value. The operations are timed so that the pac'et receptions ta'e place between the pac'et sends. Executing the simulation with a sequential kernel =. Press Ctrl-Shift-R to start the simulation using the current configuration. This is e&uivalent to choosing DES 2 Run Discrete Event Simulation. The simulation is configured to use the development 'ernel and the OPN T "ebugger #O"$%. You should see an OPN T +onsole window with messages associated with the simulation loading and initiali>ation, and finally an odb prompt.
?. @t the odb prompt, type cont to let the simulation run to completion. Once the simulation completes, you will see the message Press <ENTER> to continue. Do !O" press #E!"ER $et. A. /a'e a copy of the console output for later comparison. a. !croll bac' the console output until you see the odb cont command you entered.
P)g$ , o+ !*
b. +lic' on that line and drag the mouse down until you reached the end of the simulation output #the display should scroll along with you%.
c. /a'e sure you are selecting the entire width of the display, then press #E!"ER #this will copy the selected area into a buffer and the white selection mar'ing will disappear.%
d. -n the Pro,ect editor, select Edit 2 Open Edit %ad.
e. -n the dit Pad window, select Edit 2 %aste. You should now have a copy of the simulation output in the edit pad. Beep that edit pad around for comparison with the parallel execution later. f. !elect File 2 Save and save the content of the dit Pad as se&uential in C'(op)models. .0. You can now press #E!"ER in the OPN T console to terminate the simulation.
P)g$ # o+ !*
... +lose the Simulation Se&uence dialog box.
Executing the simulation with a parallel kernel .1. +lic' on the Confi*ure+Run Discrete Event Simulation toolbar button.
.8. -n the resulting Confi*ure Run DES dialog box, clic' on the E,ecution tree element.
P)g$ - o+ !*
.9. +lic' on the -dvanced tree element.
.:. +lic' on the .ernel %references tree element.
P)g$ . o+ !*
.;. Notice the preference values which reflect the default settings for a se&uential 'ernel. .=. +lic' on the .ernel "$pe tree element.
P)g$ / o+ !*
.?. !elect the %arallel radio button. .A. +lic' on the .ernel %references tree element. The 'ernel settings have changed to reflect the default settings for a parallel 'ernel. -f any of these popups had been set to an explicit value instead of "efault, the value would not have changed.
10. +lic' Run. Once again, an OPN T console should appear in which you can see the loading and initiali>ation of the simulation. Notice that the process models and pipeline stages are being recompiled. This is because the ob,ect files generated for the se&uential execution cannot be used for a parallel execution. -f you loo' at the content of C'(op)models, you will see ob,ect files ending in dev81.i0.pr.ob, and others ending in mtdev81.i0.pr.ob,. 1.. @t the odb prompt, type cont. 11. Once the simulation terminates, select the output of the simulation and paste it into a second edit pad li'e you did for the se&uential output. 18. !ave that second edit pad as parallel in C'(op)models. 19. +omplete the simulation by pressing #E!"ER . 1:. +lose the Simulation Se&uence dialog box.
P)g$ 0 o+ !*
Comparing the outputs 1;. Place the two edit pads side by side, with the se&uential one on the left. 1=. Now compare the two sets of outputs to notice difference between se&uential and parallel runs of the same model. a. Pac'et -"s4 i. The se&uential version shows you the first pac'et as -" 0, in all formats
Transmit 5: Creating new packet ID 0 (0 - 0x0)
i. On the other hand, the parallel version shows you the first pac'et as the 0th pac'et of the module that created that pac'et, namely module :. The decimal integer value is really of no use to you at this point.
Transmit 5: Creating new packet ID 5:0 (21474836480 - 0x500000000)
i. The output from the receiver nodes shows you that each one got a different pac'et #as expected%. $ut while the se&uential copy was numbered . #since it was the next generated%, the parallel copy is actual the 0th for module ;, the radio transmitter that performed the broadcast.
Receiver !: Received packet ID 5:0 ( "#$#%!&#%0 - 0x500000000) Receiver "&: Received packet ID 6:0 ( 5$&'%0!$$& - 0x&00000000)
i. Cater pac'et creations increase the module indexes, so that we get :4. and ;4., as opposed to 1 and 9. b. Tree -"s and -+- -"s4 i. !ame behavior for the tree and -+- -"s, as shown in the pac'et printout
P)g$ 1 o+ !*
c.
vent -"s4 i. The O"$ event banners show two different event -"s. .. schedule -"4 This indicates the order in which the event was scheduled. 1. execution -"4 This indicates the order in which the event was actually executed. ii. -n the se&uential execution, both -"s are monotonically increasing. !o the banner of the second pac'et print indicates that the event was the 8rd #0)based, so D1% event scheduled, it was scheduled while executing the .st event, and was the .0th executed.
( Time : ( .vent : ( 2o,rce : ( Data 4 5od,0e :
"00 sec) *00d 00+ 0"m #0s . 000ms 000,s 000ns 000psexecution ID (9), schedule ID (#2)) t/pe (se01 intrpt) execution ID (0)) top.s,3net.send.gen (processor) : code (0) top.s,3net.send.gen (processor) *process id: 0-
i. The event banner for the parallel execution gives you similar information, but both -"s are now module)based. -t ma'es it a bit tric'ier to chec' the overall order of events, but a lot easier to determine the ordering of events generated by a single module.
( ( ( ( Time : .vent : 2o,rce : Data : 4 5od,0e "00 sec) *00d 00+ 0"m #0s . 000ms 000,s 000ns 000psexecution ID (5:1), schedule ID (#5:1)) t/pe (se01 intrpt) execution ID (5:0)) top.s,3net.send.gen (processor) code (0) : top.s,3net.send.gen (processor) *process id: 0-
i. That information also appears in the warnings and errors generated by the simulation, as shown in the (ecoverable rror in the example4
666 Recovera30e .rror 444 7acket (5:2) is o1 a t/pe t+at does not contain 1ormatted 1ie0ds. T ("00)) .8 (5:")) 59D (top.s,3net.send.gen)) :7 (op_pk_n1d_get_int! )
d. (andom numbers4 i. The random values generated in the parallel execution are different from the ones from the se&uential execution. ii. $ut if you were to add another receiver module and run the simulations again, you will notice that while the additional module in the se&uential execution affects the transmitter values, the parallel execution generates the same values for the transmitter. This is because the parallel 'ernel uses per)module random number streams, so adding additional modules does not perturb stream of random numbers generated by existing modules.
P)g$ *" o+ !*
e.
vent count4 i. The se&uential execution had .? events.
;----------------------------------------------------------------------------; ; 2im,0ation Comp0eted - Co00ating Res,0ts. ; ; .vents: Tota0 (18)) <verage 2peed ($ events=sec.) ; ; Time: .0apsed (0. 5 sec.)) 2im,0ated (" +r. 0 min. 0 sec.) ; ; 2im,0ation >og: entries ; ;----------------------------------------------------------------------------;
i. The parallel one had 11 events..

;----------------------------------------------------------------------------; ; 2im,0ation Comp0eted - Co00ating Res,0ts. ; ; .vents: Tota0 (22)) <verage 2peed (%% events=sec.) ; ; Time: .0apsed (0. 5 sec.)) 2im,0ated (" +r. 0 min. 0 sec.) ; ; 2im,0ation >og: entries ; ; .v=tce00: <vg? .00 5ax?# se@.evA?%".% A<ctv?"00.0 AB0ck?0.0 Tavg?".0 ; ;----------------------------------------------------------------------------;
This is because the two radio transmissions added events to process the pipeline stages 1 through : for the two receivers. 1 transmission receiver events 1 transmissions E 9 additional events. Of course, all the settings used for the parallel 'ernel by default can be used in the se&uential one by explicitly setting them. They will cause the simulation to run a little slower in se&uential mode though, but this is typically a fraction of a percent. #onclusion $y default the parallel execution uses a module)based approach for generating various -"s and random values. -t also adds extra events for radio transmissions. @ll of these are designed to eliminate contention for resources in the 'ernel and to allow maximum parallel execution of events. @ se&uential execution can be set up to also use the module)based approach, but defaults to the global approach to match the behavior that most OPN T users are accustomed to seeing.
!$D %& LAB 1
P)g$ ** o+ !*
Lab ': Ma(ing a mo el M)*&rien l+ an M)*Safe

This lab illustrates the various concepts of ma'ing model code /T)3riendly and /T)!afe for use in parallel simulations. You are given an existing model that is built for normal #se&uential% execution. You will examine this model and ma'e changes to a particular process model to enable it to run in the parallel simulation 'ernel. Review of the models 1?. !tart Modeler/ if it is not already running. 1A. Open the lab0 pro,ect. a. !elect the File 2 Open b. "ouble)clic' on the lab0 entry in the 3iles4 list. The resulting Pro,ect editor should show you the starburst scenario with several interconnected star topologies.
P)g$ *! o+ !*
This model consists of several stars of sendFreceive 5edge6 nodes around a central hub. The hubs are connected to each other in nearly #but not exactly% a full mesh. Githout going into a great deal of detail, the hub node and associated processes obtains pac'ets sent to it and attempts to deliver them to a connected edge node if the destination is directly connected to the hub #5local net6%. The hub will forward pac'ets to a neighboring hub at random if the destination edge is not directly connected to the hub #5remote net6%. The hub models have already been mar'ed as /T)!afe and therefore will not be part of this lab. You will concentrate on ma'ing the 5edge6 modules /T)safe. 80. "ouble)clic' on an 5edge6 node to see its node model #or open the lab0)ed*e node model directly%.
The edge node consists of a pac'et generator processor #sender% that sends pac'ets out over its transmitter and a receive processor that receives pac'ets and is a simple sin' for them. Ge will be concentrating our attention on the sender.
P)g$ *, o+ !*
8.. "ouble)clic' on the sender processor to see its process model.
The sender process performs several stages of initiali>ation #idle, calc)receivers, set)dest)dist, set)map% and then transitions to send)pac1et to continuously send out pac'ets. The initiali>ation stages are executed at .)second intervals from each other. Cets try to compile the lab0)ed*e process for parallel execution to see what happens. Try to compile lab2_edge process for parallel execution 81. !elect Compile Compile Code 2-dvanced3. The advanced compilation dialog box appears.
P)g$ *# o+ !*
Note that the "ar*et Simulation .ernels' only has one target selected. You will want to select the other chec'mar's to re&uest that the model be compiled for both se&uential and parallel execution. 88. Put chec'mar's in all 9 enabled chec'boxes in "ar*et Simulation .ernels. 89. +lic' Compile.
Ghy did we have compile errors for the parallel target but not the se&uentialH $ecause the model code was not made /T)3riendly. 3or example, 'ernel procedures that re&uired a !imulation +ontext during parallel execution were not being passed the context. You will fix it in this lab. 8:. +lose the errors and warnings dialog box and the compile dialog box. Examining the model code -f you wish, ta'e : minutes to examine the process model on your own and see if you can identify the areas that need fixing. Note to chec' the code in the 3unction $loc' and 7eader $loc' as well as the contents of the states. The body of code is not very large. Once you are done, or if you want to s'ip this step, move to the next procedure, which identifies the areas that need fixing.
P)g$ *- o+ !*
Review of model fixes to perform @s mentioned in this session, particular areas we must address are .% Ise of 'ernel procedures that re&uire a simulation context #to ma'e the model /T)3riendly% and 1% @ccess to global variables #to ma'e the model /T)!afe%. To review, /T)3riendly code can compile and run in the parallel 'ernel. /T)!afe code is /T) 3riendly code that executes with correct results. Non)/T)3riendly code cant even compile. !imply ma'ing code /T)3riendly but not /T)!afe will allow it to execute, but not necessarily with correct results #remember the example of the function to increment the global variable%. 7ere is a listing of areas in the model that need to be updated4 @ccess and updating of the receiver)count global variable in the calc)receivers state. o GhyH $ecause reading and updating a global variable is not /T)!afe. +reation of the receiver)map global variable in the set)map state. o GhyH !imilar to the reason for receiver)count4 processes may concurrently 5see6 the value of receiver)map as NICC and try to allocate memory for it. o -s the setting of receiver_map*m/_receiver_id- a problemH No * this access to the global turns out to be safe because each process instance will be updating a different 5slot6 of receiver)map and therefore concurrent access is safe. This is a subtle point, and when in doubt, you should protect access to globals with mutexes anyway. /issing 3-NF3OITF3( T macros in the functions within the function bloc'. o GhyH $ecause calls to 'ernel procedures re&uire a simulation context. The 'ernel calls within the executives of the state machine have implicit access to the simulation context. $ut functions defined in the function bloc' do not. The missing 3-NF3OITF3( T ma'e the code in the function bloc' not /T)3riendly. ake the lab2_edge process model T!"riendly and T!#afe
8;. 3irst, lets define a mutex, to control access to the calc)receivers and receiver)map global variables4 a. +lic' on the 4eader 5loc1 # % toolbar button.
b. @dd the following variable definition to the end of the bloc'4 7rgT_5,tex ( edge_m,tex ? CD>>E
P)g$ *. o+ !*
c. Ctrl-S to save the header bloc'. 8=. Now create the mutex at model initiali>ation time4 a. "ouble)clic' on the enter executives of the idle state and enter the following code at the end4 i1 (Fedge_m,tex) G edge_m,tex ? op_prg_mt_m,tex_create( 97C_5T_5DT.H_C9_97TI9C2) 0) Im,tex to access g0o3a0sJ)E K b. Ctrl-S to save the enter execs. c. $onus Juestion .4 since ed*e)mute, is itself a global variable that weve declared in the header bloc', why is it safe to chec' its value without first obtaining a mutexH d. $onus Juestion 14 how can we create mutexes to guard against multiple creation of mutexesH "ont we run into a problem that a mutex to guard a global is itself a global and therefore we have to 'eep creating mutexes to guard the mutexes to guard the globalsH 8?. Now use the mutex to control access to the globals4 a. Open the enter executives of the calc)receivers state and add the code in bold around the receiver)count use4 op p!" #t #utex loc$(ed"e #utex, %&' () (*)+, -% %&)I%-.)/ m/_receiver_id ? receiver_co,ntE receiver_co,ntLLE op p!" #t #utex unloc$ (ed"e #utex)/ b. Ctrl-S to save the enter executives. 8A. Open the enter executives of the set)map state. a. @dd the code in bold. op p!" #t #utex loc$ (ed"e #utex, %&' () (*)+, -% %&)I%-.)/ i1 (receiver_map ?? CD>>) G receiver_map ? prg_mem_a00oc (siMeo1 (int) ( receiver_co,nt)E K op p!" #t #utex unloc$ (ed"e #utex)/ b. Ctrl-S to save the enter executives.
P)g$ */ o+ !*
"ix code in the function block$ You have two ways to fix the code in the function bloc'. The first #using 3-NF3OITF3( T macros% is the fastest in terms of development time, but results in slightly slower execution. The second, using #3-NK/T% results in faster code but re&uires you to pass in the simulation context explicitly. Ge will employ one of each for the two functions in the function bloc'. 90. 3ix the build)pac1et function using 3-N macros. a. +lic' on the Function 5loc1 # % toolbar button.
b. @dd the 3-NF3OIT macros as follows4 void 3,i0d_packet (7acket (pkptr) G 0I- (1uild p2c$et)/ =( Ni00 in packet 1ie0d 1or destination (= op_pk_n1d_set (pkptr) OdestinationO) (int) op_dist_o,tcome (dest_dist_ptr))E op_pk_n1d_set (pkptr) On,m_+opsO) 0)E 0%*)/ K 9.. 3ix the schedule)ne,t)send function using F6!)M" and explicit simulation context arguments4 void sc+ed,0e_next_send (%& .I( '%-)+,) 345 %&) # . ) G do,30e next_send_timeE 0I- () (schedule next send)/ next_send_time ? op_dist_o,tcome (dist_ptr)E i1 (next_send_time 60) G next_send_time ? 0E K op_intrpt_sc+ed,0e_se01 (op_sim_time () L next_send_time) 0)E 0%*)/ K 98. Ctrl-S to save your function bloc' changes. 99. 3ix the prototype of schedule)ne,t)send in the header bloc'.
P)g$ *0 o+ !*
a. +lic' on the 4eader 5loc1 # b.
% toolbar button.
dit the prototype of schedule)ne,t)send as follows4 void sc+ed,0e_next_send (%& .I( '%-)+,) 345 %&))E
c. Ctrl-S to save your header bloc' changes. 9:. 3ix callers of schedule)ne,t)send to pass in the simulation context explicitly. a. @t the end of the enter executives code in both the set)map and send)pac1et states, modify the schedule)ne,t)send calls as follows4 sc+ed,0e_next_send (%& .I( '%-)+,) &)4 %&))E b. Ctrl-S in each enter executives edit window to save changes. 9;. You are now done with ma'ing your model /T)!afe and /T)3riendly. To verify this, recompile the model for all 'ernels4 a. !elect Compile c. +lic' Compile. -f the compilation is not successful, review your changes or as' a T@ for help. 9=. Now that the model compiles and your review has determined that it is /T)!afe, we can mar' it as safe for parallel execution. a. !elect the 6nterfaces Support %arallel E,ecution menu. Compile Code 2-dvanced3. b. Lerify that all 9 enabled chec'boxes in "ar*et Simulation .ernels are chec'ed.
9?. Ctrl-S to save the process model.
P)g$ *1 o+ !*
Running your model Though we dont have multiprocessor machines in the classroom, lets run the simulation using the parallel 'ernel anyway to see what happens. 9A. +lose any open process and node editors. :0. (eturn to the lab0 pro,ect. :.. +lic' Ctrl-R to configure the simulation 2e&uivalent to choosing DES Discrete Event Simulation% Confi*ure+Run
+lic' on the E,ecution tree element on the left side of the dialog box. :1. +lic' on the -dvanced tree element under E,ecution, then on the .ernel "$pe tree element to display the .ernel "$pe panel.
:8. !et the Bernel to 7se specific 1ernel for this simulation set and choose Optimi8ed. Then choose %arallel as the 'ernel type.
P)g$ !" o+ !*
:9. !et the !umber of processors to 9. Note that this is a contrived setting as we are wor'ing on uniprocessor machines. /ost li'ely, you would leave the value at 5/aximum6 to let the simulation ta'e advantage of all physical processors on your hardware.
::. +lic' Run to run the simulation. NOT 4 !imulation performance of parallel simulations on uniprocessor machines will be extremely poor. You are only performing this exercise to see how parallel simulations are to be launched, and not to see any reasonable indicator of performance on a true multiprocessor. #ummary You have successfully been able to ta'e a model written for use in se&uential simulations and made it safe to use in parallel simulations. $onus &uestion4 what difference would it ma'e if all the 5initiali>ation6 states were separated by 0.0s schedule intervals instead of ..0sH 7ow would this impact the code needed to ma'e the model /T)safeH -f you were running on a multiprocessor, you could compare the performance of this simulation versus its se&uential counterpart. $ut note that this model does not necessarily represent an ideal candidate for parallel simulation, and is rather meant to be a good demonstration of the type of modifications you would perform to ma'e existing model code /T)3riendly and /T)!afe.
!$D %& LAB '
P)g$ !* o+ !*

1551 LabManual OPNK2004

Uploaded by

Document Information

Original Description:

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

1551 LabManual OPNK2004

Uploaded by

Copyright:

Available Formats

1551 - Accelerating Simulations with the Parallel Kernel

1551 - Accelerating Simulations with the Parallel Kernel

1551 - Accelerating Simulations with the Parallel Kernel

1551 - Accelerating Simulations with the Parallel Kernel

d. -n the Pro,ect editor, select Edit 2 Open Edit %ad.

1551 - Accelerating Simulations with the Parallel Kernel

... +lose the Simulation Se&uence dialog box.

1551 - Accelerating Simulations with the Parallel Kernel

.9. +lic' on the -dvanced tree element.

.:. +lic' on the .ernel %references tree element.

1551 - Accelerating Simulations with the Parallel Kernel

1551 - Accelerating Simulations with the Parallel Kernel

1551 - Accelerating Simulations with the Parallel Kernel

1551 - Accelerating Simulations with the Parallel Kernel

( Time : ( .vent : ( 2o,rce : ( Data 4 5od,0e :

1551 - Accelerating Simulations with the Parallel Kernel

vent count4 i. The se&uential execution had .? events.

i. The parallel one had 11 events..

1551 - Accelerating Simulations with the Parallel Kernel

Lab ': Ma(ing a mo el M)*&rien l+ an M)*Safe

1551 - Accelerating Simulations with the Parallel Kernel

1551 - Accelerating Simulations with the Parallel Kernel

8.. "ouble)clic' on the sender processor to see its process model.

1551 - Accelerating Simulations with the Parallel Kernel

1551 - Accelerating Simulations with the Parallel Kernel

1551 - Accelerating Simulations with the Parallel Kernel

1551 - Accelerating Simulations with the Parallel Kernel

1551 - Accelerating Simulations with the Parallel Kernel

a. +lic' on the 4eader 5loc1 # b.

9?. Ctrl-S to save the process model.

1551 - Accelerating Simulations with the Parallel Kernel

1551 - Accelerating Simulations with the Parallel Kernel

You might also like

Lab ': Ma(ing a mo el M)&rien l+ an M)Safe