CorteXlab's Wiki

User Tools

Site Tools

Trace:
gnu_radio_benchmark_example

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
gnu_radio_benchmark_example [2016/12/12 11:59] – [Logging into the SSH front-end] onicolasgnu_radio_benchmark_example [2018/10/24 12:01] (current) – [Logging into the SSH front-end] lcardoso
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 27: Line 27:
 </code> </code>
  
-Let's get inside and see what's all about:+Let's get inside and see what it's all about:
  
 <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>
  
-Let go over each one of these files:+Let's go over each one of these files:
  
   * ''benchmark\_tx.py'': the GNU Radio python script for the OFDM transmitter   * ''benchmark\_tx.py'': the GNU Radio python script for the OFDM transmitter
   * ''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, lets 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 58: Line 58:
 # 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>
        
-The file is self-explanatory, but for now lets ignore all the other lines, except the indented ones following ''node4:'' and ''node6:''. You'll have the opportunity to understand them better later on. +The file is self-explanatory, but for now let's ignore all but the indented lines following ''node4:'' and ''node6:''. You'll have the opportunity to understand the rest better later on. 
  
-Lets go over each one now:+Let's go over each said line now:
  
   * ''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 uselfull when you want to have the same code running differently on different nodes. The parameters are not dependent on CorteXlab but rather on the code give by the users. In this particular case they're almost self-explanatory, but lets 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 +  * ''passive: true'': 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 far: 15 +num tasks waiting: 0 
-Number of awaiting jobs: 0 +num tasks running: 0 
-ID of the running job: 15 (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.1481540373.txt.gz · Last modified: by onicolas
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki