User Tools

Site Tools


gnu_radio_benchmark_example

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
gnu_radio_benchmark_example [2016/12/12 16:08]
onicolas [Inspecting the example task]
gnu_radio_benchmark_example [2018/10/24 12:01] (current)
lcardoso [Logging into the SSH front-end]
Line 11: Line 11:
  
 <​code>​ <​code>​
-you@yourpc:​~$ ssh -X -v [-i path/​to/​the/​key] ​-p 2269 username@gw.cortexlab.fr ​+you@yourpc:​~$ ssh -X -v [-i path/​to/​the/​key] username@gw.cortexlab.fr ​
 </​code>​ </​code>​
  
Line 20: Line 20:
 ## Inspecting the example task ## Inspecting the example task
  
-Checkout ​the examples repository on GitHub :+Retrieve ​the examples repository on GitHub :
  
 <​code>​ <​code>​
Line 33: Line 33:
 you@srvairlock:​~/​examples/​my_task$ ls you@srvairlock:​~/​examples/​my_task$ ls
 benchmark_rx.py ​ receive_path.py ​ transmit_path.py benchmark_rx.py ​ receive_path.py ​ transmit_path.py
-benchmark_tx.py ​ scenario.desc    ​uhd_interface.py+benchmark_tx.py ​ scenario.yaml    ​uhd_interface.py
 </​code>​ </​code>​
  
Line 41: Line 41:
   * ''​benchmark\_rx.py'':​ the GNU Radio python script for the OFDM receiver   * ''​benchmark\_rx.py'':​ the GNU Radio python script for the OFDM receiver
   * ''​transmit\_path.py'',​ ''​receive\_path.py''​ and ''​uhd\_interface.py'':​ are helper codes for both benchmark python scripts   * ''​transmit\_path.py'',​ ''​receive\_path.py''​ and ''​uhd\_interface.py'':​ are helper codes for both benchmark python scripts
-  * ''​scenario.desc'':​ a scenario description file, which assigns the roles of "​transmitter"​ and "​receiver"​ to a set of nodes+  * ''​scenario.yaml'':​ a scenario description file (in yaml format), which assigns the roles of "​transmitter"​ and "​receiver"​ to a set of nodes
  
 Now, let's inspect the scenario description file, to understand what will happen during this experiment: Now, let's inspect the scenario description file, to understand what will happen during this experiment:
  
 <​code>​ <​code>​
-you@srvairlock:​~/​examples/​my_task$ less scenario.desc+you@srvairlock:​~/​examples/​my_task$ less scenario.yaml
 </​code>​ </​code>​
  
Line 53: Line 53:
 <​code>#​ Example scenario description file <​code>#​ Example scenario description file
 # #
-#   All lines starting with "#"​ and empty lines are ignored+#   All lines starting with "#"​ and empy lines are ignored
  
  
 # Scenario textual description # Scenario textual description
 #   ​simple string (a one liner) #   ​simple string (a one liner)
-desc base scenario for CorteXlab+description: ​base scenario for CorteXlab
  
 # Experiment maximum duration # Experiment maximum duration
 #   Time after which the experiment is forced to stop #   Time after which the experiment is forced to stop
-#   ​integer (minutes+#   ​integer (seconds
-durat 5+duration: 300
  
 # Node list # Node list
Line 69: Line 69:
 #   ​format:​ #   ​format:​
 # #
-#   ​(machine):​ +#   nodes: 
-  entry (entry point script relative to the task root+#     (machine):​ 
-#   exit (exit point script relative to the task root. Use "​none"​ for none)+      command: ​(entry point script relative to the task root)
  
-node4: +nodes:
-   entry benchmark_rx.py +
-   ​params --antenna="​TX/​RX"​ --rx-gain=25 -v -W 2M -f 2.49G +
-   ​passive true+
  
-node6: +  node4: 
-   entry benchmark_tx.py +    command: ./​benchmark_rx.py --antenna="​TX/​RX"​ --rx-gain=25 -v -W 2M -f 2.49G 
-   ​params ​--antenna="​TX/​RX"​ --tx-amplitude=0.2 -v -W 2M -f 2.49G+    passive: true 
 + 
 +  ​node6: 
 +    ​command:​ ./benchmark_tx.py --antenna="​TX/​RX"​ --tx-amplitude=0.2 -v -W 2M -f 2.49G
 </​code>​ </​code>​
        
Line 88: Line 88:
  
   * ''​node4:'':​ This opens the node4 declaration of options   * ''​node4:'':​ This opens the node4 declaration of options
-  * ''​entry benchmark\_rx.py'':​ states that the benchmark\_rx.py ​is the //entry// point of the experiment at node4. In other words, this will be the script executed at node4. +  * ''​command: ​./benchmark\_rx.py --antenna="​TX/​RX"​ --rx-gain=25 -v -W 2M -f 2.49G'': ​states ​the command to run on node4. ​Details of the parameters are:
-  * ''​params ​--antenna="​TX/​RX"​ --rx-gain=25 -v -W 2M -f 2.49G'': ​these are the set of parameters that will be used for the ''​benchmark_rx.py''​ script at node4. ​This is particularly useful when you want to have the same code running differently on different nodes. These parameters are not dependent on CorteXlab but rather on the user's code. In this particular case they'​re almost self-explanatory,​ but let's go over them anyway:+
     * ''​--antenna="​TX/​RX"'':​ this indicates which antenna connector to use on the USRP radio platform connected to the node     * ''​--antenna="​TX/​RX"'':​ this indicates which antenna connector to use on the USRP radio platform connected to the node
     * ''​--rx-gain=25'':​ this sets the receive gain of the USRP radio platform     * ''​--rx-gain=25'':​ this sets the receive gain of the USRP radio platform
Line 95: Line 94:
     * ''​-W 2M'':​ this sets the bandwidth of the signal to 2 MHz     * ''​-W 2M'':​ this sets the bandwidth of the signal to 2 MHz
     * ''​-f 2.49G'':​ this sets the carrier frequency of the signal to 2.49 GHz     * ''​-f 2.49G'':​ this sets the carrier frequency of the signal to 2.49 GHz
-  * ''​passive true'':​ the node 4 will be passive, meaning it will stop when all active nodes are finished ​+  * ''​passivetrue'':​ the node 4 will be passive, meaning it will stop when all active nodes are finished ​
  
 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 129: Line 128:
 </​code>​ </​code>​
  
-And now we have a new file called ''​my_task.task''​ which is ready to be submitted. Warning, do not leave a slash after the directory task name (i.e. ''​my_task''​ ) of the command will fail.+And now we have a new file called ''​my\_task.task''​ which is ready to be submitted. Warning, do not leave a slash after the directory task name (i.e. ''​my_task''​ ) or the command will fail.
  
 ## Submitting the task ## Submitting the task
Line 141: Line 140:
 </​code>​ </​code>​
  
-This will run a 30 minutes ​job and open a subshell in which you can run minus tasks. This subshell will be killed after 30 minutes, and if you leave the shell earlier, it will terminate the corresponding oar job. More documentation on oar can be found [[reserve|here]]. You can also monitor the current jobs in the [gantt web interface](http://​xp.cortexlab.fr/​drawgantt/​).+(If you're running your reservation in a container reservation):​ 
 +<​code>​ 
 +you@srvairlock:​~/​examples$ oarsub -t inner=<​id of container>​ -l {"​network_address in ('​mnode4.cortexlab.fr',​ '​mnode6.cortexlab.fr'​)"​}/​nodes=2,​walltime=0:​30:​00 -I 
 +</​code>​ 
 + 
 +(Be sure that no one else is using the same node as you) 
 + 
 +This will run a 30 minute ​job and open a subshell in which you can run minus tasks. This subshell will be killed after 30 minutes, and if you leave the shell earlier, it will terminate the corresponding oar job. More documentation on oar can be found [[reserve|here]]. You can also monitor the current jobs in the [gantt web interface](http://​xp.cortexlab.fr/​drawgantt/​).
  
 We then submit the minus task: We then submit the minus task:
Line 150: Line 156:
 </​code>​ </​code>​
  
-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 ​the tasks status ​and aborting the task, if necessary.+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 ​its status ​or to abort it, if necessary.
  
-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:
  
 <​code>​ <​code>​
 you@srvairlock:​~/​examples$ minus testbed status you@srvairlock:​~/​examples$ minus testbed status
-Testbed status+num total tasks  2540 
-ID count so far15 +num tasks waiting0 
-Number of awaiting jobs: 0 +num tasks running: 0 
-ID of the running ​job15 (None means server is idle)+tasks currently ​running: 
 +  ​(none) 
 </​code>​ </​code>​
  
-Three pieces of information are given back:+These information are returned:
  
-  * ''​ID count so far: 15'':​ This is the number of the last task created +  * ''​num total tasks'':​ This is the number of the last created ​task 
-  * ''​Number of awaiting jobs: 0'':​ This is the number of tasks currently awaiting in the queue +  * ''​num tasks waiting'':​ This is the number of tasks currently awaiting in the queue 
-  * ''​ID of the running ​job: 15'':​ This indicated ​the number of the task currently ​being treated ​+  * ''​num tasks running'':​ This is the number ​of tasks currently executing (most of the time, there can only be one task running at the same time. Only in special situations, such as demos, tutorials, can several users run tasks concurrently). 
 +  * ''​tasks ​currently ​running'':​ This is a detailed list of tasks currently running.
  
-## Collecting and analysing ​the output+## Collecting and analyzing ​the output
  
-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, ​such that you can analyse ​it.+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, ​so that you can analyze ​it.
  
 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'​s ​go and have a look at them:
  
 <​code>​ <​code>​
Line 197: Line 206:
 you@srvairlock:​~/​results/​task_15/​node4$ ls you@srvairlock:​~/​results/​task_15/​node4$ ls
 benchmark_rx.py ​ receive_path.pyc ​ stdout.txt ​       uhd_interface.pyc benchmark_rx.py ​ receive_path.pyc ​ stdout.txt ​       uhd_interface.pyc
-benchmark_tx.py ​ scenario.desc     transmit_path.py+benchmark_tx.py ​ scenario.yaml     transmit_path.py
 receive_path.py ​ stderr.txt ​       uhd_interface.py receive_path.py ​ stderr.txt ​       uhd_interface.py
 </​code>​ </​code>​
Line 206: Line 215:
   * ''​stderr.txt'':​ all error messages are printed here. If you see strange things on the ''​stdout.txt''​ or nothing at all, it might be interesting to take a look at the ''​stderr.txt''​ to debug your code.   * ''​stderr.txt'':​ all error messages are printed here. If you see strange things on the ''​stdout.txt''​ or nothing at all, it might be interesting to take a look at the ''​stderr.txt''​ to debug your code.
  
-Lets take a look inside both, starting with the ''​stdout.txt'':​+Let'​s ​take a look inside both, starting with the ''​stdout.txt'':​
  
 <​code>​ <​code>​
Line 264: Line 273:
 </​code>​ </​code>​
  
-Lets try to understand it:+Let'​s ​try to understand it:
   * 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 ''​ok:​ False        pktno: 169      n\_rcvd: 1       ​n\_right:​ 0''​ are the receiver trying to decode the OFDM packets. ​Lets further inspect these lines:+  * The lines starting with ''​ok:​ False        pktno: 169      n\_rcvd: 1       ​n\_right:​ 0''​ are from the receiver trying to decode the OFDM packets. ​Let'​s ​further inspect these lines:
     * ''​ok:​ False'':​ means the packet was incorrectly decoded, i.e., it failed to pass the checksum     * ''​ok:​ False'':​ means the packet was incorrectly decoded, i.e., it failed to pass the checksum
     * ''​pktno:​ 169'':​ is the sequence number seen at the receiver     * ''​pktno:​ 169'':​ is the sequence number seen at the receiver
Line 274: Line 283:
     * ''​n\_right:​ 0'':​ is the number of correctly received packets     * ''​n\_right:​ 0'':​ is the number of correctly received packets
  
-As it can be seen, there'​s a local oscillator (LO) mismatch between both nodes that complicate ​the decoding process. ​+As can be seen, there'​s a local oscillator (LO) mismatch between both nodes that complicates ​the decoding process. ​
  
 You can also look into the stderr.txt: You can also look into the stderr.txt:
gnu_radio_benchmark_example.1481555335.txt.gz · Last modified: 2016/12/12 16:08 by onicolas