Statistics
| Branch: | Revision:

root / PORTING @ master

History | View | Annotate | Download (3.99 KB)

1
 Porting an OMNeT++ model to Horizon
2
 ===================================
3

    
4
 Porting a given model to run on top of Horizon is relatively straightforward.
5

    
6
  * New base class for modules (OBSOLETE!!!)
7
	We used to have a separate base class for asynchronous modules. If you are
8
	still using this class (cAsyncModule), please go back to cSimpleModule.
9
	cAsyncModule is no longer required nor included.
10

    
11
  * No Module_Class_Members() macro
12
    Remove the Module_Class_Members() macro if it is used in your modules.
13
	This macro is not compatible with Horizon and also not needed.
14

    
15
  * No findObject
16
    In Horizon, the ownership handling of OMNeT++ is partly disabled to allow for
17
    an efficient parallel execution: Child modules still know their parent, but the
18
    parents do not know their children. Hence, it is not possible to find a
19
    child object this way.
20
    cQueue provides a set of replacement methods that allow to search for an
21
    object in the queue:
22
     - findObjectByName(const char* name)
23
     - removeByName(const char* name)
24
     - containsByName(const char* name)
25

    
26
  * Random number generation (OBSOLETE!!!)
27
    We used to require the use of numGen->uniform(a,b) instead of uniform(a,b)
28
	for using local RNGs instead of a global, not-thread-safe RNG. We changed
29
	the default behavior. The numGen object no longer exists, you automatically
30
	use local RNGs when you run uniform(a,b).
31
	If you are still using numGen->uniform(a,b), please go back to uniform(a,b).
32
    Seeding of the local random number generators is done by means of a global
33
    seed generator RNG. During the sequential initialization phase of the model,
34
    every model requests a seed for its local RNGs from the central seed generator.
35

    
36
 Performance optimization
37
 ========================
38
 
39
 The migration process described above only allows to run a model on top of 
40
 Horizon, but it does not consider parallel performance. This section tries to
41
 give some hints on how to achieve a good parallel performance.
42
 
43
   * Specify event durations
44
     Horizon can only process events in parallel if 
45
       i) they are discrete and start at the same point in simulated time or
46
      ii) if they are expanded events, i.e., they span a period of simulated time,
47
          and those periods overlap.
48
     To define a durations for an expanded event, a specific method inside of the
49
     module needs to be implemented:
50
     
51
      - simtime_t getProcessingDelay(cMessage* msg)
52
     
53
     This method receives a message and returns the associated duration of this
54
     event. If it is not implemented, the default duration for an event is 0.
55
     
56
     NOTE: When defining an expanded event a few issues need to be considered:
57
     
58
      - Expanded events may only create new events which start AFTER the current
59
        event finished. I.e., if an event spans from 1.0s to 1.5s
60
        in the simulation, ALL events it sends and schedules may ONLY start at or
61
        after 1.5s in the simulation.
62
        One can access the duration of the current expanded event by calling
63
        getCurrentProcessingDelay() and add this to the send/scheduleAt call:
64
        send(msg, "gate")  ==>  sendDelayed(msg, getCurrentProcessingDelay(), "gate")
65
        
66
      - Defining expanded events changes the timing of the model. This might
67
        potentially mess up the order of events. 
68
     
69
   * Splitting functionality
70
     For data consistency reasons, only one event is active inside of each module.
71
     In order to achieve as much parallelism as possible, parallel computations
72
     that do not depend on each other should be conducted in separate instances
73
     of modules.
74
     Example: pathloss calculation. Multiple such calculations can run in parallel
75
     because the only depend on the position of the sender and receiver. If there
76
     is only one instance of the "PathlossModule", all calculations must be done
77
     sequentially. Hence, it is better to create multiple instances (for example
78
     one for each receiver module) which then calculate the pathloss in parallel
79
     to the other modules.
80
 
81