You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the recent changes download timings are no longer accurate for time spent downloading an individual file in multifile mode.
This is related to some chunks blocking on connections so download_elapsed is effectively total_elapsed in all cases.
Pget should have a way of communicating time spent for a chunk and aggregating it for a given file rather than download_elapsed including blocking time. This also breaks the throughput calculation.
An alternative is to explore downloading one file at a time and allocating connections to meet the target chunk size before moving on to the next file.
If we go with communicating the download time up the stack, this feels like a legitimate use for values in the context (pointer to per-chunk data) instead of trying to pass data back up the whole stack.
The text was updated successfully, but these errors were encountered:
tempusfrangit
changed the title
Rework timing for download
Bug: file download time and throughput is no linger accurate
Dec 3, 2023
tempusfrangit
changed the title
Bug: file download time and throughput is no linger accurate
Bug: file download time and throughput is not accurate
Dec 3, 2023
With the recent changes download timings are no longer accurate for time spent downloading an individual file in multifile mode.
This is related to some chunks blocking on connections so download_elapsed is effectively total_elapsed in all cases.
Pget should have a way of communicating time spent for a chunk and aggregating it for a given file rather than download_elapsed including blocking time. This also breaks the throughput calculation.
An alternative is to explore downloading one file at a time and allocating connections to meet the target chunk size before moving on to the next file.
If we go with communicating the download time up the stack, this feels like a legitimate use for values in the context (pointer to per-chunk data) instead of trying to pass data back up the whole stack.
The text was updated successfully, but these errors were encountered: