gnu_radio_docker_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_docker_benchmark_example [2022/12/13 11:48] – [Submitting the task] lcardoso | gnu_radio_docker_benchmark_example [2023/12/12 17:06] – Update to use OFDM benchmark adapted to GR3.10 cmorin | ||
---|---|---|---|
Line 8: | Line 8: | ||
## Create your docker image | ## Create your docker image | ||
- | Using docker, we will enable on your laptop an environment suitable for CorteXlab with gnuradio and needed software. Your goal is to develop this image (with new software and files) so you can run your experiment. It will only modify the environment of the image and not your laptop. Then you will be able to save and deploy the new image on cortexlab, without having to re-install everything and dealing with software compatibility and versioning. | + | Using docker, we will enable on your laptop an environment suitable for CorteXlab with gnuradio and needed software. Your goal is to develop this image (with new software and files) so you can run your experiment. It will only modify the environment of the image and not your laptop. Then you will be able to save and deploy the new image on CorteXlab, without having to re-install everything and dealing with software compatibility and versioning. |
Therefore, you can retrieve and run the following image. | Therefore, you can retrieve and run the following image. | ||
< | < | ||
- | you@yourpc: | + | you@yourpc: |
- | you@yourpc: | + | you@yourpc: |
</ | </ | ||
Line 34: | Line 34: | ||
< | < | ||
root@yourpcwdocker: | root@yourpcwdocker: | ||
- | root@yourpcwdocker: | + | root@yourpcwdocker: |
</ | </ | ||
- | Let's go over each one of the files in this example: | + | Let's go over each one of the files in this `ofdm_benchmark` folder: |
- | * '' | + | * '' |
- | * '' | + | * '' |
- | * '' | + | * '' |
- | * '' | + | * '' |
Here, this is all the modifications we need to do in order to prepare our experiment. When it is working properly, you can exit the container with Ctrl + d. Now, let's save our updated container as a new docker image. We can then push it on dockerhub (dockerhub is a repository of docker images, you need to create an account on it). | Here, this is all the modifications we need to do in order to prepare our experiment. When it is working properly, you can exit the container with Ctrl + d. Now, let's save our updated container as a new docker image. We can then push it on dockerhub (dockerhub is a repository of docker images, you need to create an account on it). | ||
Line 102: | Line 102: | ||
* '' | * '' | ||
* '' | * '' | ||
+ | The same reasoning applies for node 16. | ||
+ | This is the scenario at hand: | ||
- | We will use the ssh method for this example, but know that you can also use the '' | + | * **Node14** |
+ | * **Node16** will behave as the **OFDM transmitter** | ||
+ | |||
+ | For more info on where these nodes are located inside the platform, please check the node position map at the home of this wiki. | ||
+ | |||
+ | Assuming your account has been correctly created, you can now copy the folder with the scenario file into the Airlock SSH front-end: | ||
+ | |||
+ | < | ||
+ | you@yourpc: | ||
+ | </ | ||
+ | |||
+ | |||
+ | ### Non interactive scenario (No SSH) | ||
+ | The example of this tutorial demonstrates an ssh connection to the nodes. But know that you can also use the '' | ||
+ | |||
+ | In this situation, you might want to directly call the program to run on the nodes via the '' | ||
< | < | ||
Line 111: | Line 128: | ||
container: | container: | ||
- image: [DOCKER USERNAME]/ | - image: [DOCKER USERNAME]/ | ||
- | command: | + | command: |
- | passive: true | + | passive: true |
node16: | node16: | ||
container: | container: | ||
- image: [DOCKER USERNAME]/ | - image: [DOCKER USERNAME]/ | ||
- | command: | + | command: |
</ | </ | ||
- | | + | |
- | * '' | + | * '' |
- | * '' | + | * '' |
- | * '' | + | * '' |
- | * '' | + | * '' |
- | * '' | + | |
* '' | * '' | ||
- | Same reasoning follows for the section on node6. So this is the scenario at hand: | ||
- | * **Node14** behaves as the **OFDM receiver** | + | Note that, **the rest of this tutorial uses the ssh method**, not the one mentioned in the current section. |
- | * **Node16** behaves as the **OFDM transmitter** | + | Also note that the command must point to the file to be executed, either with a relative path, from the '' |
- | + | ||
- | For more info on where these nodes are located inside the platform, please check the node position map at the home of this wiki. | + | |
- | + | ||
- | Assuming your account has been correctly created, you can now copy the folder with the scenario | + | |
- | + | ||
- | < | + | |
- | you@yourpc: | + | |
- | </ | + | |
## Access Airlock | ## Access Airlock | ||
- | You can now access the Airlock | + | You can now access the Airlock |
< | < | ||
Line 183: | Line 190: | ||
I a new browser window open the [CorteXlab web app](http:// | I a new browser window open the [CorteXlab web app](http:// | ||
- | {{ :: | + | {{ :: |
- | < | + | Use the "Book the testbed" |
- | you@srvairlock: | + | |
- | </ | + | |
- | (If you're running your reservation in a container | + | You'll get to a screen that looks like this: |
- | < | + | |
- | you@srvairlock:~/ | + | {{ :: |
- | </ | + | |
+ | Now let's create the reservation! | ||
+ | |||
+ | Under "Book the testbed" | ||
+ | |||
+ | {{ :: | ||
+ | |||
+ | And using the clock icon select the start time of your reservation by dragging the clock pointers: | ||
+ | |||
+ | {{ :: | ||
+ | |||
+ | Now, in the duration, select the end of your reservation the same way as above. | ||
+ | |||
+ | Finally select the nodes in the map of CorteXlab by clicking on the ones required for your experiment such that their color changes to orange. Since we're using 14 and 16, those are the ones to be selected: | ||
+ | |||
+ | {{ :: | ||
+ | |||
+ | Finally click on the "Book the testbed" | ||
- | (Be sure that no one else is using the same node as you) | ||
- | This will run a 30 minute job and open a sub-shell in which you can run minus tasks. This sub-shell 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:// | ||
- | We then submit the minus task: | + | Back to the airlock terminal screen, we now can submit the minus task: |
< | < | ||
Line 241: | Line 261: | ||
< | < | ||
# From node 14 | # From node 14 | ||
- | root@mnode14: | + | root@mnode14: |
# From node 16 | # From node 16 | ||
- | root@mnode16: | + | root@mnode16: |
</ | </ | ||
Line 252: | Line 272: | ||
< | < | ||
- | linux; GNU C++ version | + | [INFO] [UHD] linux; GNU C++ version |
+ | [INFO] [USRP2] Opening a USRP2/ | ||
+ | [INFO] [USRP2] Current recv frame size: 1472 bytes | ||
+ | [INFO] [USRP2] Current send frame size: 1472 bytes | ||
+ | [WARNING] [UDP] The send buffer could not be resized sufficiently. | ||
+ | Target sock buff size: 2500000 bytes. | ||
+ | Actual sock buff size: 1048576 bytes. | ||
+ | See the transport application notes on buffer resizing. | ||
+ | Please run: sudo sysctl -w net.core.wmem_max=2500000 | ||
+ | [WARNING] [UDP] The send buffer could not be resized sufficiently. | ||
+ | Target sock buff size: 2500000 bytes. | ||
+ | Actual sock buff size: 1048576 bytes. | ||
+ | See the transport application notes on buffer resizing. | ||
+ | Please run: sudo sysctl -w net.core.wmem_max=2500000 | ||
+ | [WARNING] [UDP] The send buffer could not be resized sufficiently. | ||
+ | Target sock buff size: 2500000 bytes. | ||
+ | Actual sock buff size: 1048576 bytes. | ||
+ | See the transport application notes on buffer resizing. | ||
+ | Please run: sudo sysctl -w net.core.wmem_max=2500000 | ||
+ | [INFO] [MULTI_USRP] | ||
+ | [INFO] [MULTI_USRP] | ||
+ | Packet Comparator0 :info: Received packet num 1 with a BER of 0.0445 | ||
+ | Packet Comparator0 :info: Received packet num 2 with a BER of 0.0388 | ||
+ | Packet Comparator0 :info: Received packet num 3 with a BER of 0.0357 | ||
+ | Packet Comparator0 :info: Received packet num 4 with a BER of 0.0367 | ||
+ | Packet Comparator0 :info: Received packet num 5 with a BER of 0.0409 | ||
+ | Packet Comparator0 :info: Received packet num 6 with a BER of 0.0656 | ||
+ | Packet Comparator0 :info: Received packet num 7 with a BER of 0.0596 | ||
+ | Packet Comparator0 :info: Received packet num 8 with a BER of 0.0419 | ||
+ | Packet Comparator0 :info: Received packet num 9 with a BER of 0.0435 | ||
+ | Packet Comparator0 :info: Received packet num 10 with a BER of 0.0667 | ||
+ | Packet Comparator0 :info: Received packet num 11 with a BER of 0.0375 | ||
+ | Packet Comparator0 :info: Received packet num 12 with a BER of 0.0378 | ||
- | -- Opening a USRP2/ | ||
- | -- Current recv frame size: 1472 bytes | ||
- | -- Current send frame size: 1472 bytes | ||
- | -- Detecting internal GPSDO.... Found an internal GPSDO | ||
- | -- found | ||
- | -- Setting references to the internal GPSDO | ||
- | -- Initializing time to the internal GPSDO | ||
- | |||
- | UHD Receiver: | ||
- | UHD Args: | ||
- | Freq: | ||
- | LO Offset: | ||
- | Gain: | ||
- | Sample Rate: 2Msps | ||
- | Antenna: | ||
- | Subdev Sec: None | ||
- | Clock Source: None | ||
- | Using Volk machine: avx_64_mmx_orc | ||
- | |||
- | OFDM Demodulator: | ||
- | Modulation Type: bpsk | ||
- | FFT length: | ||
- | Occupied Tones: | ||
- | CP length: | ||
- | Warning: failed to enable realtime scheduling | ||
- | ok: False pktno: 169 n_rcvd: 1 n_right: 0 | ||
- | ok: False pktno: 170 n_rcvd: 2 n_right: 0 | ||
- | ok: False pktno: 171 n_rcvd: 3 n_right: 0 | ||
- | ok: False pktno: 173 n_rcvd: 4 n_right: 0 | ||
- | ok: False pktno: 174 n_rcvd: 5 n_right: 0 | ||
- | ok: False pktno: 175 n_rcvd: 6 n_right: 0 | ||
- | ok: False pktno: 176 n_rcvd: 7 n_right: 0 | ||
- | ok: False pktno: 177 n_rcvd: 8 n_right: 0 | ||
- | ok: False pktno: 178 n_rcvd: 9 n_right: 0 | ||
- | ok: False pktno: 179 n_rcvd: 10 n_right: 0 | ||
- | ok: False pktno: 180 n_rcvd: 11 n_right: 0 | ||
- | ok: False pktno: 181 n_rcvd: 12 n_right: 0 | ||
- | ok: False pktno: 182 n_rcvd: 13 n_right: 0 | ||
- | ok: False pktno: 185 n_rcvd: 14 n_right: 0 | ||
- | ok: False pktno: 186 n_rcvd: 15 n_right: 0 | ||
- | ok: False pktno: 191 n_rcvd: 16 n_right: 0 | ||
- | ok: False pktno: 192 n_rcvd: 17 n_right: 0 | ||
- | ok: False pktno: 197 n_rcvd: 18 n_right: 0 | ||
- | ok: False pktno: 203 n_rcvd: 19 n_right: 0 | ||
... | ... | ||
</ | </ | ||
Let's try to understand it: | Let's try to understand it: | ||
- | * The first 9 lines correspond to the UHD messages | + | * The first 21 lines correspond to the UHD messages |
- | * The next 16 lines correspond to the GNU Radio messages and radio configuration parameters | + | * The lines starting with '' |
- | * There might be a warning message about realtime scheduling that can be safely ignored | + | * Packet number. This should increase regularly. Missing elements in the sequence |
- | * The lines starting with '' | + | * Bit Error Rate. Computed only on the current packet |
- | * '' | + | |
- | * '' | + | |
- | * '' | + | |
- | * '' | + | |
- | + | ||
- | As can be seen, there' | + | |
If you decide to directly run your experiment in the '' | If you decide to directly run your experiment in the '' | ||
Line 323: | Line 325: | ||
you@srvairlock: | you@srvairlock: | ||
you@srvairlock: | you@srvairlock: | ||
- | node14.tgz | + | node14 |
</ | </ | ||
- | So we see that we have a folder for each task and inside each folder one compressed file per participant node. Let's extract one of those files and see what's inside: | + | So we see that we have a folder for each task and inside each folder one folder |
< | < | ||
- | you@srvairlock: | ||
- | you@srvairlock: | ||
- | node14 | ||
you@srvairlock: | you@srvairlock: | ||
you@srvairlock: | you@srvairlock: | ||
- | benchmark_rx.py receive_path.pyc | + | task_XXXX_container_0 |
- | benchmark_tx.py scenario.yaml | + | task_XXXX_container_0.log.stdout |
- | receive_path.py | + | task_XXXX_container_0.create.stderr |
+ | task_XXXX_container_0.start.stderr | ||
</ | </ | ||
- | We see that all of the files we used to create | + | We see a series |
+ | * create: Downloading of image file | ||
+ | * start: Start of container | ||
+ | * log: Execution of specified command | ||
+ | * wait: Waiting period before closure | ||
+ | * kill: Task cleanup | ||
+ | |||
+ | Create, start, wait, and Kill should not have anything in their .stderr logs. | ||
+ | The most interesting | ||
+ | |||
+ | The `task_XXXX_container_0` folder contains all the files that have changed during the execution of the container. | ||
+ | Here, it only contains internal cache and log files that are not useful to us, but if your task records data in a file, it will show up here. | ||
- | * '' | ||
- | * '' | ||
## What next? | ## What next? |
gnu_radio_docker_benchmark_example.txt · Last modified: 2024/03/08 15:59 by cmorin