--write-out values for total_time, download_size, and speed_download do not agree #7017
I did this
Running on Ubuntu 20.10 using curl 7.76.1 (both from Ubuntu's repo and compiled from source) I was collecting some download speed statistics using the --write-out options with the following command
The following shows a sample of the output I received:
Note that the value reported for speed_download is not equal to the size_download divided by the time_total. Instead it appears that the time_total has been truncated to the millisecond before calculating the speed_download. On my system, clock_getres for the monotonic clock indicates a 1 nanosecond resolution, so I have no reason to believe the printed times (to microsecond resolution) are incorrect.
I expected the following
I expect one of two things depending on whether or not the resolution of time measurements is 1 millisecond or 1 microsecond.
If the resolution for times is 1 millisecond, I would expect times to be printed with no more than three decimal places (i.e. millisecond resolution) and in this case the speed_download number is correct.
If the resolution for times is 1 microsecond, as it appears to be from the six places after the decimal, I expect speed_download to use the full value of the time for its calculation rather than the time truncated to milliseconds.
Compiled from source version:
Linux yemaya 5.11.0-7614-generic #15~1618626693~20.10~ecb25cd-Ubuntu SMP Thu Apr 22 16:00:45 UTC x86_64 x86_64 x86_64 GNU/Linux
The text was updated successfully, but these errors were encountered:
I did a little more digging and it appears the culprit might be the
I feel like I could fix this, but I am concerned that perhaps there are many places where it is assumed the time difference is in milliseconds.
I don't think it is at all related to
In libcurl, that value is calculated here:
It does indeed use millisecond precision there.
I'll create a PR with what I believe could be an appropriate fix would be neat if you could try it out!
... this improves precision, especially for transfers in the few or even sub millisecond range. Reported-by: J. Bromley Fixes #7017