Make units for transfer rates configurable

[jedie]

Change the Down-/Upload rate from "bps" to "KB/s" or "MB/s" because it's more common, isn't it?

EDIT: Also "Outgoing Rate Limit (KBps)" and "Max File Change Rate (KBps)"

[calmh]

I don't think it is. In my experience transfer rates are usually given in bits per second, see for example broadband services (usually marketed as 24 Mbps and similar, seldom as 3 MB/s). I could see a case for allowing whatever rates the user is more comfortable with; low on my prio list, pull requests accepted.

[jedie]

What's about a tooltip with the other unit?

[calmh]

Yeah, or click the unit to cycle between b/s, B/s, B/min (seen in at least some old crappy backup software I remember).

[fazo96]

It's just a matter of preference, I think there should be an option to cycle between B/s and b/s and also I think the scale should adapt in function of the speed. Like 3MBps but if it drops below it's shown as KBps and so on.

[jedie]

What i mean with the tooltip is this:

Or it's possible to switch between kbps and KB/s via CSS ;)

[calmh]

@fazo96 It does adapt as is.

@jedie Yep, I understood. However without seeing this background discussion I think it would be weird to hover on a metric and get a tooltip with another value, in another unit. Especially if the user isn't all that clear on the different units to begin with... :)

[jedie]

OK, then a selectbox in settings can be a solution?

[calmh]

Sure.

[jpjp]

Please can we use unambigous standardised units (KiB or MiB per second)?

[calmh]

We are, although that may not be obvious unless you already know about it. ;) The following units are currently in use in the syncthing GUI;

• KiB and MiB for amounts of data; seen in the repo and RAM usage stats. Base two prefixes on bytes as is common for file sizes (except on Mac, curiously, where things are base ten since a while back).
• kbps and Mbps for transfer rates; seen in the node transfer stats. Base ten prefixes on bits, as I've grown accustomed to in all networking. I guess we could argue about whether to use a "p" (tradition, see also "mph") or a slash (modern, SI, see also "km/h")...

Personally I think this is As It Should Be(tm), but at some point I guess we'll gain KiB/MiB per second as an option for transfer rates.

Edit: Oh, there is actually one crappy inconsistency. The config values for rate limits are labeled as being in "KBps" which is a non-unit. I meant "KiB/s" here, that should be cleaned up. And you could argue that I just said I like rates in bits per second so what gives, and I don't know...

[jpjp]

Ah yeah. I just saw KB and freaked out.

[calmh]

@jpjp As you should!

[v-ko]

Firstly - sorry for the duplicate bug report, no idea why I thought no one else raised the issue. So if I may sum up the comments above, calmh , you're ok with adding an option for the measurement unit (choosing between Mbps and MiB/s) in the settings?

[endolith]

Ah yeah. I just saw KB and freaked out.

There's nothing wrong with kB and MB, as long as they mean 1,000 and 1,000,000. I think that makes more sense for file sizes/amounts of data, and KiB/MiB should only ever be used for RAM sizes (which naturally come in powers of 2, unlike file sizes), but that's just my opinion.

Networking is always measured in 1000s like "kbit/s" though.

[jpjp]

Wikipedia disagrees... https://en.wikipedia.org/wiki/Data_rate_units

[v-ko]

It's an opinionated matter, even the wikipedia article was written by someone with just an opinion. I'm pretty sure there wasn't a statistical survey on the matter. Plus "modern residential high-speed Internet connections are most commonly expressed in multiples of bits per second, such as megabits per second (Mbit/s)" because it sounds like more (like, 8 times more) to the average user who has little idea on the matter, not because it's more practical.
I'm a big fan of SI, but when your hard disk space and file sizes are mostly measured in bytes, kilobytes, etc. , it's just not practical to have your network speed in bits. Do tell me for which purposes do you look at your transfer rate, and how is it easier for you to read it in bits (of course if you're used to it, you'll get a feeling of how fast you're transferring, but that really doesn't fulfill any practical task) ?
I, personally, mostly look at the transfer rate in order to get an idea how long it will take for some particular amount of data to get transferred. The latter as I mentioned is measured in bytes, so with bytes/sec my equasion looks like this : time=data/transfer rate . With bits it's time=data/(8*transfer rate) , so my brain at this point says "you're on your own, man" and that's that.

[uok]

Thanks for reopening!
I think the two options should be

• GB/s, MB/s, KB/s, B/s (not GiB/s, MiB/s, KiB/s) - common in windows, download software, ...
• bits/kbits/mbits - networking and *nix 😄

[generalmanager]

@petko10 summarized it perfectly. While network engineers have legitimate reasons to use bits per second, ISPs use it to confuse consumers.

With byte-based units it's trivial to guesstimate the time left for a transfer. They also give the average user a trivial way to compare transfer speeds, because every download manager and file sharing tool uses kB/s, MB/s and GB/s.

[endolith]

ISPs use bit/s because ISPs are network engineers. Measuring in bit/s is practically useful because it shows how much of your bandwidth you are using without having to do a conversion.

[generalmanager]

@endolith The network engineers at ISPs use bits/s, for legitimate reasons. The marketing departments...not so much.
Sure it's nice to know how much of your theoretical bandwidth limit you are using. But having a unit that directly relates to the file size and is comparable to the data from basically all every day usage scenarios (except speed tests) should outweigh this advantage.

The only reason speed tests use bits/s is that ISPs advertise their services with units based on bits/s, not because it is anything close to meaningful for the average user.

[calmh]

I'm going to close this for further discussion. :) There are legitimate reasons to prefer each of the possible variants, and probably all of them are mentioned somewhere above. We can bikeshed it to infinity, but the issue here refers to enabling the user to make the choice. I'm fine with that. Write the code. :)

[lkwg82]

I suggest to close this until we see a PR.

[AudriusButkevicius]

Well it's a valid feature request, so I think it should live.

[canton7]

I don't think there's any need to go around closing "Unplanned" issues. They're markers saying "hey, we considered this. If you're looking for something to contribute, give it some thought" . People will just open new issues if we close the old ones.

[calmh]

Yes. Closing means I don't want a PR, or at least am unlikely to accept one without persuasion. Close if something doesn't fit with what we want to do, or is unfeasible for some reason. This is neither.

[lkwg82]

ok, got it ;) Just went around and thought of cleaning stale issues.

[AudriusButkevicius]

Github not doing its job.

[calmh]

Yes that's odd. I see nothing wrong with my tagging, but it didn't pick it up at all. For posterity:

#4074