public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Tony Foiani <tkil@scrye.com>
To: davids@webmaster.com ("David Schwartz")
Cc: leon.woestenberg@gmail.com ("Leon Woestenberg"),
	linux-kernel@vger.kernel.org
Subject: Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)
Date: Sat, 20 Jan 2007 17:07:14 -0700	[thread overview]
Message-ID: <gzm8d1bv1.fsf@brand.scrye.com> (raw)
In-Reply-To: <MDEHLPKNGKAHNMBLJOLKEEKNBAAC.davids@webmaster.com> (David Schwartz's message of "Sat, 20 Jan 2007 14:54:10 -0800")

>>>>> "David" == David Schwartz <davids@webmaster.com> writes:

David> The way RAM and flash are measured is correct.

In my experience, RAM and flash *drives* are measured differently.  

I understand that individual flash chips come in powers of 2, but by
the time they're packaged as a "flash drive", some of that has been
used up -- yet they're still sold as the full capacity, and the
manufacturers use the confusion between MiB and MB to defend the
practice.

   This "16Mb" drive doesn't really have 16 megabytes of capacity -
   it's really got 15.5. But that's just standard operating procedure
   for storage manufacturers. Non-volatile storage manufacturers,
   including hard drive companies, like to define a megabyte as
   1,000,000 bytes and a gigabyte as 1,000,000,000 bytes. They're
   actually two-to-the-power-of-20 and two-to-the-power-of-30 bytes,
   which is 1,048,576 and 1,073,741,824 bytes respectively. This is
   the main reason why a "20Gb" hard drive won't actually give you
   20Gb of capacity.

   In flash RAM devices, things can get a bit more complex again,
   thanks to the small amount of memory which may be used by the
   device itself for housekeeping. That can vary between device
   families; a CompactFlash card with a given nominal capacity may
   actually have a bit less space than a SmartMedia card with the same
   number on the label. And manufacturers may throw in some more
   memory to push the real capacity up closer to the stated one, which
   is what they've done with the USBDrive. It's still about three per
   cent shy of its claimed capacity, though.

   -- http://www.dansdata.com/flashcomp.htm

(E.g., my "512MB" CF card shows up as "487MB" in the camera -- a
difference of exactly 5%, as would be expected by the MB-vs-MiB scam.
I'd be happier if the camera said "487MiB", but we're looking at OSes
we do have control over, not others.)

And this cheat is getting better (for the seller) with every expansion:

   1 MiB is  5% bigger than 1 MB
   1 GiB is  7% bigger than 1 GB
   1 TiB is 10% bigger than 1 TB

So when you go out to buy your 1TB drive this year, you're really only
buying 0.9TiB or so.

Since all the manufacturers do the same thing, it's possible to
consider it "fair", at least for comparisons -- but when the customer
gets home and formats their drive, I think they'd be happier if the
number was the same as on the carton.

Just last night I formatted some new "500GB" drives, and they
eventually came back with 465GB as the displayed capacity.  Wouldn't
it make more sense to display that as "465GiB"?

David> Talk about a cure worse than the disease! So you're saying that
David> 256MB flash cards could be advertised as having 268.4MB? A
David> 512MB RAM stick is mislabelled and could correctly say 536.8MB? 
David> That's just plain craziness.

No, it sounds like he wants them advertised as 256MB and 512MiB,
respectively -- packaged flash cards tend to use the 1000 multiples,
while DRAM uses the 1024.  One extra letter doesn't sound all that
crazy.

How fast is your Ethernet port?  100Mbps or 95.37Mbps?

Somewhat archaic now, but how big was your common 3.5" floppy disk (PC
"HD" format)?  It actually used a basis of 1,024,000:

   And if two definitions of the megabyte are not enough, a third
   megabyte of 1 024 000 bytes is the megabyte used to format the
   familiar 90 mm (3 1/2 inch), "1.44 MB" diskette.

   -- http://physics.nist.gov/cuu/Units/binary.html

What's likely is that the flash and drive manufacturers will either
mark their products honestly, or they'll increase the capacity of
their product to meet the given label.

(Think about the CRT "diagonal" measurements -- it took a few
lawsuits, but they eventually switched from measuring bezel-to-bezel,
or total tube diagonal, to "viewable".  Sure, everyone in technology
"knew" that you had to chop off an inch or two from the advertised
value to get the viewable; but that's not enough to meet the standard
of truth in advertising.)

David> Adopting IEC 60027-2 just replaces a set of well-understood
David> problems with all new problems.

Which are clearly solved in the standards document, and remove any
ambiguity.  Is one extra character really that painful to you?

t.


  reply	other threads:[~2007-01-21  0:35 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-20  8:08 PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2) Michał Kudła
2007-01-20 10:29 ` David Schwartz
2007-01-20 18:07   ` Leon Woestenberg
2007-01-20 22:54     ` David Schwartz
2007-01-21  0:07       ` Tony Foiani [this message]
2007-01-21 21:12         ` Jan Engelhardt
2007-01-22  6:45           ` Tony Foiani
2007-01-22  8:25           ` Roland Kuhn
2007-01-22 15:43           ` Lennart Sorensen
2007-01-21  7:11       ` H. Peter Anvin
2007-01-21 20:03         ` Geert Uytterhoeven
2007-01-21 20:06           ` H. Peter Anvin
2007-01-21 17:04       ` Leon Woestenberg
2007-01-21 22:12         ` David Schwartz
2007-01-22  8:49           ` Benny Amorsen
2007-01-27 15:06 ` Andries Brouwer
     [not found] <7FsPf-51s-9@gated-at.bofh.it>
     [not found] ` <7FxlV-3sb-1@gated-at.bofh.it>
     [not found]   ` <7FyUF-5XD-21@gated-at.bofh.it>
2007-01-21 10:40     ` Bodo Eggert
2007-01-21 11:10       ` Eduard Bloch
2007-01-21 22:08         ` Stefan Richter
2007-01-22 15:53         ` Lennart Sorensen
2007-01-22 16:58           ` Jan Engelhardt
2007-01-22 18:36             ` Alan
2007-01-22 19:24               ` Tony Foiani
2007-01-22 22:26                 ` Bodo Eggert
2007-01-22 20:44               ` Lennart Sorensen
2007-01-22 21:17                 ` linux-os (Dick Johnson)
2007-01-22 20:43             ` Lennart Sorensen
2007-01-22 21:22               ` Jan Engelhardt
2007-01-21 14:45       ` Benny Amorsen
2007-01-21 15:06       ` Heikki Orsila
2007-01-21 21:27         ` Jan Engelhardt
2007-01-22  1:56           ` Krzysztof Halasa
2007-01-22 10:39             ` Bernd Petrovitsch
2007-01-22 10:48             ` Andreas Schwab
2007-01-23  1:04               ` Krzysztof Halasa
2007-01-23  1:45                 ` Jan Engelhardt
2007-01-23  9:23                 ` Andreas Schwab
2007-01-23 13:14                   ` Krzysztof Halasa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=gzm8d1bv1.fsf@brand.scrye.com \
    --to=tkil@scrye.com \
    --cc=davids@webmaster.com \
    --cc=leon.woestenberg@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox