Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[Bodo Eggert]

Tony Foiani <tkil@scrye.com> wrote:
>>>>>> "David" == David Schwartz <davids@webmaster.com> writes:

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

[...]

> David> Adopting IEC 60027-2 just replaces a set of well-understood
> David> problems with all new problems.
> 
> Which are clearly solved in the standards document, and remove any
> ambiguity.  Is one extra character really that painful to you?

If it's done in order to make disk vendors look good in spite of
advertizing more than they deliver, yes.

1) This change isn't nescensary - any sane person will know that it's not a
   SI unit. You wouldn't talk about megabananas == 1000000 bananas and
   expect to be taken seriously.
2) No sane person would say kibibyte as required by the standard. You'd need
   a sppech defect in order to do this, and a mental defect in order to try.
   So why should anybody adhere to the rest of this bullshit?
-- 
"Whoever said the pen is mightier than the sword obviously never
encountered automatic weapons."
-Gen. Douglas MacArthur
Friß, Spammer: x39bp@lZonner.7eggert.dyndns.org .wq@ZHh.7eggert.dyndns.org

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[Eduard Bloch]

#include <hallo.h>
* Bodo Eggert [Sun, Jan 21 2007, 11:40:40AM]:
> Tony Foiani <tkil@scrye.com> wrote:
> >>>>>> "David" == David Schwartz <davids@webmaster.com> writes:
> 
> > Just last night I formatted some new "500GB" drives, and they
> > eventually came back with 465GB as the displayed capacity.  Wouldn't
> > it make more sense to display that as "465GiB"?
> 
> [...]
> 
> > David> Adopting IEC 60027-2 just replaces a set of well-understood
> > David> problems with all new problems.
> > 
> > Which are clearly solved in the standards document, and remove any
> > ambiguity.  Is one extra character really that painful to you?
> 
> If it's done in order to make disk vendors look good in spite of
> advertizing more than they deliver, yes.
> 
> 1) This change isn't nescensary - any sane person will know that it's not a
>    SI unit. You wouldn't talk about megabananas == 1000000 bananas and
>    expect to be taken seriously.

And I cannot seriosly believe that you are cappable of reading his
examples. Megabananas are a ridiculous demonstration becase of the
object beeing counted itself, but if you take stuff from real life then
I doubt that you expect a kilometer to be 1024 meters. Same for
kilogram. And a megatone is not 1048576 tones, even not 104857600 kg,
and not 107374182400 grams. Wanna more stupid examples created by
abusing decimal units?

> 2) No sane person would say kibibyte as required by the standard. You'd need
>    a sppech defect in order to do this, and a mental defect in order to try.
>    So why should anybody adhere to the rest of this bullshit?

You talk for everybody, or is it just your (and only your) mind refusing
to accept new terms? For my taste, kib and mib are even easier to
speech, easier than {KiLoBytE} resp. {MeGaBytE} or KaaaBe / eMmmBe.

Eduard.
-- 
Das Geheimnis der kleinsten natürlichen Freude geht über die Vernunft
hinaus.
		-- Luc de Clapiers Vauvenargues

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[Benny Amorsen]

>>>>> "BE" == Bodo Eggert <7eggert@gmx.de> writes:

BE> 1) This change isn't nescensary - any sane person will know that
BE> it's not a SI unit. You wouldn't talk about megabananas == 1000000
BE> bananas and expect to be taken seriously.

What about megaparsec? I have also seen graphs delimited in megayears.
Millibar, that's another one. Not that I would have any problems
talking about megabananas, if I ever had to deal with that many
bananas.


/Benny

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[Heikki Orsila]

On Sun, Jan 21, 2007 at 11:40:40AM +0100, Bodo Eggert wrote:
> 1) This change isn't nescensary - any sane person will know that it's not a
>    SI unit. You wouldn't talk about megabananas == 1000000 bananas and
>    expect to be taken seriously.

I've met quite a few non-sane persons then. I find using kilo, mega and 
giga prefixes convenient to use. For example, I often use GEUR to refer 
to Giga Euros, because the word billion is overloaded.

> 2) No sane person would say kibibyte as required by the standard. You'd need
>    a sppech defect in order to do this, and a mental defect in order to try.
>    So why should anybody adhere to the rest of this bullshit?

I think I'm not sane then. I find it easy to use and pronounce.

IEC 60027-2 is a great standard! It removes some annoying ambiquity in 
speech and text. Adhering strictly to proper SI units (k, M, G, ...) 
makes life easier as they are taught in school to everyone.

-- 
Heikki Orsila			Barbie's law:
heikki.orsila@iki.fi		"Math is hard, let's go shopping!"
http://www.iki.fi/shd

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[Jan Engelhardt]

On Jan 21 2007 17:06, Heikki Orsila wrote:
>
>> 2) No sane person would say kibibyte as required by the standard. You'd need
>>    a sppech defect in order to do this, and a mental defect in order to try.
>>    So why should anybody adhere to the rest of this bullshit?
>
>I think I'm not sane then. I find it easy to use and pronounce.
>
>IEC 60027-2 is a great standard! It removes some annoying ambiquity in 
>speech and text. Adhering strictly to proper SI units (k, M, G, ...) 
>makes life easier as they are taught in school to everyone.

Bleh. Except for storage, base 1024 was used for almost everything
I remember. 4 MB memory meant 4096 KB, and that's still the case today.
Most likely the same for transfer rates.
It's just that storage vendors broke the computer rule and went with 1000.
Just teach all the exceptions. No life is without.


	-`J'
-- 

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[Stefan Richter]

Eduard Bloch wrote:
> * Bodo Eggert [Sun, Jan 21 2007, 11:40:40AM]:
>> 2) No sane person would say kibibyte as required by the standard. You'd need
>>    a sppech defect in order to do this, and a mental defect in order to try.
>>    So why should anybody adhere to the rest of this bullshit?
> 
> You talk for everybody, or is it just your (and only your) mind refusing
> to accept new terms?

I'd say it is the refusal to accept new *dumb* terms.
-- 
Stefan Richter
-=====-=-=== ---= =-=-=
http://arcgraph.de/sr/

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[Krzysztof Halasa]

Jan Engelhardt <jengelh@linux01.gwdg.de> writes:

> Bleh. Except for storage, base 1024 was used for almost everything
> I remember. 4 MB memory meant 4096 KB, and that's still the case today.
> Most likely the same for transfer rates.

Nope, transfer rates were initially 1000-based: 9.6 kbps = 9600 bps,
28.8 kbps = 28800 bps, 64 kbps = 64000 bps. Then it went 128, 256,
512 kbps = 512000 bps and 1 Mbps = 2 * 512 kbps = 1024000 bps.

But it's limited mostly to serial interfaces. Other networks use
10, 1000 etc. because they have nothing natural in (powers of) 2
so 1 Mbps may be 1000000 bps as well.

> It's just that storage vendors broke the computer rule and went with 1000.

1024 etc. is (should be) natural to disks because the sector size
is 512 B, 2048 B or something like that.
-- 
Krzysztof Halasa

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[Bernd Petrovitsch]

On Mon, 2007-01-22 at 02:56 +0100, Krzysztof Halasa wrote:
> Jan Engelhardt <jengelh@linux01.gwdg.de> writes:
> 
> > Bleh. Except for storage, base 1024 was used for almost everything
> > I remember. 4 MB memory meant 4096 KB, and that's still the case today.
> > Most likely the same for transfer rates.
> 
> Nope, transfer rates were initially 1000-based: 9.6 kbps = 9600 bps,
> 28.8 kbps = 28800 bps, 64 kbps = 64000 bps. Then it went 128, 256,
> 512 kbps = 512000 bps and 1 Mbps = 2 * 512 kbps = 1024000 bps.

ACK. But this and harddisk sizes are really the only areas.

> But it's limited mostly to serial interfaces. Other networks use
> 10, 1000 etc. because they have nothing natural in (powers of) 2
> so 1 Mbps may be 1000000 bps as well.
> 
> > It's just that storage vendors broke the computer rule and went with 1000.
> 
> 1024 etc. is (should be) natural to disks because the sector size
> is 512 B, 2048 B or something like that.

Yes, but it sounds in commercials better if there is a larger number
there. And you can raise the result of a fraction if you lower the
divisor.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[Andreas Schwab]

Krzysztof Halasa <khc@pm.waw.pl> writes:

> Jan Engelhardt <jengelh@linux01.gwdg.de> writes:
>
>> It's just that storage vendors broke the computer rule and went with 1000.
>
> 1024 etc. is (should be) natural to disks because the sector size
> is 512 B, 2048 B or something like that.

But other than the sector size there is no natural power of 2 connected to
disk size.  A disk can have any odd number of sectors.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[Lennart Sorensen]

On Sun, Jan 21, 2007 at 12:10:00PM +0100, Eduard Bloch wrote:
> And I cannot seriosly believe that you are cappable of reading his
> examples. Megabananas are a ridiculous demonstration becase of the
> object beeing counted itself, but if you take stuff from real life then
> I doubt that you expect a kilometer to be 1024 meters. Same for
> kilogram. And a megatone is not 1048576 tones, even not 104857600 kg,
> and not 107374182400 grams. Wanna more stupid examples created by
> abusing decimal units?

The computer world has a long history of borrowing and abusing terms.
Probably the majority of computer terms came to be that way.  Why should
we change any of them now?  Should we stop calling it booting because
some people might be confused and think it means kicking the computer?
Should we rename threads because people might think it has something to
do with sewing stuff together?

> You talk for everybody, or is it just your (and only your) mind refusing
> to accept new terms? For my taste, kib and mib are even easier to
> speech, easier than {KiLoBytE} resp. {MeGaBytE} or KaaaBe / eMmmBe.

There is too much legacy code and systems around for it to ever be
nonambiguous.  It is too late to fix it, and the units that this
"standard" came up with just sound too stupid to be taken seriously.

You also don't pronounce units just because it looks like you can.  So
KiB is not easier than KB.  Heck most people in speach wouild just call
them Ks (kays or something like that).  And MBs just become Megs.  Same
for Gigs.

Whoever wasted their time coming up with this standard, well they simply
wasted their time.  It will NEVER catch on, and it will never replace
the common usage.  It's about 50 or 60 years to late for that.

--
Len Sorensen

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[Jan Engelhardt]

On Jan 22 2007 10:53, Lennart Sorensen wrote:
>
>> You talk for everybody, or is it just your (and only your) mind refusing
>> to accept new terms? For my taste, kib and mib are even easier to
>> speech, easier than {KiLoBytE} resp. {MeGaBytE} or KaaaBe / eMmmBe.
>
>There is too much legacy code and systems around for it to ever be
>nonambiguous.  It is too late to fix it, and the units that this
>"standard" came up with just sound too stupid to be taken seriously.

For "F"s sake, when you gotta use abbreviations, then just use k=1000 and
K=1024 already, b for bits and B for bytes. Problem gone.

>You also don't pronounce units just because it looks like you can.  So
>KiB is not easier than KB.  Heck most people in speach wouild just call
>them Ks (kays or something like that).  And MBs just become Megs.  Same

kegs perhaps? :)


	-`J'
-- 

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[Alan]

> For "F"s sake, when you gotta use abbreviations, then just use k=1000 and
> K=1024 already, b for bits and B for bytes. Problem gone.

K is Kelvin, k is kilo-

See ISO 31. There is a standard for this stuff which is used worldwide
and only bits of the computing industry appear incapable of following it.

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[Tony Foiani]

>>>>> "Jan" == Jan Engelhardt <jengelh@linux01.gwdg.de> writes:

Jan> For "F"s sake, when you gotta use abbreviations, then just use
Jan> k=1000 and K=1024 already, b for bits and B for bytes. Problem
Jan> gone.

   The one-letter abbreviations are identical to SI prefixes, except
   for "K", which is used interchangeably with "k" (in SI, "K" stands
   for the kelvin, and only "k" stands for 1,000).

   [...]

   BIPM (which maintains SI) expressly prohibits the binary prefix
   usage, and recommends the use of the IEC prefixes as an alternative
   (computing units are not included in SI).

   Some have suggested that "k" be used for 1,000, and "K" for 1,024,
   but this cannot be extended to the higher order prefixes and has
   never been widely recognised.
   -- http://en.wikipedia.org/wiki/Binary_prefix

So if you continue insisting that "MB" is really 2^20 bytes, you're
flouting the SI in at least two ways.  I'd expect that from an USAian,
not a German.  ;-> (To be clear, I *am* a USAian, and I really
desperately wish this country were metric...)

Some other gems from that article that haven't been covered in this
thread:

 * CD-Rs are generally specified in MiB, but DVD-Rs in GB
 * CPU clocks are given in decimal

(See http://en.wikipedia.org/wiki/Binary_prefix#Usage_notes )

It also points out that there are some ongoing lawsuits on exactly
this topic, completely analogous to the CRT diagonal cases.

>>>>> "Alan" == Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

Alan> K is Kelvin, k is kilo-

One nice thing about IEC 60027-2 is that it seems to have fixed the
capitalization inconsistency; kibi- really is "Ki".

(I never cared for the lower-case "k" for "kilo-"; there are other
clashes of symbols in the SI system proper; think "milli-" and
"meter".)

The standard also specifically states that "B", when used with the
binary prefixes, is "byte" not "Bel".  Which is nice.

t.

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[Lennart Sorensen]

On Mon, Jan 22, 2007 at 05:58:42PM +0100, Jan Engelhardt wrote:
> For "F"s sake, when you gotta use abbreviations, then just use k=1000 and
> K=1024 already, b for bits and B for bytes. Problem gone.

And for 10^6 vs 2^20?

> kegs perhaps? :)

Hmm, Mega -> Megs, Kilo -> Kils?

--
Len Sorensen

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[Lennart Sorensen]

On Mon, Jan 22, 2007 at 06:36:19PM +0000, Alan wrote:
> K is Kelvin, k is kilo-

K is a unit is Kelvin, k/K as a prefix is kilo.

> See ISO 31. There is a standard for this stuff which is used worldwide
> and only bits of the computing industry appear incapable of following it.

--
Len Sorensen

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[linux-os (Dick Johnson)]

On Mon, 22 Jan 2007, Lennart Sorensen wrote:

> On Mon, Jan 22, 2007 at 06:36:19PM +0000, Alan wrote:
>> K is Kelvin, k is kilo-
>
> K is a unit is Kelvin, k/K as a prefix is kilo.
>
>> See ISO 31. There is a standard for this stuff which is used worldwide
>> and only bits of the computing industry appear incapable of following it.
>
> --
> Len Sorensen

Perhaps. However, in the days of kilomegacycles (KMC), micromicrofarads
(MMFD), and megohms (MEG), few misunderstood what was being read. Now,
with the international symbols (http://www.bipm.org/si/si_brochure/)
many seem downright confounded because it has turned out be be more
politics than engineering. I well remember an early chart being published
with cycles-per-second as the ordinate and hertz as the abscissa.

There are now "advertising units" where a gigabyte is something greater
than what's really on the drive, where power consumption, clock speeds,
transfer rates, acoustic noise, and other technical specifications
do not have any basis in reality.

It is probably caused by the relegation of computers to "consumer goods."
Such goods brought out such hype as IHF audio power ratings, and EPA
mileage, which have nothing whatsoever to do with reality. It's not just
the specs. In the United States, check out your telephone bill. What
is supposed to be a US$29.95 service, bills out at nearly US$40.00.
"There are lies --and damned lies..."

Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.24 on an i686 machine (5592.59 BogoMips).
New book: http://www.AbominableFirebug.com/
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[Jan Engelhardt]

On Jan 22 2007 15:43, Lennart Sorensen wrote:
>
>On Mon, Jan 22, 2007 at 05:58:42PM +0100, Jan Engelhardt wrote:
>> For "F"s sake, when you gotta use abbreviations, then just use k=1000 and
>> K=1024 already, b for bits and B for bytes. Problem gone.
>
>And for 10^6 vs 2^20?

"My harddisk is a 251 gB" actually even though it is advertised as 250 GB.


	-`J'
-- 

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[Bodo Eggert]

On Mon, 22 Jan 2007, Tony Foiani wrote:

> >>>>> "Jan" == Jan Engelhardt <jengelh@linux01.gwdg.de> writes:
> 
> Jan> For "F"s sake, when you gotta use abbreviations, then just use
> Jan> k=1000 and K=1024 already, b for bits and B for bytes. Problem
> Jan> gone.
> 
>    The one-letter abbreviations are identical to SI prefixes, except
>    for "K", which is used interchangeably with "k" (in SI, "K" stands
>    for the kelvin, and only "k" stands for 1,000).
> 
>    [...]
> 
>    BIPM (which maintains SI) expressly prohibits the binary prefix
>    usage, and recommends the use of the IEC prefixes as an alternative
>    (computing units are not included in SI).
> 
>    Some have suggested that "k" be used for 1,000, and "K" for 1,024,
>    but this cannot be extended to the higher order prefixes and has
>    never been widely recognised.
>    -- http://en.wikipedia.org/wiki/Binary_prefix
> 
> So if you continue insisting that "MB" is really 2^20 bytes, you're
> flouting the SI in at least two ways.

The use of SI is not even accepted on bytes.
See <URL:http://www.bipm.org/utils/common/pdf/si_brochure_8_en.pdf>.

Therefore "MB" is undefined in the SI world, and 2^20 B in the IT world.

>  I'd expect that from an USAian,
> not a German.  ;-> (To be clear, I *am* a USAian, and I really
> desperately wish this country were metric...)

I'd even prefer decimal hours, minutes and seconds.

> Some other gems from that article that haven't been covered in this
> thread:
> 
>  * CD-Rs are generally specified in MiB, but DVD-Rs in GB
>  * CPU clocks are given in decimal

Hz is a supplementary SI unit.
-- 
"Those who would give up essential liberty, to purchase a little
temporary safety, deserve neither liberty nor safety."
	-- Benjamin Franklin, Historical Review of Pennsylvania, 1759

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[Krzysztof Halasa]

Andreas Schwab <schwab@suse.de> writes:

> But other than the sector size there is no natural power of 2 connected to
> disk size.  A disk can have any odd number of sectors.

But the manufacturers don't count in sectors.

It should be consistent, though. "How many GB of disk space do you
need to store 2 GB of USB flash, and how many to store 2 GB RAM image"?
:-)
-- 
Krzysztof Halasa

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[Jan Engelhardt]

On Jan 23 2007 02:04, Krzysztof Halasa wrote:
>Andreas Schwab <schwab@suse.de> writes:
>
>> But other than the sector size there is no natural power of 2 connected to
>> disk size.  A disk can have any odd number of sectors.
>
>But the manufacturers don't count in sectors.
>
>It should be consistent, though. "How many GB of disk space do you
>need to store 2 GB of USB flash, and how many to store 2 GB RAM image"?

Here's the marketing gap a company could jump in:
  "first to count in real GB"


	-`J'
-- 

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[Andreas Schwab]

Krzysztof Halasa <khc@pm.waw.pl> writes:

> Andreas Schwab <schwab@suse.de> writes:
>
>> But other than the sector size there is no natural power of 2 connected to
>> disk size.  A disk can have any odd number of sectors.
>
> But the manufacturers don't count in sectors.

The exact number of sectors is often printend on the label.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[Krzysztof Halasa]

Andreas Schwab <schwab@suse.de> writes:

> The exact number of sectors is often printend on the label.

Sure, I'd even say "almost always" for recent disks. Still, they
count in GBs, not sectors.

OTOH it would be great if they say "xxx,xxx,xxx 512-byte sectors",
and maybe "approx. X GB".
-- 
Krzysztof Halasa

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[Andries Brouwer]

On Sat, Jan 20, 2007 at 09:08:47AM +0100, Michał Kudła wrote:
> Hello,

> after 
> ...
> hdb: max request size: 512KiB
> hdb: 488397168 sectors (250059 MB) w/8192KiB Cache, CHS=30401/255/63, 
> 
> Should be everywere KiB, MiB, GiB, ... according to IEC 60027-2 

You are mistaken. The MB here are actual megabytes (million bytes), not MiB.
Read the code, or do the computation: 488397168*512 = 250059350016.

(Precisely what one wants - the kernel gives the correct size,
just like the disk manufacturers, and there is no discrepancy.
Binary abuse for decimal prefixes is a sloppiness that might be
acceptable for stuff that naturally comes in powers of two.
It is long ago that that was true for disks.)

Andries

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[Lennart Sorensen]

On Sun, Jan 21, 2007 at 10:12:55PM +0100, Jan Engelhardt wrote:
> Same lie like with harddrives. It's around 80, not 100.
> But it depends on how you look at it. 80 for Layer3, possibly
> a little more for Layer2/1.

Strange, I tend to get about 95 for layer 3.

--
Len Sorensen

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[Benny Amorsen]

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

DS> If you are right, a "512MB" RAM stick is mislabelled and is more
DS> correctly labelled as "536.8MB". (With 512MiB being equally
DS> correct.)

DS> Isn't that obviously not just wrong but borderline crazy?

No. It is not obvious to me what is wrong with that. RAM is the only
thing using binary units, everything else is decimal. It is about time
that RAM switched too.


/Benny

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[Roland Kuhn]

[-- Attachment #1.1: Type: text/plain, Size: 1175 bytes --]

Hi Jan!

On 21 Jan 2007, at 22:12, Jan Engelhardt wrote:

>> How fast is your Ethernet port?  100Mbps or 95.37Mbps?
>
> Same lie like with harddrives. It's around 80, not 100.
> But it depends on how you look at it. 80 for Layer3, possibly
> a little more for Layer2/1.
>
Nope, I get consistently 12e6 bytes/sec, which is 96e6 bits/sec  
across 100Mbps ethernet, fitting nicely with the frame overhead (some  
50 bytes out of 1500, without TCP options). So no lie here. With  
gigabit I'm not completely sure yet, still have to see the advertised  
125e6 symbols/sec (got only as far as 115e6 up to now).

Ciao,
                     Roland

--
TU Muenchen, Physik-Department E18, James-Franck-Str., 85748 Garching
Telefon 089/289-12575; Telefax 089/289-12570
--
CERN office: 892-1-D23 phone: +41 22 7676540 mobile: +41 76 487 4482
--
Any society that would give up a little liberty to gain a little
security will deserve neither and lose both.  - Benjamin Franklin
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GS/CS/M/MU d-(++) s:+ a-> C+++ UL++++ P+++ L+++ E(+) W+ !N K- w--- M 
+ !V Y+
PGP++ t+(++) 5 R+ tv-- b+ DI++ e+++>++++ h---- y+++
------END GEEK CODE BLOCK------



[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 4324 bytes --]

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[Tony Foiani]

>>>>> "Tony" == Tony Foiani <tkil@scrye.com> writes:

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

>>>>> "Jan" == Jan Engelhardt <jengelh@linux01.gwdg.de> writes:

Jan> Same lie like with harddrives. It's around 80, not 100.  But it
Jan> depends on how you look at it. 80 for Layer3, possibly a little
Jan> more for Layer2/1.

No, it's not the same lie.  The physical media -- as presented to the
next higher layer -- really has 100Mbps capability.  Likewise, the
"physical media" of a hard drive (as seen outside the controller on
the disk) really is 500GB/465GiB (or whatever). [1]

The overhead caused by Ethernet frames (level 2) and then IP packets
(level 3) and then TCP or UDP (level 4) are more closely related to
the losses you get on filesystem overhead (superblock, inodes,
directories) and "slack" in block-allocated systems (having to round
sizes up to the next 512 or whatever). [2]

The problem is that a drive labelled "500GB" on its packaging is
displayed as "465GB" on the computer.  The fix is to have the computer
display either "500GB" or "465GiB".

t.

[1] SFAIK, what's really on hard drive platters anymore is something
    much closer to "symbols", not just 1s and 0s.  In the same way
    that "baud" is "symbols per second", the actual thingies on the
    platters are symbols, and it's up to the drive electronics to make
    sense of them.

[2] Level numbers from: http://en.wikipedia.org/wiki/TCP/IP_model

RE: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[David Schwartz]

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

> No, I meant to advertise it as a 256 MiB flash device and a 512 MiB
> flash device, as the Mi prefix has a single interpretation, that is 2
> to the power of 20, as per IEC 60027-2, whereas M has not if used
> outside SI units.

If it actually has 256*2^20 bytes, why advertise it as "256 MiB" when "268.4
MB" is equally valid and looks better? It really comes down to this: is it
your position that "256 MB" can only correctly mean 256 million bytes?

If you are right, a "512MB" RAM stick is mislabelled and is more correctly
labelled as "536.8MB". (With 512MiB being equally correct.)

Isn't that obviously not just wrong but borderline crazy? Yes, your position
has some nice consequences, but that doesn't allow you to ignore the bad
ones.

Unfortunately, we're not writing on a clean slate here.

DS

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[Jan Engelhardt]

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

Same lie like with harddrives. It's around 80, not 100.
But it depends on how you look at it. 80 for Layer3, possibly
a little more for Layer2/1.


	-`J'
-- 

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[H. Peter Anvin]

Geert Uytterhoeven wrote:
> 
> Yeah, and Ethernet speed is measured in Mbps, not Mibps.
> 

Indeed.

	-hpa

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[Geert Uytterhoeven]

On Sat, 20 Jan 2007, H. Peter Anvin wrote:
> David Schwartz wrote:
> > 	Talk about a cure worse than the disease! So you're saying that 256MB
> > flash
> > cards could be advertised as having 268.4MB? A 512MB RAM stick is
> > mislabelled and could correctly say 536.8MB? That's just plain craziness.
> > 
> > 	Adopting IEC 60027-2 just replaces a set of well-understood problems
> > with
> > all new problems.
> 
> Except that you're wrong above.  Most 512 MB flash cards are less than 512
> MiB; most of them are, in fact, around 512 MB!  RAM, of course, is
> consistently 512 MiB.
> 
> This little tidbit discovered in the process of working on an application
> which required powers-of-two flash cards, and finding that one does have to
> use one size larger...

Yeah, and Ethernet speed is measured in Mbps, not Mibps.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[Leon Woestenberg]

David,

On 1/20/07, David Schwartz <davids@webmaster.com> wrote:
> [Leon said:]
> > One way of getting rid of those inconsistencies would be to follow IEC
> > 60027-2 for those cases where SI is inappropriate.
>
>         Talk about a cure worse than the disease! So you're saying that 256MB flash
> cards could be advertised as having 268.4MB? A 512MB RAM stick is
> mislabelled and could correctly say 536.8MB? That's just plain craziness.
>
No, I meant to advertise it as a 256 MiB flash device and a 512 MiB
flash device, as the Mi prefix has a single interpretation, that is 2
to the power of 20, as per IEC 60027-2, whereas M has not if used
outside SI units.

Leon.

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[H. Peter Anvin]

David Schwartz wrote:
> 
> 	Talk about a cure worse than the disease! So you're saying that 256MB flash
> cards could be advertised as having 268.4MB? A 512MB RAM stick is
> mislabelled and could correctly say 536.8MB? That's just plain craziness.
> 
> 	Adopting IEC 60027-2 just replaces a set of well-understood problems with
> all new problems.
> 

Except that you're wrong above.  Most 512 MB flash cards are less than 
512 MiB; most of them are, in fact, around 512 MB!  RAM, of course, is 
consistently 512 MiB.

This little tidbit discovered in the process of working on an 
application which required powers-of-two flash cards, and finding that 
one does have to use one size larger...

	-hpa

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[Tony Foiani]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

t.

RE: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[David Schwartz]

> Nice observation, however, it still leaves quite an amount of internal
> inconsistencies in the kernel output.

	I agree with the majority view that using the term 'MB' or 'GB' to mean a
million or a billion bytes is inaccurate. The way RAM and flash are measured
is correct. The way disk manufacturers advertise disk capacity is simply
*wrong*. There is no word for a million bytes. There is no word for a
billion bytes.

> One way of getting rid of those inconsistencies would be to follow IEC
> 60027-2 for those cases where SI is inappropriate.

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

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

	DS

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[Leon Woestenberg]

Hello,

On 1/20/07, David Schwartz <davids@webmaster.com> wrote:
>
> > [1.] One line summary of the problem:
> > KB->KiB, MB -> MiB, ... (IEC 60027-2 Letter symbols to be used in
> > electrical
> > technology – Part 2)
> > Should be everywere KiB, MiB, GiB, ... according to IEC 60027-2
>
>         Bytes are not an SI unit. A "megabyte" doesn't have to be a million bytes any more than a "megaphone" has to be a million phones. A "megabyte" is 1,048,576 bytes. The "mega" in there is not an SI prefix. "Mega" is only an SI prefix when it appears before an SI unit.
>
Nice observation, however, it still leaves quite an amount of internal
inconsistencies in the kernel output.

One way of getting rid of those inconsistencies would be to follow IEC
60027-2 for those cases where SI is inappropriate.

Leon.

RE: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[David Schwartz]

> [1.] One line summary of the problem: 
> KB->KiB, MB -> MiB, ... (IEC 60027-2 Letter symbols to be used in 
> electrical 
> technology – Part 2)
> Should be everywere KiB, MiB, GiB, ... according to IEC 60027-2 

	Bytes are not an SI unit. A "megabyte" doesn't have to be a million bytes any more than a "megaphone" has to be a million phones. A "megabyte" is 1,048,576 bytes. The "mega" in there is not an SI prefix. "Mega" is only an SI prefix when it appears before an SI unit.

	DS

PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[Michał Kudła]

Hello,
according to  http://www.kernel.org/pub/linux/docs/lkml/reporting-bugs.html
[1.] One line summary of the problem: 
KB->KiB, MB -> MiB, ... (IEC 60027-2 Letter symbols to be used in electrical 
technology – Part 2)
[2.] Full description of the problem/report:
kernel: 2.6.19
linux: gentoo

after 
#dmesg
I find somethings like it

Memory: 515992k/524224k available (1909k kernel code, 7684k reserved, 768k 
data, 172k init, 0k highmem)
virtual kernel memory layout:
    fixmap  : 0xfffb7000 - 0xfffff000   ( 288 kB)
    vmalloc : 0xe0800000 - 0xfffb5000   ( 503 MB)
    lowmem  : 0xc0000000 - 0xdfff0000   ( 511 MB)
      .init : 0xc03a0000 - 0xc03cb000   ( 172 kB)
      .data : 0xc02dd6d6 - 0xc039d8f4   ( 768 kB)
      .text : 0xc0100000 - 0xc02dd6d6   (1909 kB)
...
hdb: max request size: 512KiB
hdb: 488397168 sectors (250059 MB) w/8192KiB Cache, CHS=30401/255/63, 
UDMA(100)
hdb: cache flushes supported
 hdb: hdb1 hdb2 hdb3
hdc: ATAPI 40X DVD-ROM DVD-R CD-R/RW drive, 2000kB Cache, UDMA(66)


Should be everywere KiB, MiB, GiB, ... according to IEC 60027-2 

http://www.iec.ch/zone/si/si_bytes.htm
http://en.wikipedia.org/wiki/Kibibyte

[3.] Keywords (i.e., modules, networking, kernel):
modules, networking, kernel,... everywere
[4.] Kernel version (from /proc/version):
Linux version 2.6.19-gentoo-r4 (root@athlonik) (gcc version 4.1.1 (Gentoo 
4.1.1-r3)) #1 Fri Jan 19 22:22:39 CET 2007
[5.] Output of Oops.. message (if applicable) with symbolic information 
     resolved (see Documentation/oops-tracing.txt)
none
[6.] A small shell script or example program which triggers the
     problem (if possible)
dmesg | grep -E '(KB)|(KiB)|(MB)'
[7.] Environment
linux
[7.1.] Software (add the output of the ver_linux script here)
[7.2.] Processor information (from /proc/cpuinfo):
cat  /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 8
model name      : AMD Athlon(tm) XP
stepping        : 1
cpu MHz         : 1666.742
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat 
pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow ts
bogomips        : 3335.02

[7.3.] Module information (from /proc/modules):
not important
[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
not important
[7.5.] PCI information ('lspci -vvv' as root)
not important
[7.6.] SCSI information (from /proc/scsi/scsi)
not important
[7.7.] Other information that might be relevant to the problem
       (please look in /proc and include all information that you
       think to be relevant):
not important
[X.] Other notes, patches, fixes, workarounds:
“That’s one small step for a man, one giant leap for mankind.”  - Neil 
Armstrong