UDP buffer management. #19
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a first step at handling the high data loss on the UDP link.
The low level UDP stack now properly reports how many bytes were actually written to its TX buffer. Before these changes, there was no indication of buffer overflow and packets would simply go into the bit bucket once the buffers were full. With that information, and the use of much larger FIFO buffers, the data loss has been greatly minimized. Ideally, it would be great if we had access to the TX buffer status before sending any data but this is better than nothing.
For now, when the code notices the buffer is full (after a failed write), it waits a bit and tries again (once) to send the remaining data within that one message. I can't wait around long otherwise we start losing data on the UART link and the existing code can't handle a partially sent MavLink message. It then bails out and stops trying to send the remaining messages until the next loop cycle.
With these changes, I brought the drop count down from around 20% under high stress to less than 1%.
I've put an issue requesting access to the buffer status (esp8266/Arduino#1988).