User talk:Thunderbird2/The case against deprecation of IEC prefixes

IDEMA standard

what is a gigabyte?

Tom, I read that idema standard, which was new to me. I can't see how it follows from it that 1 GB = 1,000,194,048 B. Can you explain that please? Thunderbird2 (talk) 07:03, 6 August 2008 (UTC)

It is one interpretation of the formula at the bottom of the article:

LBA count = 97696368 + (1953504 * (Desired Capacity in Gbytes – 50.0))

In the case of HDDs logical blocks (LBAs) are 512 bytes so the marginal value of a Gbyte is

1,953,504 logical blocks x 512 bytes/logical block = 1,000,194,048 bytes

the other constant, 9,7696,368 is 50,020,540,416 bytes which does not divide into a whole number for Gbyte.

I suppose it is more accurate to say that IDEMA has a "variable" definition of Gbyte for ATA HDDs starting with 1,011,032,064 bytes for a 1 GB HDD and 1,000,194,048 bytes per GByte there after. I am going to change the footnote to use the terms logical blocks but I think it would be TMI to go to this detail (I can be convinced otherwise :-) ).

FWIW, I checked several ATA and SATA drive specifications by different manufacturers and found them compliant to this spec. I haven't checked the SCSI side for this issue, but I bet they comply. The reason it is important, of course, is this is how the drive responds to the systems when queried about its capacity, a hexidecimal string listing the number of 512 byte logical blocks (SCSI does support other block sizes and SATA will). How the OS presents that is the source of confusion. There are no prefixes at this level! It always has seemed sloppy, inconsistent and strange to me that the OSs change the hex string into into decimal number with binary prefixes - decimal numbers with decimal prefixes or hex numbers with hex prefixes make a lot more sense. Tom94022 (talk) 17:02, 6 August 2008 (UTC)

I see - well, I think I do. The key is in understanding that an LBA is 512 bytes, right? (what does the "A" stand for btw?). Anyway, assuming I've understood this at all, I would suggest a slightly different interpretation, as follows: Let

• C = true drive capacity, and
• N = nominal capacity / (1 GB), such that N=80 corresponds to a nominal "80 GB" drive

The relationship between C and N is then (from IDEMA)

• C / (512 B) = 97696368 + 1953504(N-50),

which can be written instead

• C = 8(1323 + 122094N) KiB.

In this interpretation, 1 GB = 10⁹ B exactly, but an "80 GB" drive has approximately, but not exactly 80 GB (the precise capacity, if I've done the sums right, being 78,150,744 KiB = 80.026 361 856 GB). This interpretation seems simpler to me because it doesn't require any departure from the standard SI prefix values. Thunderbird2 (talk) 23:14, 8 August 2008 (UTC)

That doesn't change the fact that an IDEMA GB is 1,000,194,048 bytes. Fortunately the difference is small enough that it doesn't create a rounding error until about 2,521 TB (2,438.3 TiB) at which point a the actual capacity rounds to 2522 TB (2,439.3 TiB) and no one is going to complain that they got an extra ½ TB. Tom94022 (talk) 00:33, 9 August 2008 (UTC)

Well, they might complain but they're unlikely to get much compensation for it :). Seriously though, the IDEMA document does not really define the term "gigabyte", but rather provides a means to convert "desired capacity" (N) into actual capacity (C). I'll take another look at the footnote and perhaps suggest an alternative wording. Thunderbird2 (talk) 08:25, 9 August 2008 (UTC)

Returning to the arithmetic, a neat way of expressing the relationship between C and N is

• C/GB - N = 0.010 838 016 + 0.000 194 048 N,

or (equivalently)

• C - (N GB)= 10,838,016 B + 194,048 N B.

Written like this, you see immediately that the IDEMA standard results in a minimum of 10.8 MB (a nominal "0 GB" drive would have a capacity of 10.8 MB), with an extra 194 kilobytes per gigabyte. Thunderbird2 (talk) 08:33, 9 August 2008 (UTC)

summary table

In tabular form:

nominal capacity in gigabytes (N)	true capacity in kibibytes (C/KiB)	true capacity in bytes (C/B)	extra capacity in bytes (C/B - 109N)	extra capacity in kibibytes (C/KiB - 109N/1024)
50	48 848 184	50 020 540 416	20 540 416	20 059
80	78 150 744	80 026 361 856	26 361 856	25 744
160	156 290 904	160 041 885 696	41 885 696	40 904
240	234 431 064	240 057 409 536	57 409 536	56 064

I just calculated the extra capacity in units of kibibytes, and was surprised to see the answer is an integer for all 4 examples. (See last column) Do you understand why that is? Thunderbird2 (talk) 09:39, 9 August 2008 (UTC)

It is the precision of the number and the even numbers you picked. Since the LBA today is 512 bytes, extra capacity in KiB doesn't have to be an integer but that would require an odd number of LBAs (in more ways than one). Try 50.5 for example Tom94022 (talk) 19:06, 9 August 2008 (UTC)

the IDEMA footnote

I added an extra bullet and had a stab at rewording the footnote. See what you think. Thunderbird2 (talk) 11:19, 9 August 2008 (UTC)

Looks good to me Tom94022 (talk) 19:06, 9 August 2008 (UTC)