GCS_MAVLink: optimise FTP for available bandwidth

when we don't have hardware flow control don't use more than 1/3 of
available bandwidth for ftp outgoing transfers. This makes parameter
download faster on radios without flow control
This commit is contained in:
Andrew Tridgell 2023-01-02 15:04:36 +11:00 committed by Randy Mackay
parent 5de8fcc777
commit 1f05ee2232

View File

@ -483,7 +483,27 @@ void GCS_MAVLINK::ftp_worker(void) {
break;
}
const uint32_t transfer_size = 100;
/*
calculate a burst delay so that FTP burst
transfer doesn't use more than 1/3 of
available bandwidth on links that don't have
flow control. This reduces the chance of
lost packets a lot, which results in overall
faster transfers
*/
uint32_t burst_delay_ms = 0;
if (valid_channel(request.chan)) {
auto *port = mavlink_comm_port[request.chan];
if (port != nullptr && port->get_flow_control() != AP_HAL::UARTDriver::FLOW_CONTROL_ENABLE) {
const uint32_t bw = port->bw_in_kilobytes_per_second();
const uint16_t pkt_size = PAYLOAD_SIZE(request.chan, FILE_TRANSFER_PROTOCOL) - (sizeof(reply.data) - max_read);
burst_delay_ms = 3 * pkt_size / bw;
}
}
// this transfer size is enough for a full parameter file with max parameters
const uint32_t transfer_size = 500;
for (uint32_t i = 0; (i < transfer_size); i++) {
// fill the buffer
const ssize_t read_bytes = AP::FS().read(ftp.fd, reply.data, MIN(sizeof(reply.data), max_read));
@ -516,6 +536,8 @@ void GCS_MAVLINK::ftp_worker(void) {
// prep the reply to be used again
reply.seq_number++;
hal.scheduler->delay(burst_delay_ms);
}
if (reply.opcode != FTP_OP::Nack) {