LARN issueshttps://git.nt.uni-saarland.de/groups/LARN/-/issues2021-05-01T19:21:50Zhttps://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.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/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/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/56`Receiver::on_application_write` does nothing2021-01-28T09:43:13ZSven Liefgen`Receiver::on_application_write` does nothingThe first parameter to `Receiver::on_application_write` is always 1, thus the if inside always fails.
In the C version, the first parameter was a queue size. As far as I understand the code, this queue will always only contain one or ze...The first parameter to `Receiver::on_application_write` is always 1, thus the if inside always fails.
In the C version, the first parameter was a queue size. As far as I understand the code, this queue will always only contain one or zero elements. In the async case, it should always be one at this point.
I guess it should be zero in the sync case, but then I think it should be added to the if blocks and we should drop this parameter.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/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/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/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/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/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/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/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/47Timestamps2020-08-24T15:37:42ZSven LiefgenTimestampsBitwidth of timestampsBitwidth of timestampshttps://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/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/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/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/RNA/Software/-/issues/5Make the WiFi more predictable2020-02-07T08:02:14ZAndreas SchmidtMake the WiFi more predictableFor the drone evaluations, we might consider making the WiFi more predictable:
* [ ] Check AP settings.
* [ ] Check `iwconfig` settings at the Raspi.
- [ ] `mode`
- [ ] `freq/channel`
- [ ] `rate`
- [ ] `retry`For the drone evaluations, we might consider making the WiFi more predictable:
* [ ] Check AP settings.
* [ ] Check `iwconfig` settings at the Raspi.
- [ ] `mode`
- [ ] `freq/channel`
- [ ] `rate`
- [ ] `retry`Marlene BöhmerMarlene Böhmerhttps://git.nt.uni-saarland.de/LARN/RNA/Software/-/issues/4Real-Time for Drone2020-02-07T08:04:31ZAndreas SchmidtReal-Time for Drone# Scheduling
https://www.iot-programmer.com/index.php/books/22-raspberry-pi-and-the-iot-in-c/chapters-raspberry-pi-and-the-iot-in-c/33-raspberry-pi-iot-in-c-almost-realtime-linux
# `PREEMPT_RT`
Potentially, this is work a check:
https:/...# Scheduling
https://www.iot-programmer.com/index.php/books/22-raspberry-pi-and-the-iot-in-c/chapters-raspberry-pi-and-the-iot-in-c/33-raspberry-pi-iot-in-c-almost-realtime-linux
# `PREEMPT_RT`
Potentially, this is work a check:
https://www.elektronikpraxis.vogel.de/echtzeit-mit-dem-raspberry-pi-und-linux-preempt_rt-a-630497/
* https://lemariva.com/blog/2019/09/raspberry-pi-4b-preempt-rt-kernel-419y-performance-test
* https://lemariva.com/blog/2018/02/raspberry-pi-rt-preempt-tutorial-for-kernel-4-14-y
**Result: Didn't cause a big improvement of predictability.**Marlene BöhmerMarlene Böhmer