– What’s the Practical Purpose for Using MiB (Mebibytes) Over MB (Megabytes) or Vice Versa?

518 views

– What’s the Practical Purpose for Using MiB (Mebibytes) Over MB (Megabytes) or Vice Versa?

In: 0

6 Answers

Anonymous 0 Comments

[removed]

Anonymous 0 Comments

One is more technically useful because computers work in binary.

The other is good enough for everyone else because they’re used to a base 10 system.

Anonymous 0 Comments

Because binary refers to things in two states, lots of things in computers come in powers of two. These powers of two are 2, 4, 8, 16, 32, 64, 128, 256, 512 and 1024.

So things like memory will always come in one of those powers of two. Notice that ‘1000’ is not one of them – 1000 is not an even number, in binary. But 1024 is. So memory is going to come in bundles like these, so using your unit be that power of two is sensible. You can use a 1GiB memory module, instead of a 1.07374 (approximately) GB module.

When it comes to hard drives, much of this applies when talking about the actual storage inside the device. But all of them put aside some storage for the use of the drive itself – things like spare cells to replace ones that wear out. So I expect that a 120GB hard drive has inside it 128GiB of storage – but the extra (maths done) 17.439 GB of storage is reserved for the device. Here, the manufacturers use powers of 10, just so they can put a slightly bigger number on the packaging.

Anonymous 0 Comments

It has to do with how the storage is physically manufactured. Hard drives have a magnetic film that can be subdivided into any arbitrary number of bits and bytes. If you decide that each bit is 1 micron long and you want to read the 10,000th bit, then you just move the read head to position 10,000 micron in order to read the bit at that location.

DRAM and NAND are split up into a fixed number of physical bits, arranged in a rectangular grid. In a grid, you can find any bit by knowing what row and column it’s on. So suppose you wanted the 10,000th bit, you could go to row 100 and column 100

So then this leads to, how do you tell the storage to go to a row? Well, you use a few binary bits, so 100 would be 1100100 in binary. If you want at least 100 rows, then you need at least 7 bits reserved in your communication string for the row #. Now, since you have 7 bits already, you can go up to 2^7 rows (128), so you can add 28 rows without having to reserve more bits in your communication string. The more bits you use up in your communication string, the less bits in the string are available for actual data, so you don’t really want to use even a single extra bit unless it’s absolutely necessary. By reducing the number of bits in the communication string for actual data, you’re reducing the speed of that you can send data to and from the CPU, so you want to maximize the amount of benefit that you get in exchange for that tradeoff. So you try really hard not to use the 8th bit for row until you have a grid with 256 rows, and 9th bit for 512 rows, etc.

As a result, the total number of rows and columns are almost always a power of 2, which means that the total number of bits are also a power of 2, and dividing it by 8 also gets you a power of 2. So it’s easier to just use Mebibytes to describe the total amount of storage available.

As a sidenote, NAND no longer really uses mebibytes because it reserves a lot of bits as backup and doesn’t let the CPU go to a specific row/column, so the total amount of available storage is some wonky number even if the physical bits are still in a rectangular grid. It communicates with the CPU in chunks instead, so the CPU tells it “here’s a massive bunch of data strings, go store it wherever you think works best for you”.

To make it even more confusing, JEDEC (the standards committee for DRAM) uses megabytes when they really mean mebibytes – so when you buy 16 gigabytes of RAM, you’re actually buying 16 gibibytes.

Microsoft typically follows the JEDEC standard – so when Microsoft says your hard drive is 900 gigabytes, you actually have a 900 gibibyte hard drive.

However, hard drive manufacturers follow the SI definition, so when they sell you a 1000 gigabyte hard drive, it’s actually 1000 gigabytes and not 1000 gibibytes. But since it’s 1000 gigabytes, Microsoft will show it as being ~931 gibibytes, which they then tell you as 931 gigabytes. You’d think that the consumer outrage over this confusing practice would force one of them to change to the other’s standards, but apparently not.

Anonymous 0 Comments

It’s easier to understand for a smaller number like the kB and kiB. A kB is, strictly speaking, 1000 bytes whereas a kiB is 1024 bytes. The reason we might use the second is that, if we had a computer with 10 address bits (10 wires coming out telling the memory which byte it wanted) then it could choose amongst 1024 bytes. That’s because each address wire has either a high or low voltage—two possibilities—and two possibilities to the power of ten wires is 2^(10)=1024 possibilities.

* 1 MB is 1000^2 bytes or 1000000 bytes.
* 1 MiB is 1024^2 bytes or 1048576 bytes.

Originally computer scientists just said MB when they meant MiB, assuming you could tell by context what they meant, but later MiB was created to make the meaning unambiguous.

MiB used to be used for things like hard disk drives too but now it’s more restricted to CPUs, memory (RAM) and some devices. Hard disks have mostly changed to being sized by GB and TB rather than GiB and TiB, even though the smallest unit of disk drive storage, the block, is still 0.5kiB or 4kiB.

A reason for preferring MB over MiB is mostly that it’s a real round number in our familiar base ten. Communications tends to work in multiples of ten, like Fast Ethernet is exactly 100Mbps (bit per second). The kiB, MiB, GiB and TiB units are messy because they get farther from their base ten equivalents with each step up:

* 1 kiB = 1.024 kB
* 1 MiB ≈ 1.049 MB
* 1 GiB ≈ 1.074 GB
* 1 TiB ≈ 1.100 TB

Anonymous 0 Comments

>What’s the Practical Purpose for Using MiB (Mebibytes) Over MB (Megabytes) or Vice Versa?

While other answers have already gone into beautiful detail concerning the nature of both units, the most *practical* reason for actually using one over the other, specifically MiB over MB, is simple: At this point in time it is **unambiguous**.

With MB you can never be sure whether or not the user or application refers to 1000×1000 Byte or 1024×1024 Byte because the unit is used inconsistently.

With MiB you know exactly what to expect.