-
-
Notifications
You must be signed in to change notification settings - Fork 6.7k
Units used in the progress meter are not clear #883
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
That's a fair point. I know I've heard it suggested a few times before but I can't find any references. curl has always used 1024 multiplier and I think it is too late to change that. I could see it showing 1234K instead of 1234k maybe, but there's not enough room there for KiB and MiB. And I disagree about using bits instead of bytes. |
The fact that a few persons have been uncertain what it means is not really a factor we can do much about. No matter what we do, there will be a few such persons. We've used the 1024 based system for the progress meter since the beginning and we've always showed bytes and bytes/second and that is in fact what most download tools show. I cannot see any strong reason to change that and I would object to the need for an option that would do nothing but multiplying the numbers with 8 just to show them as bits. The most complete docs for the progress meter right now is probably the progress meter section in the everything curl boo |
I think you closed this prematurely at least let's have a discussion. What's wrong with something like
|
Ok, let's discuss it. But I want someone to first tell me exactly why another option and extra code for this is necessary. The days of just adding more options without careful consideration and thinking about the weight they add is over. |
The documentation is nice, but at least you should align the case of "K" Kilobytes between the docs and the actual printout.. it seems clear that lowercase k is mandated by SI (and stand for 1000) while uppercase K is more common for computers and standard for instance in Jedec |
... that is not an argument that works on me. We've been using this output for a very long time and I think stability and consistency now weighs more than "you should use SI nomenclature" speak. Sorry. |
I did not say anything about aligning to SI nomenclature. Have you read you documentation page? it says: Units The progress meter displays bytes and bytes per second. It will also use suffixes for larger amounts of bytes, using the 1024 base system so 1024 is one kilobyte (1K), 2048 is 2K etc. curl supports these: You use K everywhere, but then you print "k" in the meter... |
Dumping the other rate units isn't necessary but I think it could be helpful to give the curl tool user an option, at least, if they want to see kbps or something. As far as replacing k with K in the progress my thinking there is the latter is less ambiguous because there's no data rate unit that uses an uppercase K and represents bits (afaik). |
Sure, but that's like the |
I have been using and recommending curl since version 0.1 probably. I use it for downloading and I use it for troubleshooting. Thanks a lot for your kindness and understanding, and the tool that I will continue using |
So you say. Let's leave this open for a bit and see if there are any other opinions. |
The man page has been updated slightly to mention the units. |
I'm happy with this change. Still the documentation uses one more time the uppercase K for Kilobytes while the code really has snprintf(max5, 6, "%4" CURL_FORMAT_CURL_OFF_T "k", bytes/ONE_KILOBYTE); It seems it would be easy to make documentation and code the same, but at least people will be able to look it up in the manual |
The curl progress bar can be used for a quick estimation of the performance of the connection, however the number and the unit is confusing. It shows lowercase "k" where it should show KiBps and M instead of MiBps.
I'm not the only one confused as this link shows:
http://superuser.com/questions/951056/what-units-does-curl-use-for-bandwidth
I also think that probably bits should be used instead of bytes here as it's more common to use bits when talking about network speed (or at least it may have a -option for that)
The text was updated successfully, but these errors were encountered: