You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[sg noup] net: ppp: delay PPP thread after receiving a packet
This is a simple way to create back-pressure towards Linux.
A better approach might be to have a separate network queue for PPP and
delay while there is already a packet in the queue. This is currently not
supported by the Zephyr network queue API (there is no method to check how
many packets are currently in the queue), and would also require a bit of
cleanup in the lb_radio driver (correctly handle getting a new packet from
PPP while receiving or starting to receive a packet via Lemonbeat).
Note regarding the defaults:
- 100 ms fixed delay is meant to accommodate for sending ACKs & general
overhead such as sending the preamble (2x 17.6 ms for packet & ACK,
another 2x 17.6 ms if a reply is sent).
- The 400 μs variable delay is meant to allow for transmission of the data
over UART (around 70 μs per byte at 115200 bps), over the air using
Lemonbeat (80 μs per byte at 100 kbps), and sending an equally large
packet back. Although a value of 300 μs should be sufficient, experiments
show that when testing with large packets and short intervals (1450
bytes, 100 ms interval), only 1-2 out of 3 pings get through; with a per
byte delay of 400 μs, all 3 pings get through.
Issue: SG-21138
(cherry picked from commit e49c0f5)
0 commit comments