PRRT issueshttps://git.nt.uni-saarland.de/LARN/PRRT/-/issues2019-12-20T16:45:54Zhttps://git.nt.uni-saarland.de/LARN/PRRT/-/issues/5Receiver-Based Coding Parameters and Channel State Information2019-12-20T16:45:54ZAndreas SchmidtReceiver-Based Coding Parameters and Channel State Information* Channel state information should be individual to a remote receiver.
* Coding parameters should be individual to a remote receiver.* Channel state information should be individual to a remote receiver.
* Coding parameters should be individual to a remote receiver.https://git.nt.uni-saarland.de/LARN/PRRT/-/issues/3Implement Pools for Data Packets, Repair Packets2019-12-20T16:46:06ZAndreas SchmidtImplement Pools for Data Packets, Repair Packets* Allocate pools when socket is created (at least half the sequence number space + maximum code block length).
* Use next free item out of pool when data is received from application layer.
* Forward pointer to item to the next stages.* Allocate pools when socket is created (at least half the sequence number space + maximum code block length).
* Use next free item out of pool when data is received from application layer.
* Forward pointer to item to the next stages.https://git.nt.uni-saarland.de/LARN/PRRT/-/issues/2Automate Performance Tests2019-12-20T16:46:11ZAndreas SchmidtAutomate Performance Tests* Evaluate fake tap Python module.
* Create fake interfaces and use them for evaluation.* Evaluate fake tap Python module.
* Create fake interfaces and use them for evaluation.https://git.nt.uni-saarland.de/LARN/PRRT/-/issues/11Add Multicast Support2018-10-19T08:44:22ZAndreas SchmidtAdd Multicast Support**Goal: Support multicast addressing schemes.**
**Implementation**
* `PrrtSocket_create()` gets additional IP parameter (Bind IP / Peer IP)
* IP Parameter
* if `isSender`: Peer IP
* if `!isSender`: Receiving IP (bind to &...**Goal: Support multicast addressing schemes.**
**Implementation**
* `PrrtSocket_create()` gets additional IP parameter (Bind IP / Peer IP)
* IP Parameter
* if `isSender`: Peer IP
* if `!isSender`: Receiving IP (bind to & add IP multicast listening)
* If `IP` in subnet 224.0.0.0/4 => `socket->multicast = true`
* Data Socket: Bind to IP (and add IP multicast listening if receiver)
* Feedback Socket: Bind to IP & add IP multicast listening
* Multiplex feedback of multiple receivers in feedbackReceiver
* Default IP for PRRT: 224.0.0.11
**Tutorials**
* http://openbook.rheinwerk-verlag.de/linux_unix_programmierung/Kap11-018.htm
* http://ntrg.cs.tcd.ie/undergrad/4ba2/multicast/antony/example.htmlhttps://git.nt.uni-saarland.de/LARN/PRRT/-/issues/13Gapfilling Mode2019-12-20T16:45:11ZAndreas SchmidtGapfilling ModeThere should be a `receive_gapfilling(..., fill_value)` mode with the following traits:
* If an expiry date approaches and the data is not there, a "zero" packet is delivered.
* The filling pattern (e.g. "zero" should be configurable on...There should be a `receive_gapfilling(..., fill_value)` mode with the following traits:
* If an expiry date approaches and the data is not there, a "zero" packet is delivered.
* The filling pattern (e.g. "zero" should be configurable on the receive call).
ToDo:
* Think about how to predict an "expiry" of a packet that has not been sent or recovered.https://git.nt.uni-saarland.de/LARN/PRRT/-/issues/15Update BBR to recent state2018-08-01T16:25:23ZAndreas SchmidtUpdate BBR to recent stateThere are updates on BBR at IETF102: https://datatracker.ietf.org/meeting/102/materials/slides-102-iccrg-an-update-on-bbr-work-at-google-00
Multiple commits have happened over here: https://git.kernel.org/pub/scm/linux/kernel/git/torval...There are updates on BBR at IETF102: https://datatracker.ietf.org/meeting/102/materials/slides-102-iccrg-an-update-on-bbr-work-at-google-00
Multiple commits have happened over here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/net/ipv4/tcp_bbr.c
- [ ] 2018-05-02: tcp_bbr: fix to zero idle_restart only upon S/ACKed data
- [ ] 2018-03-16: net-tcp_bbr: set tp->snd_ssthresh to BDP upon STARTUP exit
- [ ] 2018-03-01: tcp_bbr: remove bbr->tso_segs_goal
- [ ] 2018-03-01: tcp_bbr: better deal with suboptimal GSO (II)
- [ ] 2018-02-01: tcp_bbr: fix pacing_gain to always be unity when using lt_bw
- [ ] 2018-01-19: tcp: avoid min RTT bloat by skipping RTT from delayed-ACK in BBR
- [ ] 2017-12-08: tcp_bbr: reset long-term bandwidth sampling on loss recovery undo
- [ ] 2017-12-08: tcp_bbr: reset full pipe detection on loss recovery undo
- [ ] 2017-12-08: tcp_bbr: record "full bw reached" decision in new full_bw_reached bit
- [ ] 2017-07-15: tcp_bbr: init pacing rate on first RTT sample
- [ ] 2017-07-15: tcp_bbr: remove sk_pacing_rate=0 transient during init
- [ ] 2017-07-15: tcp_bbr: introduce bbr_init_pacing_rate_from_rtt() helper
- [x] 2017-07-15: tcp_bbr: introduce bbr_bw_to_pacing_rate() helper
- [x] 2017-07-15: tcp_bbr: cut pacing rate only if filled pipehttps://git.nt.uni-saarland.de/LARN/PRRT/-/issues/18Enhance PrrtCodingConfiguration class2019-05-15T15:05:32ZAndreas SchmidtEnhance PrrtCodingConfiguration class- [ ] Provide `PrrtCodingConfiguration.__eq__()` method.
- [x] Add `PrrtCodingConfiguration.ri(channelParameters)` method that yields how much redundancy this coding configuration causes, given a certain channel.
- [x] Add `is_valid_for(...- [ ] Provide `PrrtCodingConfiguration.__eq__()` method.
- [x] Add `PrrtCodingConfiguration.ri(channelParameters)` method that yields how much redundancy this coding configuration causes, given a certain channel.
- [x] Add `is_valid_for(applicationParameters, channelParameters, systemParameters)` method to check if it is able to fulfill application parameters given channel and system parameters.
- [x] Add `is_maximum_latency_fulfilled(applicationParameters, channelParameters, systemParameters)`
- [x] Add `is_maximum_loss_fulfilled(applicationParameters, channelParameters, systemParameters)`Ashkan TaslimiAshkan Taslimihttps://git.nt.uni-saarland.de/LARN/PRRT/-/issues/19Create PrrtChannelParameters class2019-05-17T11:26:33ZAndreas SchmidtCreate PrrtChannelParameters classThe class should store (for both `_fwd` and `_bwd`):
- [x] Packet loss rate in percent. (property `loss_rate_[...]`)
- [x] Propagation round trip time in seconds. (property `rt_prop_[...]`)
- [x] Bottleneck data rate in bits per second....The class should store (for both `_fwd` and `_bwd`):
- [x] Packet loss rate in percent. (property `loss_rate_[...]`)
- [x] Propagation round trip time in seconds. (property `rt_prop_[...]`)
- [x] Bottleneck data rate in bits per second. (property `btl_dr_[...]`)
It should provide computed properties:
- [x] Bandwidth-delay product in bits (`btl_dr * rt_prop` for both directions).
- [ ] Minimal redundancy information in percent (`ri_min()`).
- [ ] Minimal redundancy information given residual error in percent (`ri_min_residual(applicationParam.max_loss)`).
Should come with convenience methods:
- [x] `__str__`
- [x] `__repr__`
- [ ] `__eq__`
It should also nicely serialize to a 3-tuple to be used in Numpy arrays.
Python properties: https://www.programiz.com/python-programming/propertyAshkan TaslimiAshkan Taslimihttps://git.nt.uni-saarland.de/LARN/PRRT/-/issues/20Create PrrtApplicationParameters class2019-06-28T06:41:51ZAndreas SchmidtCreate PrrtApplicationParameters classThe class should store:
- [x] Maximum latency is (floating point) seconds.
- [x] Maximum residual loss rate in percent.
- [x] data_rate
Should come with convenience methods:
- [x] `__str__`
- [x] `__repr__`
- [ ] `__eq__`
It should a...The class should store:
- [x] Maximum latency is (floating point) seconds.
- [x] Maximum residual loss rate in percent.
- [x] data_rate
Should come with convenience methods:
- [x] `__str__`
- [x] `__repr__`
- [ ] `__eq__`
It should also nicely serialize to a 2-tuple to be used in Numpy arrays.Ashkan TaslimiAshkan Taslimihttps://git.nt.uni-saarland.de/LARN/PRRT/-/issues/21Improve Decoding Efficiency2018-07-10T10:51:58ZAndreas SchmidtImprove Decoding EfficiencyCurrently, all redundancy packets are reconstructed when decoding a block. It would suffice to reconstruct the missing data packets.Currently, all redundancy packets are reconstructed when decoding a block. It would suffice to reconstruct the missing data packets.https://git.nt.uni-saarland.de/LARN/PRRT/-/issues/22Improve PrrtBlock internal lists efficiency2018-11-02T11:32:38ZAndreas SchmidtImprove PrrtBlock internal lists efficiencyCurrently, PrrtBlock uses linked lists internally to store packets. Accesses are linear from the start. There should be a more efficient algorithm and data structure for this.
Run `gprof` to look for obvious performance issues.Currently, PrrtBlock uses linked lists internally to store packets. Accesses are linear from the start. There should be a more efficient algorithm and data structure for this.
Run `gprof` to look for obvious performance issues.https://git.nt.uni-saarland.de/LARN/PRRT/-/issues/23Receiver should occassionally call the clean-up routine2018-07-10T10:56:23ZAndreas SchmidtReceiver should occassionally call the clean-up routinehttps://git.nt.uni-saarland.de/LARN/PRRT/-/issues/26Ensure Clock-Synchronization is properly working2018-11-23T10:34:20ZAndreas SchmidtEnsure Clock-Synchronization is properly workingCurrently, the clock-sync start is not robust, so that packets at the beginning of a transmission are quickly discarded. Especially when the inter-packet time is high, it is not capable of reducing the phase error to a small value. With ...Currently, the clock-sync start is not robust, so that packets at the beginning of a transmission are quickly discarded. Especially when the inter-packet time is high, it is not capable of reducing the phase error to a small value. With the current implementation, the residual phase error is proportional to the inter-packet time.
Finally, all timestamps should be taken from the PRRT and not the system clock.
## Synchronization Test
* On receiver, print current time and prrt time.
* Check debug output.
## Integration Test Setup
* Purposefully de-synchronize two systems (e.g. RNAs)
* Verify that without a code change, no packets are received
* Add code changes (replacing `get_current_time()` with `get_prrt_time()`) and check if this leads to packets being received.https://git.nt.uni-saarland.de/LARN/PRRT/-/issues/27Repeat Feedback if lost2018-07-20T15:14:15ZAndreas SchmidtRepeat Feedback if lostIf a receiver does not get new data for a while (or does not need to send out new feedback), a special feedback packet should be forwarded, so that the sender can continue to send data.If a receiver does not get new data for a while (or does not need to send out new feedback), a special feedback packet should be forwarded, so that the sender can continue to send data.https://git.nt.uni-saarland.de/LARN/PRRT/-/issues/29Use RTT as window size for LossStatistics2018-11-02T11:31:31ZAndreas SchmidtUse RTT as window size for LossStatistics`PrrtReceptionTable`:
* Add array with timestamps.
* Use [now - RTT : now] as window.
Hints:
* Binary search for end-points in bitmap
* Use transposed indizes`PrrtReceptionTable`:
* Add array with timestamps.
* Use [now - RTT : now] as window.
Hints:
* Binary search for end-points in bitmap
* Use transposed indizeshttps://git.nt.uni-saarland.de/LARN/PRRT/-/issues/32Stop retransmissions after block is complete2018-10-18T07:51:09ZAndreas SchmidtStop retransmissions after block is completeCurrently, a retransmission schedule is completely executed. Instead, as soon as k packets of the block have been ACKed, the sender should stop retransmissions.
We might also think about coding the packets only shortly before they are n...Currently, a retransmission schedule is completely executed. Instead, as soon as k packets of the block have been ACKed, the sender should stop retransmissions.
We might also think about coding the packets only shortly before they are needed.https://git.nt.uni-saarland.de/LARN/PRRT/-/issues/33Potential busywait caused by Pacing2018-11-23T12:25:48ZAndreas SchmidtPotential busywait caused by PacingEvaluations with TUM revealed that if pacing is enabled, their test suite stops working in the following way:
* One peer stops receiving data.
* On this peer, the load of one CPU goes up to 100%.
This needs further investigation as set...Evaluations with TUM revealed that if pacing is enabled, their test suite stops working in the following way:
* One peer stops receiving data.
* On this peer, the load of one CPU goes up to 100%.
This needs further investigation as setting `pacingEnabled` to `false` solved the problem.https://git.nt.uni-saarland.de/LARN/PRRT/-/issues/35Revisit Pace-Filter2019-10-31T08:29:25ZAndreas SchmidtRevisit Pace-FilterWe should revisit the pace filters with respect to the following:
1. **Window Size and filter-function** should be pace-dependent (i.e. we should employ different ones for the system paces as for the network paces).
2. **Filter-functio...We should revisit the pace filters with respect to the following:
1. **Window Size and filter-function** should be pace-dependent (i.e. we should employ different ones for the system paces as for the network paces).
2. **Filter-functions** in general should be checked for prediction quality as well as runtime complexity. Maybe a 95-percentile filter is a good choice conceptually, but might be prohibitive in terms of runtime overhead.
3. **Cooperation of pace-filters**. Currently, we use multiple filters for the different components of a single pace (i.e. internal, external and dependent). Maybe they should be synchronized, i.e. they expire synchronously. The question is then obviously how we update the *current* three-tuple if a *new* three-tuple comes in (which tuple-component is used to apply MAX?).
## Collection of Ideas
* Moving Media Filter: https://codereview.stackexchange.com/questions/188512/moving-median-filter-medfilt-in-chttps://git.nt.uni-saarland.de/LARN/PRRT/-/issues/36Unittests with Cython2019-04-26T12:44:34ZAndreas SchmidtUnittests with Cython## Commandline
```python -m unittest tests/prrt/prrt_coding_configuration_test```
## Prepare PRRT for Pyximport
**`/prrt/prrt.pyxdeps`**
```
*
```
**`/prrt/prrt.pyxbld`**
```
make_ext():
sources=["prrt/*.pyx"]
```
## Unittest PRRT...## Commandline
```python -m unittest tests/prrt/prrt_coding_configuration_test```
## Prepare PRRT for Pyximport
**`/prrt/prrt.pyxdeps`**
```
*
```
**`/prrt/prrt.pyxbld`**
```
make_ext():
sources=["prrt/*.pyx"]
```
## Unittest PRRT Import
```
# Add Cython import capability
import pyximport
pyximport.install()
# Add local PRRT to import path
import sys
sys.path.append(XX)
sys.path.append(XX + "/prrt")
# Import PRRT
import prrt
```Ashkan TaslimiAshkan Taslimihttps://git.nt.uni-saarland.de/LARN/PRRT/-/issues/37Add PrrtSystemParameter class2019-06-05T15:26:31ZAndreas SchmidtAdd PrrtSystemParameter class# Add Class
```python
class PrrtSystemParameters:
response_delay
packet_loss_detection_delay
```
* [x] (D_c) Erasure coding delay in seconds. (property `block_coding_delay`)
* Measured by X-Lap (online or offline)
* [x] (D_ptx) ...# Add Class
```python
class PrrtSystemParameters:
response_delay
packet_loss_detection_delay
```
* [x] (D_c) Erasure coding delay in seconds. (property `block_coding_delay`)
* Measured by X-Lap (online or offline)
* [x] (D_ptx) Repair packet transmission delay in seconds. (property `redundancy_packet_transmission_delay`)
* Packet length / btl_dr_fwd
* [x] (D_rs) Response delay in seconds. (property `processing_delay`)
* Measured by X-Lap (online or offline)
* [x] (D_pl) Packet loss detection delay. (property `packet_loss_detection_delay`)
* Measured by X-Lap (online or offline)
* [x] (T_s) Source packet interval in seconds. (property `source_packet_interval`)
* 0.01 as default value.
# Provide system parameters from PrrtSocket
```python
class PrrtSocket:
@property
def system_parameters():
return PrrtSystemParameters()Ashkan TaslimiAshkan Taslimihttps://git.nt.uni-saarland.de/LARN/PRRT/-/issues/38Create HEC Search class2019-06-05T12:28:59ZAndreas SchmidtCreate HEC Search classFile: `/prrt/hec_search.py`
```python
class AbstractSearch():
def search(self, channelParameters, systemParameters, applicationParameters):
raise NotImplemented()
class HECFullSearch(AbstractSearch):
def __init__(self, ...File: `/prrt/hec_search.py`
```python
class AbstractSearch():
def search(self, channelParameters, systemParameters, applicationParameters):
raise NotImplemented()
class HECFullSearch(AbstractSearch):
def __init__(self, np_max):
self.n_max = 255
pass
def search(self, channelParameters, systemParameters, applicationParameters):
self.k_lim = somewhat(applicationParameters.loss_tolerance, self.n_max)
# magic happens here
return CodingConfiguration()
```Ashkan TaslimiAshkan Taslimihttps://git.nt.uni-saarland.de/LARN/PRRT/-/issues/39Evaluate Search2019-06-19T13:17:40ZAndreas SchmidtEvaluate Search```python
def evaluate(search, appParams, channelParams, systemParams):
s = search(appParams, channelParams, systemParams)
start = time.now()
config = s.search()
duration = time.now() - start
return config, duration
...```python
def evaluate(search, appParams, channelParams, systemParams):
s = search(appParams, channelParams, systemParams)
start = time.now()
config = s.search()
duration = time.now() - start
return config, duration
def test_case():
appParams = ApplicationParams(...)
channelParams = ChannelParams(...)
systemParams = SystemParams(...)
for search in [FullSearch, GreedySearch]:
config, duration = evaluate(search, appParams, channelParams, systemParams)
rows.append(..., search, config, duration)
pd.DataFrame(rows).to_csv()
```Ashkan TaslimiAshkan Taslimihttps://git.nt.uni-saarland.de/LARN/PRRT/-/issues/40Rust Bindings2020-02-27T10:18:19ZAndreas SchmidtRust BindingsIn order to create the relay, one might consider to create Rust bindings.
* An interesting talk: https://www.youtube.com/watch?v=dZexOlInedU&list=PLXajQV_H-DxJPiJQK8gvou4SUZ8Zfvgm6&index=2
* Crates.io: bindgen, cbindgen, [cmake](https:...In order to create the relay, one might consider to create Rust bindings.
* An interesting talk: https://www.youtube.com/watch?v=dZexOlInedU&list=PLXajQV_H-DxJPiJQK8gvou4SUZ8Zfvgm6&index=2
* Crates.io: bindgen, cbindgen, [cmake](https://crates.io/crates/cmake)Sven LiefgenSven Liefgenhttps://git.nt.uni-saarland.de/LARN/PRRT/-/issues/42Check support for pure repetition-ARQ2021-06-24T11:59:26ZAndreas SchmidtCheck support for pure repetition-ARQhttps://git.nt.uni-saarland.de/LARN/PRRT/-/issues/43Consider redundancy in pace calculation2020-01-27T14:23:51ZPablo Gil PereiraConsider redundancy in pace calculationIn 'dataTransmitter.c' the pace is very high when redundancy added. Redundancy packets should be scheduled at the beginning of the block, so that their effect is distributed over the pace of all the previous packets in the block.In 'dataTransmitter.c' the pace is very high when redundancy added. Redundancy packets should be scheduled at the beginning of the block, so that their effect is distributed over the pace of all the previous packets in the block.https://git.nt.uni-saarland.de/LARN/PRRT/-/issues/44Oxidize units2020-05-22T08:26:46ZSven LiefgenOxidize unitsIn the current version I decided to use `chrono::Duration` and `chrono::NaiveDateTime` for time related fields as I started with the `PrrtClock` and there it seemed most fitting as it can get the current time and supports negative durati...In the current version I decided to use `chrono::Duration` and `chrono::NaiveDateTime` for time related fields as I started with the `PrrtClock` and there it seemed most fitting as it can get the current time and supports negative durations.
For the rest of the units I use however `uom`. The three options for time are:
* `std::Duration`,
* `chrono::Duration`,
* `uom::Time`.
This issue serves mostly the purpose of reminding me that I have to think about this again, but feel free to give your opinion.Sven LiefgenSven Liefgenhttps://git.nt.uni-saarland.de/LARN/PRRT/-/issues/45NULL in codingParams2020-07-13T09:04:35ZSven LiefgenNULL in codingParamsThe current rust implementation of codingParams transforms a pointer to a vector without NULL checkThe current rust implementation of codingParams transforms a pointer to a vector without NULL checkhttps://git.nt.uni-saarland.de/LARN/PRRT/-/issues/46Passing packets to the coder2020-07-29T04:59:26ZSven LiefgenPassing packets to the coderCurrently the packets are passed to the coder as a Matrix.
This should be abstracted somehow, to make the usage more intuitive.Currently the packets are passed to the coder as a Matrix.
This should be abstracted somehow, to make the usage more intuitive.https://git.nt.uni-saarland.de/LARN/PRRT/-/issues/47Timestamps2020-08-24T15:37:42ZSven LiefgenTimestampsBitwidth of timestampsBitwidth of timestampshttps://git.nt.uni-saarland.de/LARN/PRRT/-/issues/48Correctness of PaceFilter2020-08-27T13:53:14ZSven LiefgenCorrectness of PaceFilterThe `update` on a `PaceFilter` checks if it is valid only after updating the value. Should this not happen beforehand?
As it is now, an update with a smaller value than currently in the buffer would be discarded even though the current ...The `update` on a `PaceFilter` checks if it is valid only after updating the value. Should this not happen beforehand?
As it is now, an update with a smaller value than currently in the buffer would be discarded even though the current value is not valid anymore, as it is only invalidated after the update.
[pace.rs](https://git.nt.uni-saarland.de/LARN/PRRT/-/blob/63445bee80ed2e51042a0f4ccdc711e9c71be517/prrt/src/pace.rs#L139-153)https://git.nt.uni-saarland.de/LARN/PRRT/-/issues/49Buffer length for decoding redundancy packets2020-11-03T07:20:07ZSven LiefgenBuffer length for decoding redundancy packetsThe buffer containing the raw packets has to have the right size for the redundancy packets when deserializing them into `RedundancyPayload`.If it is bigger, then the resulting payload will have additional zeroes at the end of the data.
...The buffer containing the raw packets has to have the right size for the redundancy packets when deserializing them into `RedundancyPayload`.If it is bigger, then the resulting payload will have additional zeroes at the end of the data.
This is the case, as redundancy packets do not carry length information.https://git.nt.uni-saarland.de/LARN/PRRT/-/issues/50Feature list for oxidization2020-11-18T06:53:48ZSven LiefgenFeature list for oxidizationThe following list provides some features that should improve the rust code, that came up during oxidization but have not yet bee implemented.
- [ ] Trait for stores (First steps in `src/store.rs`)
- [ ] Different packet types (I don't ...The following list provides some features that should improve the rust code, that came up during oxidization but have not yet bee implemented.
- [ ] Trait for stores (First steps in `src/store.rs`)
- [ ] Different packet types (I don't like the way it is currently)https://git.nt.uni-saarland.de/LARN/PRRT/-/issues/51Behaviour of failing locks2020-11-18T07:11:57ZSven LiefgenBehaviour of failing locksCurrently, most of the functions that use locks, return a boolean. However the return value is rarely checked. This means that if a lock fails, it is logged, but nothing else happens. Is this intended behavior?Currently, most of the functions that use locks, return a boolean. However the return value is rarely checked. This means that if a lock fails, it is logged, but nothing else happens. Is this intended behavior?https://git.nt.uni-saarland.de/LARN/PRRT/-/issues/52Review concurrency2020-12-08T10:24:54ZSven LiefgenReview concurrencyThe C code didn't use locks for a lot of accesses on the socket, which seems to be correct, as they only ever occur in one thread. However in Rust, each field that is written to has to be in a Mutex. The Mutex overhead could probably be ...The C code didn't use locks for a lot of accesses on the socket, which seems to be correct, as they only ever occur in one thread. However in Rust, each field that is written to has to be in a Mutex. The Mutex overhead could probably be omitted by using unsafe code to get mutable references without a Mutex.https://git.nt.uni-saarland.de/LARN/PRRT/-/issues/53Review Packets2020-12-23T08:20:07ZSven LiefgenReview PacketsThe implementation and especially the use of `Packet`s is quite bulky.
In a lot of cases, it is guaranteed that we have a certain kind of `Packet`, however we still need to unpack and deal with the impossible cases.The implementation and especially the use of `Packet`s is quite bulky.
In a lot of cases, it is guaranteed that we have a certain kind of `Packet`, however we still need to unpack and deal with the impossible cases.https://git.nt.uni-saarland.de/LARN/PRRT/-/issues/54Paces and Mutex2021-01-08T13:44:37ZSven LiefgenPaces and MutexThe Paces are accessed from multiple threads and thus need a Mutex, however how exactly should this be done?
Currently, each Pace has it's Mutex that is locked whenever an operation is executed on the Pace.
However, I guess, `track_star...The Paces are accessed from multiple threads and thus need a Mutex, however how exactly should this be done?
Currently, each Pace has it's Mutex that is locked whenever an operation is executed on the Pace.
However, I guess, `track_start` and `track_end` should behave like a Mutex themselves conceptually. I.e. Only the thread that started the tracking should be able to end it but others should be able to read at any time. (At least I convinced myself that this should be the case, but writing this I'm not sure anymore.)https://git.nt.uni-saarland.de/LARN/PRRT/-/issues/55Send sync2021-01-20T08:57:40ZSven LiefgenSend sync`send_sync` has to be revisited, currently it adds a packet to the same queue as `send_async`, with the difference that it blocks until the packet has been sent.
This should probably use some kind of priority queue.
The C version calls t...`send_sync` has to be revisited, currently it adds a packet to the same queue as `send_async`, with the difference that it blocks until the packet has been sent.
This should probably use some kind of priority queue.
The C version calls the sending method directly, which is not possible with the current design. However there the decision for which packet to send (sync/async) depends on which thread gets the lock first.https://git.nt.uni-saarland.de/LARN/PRRT/-/issues/57Monothonic vs Realtime clock2021-02-16T13:28:12ZSven LiefgenMonothonic vs Realtime clockUse the same clock everywhere, especially when they need to interact.Use the same clock everywhere, especially when they need to interact.https://git.nt.uni-saarland.de/LARN/PRRT/-/issues/58Abstract away matrices2021-03-17T10:00:32ZSven LiefgenAbstract away matricesChange coder API to not use matrices on the outside.
This is confusing as it is not really clear what is what and what goes where.Change coder API to not use matrices on the outside.
This is confusing as it is not really clear what is what and what goes where.https://git.nt.uni-saarland.de/LARN/PRRT/-/issues/59Error Correction2021-04-29T08:32:39ZPablo Gil PereiraError CorrectionThe current implementation does not use the feedback to derive which and how many packets were lost in a block. Therefore, the redundancy packets in cycles other than cycle 0 are always transmitted regardless of packets been lost or not.The current implementation does not use the feedback to derive which and how many packets were lost in a block. Therefore, the redundancy packets in cycles other than cycle 0 are always transmitted regardless of packets been lost or not.https://git.nt.uni-saarland.de/LARN/PRRT/-/issues/60Problem with retransmission handler2021-05-01T19:21:50ZSven LiefgenProblem with retransmission handlerRunning the sender of prrtrelay on a Raspberry Pi 2B, I got problems with thread spawning for 1000 packets caused by the retransmission handler.
I guess this creates threads that are never terminated because the retransmission logic is ...Running the sender of prrtrelay on a Raspberry Pi 2B, I got problems with thread spawning for 1000 packets caused by the retransmission handler.
I guess this creates threads that are never terminated because the retransmission logic is not implemented yet.