---
# System prepended metadata

title: Research project

---

# Research project

## 1. provare in remoto (ognuno a casa sua con una board)

## 2. usare la rete 5g (anche se non ha internet)
- ogni scheda collegata ad uno "scatolotto" 5g (sim card e dispositivo) collegata alla rete 5g di trento
- asd
- pacchetti rdp (udp?)

## Implementazione
![](https://i.imgur.com/IlE58aD.png)
elk.audio
board vanno "sincronizzate"
lab multisensory interaction

- passo 0: impostare tutto per fare p2p tramite internet
- passo 1: ripetere usando rete 4g
- passo 2: usare 5g (CONFRONTO CON 4G (e magari anche wifi))
- flusso audio 
- framework di testing per configurare i parametri di ALOHA
- ricreare flusso audio, fare roba, ..., senza le board ??
- jacktrip?

Nel frattempo
- fare udp in linux (in c++ ?)
- provare con rtp
- in formazione con il MEC
- predisporre calcoli statistiche

6 aprile scadenza (meeting)

## Piano d'azione
0. Raccogliere statistiche di reference senza MITM
1. Testare MITM
    1. Testare funzionamento base (latenza aggiuntiva rispetto a singole board, throughput massimo)
    2. Ping e2e semplice
    3. Ping su singoli link semplice
    4. RTT su singoli link con loopback audio (collegando in e out)
2. Funzionalità rete MITM
    1. Simulare connessione lenta di una board
    2. Simulare perdita pacchetti
    3. Capire come sincronizzare i pacchetti per fare mixing con il giusto ritmo (come capire il ritardo di un pacchetto rispetto all altro (dell altra board))
    4. Capire quanta latenza viene aggiunta dalla sync forzata
3. Funzionalità mixing audio MITM
    1. Implementare mixing: semplice somma di pacchetti oppure usando sushi o altre librerie
    2. Testare latenze una volta aggiunto il mixing
    3. Testare mixing con perdite di pacchetti e latenze simulate
4. 💥**Variare protocolli di rete**
    1. Inizialmente semplice switch
    2. Provare wifi (opzionale)
    3. 4G
    4. 5G
5. Aggiungere board?



## Stats
### Modalita P2P
- [x] semplice ping tra board
- [x] ping e2e con scheda audio => raccogliere anche ping dovuto a scheda audio che usiamo

### Modalita MITM
- [x] ping semplice tra i vari device (tutte le combo se possibile)
- [x] ping e2e di nuovo
- [ ] ??? rtt su singolo link: mandare pacchetto da MITM a board, loop fisico OUT=>IN, ricevere pacchetto a MITM e misurare tempo. Come fare a riconoscere pacchetto/non incasinare aloha?

| PING SWITCH *(ms)* | Avg | Min | Max | mDev |
| -------- | -------- | -------- | -------- | -------- |
| P2P b2b     | 0.117     | 0.102     | 0.165     | 0.010     |
| MITM b12m     | 0.499     | 0.346     | 1.066     | 0.118     |
| MITM b22m     | 0.472     | 0.309     | 1.452     | 0.081     |

#### Audio RTL SWITCH $(ms)$

| Windows, 48Khz, 1024f/p | Test 1 | Test 2 | Test 3 | Test 4 | Test 5 | Test 6 |
| -------- | -------- | -------- | -------- | -------- | -------- | -------- |
| SCHEDA AUDIO | $155.146$ | $156.013$ | $155.846$ | $155.930$ | $155.992$ | $154.763$ |
| BOARD OWN | $158.343$ (+3.197) | $159.210$ (+3.197) | $159.043$ (+3.197) | $159.127$ (+3.197) | $159.189$ (+3.197) | $157.960$ (+3.197) |
| P2P    | $170.293$ (+15.147) |  |  |  |  |  |
| MITM    | $171.070$ (+15.924) | $172.331$ (+16.318) | $172.171$ (+16.325) | $172.267$ (+16.337) | $172.337$ (+16.345) | $171.120$ (+16.357) |

| Linux, 48Khz, 1024f/p, 2p/b | Avg | Min | Max | mDev |
| -------- | -------- | -------- | -------- | -------- |
| SCHEDA AUDIO     | $43.47$     |      |      |      |
| BOARD OWN     | $46.705$ (+3)    |      |      |      |
| **P2P** --> BASELINE   | $58$ (+12)   |      |      |      |
| MITM     |   $62$ (+4)  | $61$ | $67$  |      |

NOTA BENE: ripartire tutto ogni volta.

#### Sniffing
328.5 KB/s
2 channels * 48KHz * 24 bit = 288 KB/s

UDP Data = 876B
UDP data for control = 52, 12 packets/min => 5sec period

#### Idee riguardo al clock
Obiettivo: ottenere latenza direzionale sui singoli link

1. Usare NTP a prescindere dal network
    - come controllare se funziona bene?
    - nel momento in cui controlli puoi anche regolarti shiftando
2. Usare NTP su switch inizialmente:
    - cercare di capire il time drift sapendo l'intervallo con cui la board manda i pacchetti e l'indice del pacchetto
3. Senza sincronizzare i clock?

### Getting Aloha Metrics

1. **Tcpdump** to collect packets: `tcpdump -i <interface> udp -w my_dump`
    - alternative: `tshark -i "Ethernet 2" -f "udp" -w my_dump.pcap` 
3. **Tshark** to export csv: `tshark -r my_dump -T fields -e ip.proto -e udp.srcport -e frame.time -e data.len -e data.data -E header=y > my_dump.csv`
4. **Python**: parse + process
5. **R**: plot

### Netem Examples

- `tc qdisc add dev eth0 root netem loss random 30%`
- `tc qdisc del dev eth0 root netem`
- `tc qdisc add dev eth0 root netem loss gemodel (Pe/b)/(1-Pe) 1/b`
- `tc qdisc change dev eth0 root netem delay 10ms 10ms`





![](https://i.imgur.com/hGIyCU9.png)

$M$ è istante in cui parte il pacchetto, secondo il time reference del MITM
$A$ tcpdump aloha board: istante in cui parte il pacchetto, secondo time ref di BOARD
$B$ tcpdump aloha mitm: istante in cui arriva il pacchetto, secondo time ref di MITM
$C$ tcpdump timediff mitm: istante in cui arriva il pacchetto, secondo time ref di MITM

Latenza rete aloha è $L_a$ <- da misurare
Latenza rete ntp è $L_{ntp}$ <- conosciuta
$T$ è time difference

$A = M + T$
$C = M + L_{ntp}$
$C = A - T + L_{ntp}$
$T = A - C + L_{ntp}$

$A = M + T$
$B = M + L_a$
$B = A - T + L_a$
$L_a = B + T - A$
$L_a = B - C + L_{ntp}$

## Audio Header 
![](https://i.imgur.com/sBvZ5P6.png)

- **`APPMESSAGE`**:
    - `NONE` = 0
    1. `IS_RECEIVING_PKTS`
    2. `RECEIVING_ACK`
    3. `STOP_STREAM_REQ`
    4. `STOP_STREAM_ACK`
    5. `RESTART_REQ`

## Netem models
| Column 1 | Column 2 | Column 3 |
| -------- | -------- | -------- |
| Text     | Text     | Text     |
