- Jan 29, 2024
-
-
Joey Hess authored
-
- Jan 25, 2024
-
-
Joey Hess authored
-
Joey Hess authored
-
Joey Hess authored
The getSocket comment that mentioned using ":port" in the hostname seems to have been incorrect or be out of date. After all, the bug report came when the user first tried doing that, and it didn't work. Sponsored-by: the NIH-funded NICEMAN (ReproNim TR&D3) project
-
Joey Hess authored
-
Joey Hess authored
-
Joey Hess authored
-
Joey Hess authored
-
Joey Hess authored
-
Joey Hess authored
-
Joey Hess authored
-
Joey Hess authored
-
Joey Hess authored
-
Joey Hess authored
-
- Jan 23, 2024
-
-
Joey Hess authored
-
- Jan 20, 2024
- Jan 19, 2024
-
-
Joey Hess authored
-
ssh://git-annex.branchable.comJoey Hess authored
-
Joey Hess authored
Sponsored-by: Dartmouth College's DANDI project
-
Joey Hess authored
external: Monitor file size when getting content from external special remotes and use that to update the progress meter, in case the external special remote program does not report progress. This relies on 703a70ca to prevent ever running the meter backwards. Sponsored-by: Dartmouth College's DANDI project
-
Joey Hess authored
Sponsored-by: Dartmouth College's DANDI project
-
Joey Hess authored
This is groundwork for using watchFileSize for downloads from external special remotes. In Annex.Content.downloadUrl, this potentially avoids jitter in the progress meter. When downloading with conduit, the meter gets updated based on both the size of the file, and on the data flowing through conduit. If that has not yet been flushed to the file, it seems possible for the meter to run backwards when meter is updated with the file size. It's probably only a few kb of jitter, so may not be visible. Sponsored-by: Dartmouth College's DANDI project
-
jstritch authored
-
ssh://git-annex.branchable.comJoey Hess authored
-
Joey Hess authored
Refactored to allow offline experimentation, and ended up changing the allowedvariation (aka fudge factor) to 3. 10 seems too high, and 1.5 too low. Scale earlier, so even if the first chunk takes less than the configured time period, allowance is made that later chunks might transfer slower. Decided to use the same allowedvariation to decide when to start scaling. Smoothed the scaling out. Some examples: ghci> upscale (BwRate 10 (Duration 60)) 25 BwRate 13 (Duration {durationSeconds = 75}) -- A small scaling upwards after 1/3rd the time. Not noticable. ghci> upscale (BwRate 10 (Duration 60)) 60 BwRate 30 (Duration {durationSeconds = 180}) -- At the configured time, 3x scaling. ghci> upscale (BwRate 10 (Duration 60)) 120 BwRate 60 (Duration {durationSeconds = 360}) -- A typical upscaling, here a 1 minute duration became 6 minutes -- due to the first chunk taking 2 minutes to transfer. ghci> upscale (BwRate 10 (Duration 60)) 600 BwRate 300 (Duration {durationSeconds = 1800}) -- Here the first chunk took 10 minutes to transfer, so it will -- take 30 minutes to detect a stall. Sponsored-by: Dartmouth College's DANDI project
-
- Jan 18, 2024
-
-
imlew authored
-
Yaroslav Halchenko authored
-
Joey Hess authored
-
Joey Hess authored
-
ssh://git-annex.branchable.comJoey Hess authored
-
Joey Hess authored
Improve annex.stalldetection to handle remotes that update progress less frequently than the configured time period. In particular, this makes remotes that don't report progress but are chunked work when transferring a single chunk takes longer than the specified time period. Any remotes that just have very low update granulatity would also be handled by this. The change to Remote.Helper.Chunked avoids an extra progress update when resuming an interrupted upload. In that case, the code saw first Nothing and then Just the already transferred number of bytes, which defeated this new heuristic. This change will mean that, when resuming an interrupted upload to a chunked remote that does not do its own progress reporting, the progress display does not start out displaying the amount sent so far, until after the first chunk is sent. This behavior change does not seem like a major problem. About the scalefudgefactor, it seems reasonable to expect subsequent chunks to take no more than 1.5 times as long as the first chunk to transfer. Could set it to 1, but then any chunk taking a little longer would be treated as a stall. 2 also seems a likely value. Even 10 might be fine? Sponsored-by: Dartmouth College's DANDI project
-
Yaroslav Halchenko authored
-
Joey Hess authored
-
imlew authored
No commit message
-
Joey Hess authored
-
Joey Hess authored
-
Joey Hess authored
-
Joey Hess authored
Avoid users getting confused and thinking this allows specifying the port. Sponsored-by: the NIH-funded NICEMAN (ReproNim TR&D3) project
-
Joey Hess authored
-