-
Notifications
You must be signed in to change notification settings - Fork 46
Running the Simulator
Elsa Gonsiorowski edited this page Feb 25, 2014
·
3 revisions
Now that you have built ROSS (and possibly learned a bit about building models), change to the rossnet-build/ross/models/wifi
directory. You should see several files including a wifi binary. Running the binary with the --help
flag should give the following output:
odin:wifi$ ./wifi --help
usage: wifi [options] [-- [args]]
802.11b Model:
--nlp=n number of LPs per processor (default 8)
--mean=ts exponential distribution mean for timestamps (default 1.00)
--mult=ts multiplier for event memory allocation (default 3.00)
--lookahead=ts lookahead for events (default 1.00)
--start-events=n number of initial messages per LP (default 1)
--memory=n additional memory buffers (default 100)
--run=str user supplied run name (default undefined)
ROSS MPI Kernel:
--read-buffer=n network read buffer size in # of events (default 50000)
--send-buffer=n network send buffer size in # of events (default 50000)
ROSS Kernel:
--synch=n Sychronization Protocol: SEQUENTIAL=1, CONSERVATIVE=2, OPTIMISTIC=3 (default 0)
--nkp=n number of kernel processes (KPs) per pe (default 1)
--end=ts simulation end timestamp (default 100000.00)
--batch=n messages per scheduler block (default 16)
ROSS MPI GVT:
--gvt-interval=n GVT Interval (default 16)
--report-interval=ts
percent of runtime to print GVT (default 0.05)
ROSS Timing:
--clock-rate=ts CPU Clock Rate (default 1000000000.00)
--help show this message
ROSS Kernel Build Options:
MEMORY
timing
QUEUE=splay
RAND=clcg4
NETWORK=mpi
CLOCK=amd64
GVT=mpi_allreduce
There are quite a few options available to us. Often, only one or two is necessary depending on your platform. On my Mac, for example, only one option is required: synch. The synch option tells ROSS which synchronization protocol to use. When run with the sequential protocol, I see the following:
odin:wifi$ ./wifi --synch=1
tw_net_start: Found world size to be 1
ROSS Core Configuration:
Total Nodes 1
Total Processors [Nodes (1) x PE_per_Node (1)] 1
Total KPs [Nodes (1) x KPs (1)] 1
Total LPs 8
Simulation End Time 100000.00
LP-to-PE Mapping linear
ROSS Event Memory Allocation:
Model events 124
Network events 50000
Total events 50124
*** START SEQUENTIAL SIMULATION ***
*** END SIMULATION ***
LP 0 had 4696 / 39957 failed Station to Access Point packets
LP 0 had 14243 / 39954 failed Access Point to Station packets
LP 1 had 4688 / 39930 failed Station to Access Point packets
LP 1 had 14242 / 39925 failed Access Point to Station packets
LP 2 had 4804 / 39905 failed Station to Access Point packets
LP 2 had 14191 / 39901 failed Access Point to Station packets
LP 3 had 4763 / 40009 failed Station to Access Point packets
LP 3 had 14238 / 40002 failed Access Point to Station packets
LP 4 had 4904 / 40114 failed Station to Access Point packets
LP 4 had 14209 / 40112 failed Access Point to Station packets
LP 5 had 4702 / 39867 failed Station to Access Point packets
LP 5 had 14180 / 39864 failed Access Point to Station packets
LP 6 had 4801 / 39972 failed Station to Access Point packets
LP 6 had 14440 / 39968 failed Access Point to Station packets
LP 7 had 4609 / 40009 failed Station to Access Point packets
LP 7 had 14251 / 40006 failed Access Point to Station packets
: Running Time = 0.8969 seconds
TW Library Statistics:
Total Events Processed 639431
Events Aborted (part of RBs) 0
Events Rolled Back 0
Efficiency 100.00 %
Total Remote (shared mem) Events Processed 0
Percent Remote Events 0.00 %
Total Remote (network) Events Processed 0
Percent Remote Events 0.00 %
Total Roll Backs 0
Primary Roll Backs 0
Secondary Roll Backs 0
Fossil Collect Attempts 0
Total GVT Computations 0
Net Events Processed 639431
Event Rate (events/sec) 712962.4
TW Memory Statistics:
Events Allocated 50124
Memory Allocated 60959
Memory Wasted 384
TW Data Structure sizes in bytes (sizeof):
PE struct 512
KP struct 104
LP struct 104
LP Model struct 328
LP RNGs 120
Total LP 552
Event struct 120
Event struct with Model 128
TW Clock Cycle Statistics (MAX values in secs at 1.0000 GHz):
Priority Queue (enq/deq) 0.0000
Event Processing 0.0000
Event Cancel 0.0000
Event Abort 0.0000
GVT 0.0000
Fossil Collect 0.0000
Primary Rollbacks 0.0000
Network Read 0.0000
Total Time 0.0000
TW GVT Statistics: MPI AllReduce
GVT Interval 16
Batch Size 16
Forced GVT 0
Total GVT Computations 0
Total All Reduce Calls 0
Average Reduction / GVT nan
The synch
option can take the following values:
- 1 (sequential): Instructs ROSS to use a sequential engine, i.e. the simulation will consist of only one processor (PE).
- 2 (conservative): Instructs ROSS to use a conservative engine, i.e. all LPs will have the same notion of virtual time.
- 3 (optimistic): Instructs ROSS to use an optimistic engine, i.e. LPs can have varying notions of virtual time, though rollbacks will be possible and a reverse event handler will be required in this case.
- 4 (optimistic debug): Executes ROSS in a serial simulation until it runs out of memory. Then it rolls every message back. This can be used to test rollback functions.
-
nkp
specifies the number of Kernel Processes (KPs) we have per Processing Element (PE). LPs are mapped onto KPs which aggregate the events processed by those LPs.
-
end
specifies the final timestamp to process. Discrete event simulations (typically) schedule a new event from within the event handler. Therefore, in the general case, it will never stop unless the simulator notices that it has simulated past the point of interest.
-
memory
specifies the amount of additional memory to allocate. This helps during simulations as we never dynamically allocate memory at runtime; we just perform a GVT and reclaim event memory. If you see a high number in the "Forced GVT" output above, try increasing this value. A good starting value for n would be 2 * batch * GVT.