From 515f54bd70ff6c78085ccadb982f83437d8ed4f0 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sun, 10 Jan 2021 16:32:44 -0400 Subject: [PATCH] idea --- doc/todo/dynamic_stall_detection.mdwn | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) create mode 100644 doc/todo/dynamic_stall_detection.mdwn diff --git a/doc/todo/dynamic_stall_detection.mdwn b/doc/todo/dynamic_stall_detection.mdwn new file mode 100644 index 0000000000..7a1fc638e9 --- /dev/null +++ b/doc/todo/dynamic_stall_detection.mdwn @@ -0,0 +1,21 @@ +annex.stalldetection lets remotes be configured with a minimum throughput +to detect and retry stalls. But most users are not going to configure this. +Could something be done to dynamically detect a stall, without configuration? + +Eg, wait until data starts to flow, and then check if there's at least some +data being sent each minute. If so, the progress display is being updated +at least every minute. So then if 2 minutes go by without more data +flowing, it's almost certainly stalled. And if the progress display is +updated less frequently, see if it's updated every 2 minutes, etc. Although +realistically, progress displays are updated every chunk, and there's +typically more than 1 chunk per minute. So longer durations than 1 minute +may be an unncessary complication. And a couple of minutes to detect a +stall is fine. + +It may still need a config to turn it on, because running +transfers in separate processes can lead to more resource use, or even +password prompting, which could be annoying to existing users. Also, if it +gets it wrong and the remote does not support resuming transfers, +defaulting to on could lead to bad waste of resources. It could +detect stalls even when not turned on, but only display a message +suggesting enabling the config. --[[Joey]] -- 2.30.2