Skip to main content

SI Prefixes and Prefixes for Binary Multiples

A flaming article on Macenstein about the use of GB in describing hard disk sizes and the resultant frenzy at Digg shows the lack of understanding of standards amongst most people. This post is to clear the air.

The computer world (especially memory manufacturers and software developers) have "always" used the prefixes kilo to represent 210, mega to represent 220, and so on. However hard disk drive (HDD) manufacturers use kilo to represent 103, mega to represent 106, and so on. The article claims that this misleading advertising by the HDD manufactures since one purchases a 1 GB HDD expecting (210)3 bytes (1 073 741 824 bytes) but only gets 109 bytes (1 000 000 000 bytes). Most operating systems uses powers-of-2 for the prefixes and will report that HDD as being 0.931322575 GB (from 1 000 000 000 / 1024 / 1024 / 1024). This is being viewed as HDD manufacturers over-reporting HDD sizes by more than 7%.

So what is going on and who is "right"?

The International System of Units (SI) has defined standard names for prefixes for over a century. The prefix kilo is defined to be 103, mega is 106, etc. This is the standard.

The confusion is due to the fact that the computer world - memory makers and operating systems - decided to reuse the same prefix names for 210, 220, etc., in violation of the SI standards. In order to alleviate this confusion, since November 2000, the International Electrotechnical Commission (IEC) has defined standard prefixes for binary multiples. The prefix kibi is 210, mebi is 220, and so on.

So the HDD manufacturers are the ones who are adhering to the SI standards. That 1 GB drive is 1 000 000 000 B and the operating system should be reporting it as 0.931322575 GiB a different unit from GB. One can only hope that operating systems and memory manufacturers start using the IEC standard for binary multiples.

It's interesting to note that the Google Calculator propagates the nonstandard prefixes. For example, it reports 1 gigabyte as 1 073 741 824 bytes.

Technorati Tags: , , ,

Comments

Rainman said…
Wow......that post seems to have evoked quite a reaction from its readers. But I agree, standardization is required.

Popular posts from this blog

Migrating from Palm Calendar to Google Calendar and iPhone

Here are the free steps to migrate from Palm's date book (or Pimlico's DateBk6 ) calendar to Google calendar for full iPhone sync. First, sync Palm with Palm Desktop . Next, open Palm Desktop, select the Calendar view, navigate to File | Export, select Export Type as Date Book Archive, Range as All and provide a file name. This will export the calendar data as Date Book Archive (.dba). There's a paid tool called DBA2CSV that converts .dba files to .csv files. However this can be done for free using Yahoo Calendar. Login into Yahoo Calendar and via Settings/Import, import the .dba file. It helps to have an empty Yahoo Calendar. Via Settings/Export, export the calendar as .csv file. Login to Google Calendar (also works with Google Apps For Your Domain GAFYD Calendar) and import the .csv file into any of the calendars. It is a good idea to create a test calendar and test the import before importing into your real calendar. That way if anything goes wrong, you can delet...

AD-5526 Digital Multimeter

The AD-5526 is an ancient multimeter from A&D but for $10 one can’t complain. Has all the basic features one would expect from a multimeter and at 5.2 cm X 9.5 cm X 2.6 cm, it’s quite compact. Uses a LRV08 12V alkaline battery – not a common battery in the USA.

Lead Tide SIM Reader

I recently came across a cheap little device for reading SIM cards . It was available from Meritline for less than USD 5 with free shipping. Curious to see what it was like, I ordered one. The device came in a small package along with a mini CD containing drivers. The packaging advertised the device as the LEAD TIDE Sim reader . Like most things these days, it's made in China. The device has a USB 1.1 interface. There was no product code or number anywhere on the packaging. Installing the drivers for the device turned out to be harder than I expected. The mini CD's autorun installed some stuff but Microsoft Windows XP couldn't install any suitable driver for the device. The mini-CD had several top level directories with what appeared to be product codes but I couldn't match any to the device itself since it had no product code. Google searches revealed that I wasn't alone in my endeavors to get the device working . Further digging revealed pointers to some thir...