mhttpd status page equipment data rate units are wrong

Issue #77 resolved
dd1 created an issue

mhttpd status page equipment data rate units are shown is "MS/s". Correct units is MBytes/sec. (as opposed to MiBytes/sec). Numbers are actually show as KBytes/sec (old status page was Mbytes/sec, I think). K.O.

Comments (14)

  1. Stefan Ritt

    I disagree.

    Frontends write in units 1kB = 1024 Bytes, see here:

                   eq->stats.kbytes_per_sec =
                       eq->bytes_sent / 1024.0 / ((actual_millitime - last_time_rate) /
                                                  1000.0);
    

    If you look in various sources, MB is sometimes 1024^2 and sometime 1000^2. See https://en.wikipedia.org/wiki/Megabyte where it says

    The megabyte is commonly used to measure either 10002 bytes or 10242 bytes. 
    

    I personally don't care which unit we use, as long as we are consistent. I guess what we should do is what people "expect". So what I (and maybe many other) are used to is what our tools give us. If you do a

    ls -lh
    

    then by default it gives you 1 MB = 1024^2 Bytes. The is a special flag --si which gives you 1 MB = 1000^2, but it is not the default. So I guess we should go with what the "ls" tool gives us by default. If you agree, close this issue unless we use inconsistent units somewhere.

    Stefan

  2. dd1 reporter

    The standard units to 1000x1000 is MB, 1024x1024 is MiB, has been for years. I do not ask stats.kbytes to be renames stats.kibytes, but on the status page we should have correct units and those are MiB, not MB. K.O.

  3. Stefan Ritt

    This tells me that either my "ls" command is wrong, meaning all Linux distributions are wrong, or your statement is not correct. But probably you are right and we have to tell Linus to change his kernel.

    Screen Shot 2017-11-13 at 19.47.59 .png

  4. Pierre-André Amaudruz

    I have to admit this is the first time that I'm exposed to this "MiB" reference. While this makes sense to us as we are aware of the difference (10^3, 2^10) (I've been confused myself on that issue), It would also confuse people and make that think twice about every "MB" that they would find on any computer package. As Stefan mentioned, it doesn't matter what the number precisely represent as long as it can be compared to other numbers with identical unit symbols. The general consent to me and obviously to others (ls, any MB or Mb in literature) MegaBytes is some number... . In fact, I would say that as soon as "M" or "K" or "G" is followed by "b" or "B" we accept this unit to be computer related stuff and everything goes in 2^10. the cmd df, df-h show in 1K-block, implicitly 1024B-block and the "G" is 1024x1024 not "Gi". So yes Konstantin you're right and everybody else is wrong based on this new symbol. They introduced it too late, we should stick to the computer convention and be consistent.

  5. Stefan Ritt
    • changed status to open

    I agree with Pierre that "MiB" for 1024 * 1024 bytes is more confusing to all users, even if it is strictly speaking correct. So I vote for keeping "MB" on the status page for 1024 * 1024 bytes, and I would like to hear the opinion of Pierre and Thomas on that. I agree that this is not the most important problem we have right now, but I think it's not good to come up with a modification which confuses most of our users.

  6. dd1 reporter

    not my problem if other people (who write "ls" and "du") do not know about MiB. json writers never heard about "nan" and "infinity" numeric values, human ignorance is unlimited. If some people feel strongly about measuring stuff in strange units "imperial kilo-gallons", I can live with this. But using wrong units is wrong. You do not say "35 degrees kelvin outside, what a hot day". If somebody else is using wrong units somewhere else, how is that relevant for us? K.O.

  7. Thomas Lindner

    I think that the status page should show things in 1024x1024 bytes. I agree that it is confusing to have different units than what is shown by tools like 'ls'.

    On the other hand, I don't think people are likely to be confused if we write MiB/s for the data rate and MiB for the file size written. I think that most people won't notice and that those that do notice will learn something new and useful.

    (As an aside, I note that the version of midas used for UCN has the labels 'MB/s' for the data rate and 'MiB written' for the Logger. I'm not sure anyone noticed in that case.)

  8. Stefan Ritt

    Well, I had already some people asking me "what the heck is this damned MiB? There is a typo! This must be MB". And I guess I will have more people in the future. I have certainly better things to do than replying to all these people here at PSI. Ok, I can't turn around Konstantin, I give up. Apparently also Pierres comment above did not help. So we have to educate the rest of the world. Good luck.

  9. Stefan Ritt

    Now we have "MiB" in the equipment list and "MB" in the logging channels. Then we have "kBytes per sec." in the ODB. In order to be consistent, all three settings should be the same. KO changed the "MB" to "MiB" in the equipment list, so I recommend that he changes also the other values. I still disagree, but we should not mix units on the same page.

  10. dd1 reporter

    Midas now shows consistent units. I would support the vote to change 1024 base units to 1000 base units with the web page becoming "MB" and the eq statistics odb name "kbytes" becoming correct. K.O.

  11. Stefan Ritt

    It did not. The equipment rate was MiB/s, the logger rate was MB/s. Now everything is in power of ten.

  12. Log in to comment