Talk:IEC 60027

Since computers calculate and manage data in base two, of which there are two states for each bit (on or off). It makes no sense to discuss information in base ten. A Kilobit thus must be counted in units that are aligned with byte quantitites.


 * One Kilobit = 1024 bits.
 * One Megabit = 1024 Kilobits.
 * One Gigabit = 1024 Megabits.
 * One Terabit = 1024 Gigabits.

This would make the conversion from bits to bytes easier:


 * 1/8 Kilobyte = One Kilobit.
 * 1/8 Megabyte = One Megabit.
 * 1/8 Gigabyte = One Gigabit.
 * 1/8 Terabyte = One Terabit.

When data rates are discussed in base ten, those data rates should be given a seperate unit of quantity and something impossible to confuse with the above.

Like


 * 1000 bits = Decabit = Deca-bit
 * 1000000 bits = DecaDecabit = BiDeca-bit
 * 1000000000 = DecaDecaDecabit = TriDeca-bit
 * 1000000000000 = DecaDecaDecaDecabit = Quad-Deca-bit
 * 1000000000000000 = DecaDecaDecaDecaDecabit = Penta-Deca-bit

Make the unit names different for base 10 measurement versus base 2 measurement. Since in the use of bits and bytes, base 2 was the preference, documentation shouldn't have to be changed to make discussion relevant to base-10 measurements as it would over-complicate existing documentation on existing systems.

Choose a human-friendly unit name for base-10 unit sizes, and a computer-friendly unit name for base-2 unit sizes.

BTW Sales/Advertising people use Mbps, MBps interchangeably, the purpose for this is to cheat/confuse consumers when discussing storage capacities and data rates, this topic is more political than practical.

--Rofthorax 00:16, 1 June 2006 (UTC)

This proposal violates a fundamental rule: never change an already-established measurement, even if the combination of the latin roots forms a different meaning than the intended result. So what if kilobit doesn't mean 1,024 bits in latin? It has been this way since before the 1960's and would make all prior software inaccurate in terms of displayed results. Confusion regarding documentation and legacy products would result from this change. The major proponents for this change are hard drive manufacturers, who claim that they do not need to make hard drives that conform to base-2 units. Frequently they stated on their packaging "30GB Capacity" when in truth they meant "30,000,000,000 Bytes", which would be closer to 27.9 GB. That's 2GB of storage space not being provided by the manufacturers. Rather than amend this error by proposing a base-10 storage allocation unit, they proposed to completely change the definition of kilobyte, megabyte, gigabyte, and so on. The scientific and engineering communities should not have to redefine established units of measurement to accomodate the marketing divisions of certain companies. If hard drive manufacturers really don't want to tack on the extra 2GB, then they can just make a new unit of measurement more appealing to them. --MNGoldenEagle


 * Your "fundamental rule" to "never change an already-established measurement" clearly dictates that the prefix "kilo" must forever maintain its already well-established meaning of "times 1000". That's exactly what this standard did. I have never seen the quantity 9.6 kbit/s to mean anything other than 9600 bit/s, just like 1 kilovolt has never meant 1024 volts and 2 kilohertz has never meant 2048 hertz. It is only in the context of silicon memory, where there has been a bit of temporary confusion during the second half of the 20-th century, which has now finally been resolved by applying exactly the principle you suggest. The kilo prefix always means 1000, no question. Well done. (Whether we really do need a prefix for 1024 – and what it should be called – I couldn't care less, as long as it is not "kilo".) Markus Kuhn 19:27, 13 December 2006 (UTC)

Consider, for example, a situation twenty years down the road: university students that need to look up an RFC document written in the early '90s, which utilizes the previous trend of using latin prefixes. Not realizing that the units had been altered, would they unwittingly attempt to create software that works in 1000's instead of 1024's? Also, consider "smart" knowledge databases such as Google. Given a certain value in a specified unit of measurement, it can convert it to another unit of measurement desired. Now let's say that the database can automatically convert these measurements within any document given. Suddenly we encounter an ambiguity: does the KB mean the early version or the later version? We could employ a number of different methods to try and figure this out, but there is no way to be certain. It makes more sense to retain the latin prefixes as they are and change the term "byte" to something else for base-10 counting. This takes care of all ambiguity and allows for us to continue using latin prefixes in either case. MNGoldenEagle 05:39, 20 December 2006 (UTC)
 * True, except for the fact that "kilo" is a number, not a unit of measurement. By itself, it does not measure anything.  "Kilogram" does, and utilized the prefix appropriately.  "Kilobyte" also uses "kilo", but it was used because 1000 is near 1024.  It was assumed that because they were so close to each other, it would be simpler to call it "kilobyte" then to make up a new prefix sequence for binary counting.  Anyone that has has taken a course in computers learns that 1 kilobyte = 1024 bytes, 1 megabyte = 1024 kilobytes, and so on.  This proposal creates a new unit of counting that is more accurate, but is not only more cumbersome to pronounce, but also invalidates all software, hardware, and documents written prior to this ruling.


 * Actually, if you take a course in computing in the 21st century, you are now quite unlikely to hear the simple 1970s story about 1 kilobit = 1024 bits. You are much more likely to hear the story that Wikipedia tells you as well, namely that there was some confusion in this area that was only resolved by introducing the kibibit. Didn't you know that half of your knowledge becomes incorrect every decade or so and needs continuous patching? We need to explain the full history, so people can correctly interpret historic documents. We also need to to explain current best practice for new text and software, and that clearly is that the kilo-prefix should only be used to mean "times 1000". Markus Kuhn 16:33, 1 January 2007 (UTC)


 * 1970s? A kilobit was 1024 bits unless hard/tape drive marketing people were involved. Nobody ever heard of this kibibit nonsense until a bunch of SI trolls invaded wikipedia. Dugodugo (talk) 19:41, 10 June 2012 (UTC)

External links modified
Hello fellow Wikipedians,

I have just added archive links to 1 one external link on IEC 60027. Please take a moment to review my edit. If necessary, add after the link to keep me from modifying it. Alternatively, you can add to keep me off the page altogether. I made the following changes:
 * Added archive https://web.archive.org/20090912150947/http://www.iec.ch:80/news_centre/release/nr2005/nr2005.htm to http://www.iec.ch/news_centre/release/nr2005/nr2005.htm

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

Cheers. —cyberbot II  Talk to my owner :Online 08:36, 19 October 2015 (UTC)

External links modified
Hello fellow Wikipedians,

I have just modified one external link on IEC 60027. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added archive https://web.archive.org/web/20130613121942/http://www.chester.iucr.org/iucr-top/cexec/rep96/idcns.htm to http://www.chester.iucr.org/iucr-top/cexec/rep96/idcns.htm
 * Added tag to http://ej.iop.org/links/rDo33k%2CNb/lrUHtuYE3BGiff6cav5vpA/me0112.pdf

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Cheers.— InternetArchiveBot  (Report bug) 21:27, 7 April 2017 (UTC)

555666 36.37.206.171 (talk) 22:37, 10 February 2024 (UTC)