Article snapshot taken from Wikipedia with creative commons attribution-sharealike license.
Give it a read and then ask your questions in the chat.
We can research this topic together.
Enlightened by Cho v. Seagate Technology (US) Holdings, Inc.
I see:
"Seagate has denied and continues to deny each and all of plaintiff's claims, and denies that anyone has been harmed or deserves compensation. The Court has not made a decision on the merits. ..." -- http://www.harddrive-settlement.com/notice-email.htm
"One gigabyte, or GB, equals one billion bytes when referring to hard drive capacity. Accessible capacity may vary depending on operating environment and formatting. Quantitative usage examples for various applications are for illustrative purposes. Actual quantities will vary based on various factors, including file size, file format, features and application software." -- http://www.seagate.com/content/pdf/datasheet/disc/ds_portable.pdf
Q1. Has Seagate here now dreamed up brief clear neutral-point-of-view that we could/ should copy/ paraphrase into Gigabyte, Megabyte, etc.?
You might want to add that all these lawsuits took place in the USA. This confirms two things: First, the US law system is very abuse-friendly and second, the universal well-defined meanings of kilo/mega/giga are widely-unknown due to refusal of the USA to use SI units. Quite obviously, the wrong companies were sued. Of course, Microsoft and Apple (albeit to a much lesser extent) are so powerful that nobody who's right in his mind would dare to sue them. --NotSarenne15:09, 3 November 2007 (UTC)
Giga vs. Mega
Gigabyte and Megabyte describe this 1024 = 1000+-2.4% dispute of people gibbering of maybe bytes differently. That difference is confusing and pointless?
At Megabyte, we say 'the term "megabyte" is ambiguous'. At gigabyte, we say "the usage of the word "gigabyte" is ambiguous, depending on the context', and then our two articles go on to diverge farther from there. Admittedly, the audience who gives adequate time & attention will eventually see that megabyte links to gigabyte which links here, but should we be requiring so much time & attention for the reader to walkaway with a correct understanding?
People are free to make fun of things but pronouncing mebibyte as "maybe bite" is just as childish as saying "I pee a dress". It mebi funny but it's completely irrelevant for a factual discussion. I remember well that people used to make fun of "giga" too before it became common. If your point is that the current articles on the issue are sub-optimal because they are too overloaded with too many criticism, discussion, repetitive information, inconsistent use of prefixes and that the same is unnecessarily duplicated in related articles, I'd agree. --NotSarenne17:24, 3 November 2007 (UTC)
220 KiB and counting
"This page is 220 kilobytes long. It may be helpful to move older discussion into an archive subpage. See Help:Archiving a talk page for guidance."
What kind of kilobytes are those? (Answering the question is not the point. It's unfortunate that we raise the question every time we publish such a message.)
It was, indeed, 220 KiB (and not 220 kilobytes) when your wrote that as one can verify by looking at the history which shows the size in bytes without use of prefixes. That's a good catch. It would be neat to either fix the message to use "KiB" or otherwise, to be "neutral" on this issue, use of prefixes should be avoided. --NotSarenne15:23, 3 November 2007 (UTC)
It is actually kilobytes in the binary sense (225,644 bytes = 220.36 kilobytes = 220.36 KB), someone a long time ago changed the template to display KiB when the other wikipedia templates use kilobytes and KB. Fnagaton16:16, 3 November 2007 (UTC)
Well, that's what I wrote, isn't it? That's why I also say, get rid of the unnecessary use of prefixes in this case. The article history doesn't use prefixes either and I believe, this would be appreciated regardless of how you'd like to define "kilobyte". It certainly does not help, if Misplaced Pages is inconsistent with itself. Actually, I dare to question the use of "byte" in this context. Text should be measured in terms of characters which is not the same in case of UTF-8. --NotSarenne17:29, 3 November 2007 (UTC)
Not it's not because the other templates use the term "kilobytes" or "KB" in the binary sense. Therefore the correct option is to not use KiB but to use KB instead and the edit history for the template also show that is the case. Fnagaton18:35, 3 November 2007 (UTC)
The mythical nona- and dogga- and toya-
User:81.63.111.215 added the phrase "as well as nobi- and dogbi-", presumably based on the assumption that there are legitimate decimal-based prefixes nona- for 10 and dogga- for 10. They are notSI prefixes, or at least NIST knoweth not of them. I'm perfectly prepared to be convinced of their existence, but I want to see some evidence that some recognized standards organization is promulgating them. I have so far found nothing but loose assertions in Google searches. Dpbsmith 00:27, 21 Mar 2004 (UTC)
I don't know what it's from, but there's a toya- claimed here. I don't see any evidence/citation for it, certainly ISO doesn't note it, so I'm deleting it. Dwheeler00:37, 7 February 2007 (UTC)
For 74 minute CD-Rs, the capacity is 74*60*44100*2*2*2048/2352 = 681984000 bytes, or 650.390625 binary MiB (exactly, no roundoff error).
For 80 minute CD-Rs, the capacity is 80*60*44100*2*2*2048/2352 = 737280000 bytes, or 703.125 binary MiB (again, this figure is exact, not rounded off).
To clarify this: CD capacity is measured in minutes, based on the original "Red Book" standard for audio CD's. Audio CD's play at 75 blocks per second (most people say "sectors" but this is arguably incorrect because CD's use a spiral track). For audio, the usable amount of data per block is 2352 bytes (usually referred to as "raw bytes"); for CD-ROM ("Yellow Book") the usable amount of data is reduced to 2048 "cooked" bytes per block because of added error detection and error correction bytes.
So, in slightly different formulas (with the same results):
The longest CD that can possibly be recorded (but violates some Red-Book specifications) is 99 minutes, 59 seconds and 74 blocks, because of the BCD-based encoding of timing information:
For DVD+/-R media, the exact capacity is 4697620480 bytes, or just shy of 4.7 decimal GB. The capacity of a DVD-R is certainly nowhere near 4.7 binary GB.
Data rates
"Lending confusion to this mess though, in some areas only decimal values are used such as when the term, "56K modem" works at a maximum speed of 56,000 bits per second, not 57,344."
"Just to avoid confusion, 33.6 Kbps = 33600 bps, 28.8 Kbps = 28800 bps (where bps means bits per second), and so on."
"Traditionally, Ethernet networks operate at 10 Mega-Bits per Second (10,000,000 Bits per second)"
1.4.48 bit rate (BR): The total number of bits per second transferred to or from the Media Access Control (MAC). For example, 100BASE-T has a bit rate of one hundred million bits per second (10 b/s). IEEE 802.3 standardCavebear4223:36, 31 May 2005 (UTC)
Is this true? Why would you have a power of 2 with a decimal unit? Does 128 kb/s really mean 128000 b/s? 128 is 2^7, which implies we're using binary. Can you provide a link to convince me otherwise? Tango19:31, 24 December 2005 (UTC)
I don't know why the strange combination was chosen, but try it for yourself with your favorite constant bit-rate MP3:
128 is a power of two, but the other available rates (32, 40, 48, 56, 64, 80, 96, 112, 128, 160, 192, 224, 256 and 320) are not. I'm sure it has to do with frame sizes or something. — Omegatron03:58, 19 June 2006 (UTC)
Well, ignoring the fact that some of those rates are powers of 2, what you'll actually find is that all of those rates are multiples of 8, as in 8 bits per byte/octet.
So the BYTE rates would be 4 KB/s, 5 KB/s, 6 KB/s, 7 KB/s, 8 KB/s, 12 KB/s, 14 KB/s, 20 KB/s, 24 KB/s, 28 KB/s, 32 KB/s, and 40 KB/s. You can see a more-rational progression in those MP3 encoding rates, right?
I think we've simply forgotten (over many years) that the "bit" is the base measurement of storage on a computer, not the "byte." A "byte" is a collection of bits, and a bit is not a division of bytes. Encoding rates for MP3s are expressed properly (128kb is 128,000 bits). This entire discussion is idiocy, to be perfectly frank, and the usage of "-bi" prefixes is only 'widespread' in that it is laughed out of facilities world-wide.
The improper use of "byte" as a base unit is akin to using the kilometer as a base unit of distance, then referring to "kilokilometers," "megakilometers," and "gigakilometers." The fact that "bits" are most often grouped into octets (or powers-of-two) is irrelevant, since this is not always so (witness 7-bit character encoding). Confusing the issue even more is the fact that hexadecimal is just behind binary in computing base-usage. (This began as a response to the MP3 rate listing, but if someone feels that it would be better relocated to another part of the discussion page, be my guest. I'm not even sure myself, at this point.) 68.166.26.22009:42, 16 February 2007 (UTC)
Hard drives
"Drive manufacturers, including Hitachi Global Storage Technologies, market their drive capacities in terms of decimal capacity. In decimal 1 kilobyte (KB) is equal to 1,000 bytes, 1 megabyte (MB) is equal to 1,000,000 bytes, and 1 gigabyte (GB) is equal to 1,000,000,000 bytes. Operating systems and some software programs (fdisk, partitioning utilities, system BIOS, etc…) all view the drive capacity in terms of a binary capacity. In binary, 1KB is equal to 1,024 bytes, 1MB is equal to 1,048,576 bytes, and 1GB is equal to 1,073,741,824 bytes." Why does my hard drive report a lower capacity than what is on the drive’s label? (Hitachi)
"Note that the Maximum Capacity shows only 3099 MB instead of 3240 MB. This is because some system BIOSs recognize a Megabyte as 1,048,576 bytes (binary). Drive manufacturers recognize a Megabyte as 1,000,000 bytes (decimal)." Hitachi
"This has to do with the way nearly every harddrive manufacturer in existance calculates hard drive size. They all define 1 gigabyte = 1,000,000,000 bytes instead of the 1 gigabyte = 1,073,741,824 bytes which it *really* is ... This is standard industry practice"
"Hard drive size is given in Gigabytes (GB). A Gigabyte is one billion bytes or one billion characters."
"Hard drive manufacturers define 1 gigabyte as exactly 1,000,000,000 bytes. By their definition, a 45BG hard drive is exactly 45,000,000,000 bytes. The true definition of 1 gigabyte is actually 1,073,741,824 bytes"
Wow, what an eccentric usage of the words real and actually. Anyway, it's not that simple. According to #Hard disk sizes above, Hitachi and Maxtor seem to use the hybrid 1 GB = 1000*1000*1024 B, and Quantum (out of business now) used 1 GB = 1024*1024*1024 B.
Standard: IEC 60027‐2, Second edition, 2000‐11, Letter symbols to be used in electrical technology — Part 2: Telecommunications and electronics
"These prefixes for binary multiples, which were developed by IEC Technical Committee (TC) 25, Quantities and units, and their letter symbols, with the strong support of the International Committee for Weights and Measures (CIPM) and the Institute of Electrical and Electronics Engineers (IEEE), were adopted by the IEC as Amendment 2 to IEC International Standard IEC 60027-2: Letter symbols to be used in electrical technology — Part 2: Telecommunications and electronics. The full content of Amendment 2, which has a publication date of 1999–01, is reflected in the tables below and the suggestion regarding pronunciation."
Standard: IEEE 1541–2002, IEEE Standard for Prefixes for Binary Multiples
"1541-2002 (SCC14) IEEE Trial-Use Standard for Prefixes for Binary Multiples Recommendation: Elevate status of standard from trial-use to full-use. Editorial staff will be notified to implement the necessary changes. The standard will be due for a maintenance action in 2007." IEEE-SA STANDARDS BOARD STANDARDS REVIEW COMMITTEE (RevCom) MEETING AGENDA 19 March 2005
"1541-2002 IEEE Standard for Prefixes for Binary Multiples (Upgraded to full use from trial use)"
Information for authors — "Information for IEEE Transactions, Journals, and Letters Authors"
TABLE OF UNITS AND QUANTITY SYMBOLS
"mega-: SI prefix for 10. The prefix mega shall not be used to mean 2 (that is, 1 048 576)."
"kilo-: SI prefix for 10. The prefix kilo shall not be used to mean 2 (that is, 1024)."
"Faced with this reality, the IEEE Standards Board decided that IEEE standards will use the conventional, internationally adopted, definitions of the SI prefixes. Mega will mean 1 000 000, except that the base-two definition may be used (if such usage is explicitly pointed out on a case-by-case basis) until such time that prefixes for binary multiples are adopted by an appropriate standards body." (the IEC standard has been published since this note was released and later published by IEEE itself)
"The IEC has adopted prefixes for binary multiples in International Standard IEC 60027-2, Second edition, 2000–11, Letter symbols to be used in electrical technology — Part 2: Telecommunications and electronics. ... Although these prefixes are not part of the SI, they should be used in the field of information technology to avoid the incorrect usage of the SI prefixes." NIST Special Publication 330 2001 Edition The International System of Units (SI)
"Because the SI prefixes strictly represent powers of 10, they should not be used to represent powers of 2. Thus, one kilobit, or 1 kbit, is 1000 bit and not 2 bit = 1024 bit. To alleviate this ambiguity, prefixes for binary multiples have been adopted by the International Electrotechnical Commission (IEC) for use in information technology." nist.gov
"The new prefixes will eliminate the present confusion between powers of 1000 and powers of 1024 since in the field of information technology the SI prefix names and symbols for decimal multiples are now often used to represent binary multiples." News briefs Section 1.9
"With significant input from the National Institute of Standards and Technology, the IEC adopted kibi (Ki), mebi (Mi), gibi (Gi), tebi (Ti), pebi (Pi) and exbi (Ei) to represent exponentially increasing binary multiples. A kibibyte, therefore, equals 2 to the 10th power, or 1,024 bytes. Likewise a mebibyte equals 2 to the 20th power, or 1,048,576 bytes. The new prefixes for binary multiples, which parallel the metric prefixes, will increase precision in expressing electronic information." Representative's Report — April 1999
"These SI prefixes refer strictly to powers of 10. They should not be used to indicate powers of 2 (for example, one kilobit represents 1000 bits and not 1024 bits)."
"These SI prefixes refer strictly to powers of 10. They should not be used to indicate powers of 2 (for example, one kilobit represents 1000 bits and not 1024 bits). The IEC has adopted prefixes for binary powers in the international standard IEC 60027-2: 2005, third edition, Letter symbols to be used in electrical technology — Part 2: Telecommunications and electronics. The names and symbols for the prefixes corresponding to 2, 2, 2, 2, 2, and 2 are, respectively: kibi, Ki; mebi, Mi; gibi, Gi; tebi, Ti; pebi, Pi; and exbi, Ei. Thus, for example, one kibibyte would be written: 1 KiB = 2 B = 1024 B, where B denotes a byte. Although these prefixes are not part of the SI, they should be used in the field of information technology to avoid the incorrect usage of the SI prefixes."
"Thus 1 kbit = 103 bit = 1000 bit and not 210 = 1024 bit, where 1 kbit is one kilobit."
More Logical?
The section titled "Usage Notes" on hard disk drives notes the following:
“When a stream of data is stored, it's more logical to indicate how many thousands, millions, or billions of bytes have been stored versus how many multiples of 1024, 1,048,576, or 1,073,741,824 bytes have been.”
According to whom? The basic unit on all modern systems is 512 bytes (see LBA). It's more logical to indicate how many blocks (units of 512 bytes) have been stored. If you didn't already know, 512 is half of 1024.—Kbolino04:12, 5 July 2006 (UTC)
I think you mean the common unit of storage in all modern hard drives is 512 bytes. Because CDROM and DVD drives have larger blocks and some tape drives have block sizes that can be set by the user to 32K, 64K, 128K, or even more. All that makes it even less logical to indicate how many blocks have been stored. But that's only assuming we're talking about the actual stored or streamed data, not the capacity. IMO, capacity is best expressed in decimal units and stored data is best expressed in binary units. Maybe the wording should make the distinction between capacity and the total size of the stored data. --JJLatWiki21:14, 5 July 2006 (UTC)
This serves merely as a reflection of my own ignorance (and, judging by the wording of the last sentence, arrogance). I was evaluating the situation from the limited perspective of hard disk drives. However, I will postulate that it is still more logical to use units of 1024 rather than 1000 because blocks (however they are defined) are multiples of 512. (32K = 32,768 bytes = 512 × 64, for example.). I will similarly disagree with the assertion that stored data and capacity should be represented with different units, as that would be akin to representing the total distance of a journey and the distance already travelled, for example, with different units (i.e., not derived from the same basic definition—miles and kilometers, for example). And finally, punch cards are no longer in use and so should have little bearing on this argument.—Kbolino07:47, 8 July 2006 (UTC)
The sentence in question is referring to punch cards. To paraphrase, "the decimal measurements for hard drives are used because they were first used for serially accessed storage like punch cards, and there is nothing about a continuous surface of magnetic material that lends itself to a certain block size". — Omegatron14:08, 8 July 2006 (UTC)
Hmm. How 'bout we forget I said anything and I will work on controlling spontaneous, unjustified outbursts that result from selective reading?—Kbolino16:54, 8 July 2006 (UTC)
I agree with you that we should represent capacity and stored data size with the same standard, with one caveat: if Microsoft will agree to start reporting drive statistics in decimal terms. As long as the operating system reports drive stats in binary terms, we are stuck with the confusing standards. It's not logical to represent a file that is exactly 1,000,000 bytes in size as 976KB or .95MB, but that is in fact what we have and it's too late to go back. It's unfortunate that consumers trust Microsoft more than the hard drive manufacturers. But unless the hard drive guys rate drive size based on the worst-case-scenario (longest file name permitted by most liberal OS with a drive filled only with files smaller than the largest cluster size option), the consumer will ALWAYS get less storage than the capacity rating. --JJLatWiki22:57, 10 July 2006 (UTC)
Some facts to perhaps put an historical perspective on this:
The first disk drive the IBM 350 (1950's) had 5,000,000 100 6 bit characters organized in 100 character sectors. This predates the SI system.
In the 1960's virtually all disk drives used IBM's variable block length format (called, Count Key Data or "CKD"). Any block size could be specified up to the maximum track length. Blocks ("records" in IBM's terminology) of 88, 96, 880 and 960 were often used for obvious reasons. The drive capacity was usually stated in full track record blocking, for example, the 100 Megabye 3330 disk pack only achieved that capacity with a full track block size of 13,030 bytes.
CKD continued into the 1990's and perhaps into this day. In the 70's and 1980's most drives were offered with unformatted tracks (the unformatted capacity) with the particular block size and formatted capacity a function of the controller design. For example, the ST412 of IBM PC/XT fame had an unformatted capacity of 12.75 MB (not MiB) and with the Xebec controller and 512 byte sectors it formatted down to 10.0 MB (not MiB). Other controllers supported other block sizes resulting in other formatted capacities.
The advent of intelligent interfaces (SCSI and IDE) in the early 1990's took the block size decision into the drive and virtually all chose 512 bytes, for no reason other than that was what IBM had chosen when they picked the Xebec controller for the PC/XT.
So, until relative recently, it was very logical to measure in decimal numbers with decimal prefixes because God gave us 10 fingers and that's the system we learned and used until some bad GUI's took the system reported binary number and mispresented it in the mixed decimal number/binary prefix mess we are in. IMO, this history shows that there is no reason, other than sloppy programming, for the current misuse of SI prefixes and therfore there is no reason to use 512 byte blocks as a measure. As it turns out, this is a particularly bad size for current HDD technology and the industry will likely move to a larger size in the near future. While it is likely to be a binary size, this imminent change will futher make measuring in 512 blocks quite arbitrary.--Tom9402204:34, 16 July 2006 (UTC)
If you think the sole reason for using a power of two sector size is that its what IBM happened to use then your knowlage of low level programming is severely lacking. power of two block sizes make sense all over computing because they allow use of efficiant bitwise operations rather than expensive modulo and integer division operations. Also standard paging based virtual memory systems would suffer very badly under a non power of two disk block size.
If and when drives move to a larger sector size (which i doubt will happen any time soon) i STRONGLY suspect it will again be a power of two. Plugwash18:59, 6 January 2007 (UTC)
Supporting Plugwash's point, it's worth noting that the sectors on a CD-ROM drive are larger and are still a power of 2: 2048 bytes. It's pretty clear that as long as computers operate on binary principles, all "multiples" of storage units in the system are likely to remain powers of two for reasons of economical processing of these addresses. I do note, though, that some historical disk/drum systems didn't implement sectors at all; you just had a collection of tracks and could read any contiguous set of storage units (words) (or even bits?) from a given track.
Not entirely true. A CD sector contains 2352 bytes of data (plus about 96 bytes of subcode data) that aren't too difficult to access. "Normal" CDs use the extra bytes mainly for error correction, but they're commonly used for video data in VCDs, at the expense of a higher error rate. Of course, last time I checked, OS X can't actually read data in those sectors. Elektron20:11, 22 August 2007 (UTC)
It's all Marketing's fault. Here is the logic. Let's say that in 1981 I am using a Vic-20 with 3.5 KiB RAM and I have a typed in a 2 KiB program and I want to save it to a mythical (in the day) 2K flash-drive. my 2048 bytes won't fit on the drive will it? that is why the OS'es give you binary bytes, the Marketing guys used to blame the difference in what you bought (250 MB) and what you got (238MiB) as overhead lost to drivers and formatting. Really they just want to say they have the bigger capacity even if it doesn't mach up with real world usage of RAM Seanm916:06, 3 September 2007 (UTC)
Windows File Sizes
Under Windows' File Properties window, it uses the ambiguous "KB", is that referring to 1000 or 1024? --Wulf06:14, 21 December 2006 (UTC)
I don't know for sure but i bet it is KiB, that is 1024. Why don't u make up several varying length text files and see how they are reported, say 999, 1001, 1023, 1025? Tom9402218:28, 6 January 2007 (UTC)
Outside of Misplaced Pages and wikipedia-based sources, there is no confusion or ambiguity on this point. Any reference in Windows to "KB" or "KiloBytes" in the Microsoft Windows operating system indicates 1,024 Bytes. (I submit to you that the wikipedia articles, as they are now, are a greater source of confusion and ambiguity than the industry standard is.) -Libertas19:59, 7 January 2007 (UTC)
There is plenty of real customer confusion - why do most HDD manufacturer websites (e.g. have a FAQ explaining this problem? Since at least Windows 3 (probably Windows 1) Microsoft has consistently and without prominent explanation used the SI system of prefixes in a manner that is incorrect in accordance with the published industry standard for kilo, etc. On the other hand, most of the HDD industry has consistently used the SI system as specified since it was standardized in the early 1960's. Microsoft has the perfect right to define its own system of units but because they are virtually identical to the industry standard I submit Microsoft is obligated to prominently display it's deviant definition, say by putting information lines, e.g.
1 GB = 1,073,741,824 Bytes
in appropriate displays. Microsoft's failure to prominently display such information has caused real customer confusion such as when things don't fit or HDD's are not reported at their specified size. Furthermore this has resulted in several lawsuits. I don't think Misplaced Pages even come close on any confusion scale. Tom9402202:38, 8 January 2007 (UTC)
Properties (click to enlarge); note number of bytes in parenthesis.Tom94022 - Please note that the "point" I was referring to was the question about the "Windows' File Properties window"; in other words, in the Windows operating system (as well as other operating systems, like Mac OS), the values have always been consistently expressed. Likewise, virtually all code written from the "early 1960's" has used the industry standard values; which came first, the software or the Hard Drive manufacturers? ;-) To answer your question, though, the HDD manufacturers have faqs because they are the ones who are confusing people (note that the HDD makers get sued for misrepresenting the values, not the software companies) :-)
As for your comment "Microsoft is obligated to prominently display it's ... definition": please see the Properties window of any file or filesystem (see image to right). Regards, -Libertas11:47, 8 January 2007 (UTC)
Liberty Miller, you keep refering to an "industry standard". To which industry are you referring? The general purpose operating system industry? Or the spinning magnetic disk industry? But I agree with you that all present day OS's and their forefathers have consistently expressed file sizes using the inaccurate and technically incorrect definition of kilo, mega, giga, etc. But because of that, it is they who are the source of the confusion. Prior to spinning disks, there were streaming tapes, and even paper punch cards. Such storage media had capacities expressed with decimal prefixes, and the expression of those capacities could predate the software reporting of the capacity.
You also said, "the HDD manufacturers have faqs because they are the ones who are confusing people (note that the HDD makers get sued for misrepresenting the values, not the software companies)". That is a logical fallacy. Wheel barrel manufacturer "get sued" when some moron hurts someone because he strapped his wheel barrel to his truck and uses it as a trailer. Plastic bag manufacturers "get sued" when someone's child suffocates in their plastic bag. Ford "gets sued" when someone gets hurt or killed because an uninsured drunk driver runs a red light at 90 MPH and T-bones some innocent family in their Ford Escape. Using law suits to decide on whom to blame the binary prefix confusion is worse than those examples, and not just because they ARE frivolous and no one got harmed in ANY way. Try find a lawyer willing to sue Microsoft (which would be truly entertaining) because its OS misrepresents the true capacity of a new hard drive, not to mention the amount of drive space it pirates and doesn't report for things other than the storage of the actual data. If the industries reversed their respective definitions of Kilo and Giga, do you think anyone would sue the OS guys for making it seem as if a 10MB file only used 9MB of disk space? --JJLatWiki17:10, 8 January 2007 (UTC)
U say "all present day OS's and their forefathers have consistently expressed file sizes using the inaccurate and technically incorrect definition of kilo, mega, giga, etc." FWIW, I'm pretty sure DOS DIR never used prefixes at all and they were also not in the original FDISK's. Likewise I am pretty sure that many if not all UNIX variants have switches on commands which allow you to get capacity in decimal or binary strings, but I also think these are without prefixes. Furthermore, at the OS level I believe all you get is a string of digits (binary in most cases, decimal if switched), so it is when the OS reported capacity is converted to a GUI representation that the confusion occurs. To me it feels like sloppy programming - sort of like the meters to feet problem that caused a Mars probe to crash Tom9402217:34, 8 January 2007 (UTC)
I concede that the MS DOS FDISK and DIR commands probably never used prefixes, but I don't think that is a sufficient test to disqualify my statement (on which I would not have bet money). In the Windows lineage, other commands have reported sizes and capacities like the CHKDSK command. I only have bootable floppies going back to a DOS 3.x, and I have no interest in climbing through boxes of crap to verify it. Since the need to report KB diminishes as you go back in time, I'll change my earlier posit slightly to say that WHEN they used prefixes, all present day OS's and their forefathers used the inaccurate and technically incorrect definition for those prefixes. I qualify my definition of "OS" to include all the standard OS utilities like CHKDSK, SMARTDRV, SCANDISK, du, df, CATALOG, and the GUI that the OS publisher created for that OS, which obviously opens a large gray area, especially for the various Unixii. --JJLatWiki17:17, 9 January 2007 (UTC)
Some of the later FDISK's did include an information line (1M = 1,048, 576 bytes) but I think you will have to concede many CHKDSK's and SCANDISK's did not use binary prefixes. For intellectual curiosity, awhile ago, i went thru various DOS's (MS & PC) on this very subject and I think I found most DOS command line utilities displayed decimal bytes without commas, or prefixes. It was painful, so I don't want to repeat the experience, but I did pull out my trusty MS-DOS Encyclopedia, (c) 1988 by Microsoft, and indeed the CHKDSK command reports in decimal digits without commas or prefixes; this corresponds to MS/PC DOS 3.3. I also ran my SCANDISK in Win2k and got a decimal digits without comma's presentation. Note that both Int 13H(hex) function 08H, BIOS "Get Current Drive Parameters" and Int 21H function 1CH System "Get Drive Data", return disk capacity as the product of several binary strings so some programmer had to convert binary strings into decimal numbers in order generate the CHKDSK and other displays in at the DOS level. Why they then chose to divide by binary numbers rather than just shift the decimal point is beyond me :-)Tom9402220:26, 9 January 2007 (UTC)
Ahah. Maybe the blame goes a little deeper. Who were the BIOS writers who created the Int 13H/08H call and why did they output binary strings? Who decided on 512 byte cylinders and why? It was probably simpler and less computationally expensive to use 512 or 1024 and binary in general instead of 500 or 1000 because of the nature of binary processors. And maybe the conversion to Ki (bit or byte) took place at an earlier point in the execution sequence before the conversion to decimal. And no one was ever interested in correcting those first mistakes for fear of causing some serious cascade of subsequent required changes. "Why fix it if it ain't broken?" was probably spoken as proportionally often back then as it is today. --JJLatWiki21:03, 9 January 2007 (UTC)
It is likely that the decisions were made by Xebec controller firmware engineers and Microsoft BIOS / Device Driver firmware engineers, all under contract to and direction of IBM for the PC/XT (I seen to recall that IBM PC/XT BIOS was written by Microsoft not IBM). I suspect most of this programming was done in assembly languages, so that Hex notation made sense. Sectors sized in binary increments of bytes also makes sense for the same reason, 512 byte sector size, was probably in someone's estimation the Goldilocks number, not too big (1024) because of truncation of small files, not too small (256) because of sector overhead, just right :-). BUT, at the DOS level, for the most part Microsoft went thru the process of calculating disk size by doing a series of hex computations AND then translating the result into decimal units - thats what u see in CHKDSK, DIR, etc. No prefixes, no problems (other than the lack of comma's made reading hard). However with the advent of the Windows GUI, someone decided to take the same calculation of drive capacity, move the binary point (shift operation) and then convert to decimal for display using decimal prefixes to account for the shift. This is mathematically improper and the source of the confusion. The whole idea of SI was to eliminate conversion factors that are required when u have non-integrated systems of units but thats what these guys created when they did this. The only possible reason is that shifting is faster (and easier) than dividing, but we are talking about a fairly high level programming by the time we get to Windows GUI's - IMHO, there is simply no reason, other than sloppy programming, why they couldn't have converted the drive capacity calculated in Hex to decimal and then divided by the SI proper values to move the decimal point. I suspect they were oblivious to the problem they were creating, simply thinking that no one would care about the difference between 1,000,000 and 1,048,576 - it's only 4% Tom9402220:36, 11 January 2007 (UTC)
Libertas - The HDD manufacturers have consistently and properly used the SI Prefixes since they were defined in the 1960's well before Microsoft and Apple even existed. Furthermore, as near as I can tell the originally dominant software company, IBM, correctly used SI Prefixes in describing it's DASD (IBM term for what we now call HDD). Ditto for Digital HDD's (they may have fallen from grace with some early floppy products). Finally, Apple bought its disk drives from disk drive companies using SI prefixes in their specifications and contracts (still do :-). I bet Microsoft does the same in its game line. Therefore, I suggest:
1) Microsoft and Apple are responsible for the confusion, and
2) because they caused the problem, they have an obligation to inform the consumer of their deviant usage.
You and I know the problem caused by mixing unit systems, the casual user does not. Therefore the screens cited are not sufficient to stop the confusion. The only way for them to stop this is to include a statement something like:
1 GB = 1,073,741,824 Bytes not 1,000,000,000 Bytes
every place they use KB, MB or GB in a deviant manner. BTW, Microsoft File Properties has NOT always displayed both the full decimal value along with its deviant prefix, see, e.g. Windows 3.11. Tom9402217:23, 8 January 2007 (UTC)
No! The "1 GB = 1,073,741,824 Bytes not 1,000,000,000 Bytes" statement sounds like "Don't listen to others, we tell you the truth!". Some people might think "Oh, according to my HDD box writing it should be 1000000000 Bytes, but if Microsoft says it isn't I should believe them.". I think that they should write "We don't care about the SI standard which says that 1 GB is 1000000000 Bytes. Instead we like to define it with the unremembarable number of 1073741824 Bytes". But if they wrote that they could as well just use the standard...
Once More On HDD
An anonymous user added text regarding HDD manufacturer usage of hybrid GB prefixes. I added a because I am not sure of any such current usage. Can anyone cite such current usage? If not, I'm likely to revert this Tom94022 18:28, 6 January 2007 (UTC)
I did the fact checking and was unable to find hybrid usage by any of the significant HDD manufacturers, so I rewrote the HDD portion of the article including eliminating the hybrid usage comment Tom9402219:50, 6 January 2007 (UTC)
0x prefixes before base 16 numbers
This prefix is probably should be omitted, because it may probably confuse some people who don't know C/C++ but know math. --Yonkie16:26, 20 January 2007 (UTC)
Consumer confusion section
Let's talk about the consumer confusion section. I like the recent edit by Tom94022, but it still illustrates a recurring problem, though not a serious one, which is that editors are inserting their personal assumptions and speculations about why the binary prefixes were used or why they are still used.
I've been involved in the computer industry only since 1991, so I don't know what or even if hard drive companies, software companies, or memory companies had motives to their use of the SI prefixes. Since my involvement in the industry in a variety of roles including programming and quality assurance, I know with a little authority, that memory companies and Flash drive have no motivation to classifying their devices with the SI prefix whether the actual capacity is 2^30 or 10^9 bytes. It's that way because "it's always been done that way". If we produce a program that reports the size of a file, the remaining capacity of a drive, or the amount of installed physical system memory, it's always the SI prefix using the binary calculation. Over the years, I've attended numerous seminars, trade shows, and industry executive meetings, and from what I've gathered, the philosophy is pretty common. No one in the various computer product industries is working seriously to implement kibi, mebi, gibi prefixes because it would probably add to the consumer confusion and otherwise produce no significant benefit.
That's all anecdotal and speculative and I make no offer of proof. I fear the same is true for the following statements: a) "the discrepancy could easily pass for manufacturing overhead", b) "manufacturers rapidly developed the capability to make much larger memory, and the discrepancy became increasingly difficult to ignore", c) "The confusion appears to relate to the advent of graphical user interfaces where there was not sufficient space to provide sufficient digits fully state capacity.", d) "some computer programmers were unaware that disk drive manufacturers used the SI notation when specifying and/or advertising capacity"
a. seems to imply a motivation. I've never heard of any evidence to support a motivation.
b. implies that manufacturers created the new prefixes to address a problem that was not theirs, and still have never used.
c. "appears" implies original research, but I don't think it was screen realestate that drove the use of prefixes. Think of the retail packaging for the 3.5" my next to last PC had, "3.5-inch 1,474,560 byte floppy disk". The last hard drive I bought would have needed a larger box just to fit the drive size in bytes. It's also just human-nature to use a shortening calculation and prefix to express really large numbers, so I think it's inaccurate and unfair to blame the confusion on the space limitations that may exist in some GUI's.
d. based on my own experience, this doesn't matter and needs some evidence since the programmers might just have likely felt that a megabyte should be 1024^2 and not 1000^2, regardless of what is being measured.
There's a lot of speculation in this section (but exclusively there), that could easily be misused. Instead of editing and waiting for the revert or new speculation, I think we should discuss it here first. --JJLatWiki22:47, 29 January 2007 (UTC)
While it is true that since 1991 "it's always been done that way," it wasn't done that way in the 1960's or probably even the 1970's so there was a transition in the 80's and to the extent we can identify it we should. With regard to your comments on the sentances:
a, & b. - we agree, that led me to try to better edit this section.
c. We are talking about consumer confusion in this section. It is impossible to prove a negative but can anyone cite any significant such confusion with DOS, IBM MVS, DEC TOPS, UNIX or any other command line (pre-GUI) OS? Isn't it the GUI reported value differing from the manufacturers advertised value that leads to the consumer confusion? Perhaps we can word smith this sentence better, but the confusion does come out of this difference. BTW, I first became aware of the confusion in the late 80's at SyQuest when we started getting consumer complaints from Macintosh users that the 88 MB SyQuest cartridge was only 85 or so MB (as reported by Apple). The problem then appeared in the Windows world, as I recall with Windows 3.11 (it may have always been in Windows but until 3.11 the market was small).
"to the extent we can identify it we should", therein lies the rub. You've certainly demonstrated a superior knowledge of the history, but without a reliable source to cite, it violates the original research guideline. The original sources of the confusion need proper citation? Even if you are one of the programmers of Windows 1.0 and you were involved in the meetings where the decision was made to called a megabyte 1024^2, it must be verifiable. Because, to take a counter position on phrase "c", one could speculate that the fact that the increase in consumer complaints about the discrepancy between rated MB capacity and GUI reported MB capacity is coincidental. GUI's are largely responsible for the increase in sales of computers and around the same time, drive sizes were reaching capacities that made the discrepancy more obvious. If PC's hadn't become so popular or drive sizes had remained relatively small, the amount of confusion would be less newsworthy. And let's not ignore the increase in frivolous litigation that drew even more attention to the discrepancy.
I think it's very likely that prior to the proliferation of GUI's, there was some program, a utility probably, that ran on DOS or Unix or some other non-GUI'd OS that presented the used space or free space of a disk or tape using the SI prefix and a binary calculation. Those programmers became the foundation for development at other companies that created early multitasking UI's, first text-based, then eventually graphical UI's. If you know different, WP considers it original research without verifiable reliable sources and without verifiable reliable sources, we have to be careful about what we say. --JJLatWiki17:31, 30 January 2007 (UTC)
The various operating systems speak for themselves and in that sense what I am stating is a compilation which is not a violation of original research guideline. I can speak from direct experience with IBM MVS and IBM DOS, MSDOS, PCDOS, all flavors of Microsoft Windows, some UNIX and some Macintosh. I have less experience with CPM and several Digital OS's. While your speculative "program, a utility probably, that ran on DOS or Unix or some other non-GUI'd OS" may exist it was likely obscure enough to not cause any consumer confusion. In fact since we are talking about "consumer confusion" aren't we really just talking about the transition from MS/PC DOS to Windows (and perhaps Apple DOS to Macintosh OS), since most if not all of the other OS's are arguably not consumer products. I agree with you that why Microsoft and Apple chose M = 2^20 for storage is not relevant, but the fact that Microsoft did so in changing from command line to GUI and thereby displayed a number different from that provided by the storage manufacturer is the source of the confusion to 95% of the consumers.Tom9402220:15, 30 January 2007 (UTC)
What do mean by, "The various operating systems speak for themselves"? That I should know where to find the evidence to support phrase c? Because I don't. I think phrase c and what you said above ("since we are talking about "consumer confusion" aren't we really just talking about the transition from MS/PC DOS to Windows") implies some causal connection, that calls for a citation. I think if Windows or any other GUI had never gained traction, drive sizes would have probably driven a change to abbreviated byte counts. It's still primarily Microsoft and Apple's fault for the extent of the confusion, but I think it's not the transition to GUIs that is the cause. --JJLatWiki03:36, 31 January 2007 (UTC)
Sorry if my language caused confusion; what i meant is that the interfaces presented to the user by each operating system is a fact that speaks for its self and therefore it follows that where you find evidence to support c. is by inspecting the various outputs of the various OS's. Personally, to refresh my recollection, I spent a few hours several months ago actually booting up various MS/PC DOS's from 2.11 thru 5, Win 3.11 and Win 95. Can we agree that the source of confusion is the OS's presentation to consumers of storage capacity with prexfix's that absent explanation appear to be SI prefixes? Then doesn't the earliest of such presentations mark the beginning of confusion? The various MS/PCDOS utilities relating to storage, DIR, SCANDISK, CHKDISK, FDISK basically did not use prefix's. Apple DOS did not handle HDD's. Macintosh used K from the beginning and Windows used K and M at least as early as Windows 3.11. So can u support it, if I change the sentence to read something like:
Consumer confusion appears to begin subsequent to the advent of Microsoft and Apple graphical user interfaces where rather than state capacity with sufficient digits (as typical of prior command line interfaces) the programmers chose deviant usage, without prominent explanation, of SI system prefixes.
I personally haven't completely verified the Macintosh statement so that is why I put a citation required there, but see the screenshots at:
The original MAC drive setup utility was "HD SC Setup" so what i really would like to see is the screen shots from early MAC "HD SC Setup" presentations. Maybe a MAC historian can help us :-)
Windows 3.11 File Manager and Explorer used K and M without explanation.
Macintosh OS's used K without qualification from the beginning.
The various MS/PCDOS utilities relating to storage, DIR, SCANDISK, and CHKDISK did not use prefix's. Some versions of SCANDISK did use M with an M=1,048,576 explanation.
"Can we agree that the source of confusion is the OS's presentation to consumers of storage capacity with prexfix's that absent explanation appear to be SI prefixes?" For the most part. How about a little rephrase to something like, "The biggest source of confusion is the storage capacity and file size presentation by OS's using SI prefix's but binary calculations without any explanation."
"Then doesn't the earliest of such presentations mark the beginning of confusion?" Except that the earliest such presentation is probably not an OS. Even though OS's now are the source of the extent of the consumer confusion and the only reason the confusion is notable, I think the earliest such presentation is probably unprovable. So we are left to speculate about which company or programmer or manager decided to call a megabyte of storage 1024^2 bytes and not 1000^2 bytes. I think this confusion is more relative to the binary prefix and not specifically to megabyte. Someone, somewhere, was probably confused why their 360KB 5.25" floppy could not store a 355KB file, or something similar. But very few people ever cared until people noticed their 120MB hard drive seemed to be missing 6MB. And people really started talking when their 40GB seemed to be missing 3000MB. Unless someone can show that an OS was the first source of confusion, the only facts available relate to the present time. I'll try fire up my old Apple IIe with ProDOS to see what it shows. Did ProDOS support hard drives? I know such drives were available for my IIe. Damn! Was a hard drive available in my beloved TI 99/4a? --JJLatWiki18:21, 1 February 2007 (UTC)
The Sinclair citation says nothing about the usage of K with regard to secondary storage - it would be interesting to see how Sinclair described its cassette storage device and how the OS reported it, the citation gives no such information. There is little dispute that K commonly meant 1024 with regard to main memory of home and personal computers, probably from the very beginning. The question we are trying to resolve is how did such usage leak into reporting of secondary storage device capacity. Macintosh so far is the earliest such substantial usage.Tom9402203:49, 30 April 2007 (UTC)
As a reference: The DOS Manual from Apple, (c)1980, state in Appendix C: (I'm translating from the french edition that I own)
"In a system DISK II, the information stored on floppy disk is recorded on 35 concentric zones called 'tracks'. The track are numbered from the outside with track $00 to the inside, track $22. ... Each track is divided in 16 segments, called sectors. The sector are numbered from $0 to $F. Each sector can hold up to 256 bytes, or $100 bytes of information."
That is 143360 bytes. Browsing of vintage computer magazines, I have a April 1983 edition of 'Micro-Systeme'. Page 152, an add for an Apple II clearly state that it has a 'Drive 140K', just to confirm something I've known for 25 years: a Apple II floppy disk was 140K, not 143 'marketing' K.
The Glossary of the Appli II, Reference Manual (c)1979 Apple, state : "Kilobyte: Kilo-octet : 1024 octets" and "K :Initial of “Kilo” signifing, in general 1000, but in computers science ('informatique' in the original) K signify 1024 = 2 ($400 in hexadecimal)
The Glossary of the Apple IIgs(c)1986 Apple, state: "K or Kilobyte: Unit of storage capacity or a computer and of its memory capacities. One k is equivalent to 1024 bytes or 1 kilobyte.
Note that 7 year later the manual doesn't bother with the decimal meaning outside of the field.
The Apple 3.5 Drive Owner Guide(c)Apple, 1986, in Appendix B: Apple 3.5 Drive Specification, make reference to a 'formated data capacity of 819.2 kilobytes per drive and 409.6 kilobytes per surface. yet page 7, 14, 18, 20, 21, 23, 25 it refer to 800K or 400K disks.
Regarding storage on tape, no-one at the time made any clear claim about how much one could store on a tape. The main reason was that it was 'audio' tape, whose length was approximate anyway. The Apple II Reference Manual, p46, claim "it take about 35 second ( plus 10 second for the initial marker) to save 4096 bytes... It doesn't make use of KB, but as expected use a power of 2 as a representative example.
Another data point is the fact that, on IBM mainframe system, size of object on storage were expressed in TRK (tracks) or CYL (cylinders), only recently (relative to the history of JCL) JCL has been extended to allow the specification of K,M in the SPACE() specification of a DD card for example. An here again K and M are used in the conventional sens.
In conclusion: The usage of decimal notation for K,M and G is limited to Marketing material of hard drive storage. When these storage devices are in use and connected to a system, size, when reported in KB or MB, is always reported in the standard meaning in the field, namely 2^10 an 2^20 bytes respectively, the usage of KB and MB didn't suddenly "leak into reporting of secondary storage device capacity", it has been consistently and exclusively the case in software, from mainframe to micro that when used K,KB,M,MB... had the conventional meaning in the field. Shmget02:28, 21 May 2007 (UTC)
Yes, floppies have often been measured using binary prefixes, which is where the Microsoft disk drive size convention originates.
The earliest floppies were actually measured with decimal units, though, like the "1.5 megabit" Memorex 650 from 1972, for example. (See Memorex 650 Flexible Disc File - OEM Manual)
Decimal prefixes weren't adopted for marketing purposes; they were in use by these engineers before their devices were even on the drawing board.
Binary units were later adopted because it meshed well with the addressing scheme used to access blocks of memory. Many of the earliest (1960s) instances of abbreviations like "40K" were decimal. "Standard meaning in the field" never really existed.
The meanings of these abbreviations have changed with time and context, and have been ambiguous for most of computing history. It's not a conspiracy. :-) — Omegatron13:52, 1 June 2007 (UTC)
The earliest floppies were actually measured with decimal units, though, like the "1.5 megabit" Memorex 650 from 1972, for example. (See Memorex 650 Flexible Disc File - OEM Manual)
And please note that 1/ it is bit not byte. and 2/ there is not use of KB, MB in this document. The question is not about if someone use 'megabits', but when did they use MB as a unit in marketing material without explanation (i.e implying that the meaning is well know and understood by the targeted audience - the title of this section is the so-called 'consumer confusion', remember ? ) -- Shmget17:36, 1 June 2007 (UTC)
Decimal prefixes weren't adopted for marketing purposes; they were in use by these engineers before their devices were even on the drawing board.
one doesn't preclude the other. There are plenty of notation, acronyms, etc.. we use during development that do not make it to the user manual and even less into marketing meterial, if for no other reason that marketing material is not written by engineers. -- Shmget
Binary units were later adopted because it meshed well with the addressing scheme used to access blocks of memory. Many of the earliest (1960s) instances of abbreviations like "40K" were decimal. "Standard meaning in the field" never really existed.
except that to this day, hard drive manufacturer use MB without any footnote or explanation to designate their memory cache, which is an admission that the meaning is clear i.e. has 'a standard meaning in the field'. They also use MB/GB with a foot note when they means it as 'decimal', which illustrate that this particular meaning is NOT what a non-expert reader would expect. -- Shmget17:36, 1 June 2007 (UTC)
The meanings of these abbreviations have changed with time and context, and have been ambiguous for most of computing history. It's not a conspiracy. :-) — Omegatron13:52, 1 June 2007 (UTC)
The systematic use of the 'MB' symbol in hard-drive marketing material came in the 80s. One reason it wasn't use before was becaue these symbol would not have been recognized by the public (just like processor frequency where advertised as 1200 Mhz (for example), for a while, until GHz became common enough that it could be use in marketing material). Marketing people don't do stuff out of tradition or purism, them make their choice of words based on marketing (i.e how much can you lie to make you look better without being caught). if one K had been 978 bytes instead of 1024, I bet you that today, marketing material for hard drive would use that meaning, no matter what the in-house engineers think or use.
To use a familiar notion of about the same period. The question is no who was first of Betamax or VHS, nor which one engineers at Sony used or liked better, the question is that when you order a TV program on 'video tape' without other specification, could it reasonably be expected to be a Betamax ? -- Shmget17:36, 1 June 2007 (UTC)
The question is not about if someone use 'megabits', but when did they use MB as a unit in marketing material without explanation
No. It's about when manufacturers first started using decimal and binary units. You've claimed that the binary sense of units was ubiquitous at some point in time and then the hard drive manufacturers, by themselves, transitioned to using decimal units in a deliberate attempt to mislead their customers. I've shown that decimal units came first, and you've provided absolutely no evidence of intentionally misleading figures.
if for no other reason that marketing material is not written by engineers
There are both technical and marketing documents on this page. None support your theory.
The systematic use of the 'MB' symbol in hard-drive marketing material came in the 80s.
Hard drives have always been measured in decimal units. Do you have evidence to refute this?
Are you asking me to prove a negative existance ???? But really, you are harping on the confusion between decimal and decimal unit. While it is true taht back in the 60s IBM where advertising the size of his storage device in 'million of byte/word...', it is not true that they 'always have used' KB/MB/GB. For one thing the never used KB in the so called 'decimal' sens (so-called because K is not a SI prefix), and the use of MB followed the widespread use of K and KB, which meant and still mean 1024 bytes.... - Shmget05:38, 2 June 2007 (UTC)
I'd be delighted to see such evidence. It doesn't matter if they abbreviated with the word "millions", "M", "Mb", or "GB".
Of course it matter, that is the ONLY thing that matter here. the significance of 'MB', not Mb, M, million, MByte or M-By or whatever other notation one can think of. The Whole point is what MB means. -- Shmget05:38, 2 June 2007 (UTC)
The meaning has been the same in every document I've ever seen. If you have a document that describes hard drive capacity in a binary sense, please present it.
That is a false dichotomy. The argument is not that hard-drive manufacture 'switched' from binary unit to decimal unit, but that they surfed the wave of popularity of these binary unit and started to use these KB/MB/GB symbol, when before they were spelling it out our using other abbreviations. divertin gthe disciton over mention of 'a million bytes' in the so-called 'decimal meaning' (what else could that be) is a Red Herring. Of course that 'a million of word' is 10^6, but that has nothing to do with the argument.
It is completely irrational to claim that hard drive manufacturers used decimal abbreviations for decades and then switched to a different type of decimal abbreviations in a deliberate attempt to mislead customers.
So why did they do so ? They certainly did not use these particulars kind of unit KB,MB,GB for 'decades', yet in the early 80s they started to advertise their hardware as such..., AFTER the meanign of K=1024 had been well established and accepted - to the point where it was not necessary to explain it anymore. I'm sure you still have some vintage magazine from the 80-83 time period, like I do, and you can read the ads in these for harddrives. -- Shmget05:38, 2 June 2007 (UTC)
They also use MB/GB with a foot note when they means it as 'decimal', which illustrate that this particular meaning is NOT what a non-expert reader would expect.
They didn't until they were sued because of the discrepancy with operating system measurements.
It wasn't important to be accurate until then; the vast majority of people just don't give a damn. — Omegatron01:26, 2 June 2007 (UTC)
Why didn't they add a footnote to explan that the MB of the cache is in 'binary' prefix, rather than a footnote to explaini the decimal meaning ? why harddrive manufacturer, 9 years after the introduction of the IEC notation, still do not use them... could it be that they have no interest in lifting the cloud of confusion they have created in a segment of the consumer population ? And Again I asked. if K was equal to 978 instead of 1024, what kind of unit would harddrives be marketed with ? What is 'completely irrational' is to pretend that marketing people care about the purity of the SI. marketing guy: 'let's see, will we advertise this drive as 100MB or 95.3MB... uhmmm, I think we'll go with 100MB, especially since surely the guy across the street will do just that, and we don't want to look bad, do we...". this is not a 'conspiracy', it just plain common sens, applied to basic psychology. All the rest is post facto rationalization. At first it didn't matter because 1- the delta was relatively small and 2/ the kind of people that where spending that kind of money for a hard drive where hobbyist or professional, that knew the trick. The thing became a 'problem' with higher unit making the delta more and more significant, the popularization of computers and the generalization of hard-drive use, leading to a bunch of uninformed people buying harddrive. I wouldn't have cared that much (and I haven't really, until I met people like Sarenne) that hardrive-manufacturer use the unit they way they do, but I do get irritated when they claim SI high-ground to rationalized their marketing decision, and insist that the rest of the world is 'wrong'/'incorrect' for not embracing their bastardized SI unit (a mix-breed between SI prefix and conflicting non SI re-defintion of the B SI unit) -- Shmget05:38, 2 June 2007 (UTC)
Word "abused" seems to be POV
"However, with amounts of computer memory these prefixes were often abused to denote the nearby powers of two..."
The word "abused" in that statement appears biased. It would seem that saying "However, with amounts of computer memory, an
alternate usage of these prefixes arose denoting the nearby powers of two..." (or something along that lines) would be a lot
more neutral.
Please sign yr comment. Also, shouldn't this be under Talk 40 above. IMHO, POV is perfectly acceptable in a Discussion page. Where else can we work this out? Tom9402204:33, 27 February 2007 (UTC)
"This is probably because some marketing person decided that this was best advertised as a double capacity version of the prior generation 720 KB product (of course, it was 720 KiB)."
Doesn't seem very informative, more like speculation.
--TJ0900:49, 7 March 2007 (UTC)
We should really find as much as we can about the origins of the terminology. I contacted John Reed a while ago — one of the people who worked on the Intel 1103, the first 1k DRAM — and he said:
Of course, "Kilo" originated in the metric system, which dates back long before there were RAMs. Before the RAM itself, "kilo" was used for example, to describe a 1,000 ohm resistor: it was a "1K" or I Kilohm resistor. "K" took a sort of special meaning in the binary-based digital world of the RAMs, as it came to represent 1,024 (2^10) instead of 1,000. So the 1K 1103 had 1,024 bits, or a kilobit. Extending that to bytes? Who knows when, but it's not rocket science to see how it would have been a natural followon.
I updated the history section to try to capture this idea, though it's going to be hard to find real references for any of this, since it really didn't matter enough to note at the time. It's actually a correct approximation for the small numbers of kilobits available in the first chips, but it became a casual usage and then an incorrect usage as memory sizes increased over time. — Omegatron00:50, 18 March 2007 (UTC)
I undid Omegatron's edit because I think it is somewhat incorrect. Most of the pre 360 computers that I've looked at did not have binary multiple word width or depth, some even weren't binary :-). Binary width and depth certainly existed with System/360 but the IBM product literature I've seen didn't use k. Gene Amdahl did use it with a k=1024 qualification in his seminal article. I'm not sure there is any particular reason for core planes to be binary since they don't have any particular pin limitation that sort of drives IC's. Tom9402204:55, 18 March 2007 (UTC)
It's a numeral system limitation more than a pin limitation. In any case, Omegatron's edit addressed early memory planes, not early computers, and he seems to have reasonable evidence to support his edit. -- mattb@ 2007-03-18T05:01Z
I see no evidence, just an unsupported opinion - do you think a Williams tube had a binary addressing scheme? How about a mercury delay line or a drum, all of which were memory systems in early computers. The statement "...memory sizes, which are always powers of two." absence substantiation is POV which has no place herein.
BTW, Dr. Wang's seminal core patent, 2,708,722 (1955) makes no mention whatsoever about binary addressing.
And quoting from the IBM305 General Information Manual, 1960, about a very successful system first shipped circa 1954:
The main memory was drum storage, its capacity is stated as:
"Each drum track has a capacity of 100 character positions. Positions are numbered from 00 to 99, sequentially around the drum."
This was the first system with a hard disk drive, its capacity is stated as:
"The capacity of the basic file, 5,000,000 characters, may be recapped as follows:
50 disks X 100 tracks per disk = 5,000 tracks
5,000 tracks X 10 records per track = 50,000 records
50,000 records X 100 characters per record = 5,000,000 characters
...The first file and/or the attached file can be of 5,000,000 or 10,000,000 character capacity to provide the system with a total of 5, 10, 15, or 20 million character storage capacity."
BTW, the drive characters were 6 bit :-) There isn't a single binary number in either memory or storage! I'm going to wait for comment, but Omegatron's edit is clearly wrong in light of the above and needs to be fixed. Tom9402221:01, 18 March 2007 (UTC)
You're confusing memory with hard storage. Hard drives have consistently been measured in decimal units since they were first invented. Memory is always made in powers of two because of addressing, though. The weird binary usage of SI prefixes came about because of memory sizes. — Omegatron21:24, 18 March 2007 (UTC)
No, the addressing issue applies to RAM, which are only powers of two. Things like hard drives or CDs can have any number of bytes, even a prime number if you are insane enough to create something like this ;) 84.58.153.21510:11, 20 April 2007 (UTC)
I'm confusing nothing - you are misstating history. As one example, please see the RAMAC computer system above, it's memory WAS NOT sized in binary units, the manuals can be found at the RAMAC restoration project website. The fact that it's main storage happened to be a drum is an historical fact. There were many such drum machines and other machines using other technologies, none of which were inherently binary. I seem to recall even some BCD machines, in which everything was power of 10. Some of them might even have used core memoryTom9402221:49, 18 March 2007 (UTC)
That's what I just said. Hard drives have always been measured in decimal units, as demonstrated by your link.
IBM's RAMAC 350, the world's first Random Access Magnetic Disk Drive the ancestor of the hard drive in your computer - with 5 million characters.
Please re read what was said about the main memory of the RAMAC (BTW RAMAC refers to both the drive and the system)as follows:
The main memory was drum storage, its capacity is stated as:
"Each drum track has a capacity of 100 character positions. Positions are numbered from 00 to 99, sequentially around the drum.
100 is not a binary number!
The IBM 1620 using core memory had memory modules of 20,000 words. NOT A BINARY NUMBER
I pulled out my 1959 "Handbook Of Automation Computation And Control - Vol 2, Computers and Data Processing" and it gives memory sizes in decimal units, no prefixes, and not binary numbers.
Historical evidence contradicts your assertion that memory comes in powers of two, it may do so now, but it did not do so in the beginning of computers. How many examples do I have to give you (2 computers, one book) before you will agree to retract or re-write your contribution?Tom9402223:19, 18 March 2007 (UTC)
One more factoid, a search of the Computer History Museum's IBM Stretch document database, 900+ documents from the 1950's and early 1960's turns up ZERO usage of k, K or M. There are many hits describing the depth of the main memory with decimal units. Stretch is the precursor to IBM's System/360.Tom9402219:55, 19 March 2007 (UTC)
I put a {fact} on the 360/30 core memory addition since this appears to me to be a current (2007) description and not how this memory plane was described in 1964 or whenever it was sold by IBM. Shouldn't we be careful to assure that all our quotes are time period appropriate? On a broader subject, isn't the issue really when did the OS's start using prefixes in a Binary Sense? Most of what we have below is evidence that there is no reason to use prefixes in a binary sense since these examples of main storage were not binary in nature.Tom9402216:01, 22 March 2007 (UTC)
Early drum and disk storage devices only held relatively small amounts of data, and were specified by the number of characters or words they could hold instead of bits or bytes. Sometimes this was a binary-based number, depending on what the computer was intended to do. See Early IBM disk storage. I would conjecture that they have always been measured in decimal units once they got to bigger, more arbitrary sizes, though. — Omegatron19:13, 25 March 2007 (UTC)
I'm not sure but I think all of the patent sources u are using are only completely full text back to about 1975 and somewhat spotty there after (this applies to USPTO and Delphion). This does raise a question of in inadvertent bias in this survey. I do have access to a full text IBM Technical Disclosure Bulletin which is full text back to 1958. FWIW, a quick check shows very little usage of kilobyte, kbyte, 64k, 128k, 256k or 1M until the late 1960's. When i have some time I think i will do some histograms as perhaps a way to illustrate the adoption.Tom9402203:11, 27 March 2007 (UTC)
I was using Google Patent Search which has full text for all patents, though the older ones have OCR errors. — Omegatron03:15, 27 March 2007 (UTC)
Timeline of terminology
Gather quotes and other evidence of the first uses of different units here assuring that the quote is accurately identified in time:
1948
Word "bit" coined by J.W. Tukey as abbreviation of "binary digit" and put in print by Claude Shannon
1952
The first magnetic core memory, from the IBM 405 Alphabetical Accounting Machine. (image shows 10x12 cores; presumably one of 8) This experimental system was tested successfully in April 1952.
Teaming up with a more experienced engineer, he built a core memory with just enough capacity to store all the information in an IBM punched card: 960 bits in a 80x12 array. In May 1952 it was successfully tested as a data buffer between a Type 405 alphabetical accounting machine and a Type 517 summary punch. This first functional test of a ferrite core memory was made in the same month that a four-times smaller 16x16-bit ferrite core array was successfully tested at MIT.
Principles of Operation does not seem to use "kilobit" anywhere. Specifies that memory tubes (IBM 706) hold 1024 bits each, drum memories (IBM 731) hold 2048 words each.
Optional magnetic core storage (IBM 737) stored 4,096 words. Each plane stored 16x16 = 4,096 bits.
1954
IBM305 General Information Manual, 1960, about a very successful system first shipped circa 1954:
The main memory was drum storage, its capacity is stated as:
"Each drum track has a capacity of 100 character positions. Positions are numbered from 00 to 99, sequentially around the drum."
"Magnetic core storage units are available with capacities of either 4,096 or 32,768 core storage registers; or two magnetic core storage units, each with a capacity of 4,096 core storage registers, may be used. Thus, magnetic core storage units are available to give the calculator a capacity of 4,096, 8,192, or 32,768 core storage registers."
"Each drum has a storage capacity of 2048 words."
1956
Word "byte" coined by Werner Buchholz
"The 650 RAMAC combines the IBM 650 Magnetic Drum Data Processing Machine with a series of disk memory units which are capable of storing a total of 24-million digits. The 305 RAMAC is an entirely new machine which contains its own input and output devices and processing unit as well as a built-in 5-million-digit disk memory."
"Electrostatic memory is the principal storage medium within the machine. It consists of cathode ray tubes which can store up to 10,000 characters of information in the form of electrostatic charges. ... Additional storage, as required, may be provided through the use of magnetic drum storage units, each having a capacity of 60,000 characters."
"A character may be a letter of the alphabet, a decimal number, or any of eleven diferent punctuation marks or symols used in report printing."
"Each one of the 10,000 positions of memory is numbered from 0000 to 9999 and each stored character must occupy one of these positions." (page 8)
"A total of 40,000 characters can be stored within the main storage unit of the Type 705."
"Each one of the 40,000 positions in memory is numbered from 0000 to 39,999." (page 17)
"One or more magnetic drums are available as optional equipment with a capacity of 60,000 characters each."
1959
Real, P. (September 1959). "A generalized analysis of variance program utilizing binary logic". ACM '59: Preprints of papers presented at the 14th national meeting of the Association for Computing Machinery. ACM Press: pg 78-1 - 78-5. doi:10.1145/612201.612294. On a 32k core size 704 computer, approximately 28,000 datum may be analyzed, … without resorting to auxiliary tape storage.{{cite journal}}: |pages= has extra text (help) The author is with the Westinghouse Electric Corporation.
1950s
in the ‘50s amazingly enough and only total coincidence, I actually was given the job of writing the operational specifications they handed me this thing and said, “You’re going to define how the hand over process works between direction centers,” and- and I had no idea what they were talking about. But we had uh.. one kilobit lines connecting the direction centers and I thought, “Good, God, 1,000 bit a second. Well we’ll surely be able to figure out something to do with that.” <chuckle>
U.S. patent 3,214,691 FREQUENCY DIVERSITY COMMUNICATIONS SYSTEM - Filing date: May 13, 1960 (earliest Google Patent search result for "kilobit")
"In actual construction, the delay line, which provides a total delay from one end to the other of one baud (10 microseconds for a 100 kilobit per second information rate), may be fabricated from lumped parameter elements, i.e., inductors and capacitors, in a well-known manner."
"At a 100 kilobit per second information rate, both mark and space signals will generally be transmitted in any 0.0001 sec, interval, and therefore this requirement is easily met with conventional resistors and capacitors."
Gruenberger, Fred (October 1960). "Letters to the Editor". Communications of the ACM. 3 (10).
The 8K core stores were getting fairly common in this country in 1954. The 32K store started mass production in 1956; it is the standard now for large machines and at least 200 machines of the size (or its equivalent in the character addressable machines) are in existence today (and at least 100 were in existence in mid-1959).
The cores were powers of 2, but were they using the binary or truncation system? Both produce "32K", no?
1951-1961
A search of the Computer History Museum's Stretch collection of 931 text documents dated from Sept 1955 thru Sept 1961 shows no usage of k or K to describe main storage size.
1961
Gray, L (1961). Radio Transmitters. New York: McGraw-Hill. ISBN0070242402. In the case of the transmission of business-machine or telemetered data, it is more usual to express the speed in bits or kilobits (1,000 bits) per second.{{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)
Quoted in OED as first instance of "kilobit", though "it is more usual" suggests it is already in common use
February 17
Gaunt, W., Jr. (1961-02-17). "A 12-Kilobit, 5-Microsecond ] Variable Store" (PDF). Solid-State Circuits Conference. Digest of Technical Papers. Vol. IV. (Bell Labs., Inc., Murray Hill, NJ, USA): IEEE International. pp. pp. 106-107. Retrieved 2007-03-22. {{cite conference}}: |pages= has extra text (help); Check date values in: |date= (help); URL–wikilink conflict (help); Unknown parameter |booktitle= ignored (|book-title= suggested) (help); Unknown parameter |coauthors= ignored (|author= suggested) (help)CS1 maint: multiple names: authors list (link)
Earliest instance of "kilobit" in both IEEE explore and Google Scholar; only occurs in title of paper
Described device contains 512 words, 24-bits each (12,288 bits = 12 kibibits = 12 kilobits to two significant digits)
It is no longer reasonable to spend as much time to transmit an 80 bit address as 12 kilobits of message information-a 1500 to 1 ratio. ... We have theoretically and experimentally proved that speech can be compressed from the straightforward requirement for 48 kilobit PCM channel capability to 2400 bits by the application of the Dudley syllabic vocoder.
'The Additional Core Storage feature for the IBM 7090 Data Processing System provides a second IBM 7302 Core Storage, increasing the capacity of main storage by 32,768 words. The block of storage represented by both 7302 units is referred to as "main storage unit."'
"Additional core storage provides two methods of using main storage: (1) The 65K mode -- the computer program is enabled to address both of the main storage units, and (2) the 32K mode -- the computer program is able to address only one storage unit, so that main storage capacity available to that program is effectively 32,768 words."
"Core storage units are available in 10,000-, 20,000- or 40,000-character position capacities."
"The matrix switch makes it possible to address any one of the 100 X-drive lines (in a 10K core array)."
"The 40K core array requires 40,000 valid five-position addresses from 0,000 to 39,999."
"This operation check detects errors in programming that cause invalid addresses. Examples: 40,000-and-above on a 40K core array; 20,000-and-above on a 20K core array. On a 10K core array, invalid addresses are detected by the address-bus validity check."
1962
A reference to a "4k IBM 1401" meant 4,000 characters of storage (memory).Sonquiest, John A. (December 1962). "Fixed-word-length arrays in variable-word-length computers". Communications of the ACM. 5 (12). ACM Press: pg 602. The following scheme for assigning storage for fixed-word-length arrays seems to meet these criteria and has been used successfully in working with linear arrays on a 4k IBM 1401.{{cite journal}}: |pages= has extra text (help) Tom94022 (talk) 07:53, 25 January 2008 (UTC)
1963
Ludwig, G.H. (1963). "The Orbiting Geophysical Observatories". Space Science Reviews. 2 (2): pp. 175-218. doi:10.1007/BF00216779. ISSN0038-6308. Retrieved 2007-03-22. The data handling bit rates can be set by ground command at 1000, 8000, or 64 000 bits per second for the EGO missions, or at 4000, 16 000, or 64 000 bits per second for the POGO missions. ... depending on whether the 1, 4, 8, 16, or 64 kilobit rate is in use.{{cite journal}}: |pages= has extra text (help); Unknown parameter |month= ignored (help)
"The computer has two blocks of 4K, 18-bit words of memory , (1K=1024 words) , attached to its central processor"
Maybe 1964?
lists it as:
Bell, C., J. Leng, J. A. Quarrington and P. K. Patwardham, "A Time-Shared Computer for Real-Time Information Processing," Instrumentation Techniques in Nuclear Pulse Analysis, National Academy of Sciences-National Research Council, Washington, D. C. Publication 1184, Report #40, (1964).
Three copies online:
Falkin, Joel (1963). "Sorting with large volume, random access, drum storage". Communications of the ACM archive. 6 (5): pp. 240-244. doi:10.1145/366552.366580. ISSN0001-0782. The Teleregister Telefile data processor includes drum storage whose capacity is far in excess of the requirements for sorting. ... The Telefile data processor provides 16,000 positions in memory, each position storing one binary coded decimal character. A floating accumulator arrangement allows the accumulator to contain any field in memory from 1 to 100 characters in length. All indexing is accomplished programmatically. Input and output tape blocking is fixed at 300 characters per block.{{cite journal}}: |pages= has extra text (help); Unknown parameter |month= ignored (help)
"The main memory is a magnetic core ... The memory unit supplied as part of the basic central processor has a capacity of 2,048 characters, each of which is stored in a separate, addressable, memory location. This capacity may be expanded in modular increments by adding one 2,048-character module and additional 4,096-character modules."
"Random access disc file and control (disc capacities of up to 100 million characters are available.)"
"Up to eight drum storage units can be connected to the Model 270 Random Access Drum Control. Each drum provides storage for 2,621,441 characters, allowing a total capacity of approximately 21 million characters."
"Drums are equipped to store either 64, 128, or 256 data blocks, providing a memory capability of 16384, 32768, or 65536 computer words" (no abbreviations)
1964
" The following is the text of an IBM Data Processing Division press release distributed on April 7, 1964.
System/360 core storage memory capacity ranges from 8,000 characters of information to more than 8,000,000."
IBM 360 model 30 Core Memory Board Plane of 2048 K bits. A Plane has 8 sections of 16 x 16 cores for a total of 2048 K bits per Board / Plane.
this is a 2007 description of an undated artifact (estimated earliest date is 1964) and as such should NOT be tabulated under this heading since there is no evidence that this plane was ever so described in 1964 or at any time prior to 2007! Every other item in this tabulation, is tabulated at a time appropriate label. This item should be removed or moved to a 2007 tabulation. Tom9402220:56, 12 April 2007 (UTC)
'To facilitate understanding of the invention, the main storage area has been illustrated as being of 8K capacity; however, it is to be understood that the main storage area may be of larger capacity (e.g., 16K, 32K or 64K) by storing address selection control data in bit positions "2," "1" and "0" of M register 197, respectively.'
1965
IBM 1620 CPU Model 1 System Reference Library, dated 7/19/65, states:
"A core storage module, which is 20,000 addressable positions of magnetic core storage, is located in the 1620. Two additional modules are available ... Each core storage module (20,000 positions) is made up of 12 core planes as shown in Figure 3. Each core plane contains all cores for a specific bit value."
'Note that "K" as used herein indicates "thousands." Each storage location in the present embodiment includes 64 data bits and 8 related parity bits, as described herein.'
"Thus, if only storage unit 1A were provided, it would contain addresses 0 through 32K; storage IB would include addresses between 32K and 64K, storage 2A would contain addresses between 64K and 96K, ..."
"1401 features supported are advanced programming, sense switches, tapes, multiply, divide, 16K core, and all standard instructions except Select Stacker."
"1401 core is simulated by 16,000 bytes of S/360 core obtained dynamically."
"Enough core must be available to allow at least 70K for a problem program area. If tape simulation is not required, this core requirement may be reduced to 50K with the removal of the tape Buffer area."
U.S. patent 3,638,185 - Filed March 17, 1969 - HIGH DENSITY PERMANENT DATA STORAGE AND RETRIEVAL SYSTEM (earliest Google Patent search containing "kilobyte")
"The data word processor 606 handles the inflow and out-flow of byte-oriented input/output data and interleaved signals at a rate of, for example, 500 kilobytes per second. Instruction processing rates of four to eight per microsecond are required for such a data flow."
"FIG. 2a shows a practical example of an operand address which consists of, for example 24 bits. It is assumed herein that each block includes 32 bytes, each sector includes 1 kilobyte, the buffer memory 116 includes 4 kilobytes, and read data is represented by one double word or 64 bits, as one word in this case consists of 32 bits."
"PDP-11 addressing modes include . . . and direct addressing to 32K words" (Page 2) This appears to be the only use of K in this manual, though; elsewhere sizes are spelled out in full. Contrast the 1973 PDP-11/40 Manual, which defines K as 1024. (Below)
1970
"The following are excerpts from an IBM Data Processing Division press technical fact sheet distributed on June 30, 1970.
Users of the Model 165 will have a choice of five main core storage sizes, ranging from 512,000 to over 3-million bytes. Seven main memory sizes are available for the Model 155, ranging from 256,000 to over 2-million bytes."
"System/360 Configuration: Model 40 with 64K bytes of storage and storage protection"
Contains a lot of examples of "30K", "136K", "next highest multiple of 2K", "The maximum buffer size is 64K bytes" and the like, as well as calculations, which could be used to determine their precise meaning. The letter "K" is also apparently used as a variable in this document??
1972
Lin, Yeong (September 1972). "Cost-performance evaluation of memory hierarchies". Magnetics, IEEE Transactions on. 8 (3). IEEE: pg 390-392. Also, random access devices are advantageous over serial access devices for backing store applications only when the memory capacity is less than 1 Mbyte. For capacities of 4 Mbyte and 16 Mbyte serial access stores with shift register lengths of 256 bit and 1024 bit, respectively, look favorable.{{cite journal}}: |pages= has extra text (help); Unknown parameter |coauthors= ignored (|author= suggested) (help)
1973
Habib, Stanley (October 1973). "Notes from industry". ACM SIGMICRO Newsletter. 4 (3). ACM Press: pg 29. {{cite journal}}: |pages= has extra text (help).
OCEANPORT, N.J., SEPT. 25, 1973 -- A 16-bit minicomputer priced at under $2,000.00 in quantities and a 32-bit minicomputer priced at under $6,000.00 in quantities were introduced today by Interdata, Inc. The 16-bit mini, the Model 7/16, includes an 8KB memory unit in its basic configuration, and will be available for delivery in the first quarter of 1974. The single unit price of the 7/16 is $3,200.00. The 32-bit mini, the Model 7/32, includes a 32KB memory unit and will be available for delivery in the second quarter of 1974. The single unit price of the 7/32 is $9,950.00.
"Direct addressing of 32K 16-bit words or 64K 8-bit bytes (K = 1024)" (Page 1-1) Contrast the 1969 PDP-11 Handbook, which avoids this usage almost everywhere. (Above)
1974
The seminal 1974 | Winchester HDD article which makes extensive use of Mbytes with M being used in the conventional, 10 sense. Arguably all of todays HDD's derive from this technology.
The October 1974 |CDC Product Line Card unambiguous uses MB to characterize HDD capacity in millions of bytes.
1975
Byte Magazine Dec 1975 article on IBM 5100 includes the following:
"User memory starts at 16K bytes in the minimum configuration and can be expanded to 64K bytes (65,536)."
Bell, Gordon (November 1975). "Computer structures: What have we learned from the PDP-11?" (PDF). ISCA '76: Proceedings of the 3rd annual symposium on Computer architecture. ACM Press: pg 1-14. memory size (8k bytes to 4 megabytes).{{cite journal}}: |pages= has extra text (help); Unknown parameter |coauthors= ignored (|author= suggested) (help); Unknown parameter |dio= ignored (help)dio
The first 5 1/4 inch floppy disk drive, the Shugart SA 400, is introduced in August 1976. The drive had 35 tracks and was single sided. The data sheet gives the unformatted capacity as 3125 bytes per track for a total of 109.4 Kbytes (3125 x 35 = 109,375). When formatted with 256 byte sectors and 10 sectors per track the capacity is 89.6 Kbytes (256 x 10 x 35 = 89,600).
"nearly 15 million bytes" with no other abbreviations
1977 Disk/Trend Report - Rigid Disk Drives, published June 1977
This first edition of the annual report on the hard disk drive industry makes extensive use of MB as 10 bytes. The industry, in 1977, is segmented into nine segments ranging from "Disk Cartridge Drives, up to 12 MB" to "Fixed Disk Drives, over 200 MB." While the categories changed during the next 22 years of publication, Disk/Trend, the principal marketing study of the hard disk drive industry always and consistently categorized the industry in segments using prefixes M and later G in the decimal sense.
VAX11/780 Architecture Handbook 1977-78. Copyright 1977 Digital Equipment Corporation.
Page 2-1 "physical address space of 1 gigabyte (30 bits of address)" The initial hardware was limited to 2 M bytes of memory utilizing the 4K MOS RAM chips. The VAX11/780 handbooks use M byte and Mbyte in the same paragraph.
"The RM02 or RM03 Disk Drive (Figure 1-1) is an 80M byte (unformatted; 67M byte formatted) ... storage device ... in the 16-bit format, the maximum storage capacity is 33,710,080 data words per disk pack" (33,710,080 * 16/8 = 67,420,160 8-bit bytes)
"Storage capacity (unformatted)" "67.4 MB", "84.2 MB", etc.
"20,480 Bytes" per track, 4 tracks per cylinder, 808+15 cylinders = 67,420,160 bytes
Sperry Univac Series V77 Microcomputer Systems Brochure, Circa 1978, Printed July 1979
Page 5: Table list memory options as 64KB, 128KB, and 256KB. Memory Expansion is up to 2048KB
Page 9: "Memory for the V77-800 is available in 128K byte and 256K byte increments up to a maximum of 2 megabytes "
Page 21: Moving Head Disks - units up to 232 million byte disk pack systems. Diskette - storage of 0.5 MB per drive.
The following statistics were taken from the Dec 1979 editions of Byte Magazine and Datamation. The first number is the number of articles or advertisements that used any variant of megabyte for HDDs or Main memory while the second number is the total number of times it was used in the advertisement or article.
Variant
Used In Decimal Sense
Used In Binary Sense
million
1 / 1
megabyte
9 / 12
1 / 1
MByte or M Byte
3 /10
MB
5 / 18
Mb
2 / 2
1 / 3
M
1 / 1
Total
20 / 43
2 / 4
1980
Shugart Associates Product Brochure, published Jun 1980 specifies the capacity of its two HDDs using megabytes and MB in a decimal sense, e.g. SA1000 formated capacity is stated as "8.4 MB" and is actually 256*32*1024 = 8,388,608 bytes! —Preceding unsigned comment added by Tom94022 (talk • contribs) 19:01, 5 February 2008 (UTC)
Shugart Associates SA410/460 Data Sheet published Oct 1980 contains capacity specifications as follows:
"User memory: 16KB to more than 512KB", "single-sided 160KB or double-sided 320KB diskette drives"
IBM (July 1982). Technical Reference: Personal Computer Hardware Reference Library (Revised Edition ed.). IBM Corp. pp. page 2-93. 6025008. {{cite book}}: |edition= has extra text (help); |pages= has extra text (help)
"The drives are soft sectored, single or double sided, with 40 tracks per side. They are Modified Frequency Modulation (MFM) coded in 512 byte sectors, giving a formatted capacity of 163,840 bytes per drive for single sided and 327,680 bytes per drive for double sided."
"Total formatted capacity ... is 5/10 megabytes (32 sectors per track, 256 bytes per sector, 612/1224 tracks)"
1983
IBM S/360 S/370 Principles Of Operation GA22-7000 includes as statement:
"In this publication, the letters K, M and G denote the multipliers 2, 2 and 2 respectively. Although the letters are borrowed from the decimal system and stand for kilo 10, mega 10 and giga 10 they do not have decimal meaning but instead present the power of 2 closest to the corresponding power of 10."Tom9402201:22, 24 March 2007 (UTC)
"Capacity, unformatted" 9.57 MB per surface = 10,416 bytes per track * 918 tracks per surface = 9,561,888 byte (decimal MB)
Shugart Associates SA300/350 Data Sheet published circa Nov 1983 (one of the first MIC standard 3.5" FDDs) contains capacity specifications as follows:
Macintosh System is an early, if not the earliest, operating system consistently using SI prefixes in a binary sense.
1984 Mac Screenshot
Apple uses SI prefixes in a binary sense, the 400 "KB" Macintosh disk was 800×512 byte sectors or 409,600 bytes = 400 KiB total. In the above illustration the disk has 232K in use and 167K (available) and 1 K unexplained (probably rounding error)
The image shows "232K", not "232 KB". Was the floppy disk actually advertised as "400 KB" or "400K"? — Omegatron01:41, 14 May 2007 (UTC)
FWIW, in the original 1984 Apple , page 8 Apple used "400K". On the other hand the February 1984 review describes it as "400K bytes". K clearly means Ki to Apple. Tom9402201:23, 29 June 2007 (UTC)
Similar usage in "ProDOS Technical Reference Manual" (c) 1985, p. 5 & p. 163
Digital Large System Mass Storage Handbook (c) dated Sep 1986
"GByte: An abbreviation for one billion (one thousand million) bytes." p. 442
"M: An abbreviation for one million. Typically combined with a unit of measure, such as bytes (MBytes), or Hertz (MHz)." p444Tom9402221:42, 16 June 2007 (UTC)
ST125 listed as 21 "Megabytes" formatted capacity, later document seems to confirm that this is decimal
Disk/Trend Report - Rigid Disk Drives, October 1987
First use of GB in a decimal sense in this HDD marketing survey; Figure 1 states "FIXED DISK DRIVES more than 1 GB" market size as $10,786.6 million.Tom9402221:42, 16 June 2007 (UTC)
Webster's Ninth New Collegiate Dictionary (1987) has binary definitions for kilobyte and megabyte.
kilobyten (1970): 1024 bytes
megabyten (1970): 1,048,576 bytes
1988
Imprimis Wren VII 5¼ Inch Rigid Disk Drive Data Sheet, printed 11/88
IBM, Entreprise Systems Architecture/370, Reference Summary (GX20-0406-0), p50 (the last page), has a two table, one to recap the decimal value of power of 2 and 16 to 2^60 , and one that read:
Symbol | Value
K(kilo) | 1,024 = 2
M(mega) | 1,048,576 = 2
G(giga) | 1,073,741,824 = 2
"Imprimis and Maxtor are the only two drive makers to offer the new generation of drives in the 1.5GB capacity range ..."
"IBM, Hewlett-Packard, Fujitsu, Toshiba, Hitachi and Micropolis are expected to enter the market for 1.5GB capacity ..."Tom9402221:42, 16 June 2007 (UTC)
"Unformatted Per Drive 1,205 MB" (133.85 MB per surface, 9 read-write heads)
2001
IBM, z/Architecture, Reference Summary, page 59, list the power of 2 and 16, and their decimal value. There is a column name 'Symbol', which list K(kilo), M(mega), G(giga), T(tera), P(peta) and E(exa) for the power of 2 of, respectively, 10, 20, 30, 40, 50, 60. - Shmget01:32, 28 May 2007 (UTC)
2007
Status quo:
Windows Vista uses the KB = 1024 bytes, MB = 1048576 bytes convention for file and drive sizes, and for data rates
BitTornado uses IEC prefixes for file sizes and standard SI prefixes for data rates
Graphical timeline
Earliest and latest instances of each notation that appear in the above list. This is not for the article, but just for our own internal use here. It's not actually accurate, since we haven't found everything yet, and is too close to original research to put in the article. (I guess it would make more sense to track each thing, like hard drives/memory/data rates, separately):
JEDEC
I believe JEDEC is a minor organization compared to the ten or so IEC prefix supporters mentioned in this talk page (try the google test, for example), and is thus given undue weight in the article. I am fairly sure, given talk going on WP:MOSNUM talk, that any attempt to remedy the situation would be met with an edit war, so I'm just going to add a POV tag to the section describing what might be wrong with it. If I was pessimist with this, you have my permission to remove the tag together with the section. --SLi20:12, 12 April 2007 (UTC)
I agree that the JEDEC section as presented is POV and therefore that the tag should not be removed. As a remedy I suggest that the section be shortened and an equally weighted IEEE section be added.Tom9402221:23, 12 April 2007 (UTC)
Isn't the IEEE already covered by the IEC section? The only difference is the abbreviations for bit and byte, which can be covered in the IEC section. If this is decided to be undue weight, we should just remove the section, but I'm not totally convinced it is undue weight. — Omegatron21:45, 12 April 2007 (UTC)
The difference between IEEE and JEDEC is glaring. Comparing them is really like comparing a Porsche and a Lada. IEEE is big and known, JEDEC is small and obscure. Presenting the two as somehow equals is biased. For example, from the Google test (which I agree is not entirely without problems): IEEE, 90.7M hits; JEDEC, 1.46M hits. See the difference between the two? --SLi22:05, 12 April 2007 (UTC)
JEDEC is important in its own rite, but it certainly doesn't have the clout of IEEE. Heck, even IEEE isn't able to enforce preferred style standards (pick up a copy of Spectrum or an IEEE computer society publication and see if you can find 'mebi' :). My issue with all this JEDEC nonsense is simply that they never claim to define how terms should be used by others; they just follow good typical technical writing practices and define how they themselves use terms. How this can be taken as an endorsement of common usage or an active denial of the IEC prefixes is beyond my comprehension (especially in light of their acknowledgement in a recent standard). The IEEE has actually explicitly endorsed the IEC prefixes and explicitly recommended their usage by electrical and computer engineering professionals. -- mattb@ 2007-04-12T22:40Z
This is the second sentence of the Binary prefixes article. "When discussing things that naturally come in powers of two (such as computer memory sizes)." The organization that develops the standards for semiconductor memory should be relevant to the binary prefix article. You cannot purchase a computer that does not use JEDEC standard memory. -- SWTPC680001:55, 13 April 2007 (UTC)
This still doesn't address the issue that JEDEC doesn't, in fact or in theory, set unit conventions. -- mattb@ 2007-04-13T02:21Z
The companies that make binary things that Misplaced Pages readers buy use JEDEC standards. Someone might want to know why every memory module is labeled with 512MB or 1GB. -- SWTPC680015:20, 13 April 2007 (UTC)
Isn't that why we have section 5 "Usage notes"? Since JEDEC is a semiconductor trade organization and Standard 100B.01 applies the binary definition "as a prefix to units of semiconductor storage capacity" it seems that a short paragraph is appropriate for section 5.2. Perhaps we should rename 5.2 to Semiconductor storage instead of Computer memory :-)Tom9402217:24, 13 April 2007 (UTC)
Some Background
"The JEDEC Solid State Technology Association (Once known as the Joint Electron Device Engineering Council), is the semiconductor engineering standardization body of the Electronic Industries Alliance (EIA), a trade association that represents all areas of the electronics industry."
"The Electronic Industries Alliance (EIA) is a national trade organization that includes the full spectrum of U.S. manufacturers. The Alliance is a partnership of electronic and high-tech associations and companies whose mission is promoting the market development and competitiveness of the U.S. high-tech industry through domestic and international policy efforts. EIA, headquartered in Arlington, Va., comprises nearly 1,300 member companies whose products and services range from the smallest electronic components to the most complex systems used by defense, space and industry, including the full range of consumer electronic products."
"Accredited by the American National Standards Institute (ANSI), EIA provides a forum for industry to develop standards and publications in our major technical areas: electronic components, consumer electronics, electronic information, telecommunications, and Internet security. The department also administrates the EIA Technology Council; a body of member companies that explores how emerging technologies potentially will affect segments of the electronics industry. The Council is also involved in creating a technology roadmap for the Alliance."
The Electronic Industries Alliance (EIA) / JEDEC has agreement with the IEC to produce Publicly Available Specifications
Microprocessor companies like AMD and Intel are members of JEDEC and to ensure their processors can utilize the latest memory systems.
All of the semiconductor memory manufactures are members of JEDEC. Here is was Micron says about the upcoming DDR3 memory standard.
"Evaluation samples of Micron's leading-edge 1Gb DDR3 components are available to select customers with production expected to begin early next year. Micron's 1Gb DDR3 components will be available in various output configurations (x4, x8 and x16), and will be fully compliant to the most recent JEDEC DDR3 specifications (JEDEC is the leading developer of standards for the semiconductor industry). These components will support module densities from 512 megabytes (MB) through 4 gigabytes (GB) and a variety of module types including FBDIMMs, UDIMMs, SODIMMs, and RDIMMs."
Why semiconductor companies use JEDEC
JEDEC is the standards organization of choice for semiconductor companies because for the flexibility and speed of the process. JEDEC Standard 21 for Configurations for Solid State Memories is published in a 3-ring binder that can be updated monthly. Each semiconductor company (and other members) gets a vote. In IEC each country gets a vote and the process takes years.
Solid State Times
OCTOBER, 1999
Volume 1, Issue 4,
Page 2
JEDEC has entered into an important new Memorandum of Understanding with the International Electrotechnical Commission (IEC) to expedite the process of moving semiconductor standards into the international marketplace. The agreement, which became effective September 1, 1999 is part of the IEC-PAS (Publicly Available Specifications) program. The program’s objective is to speed up the international standards process in areas of rapidly developing technology. It is intended to deliver information to the marketplace quickly since PAS are de facto standards. If PAS standards are approved and accepted by the international community, they ultimately will become IEC international standards.
Under the recently signed agreement, JEDEC will identify the specific standards it wishes to submit for PAS consideration. If the IEC accepts the JEDEC standard as a PAS to be entered into their Program of Work (PW), the standard will be published under the joint logos of JEDEC and the IEC, and royalties on the sale of the PAS will be divided equally between the two organizations. If the IEC later adopts the PAS as an IEC international standard, the standard will be published under the IEC’s sole logo and the division of royalties will end.
A significant feature of the new agreement is the fact that JEDEC will continue to have the right to continue developing the relevant technology, to revise and modify the underlying JEDEC standard, and to continue publishing the underlying JEDEC standard on the World Wide Web.
Solid State Times
JANUARY, 2000
Volume 2, Issue 1,
Page 10
The IEC works differently than the JEDEC committees where it is one country one vote instead of the JEDEC one company one vote. This voting practice does not favor the larger Semiconductor Countries over the smaller ones. Many smaller countries like the IEC because they can voice their opinion without being overpowered by the larger countries. The IEC normally meets twice per year to discuss new proposals and to review the present balloting results.
The IEC has 4 basic stages of balloting which include New Work Item Proposal (NP), Committee Draft (CD), Committee Draft for Vote (CDV), and Final Draft International Standard (FDIS). Since the IEC meetings are International and their meeting schedule is every 6-months, the balloting cycle can easily be 2-3 years in length. The IEC management group is working on ways to reduce this cycle time in 1/2 in order to meet the needs for the Semiconductor Market.
JEDEC Solid State Technology Association, the semiconductor engineering standardization body of the Electronic Industries Alliance (EIA) in Standard 100B.01 defines in the binary sense K, M and G as prefixes to units of semiconductor memory, noting that these definitions are “only included to reflect common usage” and that in accordance with IEEE/ASTM SI 10-1997, “This practice frequently leads to confusion and is deprecated.”
Much better, though I still don't particularly think the JEDEC needs its own section in this article. Still, your text is a marked improvement. -- mattb@ 2007-04-13T04:58Z
Good point, perhaps if Omegatron agrees we can put it into section 5.2, Computer memory. Alternatively, we could add a short IEEE section, more or less analogous to JEDEC. I'm open. Tom9402205:20, 13 April 2007 (UTC)
It appears that Omegatron added the JEDEC section on 7 April. On 12 April Sli flagged it as POV; to which I agreed. Sli has already given his permission to remove the POV. I'm not sure exactly how Misplaced Pages would want us to adjudicate this issue, but I think if Omegatron agrees to my proposed changes (or something similar) then we can move on.Tom9402216:35, 14 April 2007 (UTC)
If you're going to make such an implication against others, why haven't you yet answered the charge that the JEDEC doesn't actually standardize unit convention? The JEDEC doesn't claim to standardize more than semiconductor memory, why do you persist in the argument that their usage of common terms is prescriptive? I've pointed this out many times to you and have yet to see you respond. This has been a weak argument since the moment you brought it up and most of your claims are based in total misunderstanding of what the JEDEC does and what standard documentation practices are. -- mattb@ 2007-04-13T14:14Z
The docuements produced from the JEDEC do say things like "JEDEC Stadards document", that is prescriptive. i.e. "Sanctioned or authorized by long-standing custom or usage.". Fnagaton14:33, 13 April 2007 (UTC)
The standard document itself does not include unit prefixes, though. It merely defines them as they are used by the document as is standard technical writing practice. -- mattb@ 2007-04-13T15:03Z
The standards document defines them. It doesn't say "thou shalt only use this for verily it is thus" for each definition, but that is the danger when reading something out of context and in isolation of the whole document. By being defined for use in the standards document that appears to be good enough for all of the other documents that referene it use use those terms. Look at the language used in document JESD100B.01:
Page 1 : "JEDEC STANDARD"
Page 2 : "No claims to be in conformance with this standard may be made unless all requirements stated in the standard are met."
Page 9 : "TERMS, DEFINITIONS, AND LETTER SYMBOLS FOR MICROCOMPUTERS, MICROPROCESSORS, AND MEMORY INTEGRATED CIRCUITS"
(The caps is how the text is displayed in the document.)
That's actually prescriptive language, especially page 2.
At least I've not seen any actual use of the binary prefix terms in any documents from the JEDEC despite extensive searches looking for those terms, meanwhile I have seen plenty of kilo-, mega-, KB, MB used. Fnagaton15:30, 13 April 2007 (UTC)
Uh, that's like saying that a standard which defines the words should and must (a common practice) for its internal usage standardizes the usage of these words. That's just not how it works. --SLi16:19, 13 April 2007 (UTC)
If that's what the argument hinges on, we can always email the JEDEC and ask whether a semiconductor device would be considered out of spec with their standards if they were marketed using IEC prefixes. -- mattb@ 2007-04-13T16:43Z
I've been told sending an email and then trying to use the reply would be WP:OR and is not allowed. For the result of that email to be accept as a reliable source it would need to be published by a few reliable entities with editorial control. Fnagaton11:26, 14 April 2007 (UTC)
That's not a reason not to ask. The answer can be reported here and can inform our judgement even if it cannot go directly in the article. More information is always good. Better information is always good. And the inquiry might even spark publication; whoever answers might decide that it would be a good idea to clarify this in some press release or article or in a website FAQ or something like that. Dpbsmith(talk)14:44, 14 April 2007 (UTC)
Also, the standard says in the footnote that they are deprecated (or at least quotes a major standard saying so, without any sign of disagreement with that). Don't you think this is of any importance at all? But I do understand you, it's certainly tempting to have selective vision when that's the only way you can find support for your POV. --SLi16:51, 13 April 2007 (UTC)
Well it's not the JEDEC explicitly saying they are deprecated it's the quote in the footnote from the IEEE. So what it actually means is that the terms kilo, mega are defined in the standard and there is a footnote. The question would be to ask the JEDEC if it is standards correct to use the terms kilo,mega. I've highlighted the wider picture here. You are the one who is being selective by only fixating on tiny portions of standards documents or tiny fragments on of the MoS when you thnk it suports your point of view. Fnagaton10:10, 14 April 2007 (UTC)
As I read the JEDEC document, the footnote pretty clearly states that the binary IEC definition is "an alternative definition" to the "common usage" definitions therein. Under the definition of mega it tabulates the alternative (IEC binary) definitions. So it seems like we don't have to ask JEDEC anything, Ki, Mi, etc are permitted under this specification, at least as I read it. Tom9402216:35, 14 April 2007 (UTC)
As I read the standard using kilobyte and megabyte are acceptable terms to use in a document that wants to be notd as following the standard. Fnagaton19:24, 15 April 2007 (UTC)
Federal Trade Commission recognizes JEDEC "In the Matter of Rambus, Inc." Docket No. 9302 is the largest standardization case the Federal Trade Commission has brought in a decade. The opinion cites JEDEC as being "an industrywide standard-setting organization" in the opening paragraph. The FTC has spent the last several years supporting JEDEC efforts to promulgate memory standards for RAM. RAM is that thinging consumers put in their computers and it is measured in binary units. The Binary Units that all producers of DRAM use is MB and GB (Mb and Gb for bits). They use the JEDEC standards not the esoteric IEC standards.
By that way, if you read all 120 pages of the FTC ruling they never mention that consumers are confused by memory size. -- SWTPC680017:30, 14 April 2007 (UTC)
Was your first question sarcastic? If not, I'm confused. If so, I said right in the image description that it's cluttered because of all the partitions and should be replaced by something else eventually. But I don't want to rearrange my backup drive just to take a screenshot. Maybe it could be photoshopped? — Omegatron18:00, 13 April 2007 (UTC)
Images
We should have images from other OSes besides Linux and XP. Those are just the ones I have.
We shouldn't have too many images, so replacing the XP total drive size image with an equivalent from OS X is fine with me
I kind of wanted to show the same physical 160 GB drive in several different contexts, though, to illustrate how it differs, so I would prefer if the 160×10 examples aren't replaced.
Of course, if someone else wants to do the same thing I did, and show the outside of an external hard drive box, format it with two or three partitions, and then show how it appears in XP, Vista, Win98, Ubuntu, OS X, etc etc. that would be even better. — Omegatron17:59, 14 April 2007 (UTC)
I agree that we shouldn't have too many images and I think we have already reached that point! I'm not sure we need any other OS's beyond those necessary to illustrate the various usages. That is, the relevant minimum set of images is using one drive and showing how it is displayed in "SI GB", "GiB" and "binary GB" by various OS's. Using one drive and showing the various ways it can be displayed really illustrates the source of consumer confusion. From an historical perspective, the early usage, i.e., currently 128K MAC System is also relevant. That makes 5 images:
any GB drive,
OS display of same drive in GB
OS display of same drive in GiB
OS display of same drive in binary GB
earliest example of volume OS with binary SI units
Omegatron has done a great job with his 160 GB drive in XP, Linux and Gnome (although arguably Gnome is not an OS). IMHO, all the rest are redundant with little informative value and should be dropped or at most placed in another article, e.g. Examples Of Binary Prefix Usage (including the 128K MAC if someone comes up with an earlier and more significant example).Tom9402219:04, 14 April 2007 (UTC)
I thought it was important to show memory, hard drive, and data rate measurements, too, though, as examples of common usage. — Omegatron21:50, 14 April 2007 (UTC)
From the big picture perspective, there appears to be two issues, 1) usage by computer memory vs. the Rest Of The World, and 2) confusion between disk drive specs & OS display. In order to keep the article to a reasonable length, I suggest we just highlight with the minimum number of illustrations to cover just these two issues. The 5 images above cover the disk issue, so adding one more image for memory is a good idea, but shouldn't we stop at that point - after all, just about every other unit system is SI (the last kilo I bought had 1,000 grams :-)? Tom9402222:03, 14 April 2007 (UTC)
About the text A programmer could easily mentally calculate that "8 kay times 4 kay is 32 meg" and get it exactly right, within this powers-of-two only context. This convenience is likely one source of originally adapting "Kilo" and "Mega" from SI as shorthand for 1024 and 1,048,576, as specialized jargon within a segment of the industry..
I'm not sure I understand this. What does it have to do with what terms are used? AFAICS it works just as well with kibi and mebi. --SLi00:40, 15 April 2007 (UTC)
It does now, but kibi and mebi didn't exist then. The text is saying that calling 1024 a 'K' was convenient. Quirkie00:09, 30 April 2007 (UTC)
I agree - It's a strange example that works both with decimal and binary units. It would have been more relevant for instance to state that a programmer easily can calculate that "128 buffers of 8 K each would take up exactly 1 meg". —The preceding unsigned comment was added by 85.112.166.110 (talk) 12:27, 14 May 2007 (UTC).
Inconsitent texts
The article Megabit states 'The megabit is a unit of information, abbreviated Mbit or sometimes Mb.' The template with the table of quantities of bits clearly shows that the abbreviation is Mb and not Mbit. Shouldn't the statement be reversed so it would say: 'The megabit is a unit of information, abbreviated Mb or sometimes Mbit.' ? —Preceding unsigned comment added by 145.7.182.13 (talk) 09:15, 29 October 2007 (UTC)
Fnagaton's edits
Fnagaton, you removed "such as computer memory sizes", and added "rather than using the system described below", claiming that this makes the intro more neutral.
Computer memory is the most obvious example of a use of binary prefixes, and I can't fathom how mentioning this would be considered biased. What does this bias the intro in favor of? And there are more than one "systems described below". Which one should the reader assume you are talking about? How is removal of this phrase biased?
it says "Apparently, some computer programmers were unaware that disk drive manufacturers used the SI notation when specifying and/or advertising capacity of their hard disk drives"
This is competly bogus. There is no chance that any developers, then or now, was not aware of the practice of the drive manufacturere. by 1984 they had all switch to decimal prefixed Bytes... Practically, we (then and now) represent memory size and file size with memory unit, and calculating 'decimal' unit implied a binary to decimal conversion that is not trivial (converting a number of byte in KB is a matter of shifting right by 10 bits, which is a single and fast assembler instruction. dividing by a 1000 was a much more expensive proposition CPU wise ( [http://home.comcast.net/~fbui/intel/d.html#div 13 times more cycles for a 386).
Developer back then knew just as much as hard drive manufacturer knew that KB/MB... was used by said developers and memory manufacturers to mean 1024...
Furthermore, these were not ans still are not 'SI' notation. MB and GB (but not KB) can possibly be described as using a 'SI prefix', but that is not a 'SI notation' by any stretch of the imagination. -- Shmget07:57, 8 June 2007 (UTC)
then it says "This mixed presentation..."
What mixed presentation ? The presentation is not mixed, as the text explain later "would report the space available on a 41,959,424 byte hard disk drive as 40 MB". that is not 'mixed representation', that is a consistent presentation with all the other size in the OS. a 'mixed' representation would be to say that a a disk as 40MB of space of 40,000,000 and then send a message saying that there is 150 KB left after copying 38 1MB-file on it.... or to say that the hibernate file to swap 256MB of RAM to disk is... 268.43 MB !!!! -- Shmget07:57, 8 June 2007 (UTC)
If you contend the programmers willfully ignored the HDD manufacturers specifications and advertisements, would it be less POV to say, "For unknown reasons, some computer programmers chose to ignore the disk drive manufacturers practice of using SI prefixes when specifying and/or advertising capacity of their hard disk drives"
I content that, for the purpose this enciclopedic article, it is irrelevant who ignored what and why. One could just as well turn the statement around and say that hard drive manufacturer chose to ignore the usage of computer memory, file size and floppy disk size... But either way you turn that phrase would be POV. I content that that phrase - or the same phrase turned around, is useless and bring nothing to the article but some POV... -- Shmget06:35, 9 June 2007 (UTC)
I hope you are not seriously contending that it was to save a few machine cycles.
First of all, in the relevant time period, at the machine level, capacity was available as a string of Hex characters.
No kidding, you mean that at a 'relevant period', had disk didn't have Head, Cylinder and Sector but just a 'capacity as a string of Hex characters' ?
No programmer in his right mind would internally represent any measure in a mixed notation of decimal characters with binary prefixes.
You are right, and they don't, there is no mixed representation, internally there are Bytes, or power of two of bytes... taht's it.
I don't know of an assembler or compiler that supports prefixes of any sort.
In so called 'binary unt' that is call 'shifting'. For instance an inode contain a block-size and a number of block. the block-size is typically 5112 bytes. So when you want the size in KB you just 'shift right' the number of block by 1 bit. (See Posix description of '-k' option of du or ls for some discussions on that )
When I use them in my programs I define them as constants and use them consistently, i.e. using pseudo-code
decimal decMyNumber = 16777216m;
deximal decMega = 1000000m;
hex hexMyNumber = F00000x;
hex hexMega = 100000x;
decMyMegaNumber = decMyNumber / decMega;
hexMyMegaNumber = hexMyNumber / hexMega;
you would never see a
whatTheHeckIs = decMyNumber / hexMega;
It would be all Hex internally!
You confuse the bottle and the wine. you are confusing a string that represent a number and the binary representation of that number. that being said the example above use 'division', but really hexMyMegaNumber = hexMyNumber / hexMega; is number_of_megabyte = number_of_byte >> 20; (BTW, what programming language use suffix for numeric constant ??? I mean I have seen some variety with the prefix used to represent hexa constant, but I don't recall ever seen a programming language that used a suffix for that - and for good reason, that would make parsing unnecessarily painful) -- Shmget06:35, 9 June 2007 (UTC)
The conversion would be for display purposes and for that purpose the difference between a binary shift followed by a hex to decimal conversion is not much more than a hex to decimal conversion followed by a decimal shift. After conversion with data in a BCD format the shift is a byte shift (4 bit) shift. There is no difference in time to speak of (3 vs 4 ?) and if u just move a pointer, no time at all.
"if u just move a pointer, no time at all." ??? euh ? how exactly to you 'move a pointer' to get rid of least significant digits ? BTW shifting 'before' converting to ascii reduce the number of digit to convert. so there IS a difference. You alos miss the point that these size are not just there to be display, that they are often already expressed in power of tow, like the number of 512 bytes blocks... for that specific example: If I have the number of block of a file, all I have to do is: nb_of_KB = (nb_blocks >> 1) and then bin_to_ascii(nb_of_block). To display that using 'decimal' unit, I would need to do nb_byte = nb_block << 9 (which mean that I need a 64 bits register or I am limited to (2^32 - 1) for my file size, then calculate nb_kB = nb_bytes / 1000, and finally bin_to_ascii(nb_kB). Now imagine that you actually have a 8086 a 6502 or a 8086 processor and picture doing the later with these 8/16 bits register processor.... (the former is quite easy). -- Shmget06:35, 9 June 2007 (UTC)
The mixed presentation is the mixture of a decimal digits with a Binary Prefix Abbreviation!
What are you talking about ? I truly don;t undertand what you pint is. For one thing I never use 'binary prefix' nor does any of the operating system mentionned here. they used KB,MB,GB, these are Units, that have a value of respectvely 2^10, 2^20 and 2^30 bytes. For example If I say I am 80 years old or I am 960 months old, I am using 'decimal' number (as in 80 and 960) with some unit... how is that a mixture of anything ? is it because some else may chose to say that I am 2.524 Gs old ? -- Shmget06:35, 9 June 2007 (UTC)
The fact that the unit abbreviation B is not SI recognized is irrelevant.
When one side insist that they have the 'true'(tm) meaning on the ground of the holy BIPM, then one cannot just turn around and in the very same unit commit BIPM blasphemy. So yes it is very relevant to this whole 'fuss' by the hard drive industry.
And your point about k v K is really meaningless with regards to HDDs, I don't think there has ever been an HDD measured in k or K by the manufacturers. The first one was 5 million characters.Tom9402221:25, 8 June 2007 (UTC)
I'm sure you noticed it wasn't 5 MB. But the point is that contrary to what the current formulation says, system programmer where in no what obligated nor even remotely expected to adopt the hard-drive manufacturer definitions, quite the contrary, having done so would have created internal inconsistency. you would have had displayed a 300 'MB' (hard-drive manufacturer definition) drive containing a 256MB file size, containing the dump of you 256MB memory, but still you would have only 30 MB left of that drive... Now THAT would have been mixed and confusing. -- Shmget06:35, 9 June 2007 (UTC)
RAM storage capacity is a result of the number of address lines. Disk storage capacity is a result of tracks, sectors, and platters. Most Flash memory emulates disk storage. (There are exceptions but this covers most of the cases.)
It is a very rare solid state memory whose size is not a binary multiple. Intel's first dynamic RAM had 1024 bits. Formatted disk storage has always had capacities unrelated to binary multiples. It would be a dim witted computer programmer that did not know the difference.
There would be a case for consumer confusion among English majors, but not for computer programmers. The current statement in the Binary Prefix article is absurd. -- SWTPC680005:08, 12 June 2007 (UTC)
The 'as early as 1974' claim
the link show few things.
The text use, int he actual specification of the different model, unit like K and M for data rate (see page 6, bottom: "Rata rate: 1.2M bytes per second" (note that they do NOT use MB, but still use M), Yet the Capacity is always given as n x 10 bytes, never has n MB or even n M bytes, which surely would have been more convinient. That shows that 1/ They expected the reader to be familiar with M, and bytes since they use them for data rate, and 2/ they chose not to use such notation to describe the capacity of their product, using a n x 10 bytes notation instead. In fact the only place where 'MB' is present is on the first graphic—presented as the first page in this pdf, although the next page is page #6— not even on the scale which read 'CAPACITY (million bytes)', but on top of each bar of the bar graph. That typography not being re-use anywhere in the document hint that is more an aesthetic choice made by the graphic design people rather than a policy, engineering choice or a customary usage.
If anything this document actually show that the hard drive industry, at that time, did not have the habit of referring to the capacity of their device with MB, metric or otherwise. -- Shmget10:21, 14 June 2007 (UTC)
Thanks for acknowledging that in 1974 CDC used MB in a decimal sense to characterize their product line. The Disk/Trend report establishes that it was in general use by 1977. What is the earliest use you can find of an OS using MB in binary sense?Tom9402217:56, 14 June 2007 (UTC)
No need to thank me for something I haven't done.
"What is the earliest use you can find of an OS using MB in binary sense?" What is the earliest you can find of an OS using any kind of metric prefix, for memory size ? for file size ? for file system size ? , for device size ? What does Posix says about, for instance, du and df, and the meaning of -k in their command line ?
How was block device size represented in Unix in 70's,80's,90's.... (hint that involve a 'block', that happen to be a power of 2 in size, typically 512 bytes). Btw, who did those 'confused' consumers sued exactly ? How has to put a footnote to explain what the heck they mean on their package ? And the cherry on the cake. How does Hard drive manufacturer indicate the amoung of Cache Memory in theire drive ? you guessed it in MB, the real ones, not the 'metric' ones. When they were selling disk in the megabyte ranges then MB should be read as metric MB, but as soon as they shift to the gigabyte range, then they switch and start using MB in it's common sens, like everybody else. No wonder they got sued. -- 20:41, 14 June 2007 (UTC)
Posix is 1988. If that is your earliest date I rest my case.
Posix is just the setting in stone of what has been common use. Posix didn't 'invent' any things in that regard, just codified it. -- Shmget06:26, 15 June 2007 (UTC)
BTW, MS/PC DOS FDISK at some point added (not later than DOS 6 in 1993) a line "1 Mbyte = 1084576 bytes" but that is well after the phrase Mbyte appeared in the Memorex annual reports and elsewhere in the decimal sense. BTW, I did look into some UNIX's, MVS, IBM DOS, CPM, Apple DOS and others OS's and concluded they displayed digits without prefixes.
For one thing, these 'digits' are never 'prefixed'. when did you see "MB256" ? But, sure Unix display the number of 512 bytes block without 'prefix' nor suffix for that matter. and df -k display a number of KB without suffixing... and your point is ? How exactly does it change the fact that file size are expressed using power of two multiple unit ? How does it change the fact that, from an operating system point of view, every structures on disk or in memory are power of two in size. a block is 512 bytes, most system use a paging mechanism based on 4K pages, The minimal unit of allocation is a power of two (depend on the file system, but goes from 1K to 32, 64K...). The only time in this world that a normal human being is confronted with a size in metric MB/GB is when they read the box and the marketing fliers of a hard drive... thankfully, as soon as the said hard drive in mounted and formated, that is just a bad memory..... and what the OS is telling you is : How many 1GB file can I store in this disk! that is the only thing a user care about, hard drive are used to store files in them and file size are NOT in metric MB/GB.
Don Rumsfeld got to answer a question with a series of rhetorical questions and you see where that got us. So if you don't have any serious information, I suggest u stop wasting our time. Tom9402221:58, 14 June 2007 (UTC)
You refer to yourself with a plural now ? Or you have been mandated to speak for a 'group' of some kind ? These questions are not rhetorical, except to the extent that you already know the answer to them, just conveniently ignore them (that also fit well with the notorious character mentioned above), but we should probably stay away from political references, or someone will have to invoke Godwin's Law pretty soon -- Shmget06:26, 15 June 2007 (UTC)
Again we agree that UNIX did not display any prefixes (suffix, if you prefer) until very late with regard to the HDD industry's general use of MB in the decimal sense. BTW, it is not just the HDD companies being sued, please check out the Dan Sep 2003 litigattion.
you mean :"In September of 2003, Lanchau Dan, Adam Selkowitz, Tim Swan and John Zahabian filed a lawsuit against Dell, Inc., Apple Computer Inc., Gateway, Inc., Hewlett-Packard Co., IBM Corp., Sharp Corporation, Sony Corp. and Toshiba Corp claiming their advertising deceptively exaggerates the real capacity of their hard drives." , yes point in case. -- Shmget23:33, 15 June 2007 (UTC)
We agree again, Dell, Apple et al, at least within some portion of their company think the prefixes M and G have a decimal sense. The fact that they are sued doesn't make the plaintiff correct; it might be interesting to see how they answered the complaint.Tom9402217:43, 16 June 2007 (UTC)
Certainly, 'some portion of their company' i.e. the marketing dept, tend to use whatever look better. I would certainly agree that Apple et al. should have marketed the hardrive capacity with a unit consistant with their O.S. i.e. having a 152.5 MB dirve not a 160 metric MB.
"it might be interesting to see how they answered the complaint." Yes, I agree. I've looked for it, but I was not able to find readily accessible info in this. There are many press article about the complaint, but nothing about how it was disposed (settlement, summary judgment, trial ?... I could not even find the case number. If somebody has a subscription of FindLaw or something like that, it would be interesting to get the details... well, interesting for the sake of curiosity) -- Shmget23:24, 16 June 2007 (UTC)
If you have any facts, instead of guesses, POV and rants about the display by OS's and utilities of MB (and then GB)
You are the one ranting about how OS's developer, the IC industry,.. did not comply with the hard drive industry wishes.
I, and I suspect any other reader of this thread, would appreciate it; otherwise you are wasting our time.Tom9402218:51, 15 June 2007 (UTC)
I just went thru the timeline above. There is not one mention of an OS's or utility's usage of MB. I believe somewheres on this page u state, "Of course it matter, that is the ONLY thing that matter here. the significance of 'MB', ..." I'll give u Windows 3.11 in 1993. Can u find any such usage prior to 1990?Tom9402219:05, 15 June 2007 (UTC)
Since you insist, screen capture of an Apple IIgs, Prodos16, 1987. Just because you selectively looked for illustrations of one side of it, doesn't mean that there is no evidence of the other side.... And as far as 'guesses' goes. I actually owned and operated computers during the whole period. This is not 'history' to me, I lived through it.
also: In "ProDOS Technical Reference Manual (c) 1985 Apple", page 5: "1.1.2 Volume and File Characteristics ... Maximum capacity 32 megabytes on a volume ... afile can hold up to 16 megabytes of data" page 19 : "The largest possible standard file has a master index block that point to 128 index block. Each index block point to 256 data block and each data block can hold 512 byte in data" (just in case you try to argue that the 16 MB above are metric megabyte....), p163 "A tree file contains more than 128K bytes, and less than 16M butes ($20000 < EOF < $1000000)", p171 " B.4.2.1 The sstorage-type attribute: ... $3 indicate a tree file entry (127K < EOF < 16 M bytes).
Thanks for moving the binary MB timeline to 1986. I had guessed that Apple was the first OS to use MB but didn't find any examples. That still leaves 10 year gap between the HDD industry's use and the advent of binary MB. Tom9402217:38, 16 June 2007 (UTC)
Actually, If you want to move the timeline, you might want to concentrate of the IC industry. IIRC the first megabyte-memory chip came out in 1984. The first Megabit memory chips had to come earlier than that -- Shmget23:24, 16 June 2007 (UTC)
That being said, the crux of the argument is that it would have been non-sens, and for that matter extremely confusing, for an OS to start using metric MB.. that would have resulted in the generalization of the notorious 1.44MB floppy hybrid (1440 K). Again memory is in KB/MB/GB. Files use the same unit for obvious technical and practical reason. The size of a physical disk, one way or the other, only matter when you buy it, after what that matter is how much of a file you can put on it. From the day computer were based on binary state, the unit of size was bound to be using power of two units... and that is exactly what happened. The so called 'consumer confused', in all the example given on this page, is limited to consumer being confused about the hard drive manufacturers notations, not about the rest of the computing industry -- Shmget
You make your POV clear. Your whole argument about things fitting is specious. By the 1980's, internally everything was Hex without prefixes (suffixes, if you prefer - please don't get semantical, we are talking about the M as in both 160M and 160 MB).
I have the souce of the Aplle II Monitor, and I beg to differ. Hexadecimal constant were all prefixed by '$', and decimal constant were used.
Decimal was rarely if ever used internally except in anticipation of display; that's because consumers (as opposed to programmers) understand decimal.
You are playing on the sens of 'decimal'. using it to qualifiy a sequence of number or to qualify a metric unit as 'decimal' unit. These are two different concept. Just because I count eggs using the unit 'dozen', does not imply that I should display the number of dozen in base twelve. -- Shmget23:24, 16 June 2007 (UTC)
If a programmer worried about file space, he/she converted file size to number of blocks
That is he take the size and shift it by 9 bits.. or he take the size in KB and multiply by two.... -- Shmget23:24, 16 June 2007 (UTC)
and figured out if you had enough blocks all in Hex (Again, please don't get semantical on me; I use blocks generically to account for differences in file systems between OS's).
Calculations using prefixed sizes may not fit because of truncation and blocking, e.g., a 499K file not to fit on a 500K space. BTW, the mixed usage of decimal digits with binary prefixes is equally as likely to cause consumer confusion since, e.g., a 0.5M file will not fit into 500K remaining space (both in binary sense).
Of course it won't because 1/2 MB is 512 KB. but what's you point? that if you take a MB in a 'binary sens' and do math on it as if it was a metric MB, you get a wrong result ? duh!. The example above is the same as saying that 1MB will not fit on 1000KB (both in binary sense). Of course it won't Just like 1024 kB will not fit in 1MB (both decimal sense)!!!
As the illustrations in the article show, the consumer confusion occurs when the consumer buys a 160GB HDD but system then reports it both as 149.05GB and 152655MB.
I believe we all agree on that. (except to the extent that 160 metric GB is actually 152.58 GB, not 149.05 GB, so the delta is not entirely attributable to a unit conversion, hence the 'confusion' would remain due to people confusing 'raw' space nd 'formateed, usable space). The argument is which of the two information is 'confusing', what size is the consumers most likely to care about: the size reported on the box or the size he can actually use.-- Shmget23:24, 16 June 2007 (UTC)
Based upon the current evidence, it is clear that the OS's folks adopted the term MB in a binary sense many years after the HDD industry had had standardized on MB in a decimal sense.
'standardized' I have plenty of magazine and magazine ads for harddrive, that illustrate the the use of these unit was all but standard, even in the industry. and to top that the spec of the CD-ROM are a clear counter example to that claim. -- Shmget23:24, 16 June 2007 (UTC)
Beside, consumers (as in the general public - the segment were you can find some confusion - did not commonly use hard-drive until at least 1983. (with the IBM PC/XT), and by then teh size was a few MB at best, which could and was easely refered as 1000's of KB. of 1000's of 'blocks'.
Whether it was a good idea or a bad idea is irrelevant, it is the source of consumer confusion BTW, I suspect careful research would show the same sequence occurred with k/K to K in FDDs and G to G in HDD.Tom9402217:38, 16 June 2007 (UTC)
That is very doubtful of FDD, since its invention post-date the use of K=1024 by half a decade, add another 5-10 years for it to really 'hit the public', beside there is no serious argument that KB=1024, especially sinc KB is not a 'prefixed B unit as some what to describe these unit,, since K is not a SI prefix....
That is irrelevant for GB, TB and all subsequent unit. It is a consistency issue. Regardless of any one's preference. the one thing we all agree - I think - is that mixing these unit is completely dumb, like the notorious 1.44 MB disk... Within a given environment it is either entirely binary or entirely decimal. Of course OSs, when they eventually needed to represent GB sized object, used binary GB not metric GB. It's an obvious extension of the use of the units KB, then MB, then... -- Shmget23:24, 16 June 2007 (UTC)
History of binary K and M
Tom, I don't follow your line of thought.
K and k were used in the mid 1960s as 1024. By the late 1960 computers came with over a meg of RAM. Are you saying the M for 1024*1024 did not come into use until the 1980s?
Exactly my point with regard to M and in particular with regard to MB, the initial source of "consumer confusion". Please see the timeline above; the earliest use of MB right now is Apple IIgs in 1986 and the earliest use of MByte might be 8086 in 1981.Tom9402219:51, 17 June 2007 (UTC)
The terms like 64 K words, or 64 Kbytes are more common than 64 kilobytes in the 1970s. The ads in the first 2 years BYTE magazine use something like "4K words (4096 bytes)". Kilobyte and Megabyte became common in the very late 1970s.
No question about the dual meanings of kilobyte and all its abbreviations becoming common in the 1970s. There is no evidence of MByte and MB in a binary sense before the 1980s. I am less certain about binary megabyte, but the article is talking about M not mega. Tom9402219:51, 17 June 2007 (UTC)
In the 1960s disk had over a million bytes of storage. Most of the disk references from the 1960s are in Mbits. The disks were formatted differently for programs vs. data. They only used 6 bits for characters. (No lower case.) --
I suggest most of the 1960's references come from IBM and they are all millions of bytes. Check out the IBM literature on the 1311, 2314 and 2305 at the Tom9402219:51, 17 June 2007 (UTC)
Tom,
Here is an early 16 Mbyte example, it used 64 Kbit MOS dynamic RAM. The prototype was only 2 Mbytes total. I bought 8 Motorola 64K D-RAMs in 1981 for $100. A year later they were $10 for 8.
MIP: A flexible, microprogrammable image processor
Gonzalez, Manuel Gonzalez, Jorge IBM-Madrid Scientific Center, Madrid, Spain
This paper appears in: Acoustics, Speech, and Signal Processing, IEEE International Conference on ICASSP '82.
Publication Date: May 1982
Volume: 7 On page(s): 1211 - 1214
Abstract
This paper presents an experimental, micro-programmable processor intended for the efficient processing of multiband images. The processor is attached to a commercially available image display terminal and operates under the control of a host computer. Flexibility and programming easiness have been the most important design objectives. Main characteristics of the processor are the following: Four-stage pipe-line architecture, dedicated arithmetic and logic unit for address computation, fixed-point and floating-point instructions, microprogram memory separated from image store, look-up tables for fast implementation of some functions and 16-Mbyte image storage addressing capability. The processor performs about 3.6 millions of fixed-point instructions per second.
-- SWTPC680021:41, 17 June 2007 (UTC)
IBM Thomas J. Watson Research Center, Yorktown Heights, NY
"The stack processing method is used to compare the cost-performance ($/access) between the following: 1) two-level and three-level hierarchies; and 2) hierarchies using random access and serial access memories as a backing store. It was found that busswidth between levels in the hierarchy strongly affects the system cost-performance, and the access time ratio between the backing store and buffer somewhat less. With the technology cost assumptions used in this study, the three-level hierarchy does not have as good a figure of merit ($/access) as the two-level hierarchy unless the access time ratio exceeds about fifty. Also, random access devices are advantageous over serial access devices for backing store applications only when the memory capacity is less than 1 Mbyte. For capacities of 4 Mbyte and 16 Mbyte serial access stores with shift register lengths of 256 bit and 1024 bit, respectively, look favorable."
Gordon Bell used megabyte in this 1976 paper.(Written November 1975) "memory size (8k bytes to 4 megabytes)."
Bell, Gordon (November 1975). "Computer structures: What have we learned from the PDP-11?" (PDF). ISCA '76: Proceedings of the 3rd annual symposium on Computer architecture. ACM Press: pg 1-14. memory size (8k bytes to 4 megabytes).{{cite journal}}: |pages= has extra text (help); Unknown parameter |coauthors= ignored (|author= suggested) (help); Unknown parameter |dio= ignored (help)
There are three styles mentioned in the History section: binary, decimal, and truncation. An example is given ("The HP 21MX real-time computer (1974) denoted 196,608 as 196K and 1,048,576 as 1 M"), but the 1M could be any of the three styles. What evidence is there that this was not just another instance of truncation? — Omegatron01:39, 22 June 2007 (UTC)
You can't tell which method was used for values like 32K or 1M. You just have to look at the other values an assume they used one method. The HP 21MX also used 131K. Look on page 18 in the HP Journal link.
The fact that 2 and 10 are almost but not quite equal creates a lot of trivial confusion in the computing world and around its periphery. One hears, for example, of doubling the size of a 32K memory and getting 65K (not 64K) memories. Doubling again yields a 131K (not 130K) memory. People who use powers of two all the time know that these are approximations to a number they could compute exactly if they wanted to, but they seldom tale the trouble. In conversions with outsiders, much time is wasted explaining that we really can do simple arithmetic and we didn't mean exactly what we said.
The confusion arises because we use K, which traditionally means 1000, as an approximation for 1024. If we had a handy name for 1024, we wouldn’t have to approximate. I suggest that κ (kappa) be used for this purpose. Thus a 32κ memory means one of exactly 32,768 words. Doubling it produces a 64κ memory which is exactly 65,536 words. As memories get larger and go into the millions of words, one can speak of a 32κ(33,554,432-word) memory and doubling it will yield a 64κ (67,108,864-word) memory. Users of the language will need to have at there fingertips only the first nine powers of 2 and will not need to explain the discrepancies between what they said and what they meant.
This should not have been protected indefinitely. Sorry if it's my fault for not including the right template on the page, but someone should have unprotected it after a few days. — Omegatron17:37, 23 June 2007 (UTC)
IEC binary prefix adoption
I have been trying to measure the adoption of the IEC binary prefixes in the computer world. There is no legal obligation to use this IEC and ANSI/IEEE standard. Every IEEE standard has these disclaimers. "Use of an IEEE Standard is wholly voluntary." "The existence of an IEEE Standard does not imply that there are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to the scope of the IEEE Standard." After the ASME vs Hydrolevel antitrust case was upheld by the Supreme Court standards organizations are abundantly cautious about pushing their standards.
The use of MB and megabyte for binary values is more than common usage, there is 50 years industry practice codified in ANSI/IEEE and other standards. The previous standards formally defined what the industry was already using. Coining new terms like mebibyte is an attempt to change industry practice. In 1984 the ANSI/IEEE Std 91-1984 and IEC 60617-12 standards recommended that everyone start drawing schematic symbols of AND gates as a square box with an ampersand in it. Changing something that the industry thinks is working is very difficult.
The only significant usage is in elite standards groups. I would have the say the adoption of the IEC binary prefixes is minuscule and static. One of the major points on the consumer confusion argument was the difference between RAM, floppy disk and hard disk measurements. Floppy disks are gone, and all hard disk now come with a disclaimer stating that a GB is a billion bytes. The rest of the computer industry is staying with previous ANSI/IEEE standards that define KB, MB and GB as binary units.
Survey Method
I looked at the IEC binary prefix use by news, technical and reference publications; manufactures of computer components, semiconductors, and computer systems; operating system and application software; retail sales of computers and software; and other standards organizations.
The measurement methodology should give weight to the importance of a source. An established technical publication with a monthly circulation of 400,000 readers and an online edition is more influential than a small circulation newsletter or a personal blog. Intel has more clout than the 87th largest maker of novelty USB flash memory drives.
One search method used was Google's Advanced Search with the site limited to the company domain. For example: Mbyte site:forbes.com . The results have to be analyzed to eliminate blog content and un-edited press releases. Forbes has over 1600 hits on MB, and 19 on Mbyte. Searching MIB is a problem because it is a popular acronym (Management Information Base). Add another term such as DRAM, 64 or 512 to MIB to get better results. Forbes uses MB and GB.
Rather than just making up a list in each category, I used rankings from various sources. The lists are not perfect, but the top companies in each category make the lists.
Computer Industry Press
The IntelliQuest CIMS Business Study is a survey publishers and advertiser to determine pecking order of computer magazines. It claims the three largest publishers are International Data Group (IDG), CMP and Ziff Davis Media.
Here are the circulation numbers for the North American magazines of these publishers. This is not a definitive list of computer industry magazines but it is a good cross section. These magazines also have online versions.
None of these magazines use the IEC prefixes. They all use MB and GB with the exception of two CMP magazines; InformationWeek and EE Times also use Mbyte and GByte.
International Data Group (IDG): CIO (twice per month - 140,000}, Computerworld (weekly - 180,038), Macworld (monthly - 350,000), PC World (monthly - 853,952), InfoWorld (was around 300,000 - now web only)
CMP: InformationWeek (weekly - 440,000), EE Times (weekly 150,000) ,Dr. Dobb's Journal (monthly 120,000)
Ziff Davis Media: PC Magazine (bi-weekly 700,000), eWEEK (weekly - 400,100)
Business Press
The Wall Street Journal, Business Week, Forbes and Fortune all use the traditional MB and GB. All of the mainstream newspapers and magazines also use MB and GB.
Technical Journals
The IEEE and ACM have their journals on-line to members and subscribers. The contents can be searched by Google but the articles can not be viewed. Some universities and businesses have access in their libraries. The most effective searching required access to the IEEE and ACM search tools.
The terms Kbyte and Mbyte were the most common units in the 1970s and 1980s and are still very popular. The IEEE Computer Society magazine, Computer, still uses them. Current technical journals allow the authors to select the unit. There are some articles using the IEC prefixes but Mbyte and MB are still more common. The April and June 2007 issues of the IEEE Computer Society magazine Computer do not have any IEC binary prefixes, only Kbyte, Mbyte and Gbyte. These units are recommended by the IEEE Computer Society Style Guide.
"MB: megabyte; use Mbyte (40-Mbyte hard disk, 12 Mbytes of memory)"
Here is a sample of current (2006-2007) technical articles from IEE and ACM publications.
Rusu, Stefan (Janurary, 2007). "A 65-nm Dual-Core Multithreaded Xeon Processor With 16-MB L3 Cache". Solid-State Circuits, IEEE Journal of. 42 (1): pg 17-25. doi:10.1109/JSSC.2006.885041. {{cite journal}}: |pages= has extra text (help); Check date values in: |date= (help); Unknown parameter |coauthors= ignored (|author= suggested) (help) The authors are with Intel Corp.
Hamamoto, Takeshi (Match 2007). "A Floating-Body Cell Fully Compatible With 90-nm CMOS Technology Node for a 128-Mb SOI DRAM and Its Scalability". Electron Devices, IEEE Transactions on. 54 (3): pg 563 - 571. doi:10.1109/TED.2006.890597. {{cite journal}}: |pages= has extra text (help); Check date values in: |date= (help); Unknown parameter |coauthors= ignored (|author= suggested) (help) The authors are with Toshiba Corp.
Pilo, Harold (April 2007). "An SRAM Design in 65-nm Technology Node Featuring Read and Write-Assist Circuits to Expand Operating Voltage". Solid-State Circuits, IEEE Journal of. 42 (4): pg 813 - 819. doi:10.1109/JSSC.2007.892153. This paper describes a 32-Mb SRAM that has been designed and fabricated in a 65-nm low-power CMOS Technology.{{cite journal}}: |pages= has extra text (help); Unknown parameter |coauthors= ignored (|author= suggested) (help) The authors are with IBM Corp.
Birrell, Andrew (April 2007). "A design for high-performance flash disks". ACM SIGOPS Operating Systems Review. 41 (2): pg 88-93. doi:10.1145/1243418.1243429. A typical 1 GByte device, the Samsung K9W8G08U1M, consists of two 512 MByte dies in the same package.{{cite journal}}: |pages= has extra text (help); Unknown parameter |coauthors= ignored (|author= suggested) (help) The authors are with Microsoft Research.
Gebis, Joe; Patterson, David (April 2007). "Embracing and Extending 20th-Century Instruction Set Architectures". Computer. 40 (4). IEEE Computer Society Press: pg 68-75. doi:10.1109/MC.2007.124. For example, Cray's most recent vector processor, the X1, has 2 Mbytes of L2 cache that include vector references on each node.{{cite journal}}: |pages= has extra text (help) The authors are with the University of California, Berkeley.
Goldstein, Harry (January 2006). "Too little, too soon - solid-state flash memories". IEEE Spectrum. 43 (1): pg 30-31. doi:10.1109/MSPEC.2006.1572348. This paper discusses the disadvantages of Samsung's new NAND flash-based solid-state disks (SSD), which range in capacity from 4 to 32 GB aimed at notebook, subnotebook, and tablet computers.{{cite journal}}: |pages= has extra text (help) Harry Goldstein is a Senior Associate Editor for the IEEE Spectrum.
Moreira, Jose (November 11 - 17, 2006). "Designing a highly-scalable operating system: the Blue Gene/L story". Proceedings of the 2006 ACM/IEEE conference on Supercomputing. Tampa, Florida: ACM Press. doi:10.1145/1188455.1188578. ISBN 0-7695-2700-0. {{cite conference}}: Check date values in: |date= (help); Unknown parameter |booktitle= ignored (|book-title= suggested) (help); Unknown parameter |coauthors= ignored (|author= suggested) (help) The authors are with IBM Corp. "completing on-chip memory hierarchy is 4 MiB of embedded DRAM" The IEC binary prefixes are explained in footnotes like this: " MiB = 1,048,576 (mebibyte - http:/en.wikipedia.org/Binary_prefixes) "
Ellsworth, David (2003). "Accelerating Large Data Analysis By Exploiting Regularities" (PDF). IEEE Visualization. NASA Ames Research Center: pp. 561 - 568. The file server had two 1 GHz Pentium III processors, 2 GiB of memory, and eight 120 GB 5400 RPM IDE disks combined into one logical volume using software RAID-5.{{cite journal}}: |pages= has extra text (help); Unknown parameter |coauthors= ignored (|author= suggested) (help); Unknown parameter |month= ignored (help)
Ingalls, R.G. "Integration of the FreeBSD/kb TCP/IP-stack into the discrete event simulator OMNET++" (PDF). Proceedings of the 2004 Winter Simulation Conference. Institute of Telematics, University of Karlsruhe. {{cite conference}}: Unknown parameter |booktitle= ignored (|book-title= suggested) (help); Unknown parameter |coauthors= ignored (|author= suggested) (help) "All tests for the evaluation were performed on a Xeon dual processor system running at 2.2 GHz with 4 GiB RAM (1 GiB = 1024 MiB, 1 MiB = 1024 KiB, 1 Kib = 1024 bytes). ... The average memory consumption per host was determined to be around 20 KiB. Additional memory of 150–170 KiB is required per (bi-directional) TCP connection"
Dave Chinner, Jeremy Higdon. "Exploring High Bandwidth Filesystems on Large Systems" (PDF). Silicon Graphics, Inc. {{cite journal}}: Cite journal requires |journal= (help) "JFS was unable to exceed an average of 80MiB/s write speed in all but two of the many test points executed, and Ext3 did not score above 250MiB/s and decreased to less than 100MiB/s at sixteen or more threads."
Pramod Korathota. "Investigation of Swarming Content Delivery Systems" (PDF). University of Technology, Sydney. {{cite journal}}: Cite journal requires |journal= (help) "The distributor of some content runs an application which splits the content into small blocks, usually 256 KiB to 1 MiB in size."
Martin, P. (2002-04-03). "A pipelined hardware implementation of genetic programming using FPGAs and Handel-C". Genetic Programming: 5th European Conference Proceedings. Lecture Notes in Computer Science. Vol. 2278. Kinsale, Ireland. pp. 115–121. {{cite conference}}: Unknown parameter |booktitle= ignored (|book-title= suggested) (help) "The Celoxica RC1000 board has 8 MiB of SRAM arranged as 4 banks of 2 MiB that can be directly addressed by the FPGA, and each bank is configured as 512 Ki 32bit words."
Thorvald Natvig (2005-06-09). "Blue Gene/L" (PDF). Norwegian University of Science and Technology. Retrieved 2007-07-14. {{cite journal}}: Cite journal requires |journal= (help) "The L2 cache is only 2 KiB large, and is more accurately referred to as a large hardware prefetch buffer. The onboard 4 MiB eDRAM component can be split as desired between L3 cache and addressable memory."
Leopold, M. (2003). "Bluetooth and sensor networks: a reality check". Proceedings of the 1st international conference on Embedded networked sensor systems. pp. 103–113. {{cite conference}}: Unknown parameter |booktitle= ignored (|book-title= suggested) (help); Unknown parameter |coauthors= ignored (|author= suggested) (help) "They are based on the Atmel ATmega128L microcontroller - an 8 bit microcontroller (MCU) clocked at 7.4 MHz, with 4 KiB on chip memory and an external memory chip of up to 64 KiB."
M. Leopold (2003). "Tiny Bluetooth stack for TinyOS" (PDF). Department of Computer Science, University of Copenhagen. {{cite journal}}: Cite journal requires |journal= (help) "It has 4 KiB on chip memory and an external memory chip of 512 Kibit (64 KiB). ... (Lower case “k” refers to 1000, “Ki” refers to 1024, “b” to bits, “B” to bytes.)"
Menon, C.J. (2005). "A single network solution for safety-related applications using CANopen". Industrial Electronics Society, 2005. IECON 2005. 31st Annual Conference of IEEE. Industrial Electronics Society, 2005. IECON 2005. 31st Annual Conference of IEEE. pp. 6 pp. {{cite conference}}: Unknown parameter |booktitle= ignored (|book-title= suggested) (help) "The CSC01 is clocked at 16 MHz. It provides 10 KiB of SRAM and 256 KiB of Flash memory."
Worringen, J. (2002). "Exploiting transparent remote memory access for non-contiguous- and one-sided-communication". Parallel and Distributed Processing Symposium., Proceedings International, IPDPS 2002, Abstracts and CD-ROM. Parallel and Distributed Processing Symposium., Proceedings International, IPDPS 2002, Abstracts and CD-ROM. pp. 163–172. {{cite conference}}: Unknown parameter |booktitle= ignored (|book-title= suggested) (help); Unknown parameter |coauthors= ignored (|author= suggested) (help) "The Cray T3E reaches an efficiency of about 1 for blocksizes between 8 and 32 kiB, but has a very low efficiency for very small (< 4 kiB) and big (> 32 kiB) blocksizes."
Heirman, W. (2005). "Traffic Temporal Analysis for Reconfigurable Interconnects in Shared-Memory Systems". Parallel and Distributed Processing Symposium, 2005. Proceedings. 19th IEEE International. Parallel and Distributed Processing Symposium, 2005. Proceedings. 19th IEEE International. pp. 150a. {{cite conference}}: Unknown parameter |booktitle= ignored (|book-title= suggested) (help); Unknown parameter |coauthors= ignored (|author= suggested) (help) "Since this influences the working set, and thus the cache hit rate, the level 2 cache was resized from an actual 8 MiB to 512 KiB, resulting in a realistic 80 % hit rate. The simulation slowdown (simulated time versus simulation time) was a factor of 50,000 resulting in execution times of roughly 2 hours per benchmark on a Pentium 4 running at 2.6 GHz with 2 GiB RAM."
G. Gerhardsson. "Cacheprobe: An open source multiplatform library implementation for extraction of cache memory parameters". Master’s Thesis, Department of Computing Science, Umea University, 2004. {{cite journal}}: Cite journal requires |journal= (help) "For example, lets take a cache of size 1 MiB. If the stride is 0.5 MiB, or a multiple thereof, the memory positions will compete for the same cache positions."
Dictionary and Encyclopedia
byte . (2007). In Encyclopædia Britannica. Retrieved 28, 2007, from Encyclopædia Britannica Online Library Edition: 6:18 PM 6/28/2007
"Because a byte contains so little information, the processing and storage capacities of computer hardware are usually given in kilobytes (1,024 bytes) or megabytes (1,048,576 bytes). Still larger capacities are expressed in gigabytes (about one billion bytes) and terabytes (one trillion bytes)."
"megabyte n." The Concise Oxford English Dictionary, Eleventh edition revised . Ed. Catherine Soanes and Angus Stevenson. Oxford University Press, 2006. Oxford Reference Online. Oxford University Press. 29 June 2007
"megabyte ( abbrev.: Mb or MB ) n. (Computing) a unit of information equal to one million or (strictly) 1,048,576 bytes."
Computer Component
The research company, iSuppli Corp, measures various segments of the electronics industry and publishes the rankings. They are frequently quoted in the technical and mainstream press.
Seagate Technology, Western Digital Corp., Hitachi Global Storage Technologies (GST), Samsung Electronics Co. Ltd., Fujitsu Ltd., Toshiba Corp.
FWIW, my recently purchased Samsung HDD comes with an installation guide that uses GB throughout to mean 10, but in one place it does use GiB: "FAQ 3: Although my drive is larger than 137GB, it is only shown as 137GB. — There are two reasons of the 137GB (128GiB) capacity barrier...". The rest of that section then keeps using 137GB. (And yes, the English is very ropey). --KJBracey18:34, 7 August 2007 (UTC)
Computer Equipment Companies
Forbes Technology Hardware Equipment Ranking
IBM, Hewlett-Packard, Cisco, Dell, Apple, Toshiba
Software Companies
Forbes has a list of top software companies but over half do consulting or other behind the scene work. Here are the companies that sell software applications.
Microsoft, Oracle, SAP, Symantec, CA, Adobe Systems, Intuit, Autodesk,
Here are some other significant software companies from the Linux, FSF world.
Red Hat, Novell, Mozilla, Apache
Retailers
InternetRetailer.com published a survey to the top e-retail businesses.
Amazon, Staples, Office Depot, Dell, HP Home & Home Office Store, OfficeMax, Sears Holding Corp, CDW, SonyStyle, Newegg were the top ten. Most sell computer equipment. There could be a better selection but this is a workable list.
None of these retailers use the IEC binary prefixes.
Perhaps it is more accurate to say all of them use K/M/G and/or KB/MB/GB and/or kilobyte/megabyte/gigabyte, etc., in both binary and decimal senses, frequently in the same advertisement but none of them use IEC binary prefixes at all. Tom9402223:48, 4 July 2007 (UTC)
What is this tebibyte rubbish. Computer stuff is binary not decimal. If someone doesn't understand that a terabyte is an inherently binary value then they're going to think they got a free bonus chunk of disk, like a gmail account. They tried to say Pi is 4 before now, I for one will not call it pipi.
Oh, another one judging rather by sound then by sense. No, "computer stuff" ist not strictly binary. Processor, bus and network frequencies are even strictly decimal. Therefore, transfer rates are also strictly decimal. Yes, 10 Mbit/s of 10BaseT is decimal. Ever since. So which kind of what Terabyte could be transrered how fast over 10BaseT? Using binary prefixes in computer stuff is ok, but using same names as for decimal prefixes is less wise at least. Especially, if decimal prefixes are validly used with computer stuff as well. --213.183.10.4120:34, 31 October 2007 (UTC)
Actually the first post is quite correct in the statement that computers "stuff" is inherently binary. A circuit (or hard/optical disk) inherently is either on or off (or written or not), which is correlates to binary. This includes network transmissions. The decimal bandwidth capacity is assigned completely after the fact. The only reason these come up as decimal is that the protocols are design to be decimal, they could just as easily be designed to meet a binary standard.
Metric standard aside, the fact is that KB, MB, etc. were originally used primarily as a binary measure (before any of these network protocols and large HDDs existed). It would have made far more sense to create a new name for the decimal measurements. HDD manufacturers knew most people wouldn't know the difference, and they chose the less honest measurement. Jbrownos (talk)
Jbrownos should take a careful look at the Timeline; MB was widely used by the HDD industry long before the OS's even started reporting capacity in MB. There is one early published use of MB in a binary sense but MB and variants were far more often used in publications a decimal sense until Apple started reporting HDD capacities that way. KB has never been used for an HDD (the first one was 5 million characters) and even the first FDD usage by IBM and Shugart used KB in a decimal sense. Again the system and controller folks confused that one too.
BTW, since computers today are inherently binary, shouldn't the prefixes be in binary multiple bits, that is, 10 and 20 are not very good binary numbers. If programmers really used prefixes they would be 8 or 16 and extensions there to. The fact that the so called binary prefixes are always used with decimal numbers so that conversion requires a conversion factor suggest to me that they are just a short hand and not used in any real manner.Tom94022 (talk) 22:50, 2 January 2008 (UTC)
Image deletions
It's absurd to suggest that we can describe computer GUI dialogs with sufficient detail that a user could figure out which dialogs we're talking about when we can just use an image. Using these images in this article is a very clear case of fair use. Please remove the fair use dispute tags. — Omegatron05:10, 21 August 2007 (UTC)
I agree with you, and have both removed the pending deletions and added text to your images to explain why these images meet all fair use criteria. Tom9402206:16, 21 August 2007 (UTC)
Following my previous contribution (now in Archive 1), it seems that in modern times, all hard disk manufacturers use, as far as possible, binary GB. This has not always been the case. Take, for example, Maxtor's D540X 4D. The "80 GB" model has 158816*16*63*512 = 81964302336 bytes. The product manual instead gives the capacity as "82.0 GB" (it also, interestingly, says 30735581184 bytes is "30.0 GB").
Then there are older drives, the 90431U1 model which is 4343463936 bytes, or about 4.04 GiB (funnily, the "173" model is about 16.21 GiB, and 17,002,440 KiB. The Quantum Fireball 4.3AT CR43A101 is 8895*15*63*512 bytes (about 4.304 decimal GB, 4.008 GiB).
While I haven't found a manufacturer that defines KB, MB, or GB as anything other than powers of 1000 (or something like "one billion"), manufacturers have, for whatever reason, made hard drives which are a little over an integer multiple of 102 or even 2 bytes (I don't have an example of 102 handy, but I'm sure it's out there). They knew that 1024 was important to some people. Perhaps this is because it's far more convenient to go between KiB and block counts than not-actually-SI KB. It's also pretty obvious to me that Quantum wanted 4 binary GB, but also to present the drive size in marketing GB - the marketing reason is also why hard drives are just a little over a multiple of 10 bytes, while just a little under a multiple of $10.
And then, the use of K, etc, as powers of 1024 is not "incorrect". It is not SI. It never claimed to be SI. It's confusing, sure, that 1K = 1024, but it's no more "wrong" than using m to mean mile. Meaning is based on context, and the context has been largely binary ever since we stopped using BCD.
it seems that in modern times, all hard disk manufacturers use, as far as possible, binary GB
They do?
it's no more "wrong" than using m to mean mile.
It's no more "wrong" than using "kg" to mean "437 million graham crackers". I can define it to mean whatever I want. As long as I don't claim it to be SI, it will not be "wrong" ... right? — Omegatron23:30, 22 August 2007 (UTC)
In modern times, the available capacity is a production yield decision. All drives have somewhat more capacity than specified; they are set to provide a particular value in the manufacturing process and if u knew the "secret" commands you could gain access to the additional capacity. IMO, the set capacity is placed a little above the stated capacity in 10 units to allow for the loss of capacity due do defects grown in use. Therefore, over the life of the drive, the customer is never denied the advertised 10 capacity. We would have to talk to manufacturing folks to see exactly what they are trying to achieve but I doubt if it has anything to do with binary units. Tom9402200:09, 23 August 2007 (UTC)
I meant that HD manufacturers use 10 GB. The addressable sectors (and what I refer to) never include spare sectors - they're transparently remapped on a write to a bad block, and presumably on a read from a block with a consistently high error rate. You never see them. Therefore, over the life of the drive, the customer is never denied the advertised 10 capacity. does not follow (and I'm not sure what you mean by "10") - the number of spare sectors is pretty small, and I suspect less than 1%. What I'm talking about is how hard disk manufacturers have, quite consistently, made drives in near-multiples of 1024 or 1024³, instead of the "usual" 1000³, and how they've sometimes advertised a 81.96 10 drive as "80 GB", when they could've called it 81 GB (and they call it 82 in the manual) or just not added the extra sectors. Yes, they say "1 GB = 1000000000 bytes", but they give you a little extra for no apparent reason. ⇌Elektron13:53, 5 September 2007 (UTC)
Problems with bare links for references
I have replaced the bare links used as references in this article with proper citations per Misplaced Pages:Footnote. The essential problem with bare links (a URL with no other identifying information) is that they frequently break, and without data like news article titles or website page titles, it is often impossible even to know where to look for a replacement source. (Archive sites like the Wayback Machine or Google sometimes help, but often do not.)
For example, the following statement has become unsourced because its old ABC News link no longer exists, nor appears to be readily accessible in an archive:
Western Digital offered to compensate customers with a free download of backup and recovery software valued at US$30. They also paid $500,000 in fees and expenses to San Francisco lawyers Adam Gutride and Seth Safier, who filed the suit.
The editor contributing this "source" failed to provide any information that would allow us to find a replacement for it. (It's entirely possible that one of the existing sources has this information, but I leave this to someone prepared to do a thorough source review to fix. I'm just making it easier for such a review by properly citing the sources.)
In short, bare links should be never be used as sources for Misplaced Pages articles. You don't necessarily have to create a fully filled-out citation, but at least include basic title and/or descriptive information (date, author) with the reference. ~ Jeff Q(talk)16:47, 9 September 2007 (UTC)
As much as I like Markus Kuhn, I don't think it satisfies any requirements for notability (it's a paper published on a website and not endorsed by anyone else). It also breaks down at 1000^30, where the "next power of two" is 1024^29.9, not 1024^30. It also doesn't solve anything that the IEC proposals don't, and could cause more confusion — "b" almost universally means bit, and if you want to use a "SI" Mbyte, there's no way of saying "M means 10^6" except by spelling it out. The byte's a de-facto unit anyway, and converting between advertised Mbps to "real" 10^6 B/s is often a factor of 8, 10, ~20 (WiFi), ~16 (USB 2.0), or something equally strange. ⇌Elektron11:30, 11 September 2007 (UTC)
War has never been so much fun
My edit has just been reject as "vandalism". This is ridiculous! We can disagree all day whether M means 1000^2 or 1024^2 but this sentence is a quite different issue. In any case, 'M' is definitely not a binary prefix. The binary prefixes are Ki, Mi, Gi, Ti, Pi, Ei. Therefore, the sentence "Binary prefixes are often written and pronounced identically to the SI prefixes, despite the resulting ambiguity." is not only incorrect, it makes no sense at all. Who pronounces MiB as MB? I pronounce the former mib as in MiG (or meh-bee-bite) and the latter em-bee (or mee-gah-bite). I don't see how you could pronounce any of them identically. You could add an introduction like "SI prefixes are still frequently incorrectly used for values that are powers of 1024 instead of the unambiguous binary prefixes." but that's later explained in the article, thus redundant. --217.87.98.17100:19, 1 November 2007 (UTC)
Your edits have been reverted as vandalism because your IP and your other "anonymous" IP:
Have been used as for single purpose edits against MOSNUM policy.
Have been asked by at least three different editors to not make changes to contrary MOSNUM policy yet you continued to do so.
Have been used to write personal attacks against other editors on their talk pages and in article talk pages.
Have been asked not to harass those editors on their talk pages yet you continued to do so.
Even if you consider some of my edits as vandalism, that doesn't justify reverting whatever I edit. There is nothing wrong with "single purpose edits" and it's only against WP:MOSNUM by your definition. Also you have to specify the exact revision because WP:MOSNUM has been modified not so long ago and will likely change again. Furthermore, you've shown hostile behaviour towards me by talking in bad faith about my edits on the talk page of your friend. You are accusing me of being a sock puppet just because I do care about IEC standard prefixes and have the same opinion as someone else on this topic when there are in fact millions of people and at least dozens if not hundreds of wikipedia authors sharing the same opinion. You are even accusing me of stalking now. Stalking is a criminal offence! In fact you're doing exactly the same, you're monitoring my edits. I've told you more than once that I am not User:Sarenne and not in anyway related to this user. I do however assume that this user was banned in bad faith and if this user misbehaved it was very likely due to provocation by your group and zero-tolerance regarding a flawed and recently modified policy WP:MOSNUM. The policy is flawed in so far that use of IEC standard prefixes is not a question of style but correctness and adhering to current standards. The policy is also badly worded which allows you to get away with your constant reverts. "There is consensus that editors should not change prefixes from one style to the other, especially if there is uncertainty as to which term is appropriate within the context". As said it's not about "style" if you write 64 kB instead of 64 KiB. It's about style if you write 65.5 kB instead. The word especially makes no sense here. If an author is not sure, he certainly should not edit it at all before finding sources to make things clear. Then it says "When this is certain, the use of parentheses for IEC binary prefixes, for example, "256 KB (KiB)" is acceptable. Why are they merely acceptable? Obviously, the current wording puts anyone who likes to use the modern prefixes for clarity and correctness into a big disadvantage despite being an international standard. It is not up to Misplaced Pages or some contributers to decide what is standard and what isn't. How can you even argue that nobody knows or uses this standard (which is wrong) if Misplaced Pages which is supposed to educate people and provide objective and up-to-date knowledge, is now strongly opposing spreading this knowledge and sticking to outdated conventions? --217.87.98.17101:25, 1 November 2007 (UTC)
And once again Sarenne, this is not the place to push your views and agenda on kibi/mibi/gibi useage at Misplaced Pages. Same old stance, same old tactics, same old attitude, etc. As you were explained by Fnagton on your other ip related talk page, these things are set by WP:MOSNUM, which is the standard here. Take it up there. Your arguments, right down to the very wording, have all been heard before - all by Sarenne. You're not saying anything new, or doing anything different than the last time. And there's a lot more involved then just a "few people" or wording that was slanted in a certain favor. The wording was reached through consensus. As you were also told, "MOSNUM has been changed due to debate and consensus being formed by a large group of editors agreeing what should be done. You are also mistaken, the pro-IEC binary prefix arguments do not hold water and that is reflected in the result of the debate and consensus." To borrow some of your usual sarcasm: Any further questions? Then take them to Misplaced Pages talk:Manual of Style (dates_and_numbers) --Marty Goldberg07:42, 1 November 2007 (UTC)
Look, I'm not insulting you the least when I say you are paranoid. How often do I have to tell you guys, that I have absolutely nothing to do with Sarenne - except that we apparently share the same view on the binary prefix issue. Further, I am not insulting you but just stating facts, that you do not even understand basic English sentences. My native tongue is German. What does this tell about you? Nothing you could be proud of. Misplaced Pages policies are no standards by any means. They are guide lines and can, in fact, be modified - even inversed - any time, any day. Duck and cover! Yes, there's actually nothing new to say about binary prefixes. Everything has been said but you're still not accepting the facts. You're even trying to add confusion where there was none by arbitrarily mixing MB and MiB, so that any lay-man will never get the difference and consider them synonyms. You are not trying to spread knowledge and get rid of myths, no you are trying to reinforce these myths and hide knowledge. There are even such non-arguments as "because nobody knows what MiB means, it adds confusion". What utter nonsense! It is linked directly. Do you think readers are so stupid that they get confused by a single term they don't know? Then what's the point of Misplaced Pages at all if you only dare to expose people to facts (or non-facts) they already know (or assume to know)? "the pro-IEC binary prefix arguments do not hold water" Nice phrase but pure bullshit. The meaning of MiB is unambiguous for laymen and "experts". That alone makes it extremely useful. Furthermore, it is not up to you or anyone else at Misplaced Pages to decide what is standard and what isn't. How often do I have to repeat this simple fact? "and that is reflected in the result of the debate" You confuse quantity with good argumentation. "and consensus" Even WP:MOSNUM says that there is no consensus. Or did you change it during the last 12 hours? By the way, en.wikipedia.org is only a part of Misplaced Pages. If you actually checked one of the other languages, you'd see that in some of them the IEC prefixes are accepted and in wide use. But I guess explaining why English men have a problem with SI units would be considered anti-american/british but maybe you get the idea: EuroUKUSAInferiority complex --08:46, 1 November 2007 (UTC) —Preceding unsigned comment added by 217.87.98.171 (talk)
The current consensus in WP:MOSNUM#Binary prefixes is that "There is no consensus to use the newer IEC-recommended prefixes" and also "There is consensus that editors should not change prefixes from one style to the other" and also "stay with established usage in the article, and follow the lead of the first major contributor.". This also has parity with the other related MOSNUM guideline which says "use the units employed in the current scientific literature on that topic.". The meaning of this guideline is clear that the terms used in the majoirty of relevant reliable sources is to be used. In all the articles you and your other "anonymous" IPs have edited this means you must use KB, MB, GB, kilobyte, megabyte, gigabyte as the primary units used in the article. If you don't agree with the policy then stop your "anonymous" IP hopping, stop your threats to circumvent the system, create a user name and debate the topic on WT:MOSNUM. What you propse increases the ambiguity in articles by using terms that are not widely used. Fnagaton10:26, 1 November 2007 (UTC)
I am not hopping. Maybe you're not aware of the fact, that in Europe most consumer internet accounts have a dynamically assigned IP address. I've also explained that this is not a style issue, it's a question of correctness. The meaning of kB, MB, GB is not clear at all because you're ignoring the fact that many literature features footnotes or explanations regarding these units because use of the prefixes does not conform to use of them in any other field of science. It has also been explained that "obvious to an author" is not equivalent to "obvious to a reader". Please, see WP:OBVIOUS. Also, please, look up the meaning of ambiguity because it is not the same as ignorance as you seem to imply. I will try to fix WP:MOSNUM at a later time but not by now because it requires to inform a lot of people about the discussion and encourage them to get active because otherwise your team will simply overpower facts with quantity as last time. Last but not least, I'd like you to stop spreading lies about my identity, my intentions or edits on the talk pages of your friends. --NotSarenne18:40, 1 November 2007 (UTC)
By your own admission "You're not going to ban me this way because it's child's play to circumvent such a silly ban.". You write comments like Sarenne, you edit like Sarenne, you use the same ISP as Sarenne and you attack the same editors who got Sarenne banned. KB, MB, GB, kilobyte, megabyte, gigabyte as used in those articles are correct. Their use matches that used by relevant reliable sources. By the way you are not allowed to WP:CANVASS which "is sending messages to multiple Wikipedians with the intent to inform them about a community discussion." Fnagaton19:11, 1 November 2007 (UTC)
You know very well that you threatened to ban me first which is a policy violation as well. So we're even in this regard. There are a few million people using the same ISP as me. If Sarenne has the same native tongue as me, it's not surprising if my English style is similar. Like-wise, there are many people supporting the IEC binary prefixes, for example, the IEC members. I don't accuse of being a sock puppet of specific users albeit they all show the same hostile attitude and disagreement with my position. I have not violated WP:CANVASS or claimed to have any such plans. If you actually read it, you'll see that your claim is plain wrong and this isn't the first time, you have waved a policy in front of me inverting the meaning of the actual policy because quite obviously you either didn't read or at least did not understand it. --NotSarenne20:41, 1 November 2007 (UTC)
Actually no, you attacked editors who reverted you when following policy by accusing them of using sock puppets, and that is a policy violation. You vandalised my talk page with your attack. Your editing record demonstrates you are at fault here. I have told you before to not harass me and other editors yet you continue to do so. You will stop now. You admitted to having plans to canvass at "18:40, 1 November 2007" above when you wrote "it requires to inform a lot of people about the discussion and encourage them to get active ". Fnagaton21:08, 1 November 2007 (UTC)
That my very well be your view of reality but I can assure you in my reality, you used the term "sock puppet" first and then I used it in a reflective manner. If you are allowed to accuse me of something, I'm certainly free to do the same. I do not actively accuse you or your friends of using "sock puppets" though. It's just every time you throw dirt at me, I'll throw it right back to you. Fair, isn't it? So far you have informed a lot more people than I have and you used a huge amount of prejudice. Do you even realize that you sound like a broken record? I came here to improve the article within the tight bounds of the current WP:MOSNUM policy but you're constantly turning this into a feud. Apparently your vendetta against Sarenne and IEC prefixes has made you deaf for any kind of facts and arguments that do not fit your personal preferences. --NotSarenne00:37, 2 November 2007 (UTC)
You are completely wrong because you used the term sockpuppet first. Your use of the word combined with mentioning old binary prefix history, something Sarenne would know and a new user would not know, is the final straw that made me conclude that you are a sock puppet of Sarenne. Here is the proof, firstly in chronological order all my edits that I addressed to you and your previous "anonymous" IP edits: Revert changes MOSNUM explanation You revert someone elses change You first mention "sock puppet accounts" here Also in this edit you mention the "anti-kib tag team" and "how few people contributed to it and the weak arguments" these phrases plus your previous edits and comments give very strong evidence that you are Sarenne. The final straw was your personal attack later on in that comment, you are a sock puppet of Sarenne. So now I have proven you to be wrong I demand you retract and apologise for your lies that you are writing about me. What you are doing is deliberately misrepresenting me and as such you are acting against policy, so stop it, retract all your lies (which would be all of your recent edits) and then stop responding to my edits because you are harassing me and other editors. Fnagaton15:58, 2 November 2007 (UTC)
It seems you're right that I used actual term sock puppet first. This was however in response to your comment here: which implies that you consider me a potential sock puppet. I did then check some of your recent edits on the topic, about User:Sarenne and discussions about the binary prefix issues You and others have been accusing others of sock puppetry quite a lot there in cases that were similar to my edits. I've noticed with these few checks that you and others are frequently getting emotional and rude concerning the IEC standard prefixes, So it was just a question of time before you'd use this term against me. Do you seriously deny that you are anti-kib - short for against the IEC standard binary prefixes - and are teaming up with a couple of editors to prevent use of them? You should also read Talk:MB and realize that my edits to this talk page were alright in accordance to the guidelines. Further, I clearly have not violated any policies to the best of my knowledge under this account. Every single time that you and your friends accused me being in violation of a policy, you and them were wrong. I will certainly not apologize for anything, even if I made some minor mistakes, especially due to your extremely rude and childish stance against me. I believe at some point we were even in concern to rude behaviour but at this time I consider me the victim of your harassment, if you keep insisting that there is any harassment going on. --NotSarenne17:17, 2 November 2007 (UTC)
Do not mistake "rude" with "being efficiently accurate with my arguments". Do not forget you used multiple personal attacks first. Stop with the "implies" rubbish and trying to misrepresent what I write with your ad hominem. The facts prove you are wrong so apologise and retract your edits. Your continued stalking and harassment only go to prove how bad your behaviour is and how I am justified for creating a sock puppet report about you. Your refusal to apologise for your actions shows this. I did accuse Sarenne of using a sock puppet, by adding facts and references to his sock puppet report, and the result of that was the user was banned. Fnagaton17:30, 2 November 2007 (UTC)
Rubbish you say? I wrote "I wonder how many sock puppets you have." That is not the same as a claim and it's roughly the same as implying that I am Sarenne by writing "I hope it's not Sarenne coming back" and it's none of your business because I didn't write that to you but Marty Goldberg. Oh wait... just kidding. Anyway, regarding Misplaced Pages:Sock_puppetry, I see that you're again reading a policy to the letter but don't get the idea. I knew the term since long ago and I have occasionally been editing articles, reverting vandalism etc. without using an account for years without causing any conflicts. Perhaps because I rarely edited any controversial article or just didn't check what happened to my edit. So I'm not unfamiliar with Misplaced Pages. You're interpretation is that this is "another prove" that I must be Sarenne. Oh well, believe whatever you want, but please, cease your vendetta. You're smarter than me, aren't you? Shouldn't you give in then and stop wasting your time? --NotSarenne18:19, 3 November 2007 (UTC)
The fact is you made direct accusations which are untrue without any evidence. You have been proven to be wrong and you still fail to retract and apologise. You are acting against policy. The rest of your edit misrepresents that actual facts of the situation. Fnagaton18:50, 3 November 2007 (UTC)
You are not just talking. As demonstrated above you write lies about me and then refuse to retract and apologise when you are proven to be wrong. You personally attack me and other editors and because of your bad behaviour I have told you to stop writing about me and stop responding to me yet you continue to do so. So stalking as it applies to your actions is "to follow or observe a person persistently, especially out of obsession or derangement". Prove you are not stalking me by complying with the warnings I gave you and your other anonymous incarnation. Do not forget it is your actions and bad behaviour that cause you to be warned in such a way. Obviously those others editors are examples of people who disagree with your behaviour. Fnagaton12:21, 3 November 2007 (UTC)
You should rather link to the history of my talk page, so that readers get the big picture. What the heck makes you believe you can address me on my very own page and then forbid me to write a response on the very same page. It is violating exactly the policies that you were waving in front of me. Further, what do you think gives you the right to forbid me to answer you on whatever page you are talking to me? If you had any kind of honour and actually believed in what you said, you would have addressed those pseudonymous users and asked them to not participate in something that is none of their business. --NotSarenne17:54, 3 November 2007 (UTC)
The "big picture" as you put it is actually you writing lies about me, there is policy which states you are not allowed to use your talk page to wilfully misrepresent other editors and you are violating that policy. I do have honour and those editors obviously see you are at fault and since they are not attacking me (like you do) and are addressing the fact you are being disruptive then they can comment as they see fit. The fact is you are violating policy and your reply by your own admission also proves that you are stalking me. Fnagaton18:27, 3 November 2007 (UTC)
About prefixes and units
I'd like to explain why this revert is unjustified: . MB is a unit but not a SI unit because bit and byte are no SI units. k, M, G, T are SI prefixes. They are prefixes because you put them in front of units. A unit itself can be considered a suffix because you put it behind a value. MB is a (scaled) unit but never a prefix. Therefore, the sentence made no sense and I modified it. Maybe sentences don't need to make sense here, so the revert might be okay. Who knows? --217.87.98.17104:38, 1 November 2007 (UTC)
Once again, that's misreading the si prefix article. Specifically, its talking about the K, B, and G prefix added to the unit (bit, byte, etc.). It is not stating to use K, B, and G alone. The traditional usage is KB (or kB), MB, and GB. --Marty Goldberg04:48, 1 November 2007 (UTC)
I'm not misreading. The current sentence reads the decimal meanings of KB, MB, and GB are often referred to as SI prefixes. So MB is referred to as a SI prefix? No, it's not. M is referred to as SI prefix. MB is a unit, not a prefix. --217.87.98.17105:22, 1 November 2007 (UTC)
Basic English
Could someone who has studied English or is a very good English writer, explain why this revert is justified: ? In how far, is my edit worse than the other revision? To me "decimal prefix meanings of KB" really makes no sense. I've explained above what prefix is and that KB is not a prefix but a unit. --NotSarenne20:30, 1 November 2007 (UTC)
Personally I don't think the revert is justified in that your original statement is unambiguous, while the reverted statement arguably is ambiguous in that an uninformed person might think that KB, etc., are prefixes. An informed reader would recognize that they are prefixed units and deal with the prefix separate from the unit. In the end, I doubt if the potential confusion is sufficient to justify the angst. Tom9402203:21, 2 November 2007 (UTC)
Thanks for your response and the edit. Though I do think that this version was better: . Maybe the grammar isn't quite correct? Let me explain why I consider it better: The first online mention of the term binary prefix seems to be this here: by Markus Kuhn. So, strictly speaking, it refers only to KiB, MiB, GiB etc. but not to SI prefixes used in the "binary sense". The term "binary prefix" seemingly did not exist before this standard. With that in mind I'd say that your phrasing was less clear than the previous version. That's also why I think the headline of the paragraph "Binary prefixes using SI symbols" is nonsense. It should be " expressed (ab)using SI symbols" or similar whereas I'm struggling with the . These are not binary values or numbers. Apparently it should be "multiples of powers-of-two". --NotSarenne02:45, 4 November 2007 (UTC)
In my opinion it is not useful to repeat information like 1 kB may denote either 1,000 bytes or 1,024 bytes on the disambiguation pages. Otherwise, these will always additional places for disputes regarding the binary prefix notation. The reader must follow the links anyway to understand why there are different meanings/uses and which of them is used in what contexts. I think the current pages for TB is most appropriate, so KB should read like this:
* kilobit (kb), a unit of information or computer storage
* kilobyte (KB, kB), a unit of information or computer storage
I support this proposal. There's already enough discussion in the individual articles - there's no point in encouraging it to spill over into the re-direction pages. Thunderbird217:19, 4 November 2007 (UTC)
I'd prefer to get some other opinions first. As it affects several articles, it may be wise to raise in wp:mosnum before carrying out the change. Would you object to that? Thunderbird218:30, 4 November 2007 (UTC)
My opinion is no longer accepted here. I just wanted to let you know, that there is no point in waiting for a response from User:NotSarenne. I'm almost certain the proposed changed would be accepted though as long as it's not me who makes them. You could certainly try to discuss it at WP:MOSNUM, if you think that's necessary. --217.87.59.24718:35, 4 November 2007 (UTC)
Common usage and standards
There seems to be a conflict between (1) how words like megabyte and gigabyte are used by most speakers of English and (2) standards proposed or adopted by various bodies.
Is there also a US-EU split or a Windows/Linux split here?
Maybe we should indicated which language communities, regions, professions, etc. use the various gigabyte vs. gibibyte terminology.
Basically there are two meanings of the mega, giga, tera serios of prefixes: powers of 1000 (as in the metric system invented over a century ago in France) and powers of 1024 (used in recent decades mostly in reference to file size).
Hasn't everyone noticed that the so called binary prefixes are always used with decimal digits which, IMO. is quite absurd since it forces conversion factors for each change in prefix. Isn't the whole idea of prefixes is to not have conversion factors, just shift the digit point? Binary prefixes might make sense with digits in Hexadecimal or Octal but then the prefixes would not be of the form 2 (n=1,2,3,etc) but two would be raised to other powers such as 2 for a 3 Hex digit shift or 2 for 3 Octal digits. Also note that a 3 digit shift doesn't make a lot of binary sense either, two or four would be much more binary. Since programmers and engineers are generally lazy, this further suggests to me that binary prefixes are never used in any serious engineering and/or programing calculations but instead are shorthands used by technical, marketing and GUI persons to save space in reports, advertisements, displays, etc. Therefore, IMO, when these prefixes were used in a binary sense, they were never intended to be precise values and should not be interpreted in such a manner. Tom94022 (talk) 00:34, 17 January 2008 (UTC)
Recently I did an example that shows exactly how much consensus the IEC "standard" has in the real world. A while ago on Misplaced Pages we had one user edit hundreds of articles to change from kilobyte to kibibyte (and all of the other units as well) so since this would alter any attempt to use Google to judge real world consensus on this issue the searches are conducted with "-wikipedia".
Historical use search terms
Results
kilobyte -wikipedia
1,940,000
megabyte -wikipedia
6,190,000
gigabyte -wikipedia
3,640,000
Total: 11,770,000
IEC Search terms
Results
kibibyte -wikipedia
28,800
mebibyte -wikipedia
17,100
gibibyte -wikipedia
19,000
Total: 64,900
Consensus for historical use: 99.449%
This shows the IEC standard does not have consensus in the real world, so I don't think the IEC can be seen as authoritative in this regard.Fnagaton08:57, 17 January 2008 (UTC)
I didn't make my point clear, k = 1024, M = 1,048,576, etc are absurd! Ki, Mi, etc. happen to be an unfortunate necessity resulting from incompetent and/or lazy programmers at Apple and Microsoft using K,M, etc. in an unusual way without explaining their usage. Tom94022 (talk) —Preceding comment was added at 20:23, 17 January 2008 (UTC)
K=1024 etc is not absured. What is absured are the attempts by the IEC to rewrite what is already well known. Most of the world disagrees with the IEC. Fnagaton21:07, 17 January 2008 (UTC)
Yr statistics are questionable since you cannot tell whether megabyte and kilobyte are used in a decimal sense or a binary sense. Pick your own term, but u never addressed my observation that the combination of decimal digits with a binary prefix doesn't make a lot of sense. Tom94022 (talk) 22:04, 20 January 2008 (UTC)
What "proportion" is irrelevant to my point, as is the use of base ten numbers with binary prefixes. My point is more than 99% of the internet uses those terms and less than 1% use the so called IEC "standard". You may think it doesn't make a lot of sense however I think it makes perfect sense. Fnagaton23:21, 20 January 2008 (UTC)
I objected strongly when the changes were made to the style manual back elsewhen, and it was clear that no actual consensus was really achieved to "force" the changes onto Misplaced Pages. My attitude still is that the whole issue of KiB vs. KB is nitpicking over nothing, and in fact the articles that try to push the term "kilobyte" to mean 10^3 bytes rather than 2^10 bytes is nothing more than naval gazing.
Time will tell if the proper choice was made, but it certainly doesn't meet with "current" industry practices and popular usage. I have other battles to fight over than this one, so it seems that only those with a real axe to grind and a desire to push a POV are winning here. I have patience, and ten years from now we will see if these silly terms get adopted into mainstream computer culture or not, at which time all of this nonsense can be edited out of Misplaced Pages for once and for all. And I'll be here ten years from now still working on Misplaced Pages in one form or another. --Robert Horning (talk) 06:21, 9 February 2008 (UTC)
Sorry but I don't quite understand what are you trying to say. Who is an axe grinder? In how far is this related to naval gazing exactly? What is "nonsense" and which are the "silly terms" in this context? Also what makes you certain you'll be still here in ten years and what relevance has this assumption? Please clarify. Thanks. --217.87.88.179 (talk) 18:30, 10 February 2008 (UTC)
There is nothing silly about an encyclopaedia attempting to distinguish between two different definitions of megabyte, when both definitions are in common use by the computer and communications industries. I think the term "bad-ass" is completely inappropriate, but if the blame lies anywhere, it is with the computer industry as a whole for failing to standardise on the meaning of this and related terms. Thunderbird2 (talk) 09:10, 9 February 2008 (UTC)
Misplaced Pages uses consensus so it is silly to try to use terms that do not have real world consensus. Since kibibyte etc do not have real world consensus and do not have consensus in Misplaced Pages either then it is not the place of individual editors to try to enforce use of kibibyte etc. Don't worry Robert many other editors (including myself) have caused the binary prefix entry for WP:MOSNUM to change from the version that enforced using these neologisms. It now makes it perfectly clear that "There is no consensus to use the newer IEC-recommended prefixes in Misplaced Pages articles to represent binary units." Fnagaton10:43, 9 February 2008 (UTC)
At the end of this year we should look at the adoption of the IEC binary prefixes. A full decade is long enough to see if the standard will ever be adopted by the computer industry and technical press. If the adoption rate is the same as today, the manual of style should discourage the use the IEC prefixes on Misplaced Pages. -- SWTPC6800 (talk) 01:33, 10 February 2008 (UTC)
If Misplaced Pages wishes to make unambiguous statements about computer storage and data transfer rates (and in my opinion it should), then it needs to have unambiguous units in which to express such statements. Thunderbird2 (talk) 11:34, 10 February 2008 (UTC)
Which is to specify the exact number of bytes and not use the "bi-" neologisms because they are not widely used and can cause confusion. Fnagaton12:18, 10 February 2008 (UTC)
Yes, that is a good way of removing the ambiguity. Let us hope that editors start to follow it. But the confusion is caused by the ambiguity that was there all along, not by the attempts of the IEC to resolve it. Thunderbird2 (talk) 12:51, 10 February 2008 (UTC)
If the IEC had said "kilobyte" is now defined as 1024 bytes (like the JEDEC did) that would have made more sense as it would have followed real world consensus. Much better than inventing new terms that don't used used by the vast majority of people, even after nine years. ;) Fnagaton16:01, 10 February 2008 (UTC)
So if I want to talk about 2 GiB of RAM I should say 2147483648 bytes of RAM?! As for confusion, simply wikifying MiB would remove any confusion as to what a MiB is. If you prefer to use GB, the context should make it clear which one you're talking about. The gigabyte page lists when the 1024-based definition is used and when the 1000-based definition is used. Andareed (talk) 13:15, 10 February 2008 (UTC)
The suggestion is that 1 GiB would be written as 1 GB (1024 B) and the decimal gigabyte as 1 GB (1000 B). I don't know whether the context (without this clarification) would make it clear to an expert. But we are not writing for experts, and it certainly does not make it clear to me. Thunderbird2 (talk) 13:30, 10 February 2008 (UTC)
Andareed, using -bi (especially with it wikified) as the main unit adds confusion because in the majority of cases it changes the article units compared to the units found in the sources relevant to the article. Consistency with real world language and hence consensus is important. I also think using -bi as disambiguation adds confusion by introducing less well known terms than is expected by common use and that found in real world consensus. Your solution, wikifying it, can be equally applied to the existing terms kilobyte/megabyte/etc to make it clear to the reader how many bytes it is and this way it doesn't introduce an extra neologisms. For example if the sections existed in the pages then using something like ] or ] would work. Fnagaton15:59, 10 February 2008 (UTC)
It's about time you learn the meaning of "confusion". Exactly nobody is confused when they read MiB or Mebibyte. Not a single person. It's you who confuses "confusion" with "lacking knowledge of terminology". Do you actually know what neologism means? You make it look as if neologisms are something bad. It's derived from ancient greek, neo means new and logos means word if I remember correctly. Why don't you use your native tongue English instead? Are you from ancient Greece? Mebibyte is a relatively new word but Megabyte isn't exactly old either but every educated person knows that "mega" means million and its definition hasn't changed for centuries. --217.87.88.179 (talk) 18:15, 10 February 2008 (UTC)
JEDEC Solid State Technology Association (December 2002), "Terms, Definitions, and Letter Symbols for Microcomputers, Microprocessors, and Memory Integrated Circuits", JESD 100B.01
Done 
