Opened 2 years ago

Closed 11 months ago

#1913 closed enhancement (fixed)

Use SI units everwhere

Reported by: jogger Owned by: zzz
Priority: maintenance Milestone: 0.9.34
Component: apps/console Version: 0.9.28
Keywords: si units Cc:
Parent Tickets:

Description

i2p currently uses JEDEC notation when it comes to transfer speeds or storage. This conflicts with disk manufacturers, OS producers, router manufacturers, telecom providers all using SI units.

To make notation clear one could as a quick solution easily switch from kB to KiB and so forth by using correct IEC units. This would produce additional screen clutter and not help the user.

Users want to know: Will this torrent fit on my HD? Will this u/l bandwidth incl. burst fit my router configuration?

Benefits: One can easily compare stats and graphs to the left hand panel. Screen clutter is reduced. i2p reported figures relate to the outside world.

affected areas: stats, graphs, panel, config/bw, snark

Subtickets

#1912: reduce screen clutter by using 2.5 digit formattingenhancementclosedzzz

Change History (22)

comment:1 Changed 2 years ago by zzz

  • Component changed from unspecified to apps/console
  • Priority changed from minor to maintenance
  • Status changed from new to open

I really dislike the KiB notation and I don't think most people know what it means. Haven't heard any complaints about the way things are now, until this ticket. And I don't know offhand what JEDEC and IEC standards imply... there's a standard for whatever way you want to do it. There's also regional and cultural differences, and tech vs. non-tech user expectations, so it's impossible to make everybody happy here, and easy to bikeshed. But I could be wrong. Others please comment.

We use common code for almost all number display. If there's any inconsistencies (you mention stats vs graphs vs. left panel) that's arguably a bug and we should think about fixing it. The graphs are problematic because it's a separate library (jrobin). Stats page is a place where the additional precision is useful, so may be another exception worth keeping.

comment:2 Changed 2 years ago by zzz

Add a subticket #1912.

comment:3 Changed 2 years ago by jogger

wikipedia has a related article for "byte". i2p currently uses 1kB = 1024 byte which stems from old times when programmers thought in terms of pages sizes and disk allocation blocks. For network applications there is no reason sticking to this. When telecom providers sell bandwidth 10Mbit/s is 1.25MB/s = 1250000 bytes/s. We should adopt that.

displaying something like 1.7 kB now implies we are able to split the bit as it apparantly means 1024 + 1024*7/10.

together with the 2.5 digit proposal we could cleanly write in SI units:
198 kB (198000 bytes)
199 kB (199000 bytes)
.2 MB (200000 bytes)
.21 MB (210000 bytes)

comment:4 follow-up: Changed 2 years ago by zzz

ok, so what you're asking for is 1000 instead of 1024? Is that it?

Still not sure if you're also asking for changes in the letters (k or Ki instead of K)

As we're trying to simplify our UI, I think the existing 1234 is better than 1.2K which you propose in #1912.

Also not sure what you mean by "2.5 digit formatting" in #1912, perhaps you mean like a printf %2.5f format? This isn't C, it's Java, although there are some C-like formatting classes.

This would all go easier if it was clear what you're proposing. Then, perhaps, we can address the details.

comment:5 Changed 2 years ago by zzz

related, alternate snark proposal: #1838

comment:6 Changed 2 years ago by echelon

Moin

just to add: we had this discussion about SI and Computer like numbers years before. We changed it to the way it is and it works out.
All user do see the speed of I2P in MBit (all DSL lines I know are rated in MBit (like in 1024, not 1000)) in configuration speed, even if they sell it as 16 MBit. Even my cable does sell me 100 MBit, which is roughly above 11 MByte/sec. Snark page does show a value of kByte, which is correctly 1024 bytes, else we need to use KiBytes?, which nearly no one knows neither unterstand.
1 kByte = 1024 bytes. Thats not old, it is still up to date in all party of the computer (or what do you call datatypes, int,bit,.. - they do not work in 1000er).

I suggest keeping the current format. Thats the way it works all over the world, except for harddisk drives, in which companies try to gain more money.

comment:7 Changed 2 years ago by jogger

Sorry, I won´t change your mind, but here are 5 examples of popular services proving that you are dead wrong.

  • The Mac desktop uses Mbytes 1000-based
  • The Linux desktop uses Mbytes 1000-based
  • Popular routers report bandwidth in Mbps 1000 based
  • Internet providers do so (I bought 300 Mbps raw ethernet right at the plug in writing 300,000,000)
  • and most important: the linux man pages have a 30 year old example for k = 1000 when it comes to data transmission

Anybody should make the switch now, if it does not break backward compatibility like du, df and the like.

comment:8 Changed 2 years ago by echelon

Hi

Interestingly does my Linux Desktop show all values in 1 Kbyte = 1024bytes. Which is KDE, same with Mac I used last year.
Most routers I do know (Cisco) do use the same values 1k = 1024, same with my cable network adaptor, which is used by UPC europe wide.
Also most network providers I do know offers different lines, they do mix the values. E.G. in DSL line they do offer 16.000 lines, which are offered as 16 Mbit, which is wrong, it should be 16 MiBit?. But in case of real internet lines, the do work in Gigabit in case of 1 G = 1024M.
And even if one Linux manpage has a example for 1k= 1000, the kernel and filesystem and other subsystems of a Linux system do use 1k = 1024.

So, if we switch, we need to change the Letters/synonyms on all places, currently not needed.

echelon

comment:9 Changed 2 years ago by zzz

and we were having such a good conversation... absolutes like "proving dead wrong" aren't helpful. There is room here for discussion and it's easy to find examples to support any choice.

Perhaps the one place where 1000 might be good is on the /config page, for total bandwidth setting, perhaps inside the parenthesis where we print alternative units.

For i2psnark, we'd want to be consistent with other torrent clients, trackers, websites, etc. Did a quick check and thepiratebay uses 1024 for file sizes.

comment:10 Changed 15 months ago by zzz

see also #2126

comment:11 Changed 14 months ago by zzz

  • Milestone changed from undecided to 0.9.34
  • Owner set to zzz
  • Status changed from open to accepted

comment:12 Changed 14 months ago by zzz

Preliminary changes in 8cbf0e7bf35bfa697e95c9a205cacc456b37362c 0.9.33-1

comment:13 in reply to: ↑ description Changed 14 months ago by Reportage

Replying to jogger:

To make notation clear one could as a quick solution easily switch from kB to KiB and so forth by using correct IEC units. This would produce additional screen clutter and not help the user.

Switching to KiB does indeed produce additional screen clutter and does not help the user. This is most obvious in I2PSnark, where filesize values are now displayed to 2 decimal places in addition to the extra character (xB -> xiB), breaking the UI in the main torrent display table.

Users want to know: Will this torrent fit on my HD? Will this u/l bandwidth incl. burst fit my router configuration?

ISP's invariably offer speeds based on KBps/Mbps. Fortunately the latest changes to I2P retain this system. Memory manufactures also supply ram in MB, not MiB. The memory display in the sidepanel has regressed with the MiB notation. As mentioned by zzz, trackers also indicate filesize in KB/MB, so why should we introduce conflicting notation in I2PSnark?

Benefits: One can easily compare stats and graphs to the left hand panel. Screen clutter is reduced. i2p reported figures relate to the outside world.

Evidentially, based on the changes in 0.9.33-1, there is now more screen clutter, 2 separate notation systems in play, more (unneeded) characters on screen, and less coherence. Arguably most users are more comfortable with the KB/MB notation scheme. The KiB/MiB notation is a major regression in my opinion.

comment:14 in reply to: ↑ 4 Changed 14 months ago by Reportage

Replying to zzz:

Also not sure what you mean by "2.5 digit formatting" in #1912, perhaps you mean like a printf %2.5f format? This isn't C, it's Java, although there are some C-like formatting classes.

I think he's asking for values to be displayed to one decimal place, which, in many places in the console and webapps is a sane request and would considerably reduce screen clutter.

comment:15 Changed 14 months ago by zzz

I checked this in without any elaboration, so here's why I did what i did:

  • I checked it in at the very beginning of a dev cycle for a reason, so there's time to review and fix up.
  • Can't make everybody happy on this. Usage varies around the world. See the numerous comments above, starting with comment 1 from me.
  • There's no way to reconcile "most users are more comforatble with KB" with changing things to be strictly correct, if we're going to use any binary K anywhere.
  • While it's a 20 year old standard, the binary 'KiB' notation wasn't very common a few years back, but it does seem to be getting a lot more common over the recent years.
  • After a lot of research, I determined that the most common usage was decimal K for speeds and binary K for memory/disk sizes, and that's what I decided to do. Bittorrent clients, trackers, and sites clearly use binary K, whether it's displayed as K or Ki. The OP of this ticket asked that we be strictly correct and use K for decimal and Ki for binary, and that's what I did. Yes it is now "two separate notation systems in play". And it is odd that the rate is a different base than the size, so if you are running 10 KBps you don't get exactly 10 KIB in a second. But I'm not sure that matters.
  • While OP listed the case of 'will this fit on my hard disk', and that hard disk manufacturers use decimal, that doesn't seem like a likely use case. Comment 7 claims that operating systems use decimal but I need to research that. Also, to use decimal K for sizes in the bittorrent client would make it inconsistent with other bittorrent sites and clients.
  • Snark used to have its own formatting method and with this change I switched it to our library method with two decimal places. It's an experiment and it is more cluttered. Rereading #1912, what he means by 2.5 formatting, I think, is it's 2 decimal places with an integer part of 1 digit, 1 decimal place with an integer part of 10-19, and no decimal places with 20 or higher. That's an interesting proposal that could be implemented either in the library method or just for snark.

Plenty of time to work this out but it's going to be a compromise. I'll be trying out tweaks in the coming weeks.

comment:16 Changed 13 months ago by zzz

Changed the util method to be 2 decimal places for 1-19, 1 for 20-999, 0 for 1000-1023
This doesn't affect everything, in particular the summary bar doesn't use this method.
It does reduce the clutter, somewhat, in snark and susimail.
In 429fea8f96ff06c6829f71a02fcb81a98aa6f1a5 0.9.33-4.
Still plenty of time for more tweaks.
The comments here are the only ones I've received so far.

Last edited 13 months ago by zzz (previous) (diff)

comment:17 Changed 13 months ago by Reportage

Definitely less visual noise with the latest changes, which is an improvement. However, the KiB/MiB notation still feels wrong. The OP suggested using SI units everywhere, which would keep the KB/MB notation while calculating filesize as a multiplier of 10, not 16. This would be preferable. As for RAM, KB/MB also seems like the correct notation, even if it's using binary notation ie. 1MB = 1024KB.

When implementing changes like this that are likely to attract divergent views, why not cover all bases and implement a simple pref to switch between variants? An option in the UI or via a console pref (routerconsole.notation.suffix={decimal/binary}) would suffice.

comment:18 Changed 13 months ago by zzz

I believe the intent of the OP is to be strictly correct in our notation. That is, use KB for decimal and KiB for binary. He offered two simple alternatives, either to switch to decimal everywhere, or binary everywhere.

My decision was to be strictly correct everywhere, but use decimal for speeds and binary for sizes. I explained my reasoning, in detail, in comment 15.

In comment 17, you propose that we not be strictly correct, and use KB whether we mean binary or decimal? I don't agree and it also doesn't solve OP's issue.

See #2163 for why more options is bad. Also, seems like a copout.

comment:19 Changed 13 months ago by Reportage

Trailing zeroes should be dropped, they don't add any value and take up space. Seeing plenty of those in susimail:

  • 4.00KiB -> 4KiB
  • 1.60MiB -> 1.6MiB
  • 80.0KiB -> 80KiB

Still not convinced that KiB is really that helpful, even if it's technically more accurate. Adding the option to display all measurements in KB/MB doesn't seem like a copout, it's more a question of catering to differing tastes. A simple router.units=KB/KiB/auto or the like would be sufficient, no need to overcomplicate things.

Last edited 13 months ago by Reportage (previous) (diff)

comment:20 Changed 13 months ago by zzz

Re: trailing zeroes, agreed, was thinking the same thing myself.
Changed in 78f2e3713efa67c5c5e44089a1a6d96abdff02a9 to be 0.9.33-8
A good test if you have a lot of emails in susimail is to sort by size, then page through.

comment:21 Changed 13 months ago by zzz

changed snark up/down speeds to decimal in 32b4b4319812db8525efe91c06f593d99d1a0b7f to be 0.9.33-10

comment:22 Changed 11 months ago by zzz

  • Resolution set to fixed
  • Status changed from accepted to closed
Note: See TracTickets for help on using tickets.