gnu_radio_benchmark_example
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
gnu_radio_benchmark_example [2016/01/08 11:44] – mimbert | gnu_radio_benchmark_example [2017/11/15 16:05] – [Inspecting the example task] onicolas | ||
---|---|---|---|
Line 1: | Line 1: | ||
# GNU Radio benchmark example | # GNU Radio benchmark example | ||
- | This tutorial executes an OFDM transmission between two nodes in CorteXlab transmitting dummy packets between them. | + | This tutorial executes an OFDM transmission between two nodes in CorteXlab, transmitting dummy packets between them. |
- | We base this tutorial | + | We base this tutorial |
Line 14: | Line 14: | ||
</ | </ | ||
- | If this doesn' | + | If this doesn' |
If everything goes well you should get the CorteXlab welcome screen and an srvairlock prompt. | If everything goes well you should get the CorteXlab welcome screen and an srvairlock prompt. | ||
Line 20: | Line 20: | ||
## Inspecting the example task | ## Inspecting the example task | ||
- | Checkout | + | Retrieve |
< | < | ||
- | you@srvairlock: | + | you@srvairlock: |
you@srvairlock: | you@srvairlock: | ||
</ | </ | ||
- | Let's get inside and see what's all about: | + | Let's get inside and see what it's all about: |
< | < | ||
Line 33: | Line 33: | ||
you@srvairlock: | you@srvairlock: | ||
benchmark_rx.py | benchmark_rx.py | ||
- | benchmark_tx.py | + | benchmark_tx.py |
</ | </ | ||
- | Let go over each one of these files: | + | Let' |
* '' | * '' | ||
* '' | * '' | ||
* '' | * '' | ||
- | * '' | + | * '' |
- | Now, lets inspect the scenario description file, to understand what will happen during this experiment: | + | Now, let' |
< | < | ||
- | you@srvairlock: | + | you@srvairlock: |
</ | </ | ||
Line 58: | Line 58: | ||
# Scenario textual description | # Scenario textual description | ||
# | # | ||
- | desc base scenario for CorteXlab | + | description: |
# Experiment maximum duration | # Experiment maximum duration | ||
# Time after which the experiment is forced to stop | # Time after which the experiment is forced to stop | ||
- | # | + | # |
- | durat 5 | + | duration: 300 |
# Node list | # Node list | ||
Line 69: | Line 69: | ||
# | # | ||
# | # | ||
- | # | + | # nodes: |
- | # entry (entry point script relative to the task root) | + | # (machine): |
- | # exit (exit point script relative to the task root. Use " | + | # command: |
- | node4: | + | nodes: |
- | entry benchmark_rx.py | + | |
- | | + | |
- | node6: | + | node4: |
- | entry benchmark_tx.py | + | command: ./ |
- | | + | passive: true |
+ | |||
+ | | ||
+ | | ||
</ | </ | ||
- | The file is self-explanatory, | + | The file is self-explanatory, |
- | Lets go over each one now: | + | Let' |
* '' | * '' | ||
- | * '' | + | * '' |
- | * '' | + | |
* '' | * '' | ||
* '' | * '' | ||
Line 94: | Line 94: | ||
* '' | * '' | ||
* '' | * '' | ||
+ | * '' | ||
Same reasoning follows for the section on node6. So this is the scenario at hand: | Same reasoning follows for the section on node6. So this is the scenario at hand: | ||
Line 127: | Line 128: | ||
</ | </ | ||
- | And now we have a new file called '' | + | And now we have a new file called '' |
## Submitting the task | ## Submitting the task | ||
Line 139: | Line 140: | ||
</ | </ | ||
- | This will run a 30 minutes | + | (If you're running your reservation in a container reservation): |
+ | < | ||
+ | you@srvairlock: | ||
+ | </ | ||
+ | |||
+ | (Be sure that no one else is using the same node as you) | ||
+ | |||
+ | This will run a 30 minute | ||
We then submit the minus task: | We then submit the minus task: | ||
Line 148: | Line 156: | ||
</ | </ | ||
- | You'll see that Minus recognizes you as the submitter of the task and gives you a task number (15 in this example, it will be certainly different for you). You'll want to __write down the number__ of the task as it will be important for checking | + | You'll see that Minus recognizes you as the submitter of the task and gives you a task number (15 in this example). You'll want to __write down the number__ of the task as it will be important for checking |
- | Bear in mind that you task has been put on a queue and will await running tasks and other scheduled tasks to start, so it may take a while before it runs. | + | Bear in mind that your task has been put on a queue and will await running tasks and other scheduled tasks to start, so it may take a while before it runs. |
- | Minus can also help you check what is the status of the queue: | + | Minus can also help you check the status of the queue: |
< | < | ||
you@srvairlock: | you@srvairlock: | ||
- | Testbed status: | + | num total tasks: 2540 |
- | ID count so far: 15 | + | num tasks waiting: 0 |
- | Number of awaiting jobs: 0 | + | num tasks running: 0 |
- | ID of the running | + | tasks currently |
+ | | ||
</ | </ | ||
- | Three pieces of information are given back: | + | These information are returned: |
- | * '' | + | * '' |
- | * '' | + | * '' |
- | * '' | + | * '' |
+ | * '' | ||
- | ## Collecting and analysing | + | ## Collecting and analyzing |
- | Generally the OFDM example task will take a few minutes to run. Once its finished, Minus will take care of copying the results and output messages back to your home folder in srvairlock, | + | Generally the OFDM example task will take a few minutes to run. Once it is finished, Minus will take care of copying the results and output messages back to your home folder in srvairlock, |
All results are stored by task number in the results folder, inside your home folder. | All results are stored by task number in the results folder, inside your home folder. | ||
- | Lets go look for them: | + | Let' |
< | < | ||
Line 186: | Line 197: | ||
</ | </ | ||
- | So we see that we have a folder for each task and inside each folder one compressed file per participant node. Lets decompress | + | So we see that we have a folder for each task and inside each folder one compressed file per participant node. Let's extract |
< | < | ||
Line 195: | Line 206: | ||
you@srvairlock: | you@srvairlock: | ||
benchmark_rx.py | benchmark_rx.py | ||
- | benchmark_tx.py | + | benchmark_tx.py |
receive_path.py | receive_path.py | ||
</ | </ | ||
Line 204: | Line 215: | ||
* '' | * '' | ||
- | Lets take a look inside both, starting with the '' | + | Let' |
< | < | ||
Line 262: | Line 273: | ||
</ | </ | ||
- | Lets try to understand it: | + | Let' |
* The first 9 lines correspond to the UHD messages | * The first 9 lines correspond to the UHD messages | ||
* The next 16 lines correspond to the GNU Radio messages and radio configuration parameters | * The next 16 lines correspond to the GNU Radio messages and radio configuration parameters | ||
* There might be a warning message about realtime scheduling that can be safely ignored | * There might be a warning message about realtime scheduling that can be safely ignored | ||
- | * The lines starting with '' | + | * The lines starting with '' |
* '' | * '' | ||
* '' | * '' | ||
Line 272: | Line 283: | ||
* '' | * '' | ||
- | As it can be seen, there' | + | As can be seen, there' |
You can also look into the stderr.txt: | You can also look into the stderr.txt: |
gnu_radio_benchmark_example.txt · Last modified: 2018/10/24 12:01 by lcardoso