mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

improved bwrate limiting implementation

Browse source 
New method is much better. Avoids unrestrained transfer at the beginning
(except for the first block. Keeps right at or a few kb/s below the
configured limit, with very little varation in the actual reported bandwidth.

Removed the /s part of the config as it's not needed.

Ready to merge.

Sponsored-by: Luke Shumaker on Patreon
This commit is contained in:
Joey Hess 2021-09-22 15:14:28 -04:00
parent 44d3d50785
commit e8496d62e4
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
5 changed files with 46 additions and 55 deletions
Download patch file Download diff file Expand all files Collapse all files

18
doc/todo/bwlimit.mdwn
View file

@ -10,17 +10,17 @@ works, it will probably work to put the delay in there. --[[Joey]]
[[confirmed]]
> Implmentation in progress in the `bwlimit` branch. Seems to work, but see
> commit message for what still needs to be done. --[[Joey]]
> The directory special remote, when resuming an interrupted
> Implemented and works well.
>
> A local git remote, when resuming an interrupted
> transfer, has to hash the file (with default annex.verify settings),
> and that hashing updates the progress bar, and so the bwlimit can kick
> in and slow down that initial hashing, before any data copying begins.
> This seems perhaps ok; if you've bwlimited a directory special
> This seems perhaps ok; if you've bwlimited a local git remote,
> remote you're wanting to limit disk IO. Only reason it might not be ok
> is if the intent is to limit IO to the disk containing the directory
> special remote, but not the one containing the annex repo.
> is if the intent is to limit IO to the disk containing the remote
> but not the one containing the annex repo. (This also probably
> holds for the directory special remote.)
>
> Other remotes, including git over ssh, when resuming don't have that
> problem. Looks like chunked special remotes narrowly avoid it, just
@ -28,4 +28,8 @@ works, it will probably work to put the delay in there. --[[Joey]]
> when resuming. It might be worthwhile to differentiate between progress
> updates for incremental verification setup and for actual transfers, and
> only rate limit the latter, just to avoid fragility in the code.
> I have not done so yet though, and am closing this..
> --[[Joey]]
[[done]]