idea
This commit is contained in:
parent
e26bf1b4bb
commit
515f54bd70
1 changed files with 21 additions and 0 deletions
21
doc/todo/dynamic_stall_detection.mdwn
Normal file
21
doc/todo/dynamic_stall_detection.mdwn
Normal file
|
@ -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]]
|
Loading…
Add table
Reference in a new issue