How many bytes are there in 8 GiB RAM?

[Portreve]

Do I even dare ask what the heck a mebibyte and a gibibyte are? Is that anything like kiloquads from ST:TNG? Or sectons, microns, and milli-centons from BSG?

[xenopeek]

They came up with mebi-/gibi- and so on prefixes to make explicit a unit is a power of 2. The counterpart mega-/giga- prefixes are used for units that are power of 10, though they can also be used for units that are power of 2. That caused confusion hence the different prefixes.

In short a megabyte (MB) is 1,000² bytes and a mebibyte (MiB) is 1,024² bytes. A gigabyte (GB) is 1,000³ bytes and a gibibyte (GiB) is 1,024³ bytes.

[Coggy]

This old chestnut. Here is the truth: https://physics.nist.gov/cuu/Units/binary.html
Kibi and Mebi prefixes were defined near the end of the last century. Kilo and Mega prefixes were defined much earlier than that.
Microsoft still continue to use the wrong prefix in all their software as far as I know.

RAM chips always store a power of 2 bits, and this is by their electrical design - they are addressed by a number of address bits that carry a voltage that's either logical 1 or 0. As an example, the intel 1103 has 10 address bits, 1024 possible combinations. All RAM chips are constrained to storing powers of 2 bits because this is how the bits are addressed. antikythera has not understood this fact, probably because the manufacturers use the wrong prefix on their data sheet.

So folk got lazy and used the term "kilobyte, megabyte" etc when the precise storage was always a bit more due to the power of 2 constraint. Then other folk got to thinking that "well when you are talking computers, 'kilobyte' means exactly 1024 bytes". Wrong. If both people know they are referring to capacity of a RAM chip, then they can infer what they really mean. But hard disks, USB sticks etc. aren't constrained to exact powers of two so that assumption is no longer valid. And returning to what started this discussion, even when the RAM chips on a motherboard are constrained to a power-of-2 capacity by their electrical design, a motherboard may choose to reserve some of that for its own use and not let the OS see it all.

[rene]

Coggy already said it well, but I was meanwhile writing the below, so, ...

Do I even dare ask what the heck a mebibyte and a gibibyte are?

https://en.wikipedia.org/wiki/Binary_prefix. And that's to say then that xenopeek's above "they" is not some poorly defined random "they"; is the entire international scientific and technical community.

So as to concisely wrap up this thread -- hah! -- in a manner which may even be linkable the next few million times the subject comes up...

Kilo, mega, etc., prefixes mean and have always meant 1000, 1000², etc. In the scientific community world-wide, and also very much in everyday use in countries using the metric system for measurements; a kilometer is very much known to be a 1000 meters, say. Memory-technology is naturally base 2 due to an n-bit address bus being able to address 2ⁿ datums, and back when memory sizes were small, 2¹⁰ being 1024 -- "nearly 1000" -- lead to 1024 bytes also being referred to as a kilobyte, even if this was always just convenient shorthand. Due to its fairly direct relation to RAM/ROM-technology, general storage also historically adopted the usage but has now dropped it for more than 20 years already: certainly when you hit G/Gi the difference starts to be too noticeable to ignore. And note that memory/storage is as far as it ever went anyway: a 10MHz CPU always ran at 10x1000² Hz and 10Mb networking always did 10x1000² bits per second (max) for example.

The operating systems that we use today grew up in the world of old and have as such historically also in the memory and general storage contexts used kilobyte, megabyte and their abbreviations KB, MB, etc., in the 1024, 1024², etc., sense. On Linux there's been a somewhat successful push to have tools switch to displaying the in fact correct Ki, Mi, etc., prefixes ever since they were invented but it's not done consistently/correctly everywhere (yet) and especially not in actual memory contexts, both as a matter of backwards compatibility -- tools parsing /proc/meminfo, say -- and "because everyone knows anyway so why upset the apple cart".

A DIMM sold as say a 4G one holds 4GiB and not 4GB but hardware-sides that's also just about the last remaining user of the 1024-based prefixes which doesn't generally explicitly note them to be the 1024-based prefixes. On the software-side Linux isn't as said always correct/consistent, and as far as I'm aware Windows has never even tried to be. As antikythera showed above, nor have BIOS vendors.

So it's still a bit of mess but you should indeed certainly at this point know what a mebibyte and a gibibyte are -- even though I'm personally completely fine with someone writing, say, "a 4G DIMM" and pronouncing it however one wishes. Because everyone knows anyway, so why upset...

[rambo919]

I have to wonder why this same argument keeps coming back....

Think the first time it popped up for me was CD's.... which was a pain when writing.

[rene]

I've been personally entertaining the notion that it's probably a lot more expected to not notice this issue "as much" when you do not as a matter of course use e.g. kilometers, kilograms, megawatts (well, that one a bit less generally...) but, say, maxifurlongs and lotsafortnights.

[Portreve]

This post here...

⬇︎⬇︎⬇︎

I've been personally entertaining the notion that it's probably a lot more expected to not notice this issue "as much" when you do not as a matter of course use e.g. kilometers, kilograms, megawatts (well, that one a bit less generally...) but, say, maxifurlongs and lotsafortnights.

...I think really brings things into a sharper focus for me.

For Americans — certainly for the "average" American on the street — the Metric System doesn't really mean very much. I doubt that "a two-liter" (bottle of soda) is anything other than just a name for a particular container (as opposed to a measurement), to cite just one example of the mindset. I must personally confess to a bit of... magic thinking? ... soft thinking? ... on this basis. I've kind of ignored or mentally swept under the rug the fact that "kilo" is 1000 in Metric contexts and 1024 in technology contexts.

[rambo919]

Yeah the non-metric way of counting tends resemble "who's line is it anyway".

[rickNS]

For the most part I could care less about the small difference, EXCEPT it would be nice if installers (like Mint), and partitioning tools (like Gparted) would use the same system.
(If I'm not wrong?) The Mint installer, and Disks program use GB as shown in this ss,

ksnip220706-1129.jpg (3.36 KiB) Viewed 341 times

And Gparted uses GiB

This gave me a bit of pain once trying to create an exact duplicate sized partition to clone to. For this reason I now always pre-partition before installation.

FWIW the terminal output does not match exactly the Gparted numbers

Code: Select all

rick@t420 ~ $ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            3.9G     0  3.9G   0% /dev
tmpfs           787M  1.6M  785M   1% /run
/dev/sda1        19G  8.2G  9.2G  48% /

[Portreve]

Because of the U.S. being a superpower — and, more to the point, the world-dominating superpower — there's kind of this "How America does things and then how the rest of the world does things" reality (I wanted to use the term "mindset" but it's more than that) in which whether you use or find purposeful the Metric System almost totally depends upon whether you're from the U.S. or you're not.

I used to work as an inventory auditor for Circle K. When we would go over discrepancies for wine (yes, gas stations sell bottles of wine) there's different sizes, and they are ONLY dealt with in Metric. Nearly nobody understood that 750 ml bottles were *also* three-quarters of a liter. Just looking at the two options for "regular bottles", there are two sizes: the small one which is 750 ml, and the large one which is 1.5 l. Most of the folk I dealt with, even including other auditors, had little to no concept of what was what. Now, one would think it should be a matter of common sense, and I won't sit here and argue that there aren't plenty of people out there who are intellectually lazy and expect everything delivered to them on a silver platter (not unlike the old-school "AOLuser"), but when people only ever get instruction-in-passing about the Metric System in middle school in an environment (the U.S.) where it's like "Yeah, I have to teach you this because it's a requirement, but I don't actually care if you get it because you'll never really use it" then it's somewhat more understandable that people here have no clue.

In my experience, in the U.S. when you hear Metric measurements being used (and I'm thinking strictly outside of any kind of published scientific context) it's normally only in one of three scenarios:

• medical context
• certain beverages (2 liter bottles, for example)
• illegal drugs

My German friends have all to one extent or another commented they felt understanding multiple languages had its own neurological and psychological benefit, and as I understand it this is one of many different things humans can do to promote better brain functioning (other things include solving riddles and puzzles, etc.) My American friends, nearly without exception, see absolutely no point in learning any language beyond English unless you absolutely need it to function in a certain environment (for example, working in retail and dealing with Spanish-speaking co-workers and customers). And from what I've seen of American educational curriculum in recent times — let's call it the last 15 or so years — this attitude would seem to be supported by what is being done within the education industry.

So why have I seemingly gone off the deep end in writing a long-winded tangent in a thread supposedly all about understanding data measurement? Well...

I believe it is useful to understand different systems and also the rationale behind why they exist. I also wanted to draw some parallels between the GB vs. GiB discussion and other real-world situations. Actually, another parallel I can draw is how those of us who grew up in the 70s/80s era of computers and technology enthusiasm vs. those who did so from the mid-to-late 90s and on, where "we" understand there's lots of ways one can approach things and "they" only know (mostly) the Microsoft way, and how it boggles their mind that there could be other realities beyond simply Windows. And beyond that, there's also been expressed elsewhere on this board the concern about how the super-abundant choice which exists within the Linux world (so many different distros / desktop environments / etc.) is this huge negative and a lead weight with respect to broader desktop adoption of Linux.

Anyhow, I view the only possible viable way forward on this discussion is education outreach. Or, to phrase it another way, you can lead a horse to water, but you can't make them drink.

[dave0808]

I always thought it was a ruse by the hardware manufacturers. People like me would buy things thinking the sizes were power of 2, but we the customers would be missing out because they are ^10. As we move[d] from MB to GB to TB, we're missing out on more and more bits!

Nice history lesson in this topic.

[rene]

[ ... ] you can lead a horse to water, but you can't make them drink.

Always wondered a bit about that saying. I mean, if you tie the horse down tight enough and ram a funnel down its throat...

[Portreve]

[ ... ] you can lead a horse to water, but you can't make them drink.

Always wondered a bit about that saying. I mean, if you tie the horse down tight enough and ram a funnel down its throat...

Wouldn't that be Funnel Cruelty?

[Coggy]

FWIW the terminal output does not match exactly the Gparted numbers

Code: Select all

rick@t420 ~ $ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            3.9G     0  3.9G   0% /dev
tmpfs           787M  1.6M  785M   1% /run
/dev/sda1        19G  8.2G  9.2G  48% /

It's worse than that. Lookee here:

Code: Select all

steve@StevesPC:~$ df -h | grep /sd
/dev/sda3        31G   14G   16G  47% /
/dev/sdb6       878G  323G  511G  39% /home
/dev/sda1       477M  5.3M  471M   2% /boot/efi
/dev/sda4        33G   18G   14G  56% /run/timeshift/backup
steve@StevesPC:~$ df --si | grep /sd
/dev/sda3        34G   15G   17G  47% /
/dev/sdb6       943G  347G  548G  39% /home
/dev/sda1       500M  5.5M  494M   2% /boot/efi
/dev/sda4        35G   19G   15G  56% /run/timeshift/backup

[rene]

What you are showing there is (as you know) the 1000/1024 difference -- but that's not in fact the case for the gparted/df difference which rickNS noted; gparted and df -h both use the 1024-based units.

I must say his 18,63 GiB of gparted vs 19 GiB of df isn't fully clear to me either: gparted notes the size of the partition and df the size of the file-system that lives on said partition; latter should as such after a bit of file-system metadata overhead only be smaller and not larger. That same effect is however what explains the difference in the "used" statistic: according to df 18,2 used by actual file-content, according to gparted 18,63 by file-content and metadata (and some additional slackspace since while ext4 uses a 4KiB blocksize, df reports using a 1KiB one). The difference in the "available" number is for the largest part explained by df not showing the 5% root-reserved blocks as being available to the user.

Sure you could make it match to the last byte if you dig deep enough -- but I wouldn't. Details, details, ...