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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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 - 10⁹N)	extra capacity in kibibytes (C/KiB - 10⁹N/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)[reply]

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)[reply]

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)[reply]

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

It goes back to the 1960s

The misuse of K and M goes back to the 1960s, including the infamous "octal K = 512". -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:27, 15 July 2024 (UTC)[reply]

@Chatul: If u can find a reference to the "octal K = 512" u probably should add it to Timeline_of_binary_prefixes; a quick search on my part found Octal K used in the form of "twelve digit octal integers followed by the letter K, except that leading zeros may be omitted." For example, 127K2 == 000000012700 octal which is really not a binary prefix in the sense of current misusage. Tom94022 (talk) 16:35, 16 July 2024 (UTC)[reply]

I'm afraid that I don't have documentation for the CDC usage octal K = 1000₈ or byte = 12 bits. At the time, I considered the second a lot more reasonable than the first. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:23, 16 July 2024 (UTC)[reply]

@Tom94022: I did find a reference ^[1] for the inconsistent misuse of K at least as far back as 1962, rendering 65536 as "64K" for one machine and "65K" for another. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:29, 18 July 2024 (UTC)[reply]

@Chatul: I can't find any such inconsistency on the Datamation page 31 that you reference and I note on page 33 under "Storage Capacity and Type:" it states "K representing thousands (Example: "32K core" for the IBM 7090 indicates that 32,000 words of magnetic core are available.)." The use in the table beginning on page 34 seems consistent, i.e. 65K, but perhaps there is some inconsistency in the table that you can add to the Timeline_of_binary_prefixes. Note the current earliest documented misuse of k or K in a binary sense is 1964 so a 1962 find should be added. Tom94022 (talk) 06:06, 19 July 2024 (UTC)[reply]

@Tom94022:You clicked on the wrong link: click on the 34 generated from |page=[http://bitsavers.org/magazines/Datamation/196211.pdf#page=36 34] and compare "4-64K core" for L1BRASCOPE 3000 with "16-65K core" for UNIVAC 1107. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:34, 19 July 2024 (UTC)[reply]

@Chatul: Sorry, the double link in one ref confused me. Given the statement in the table's taxonomy, "K representing thousands," and its consistent usage that way in unambiguous sizes elsewhere (e.g. 262K) suggests this single instance in the Librascope entry is a typo rather than a deliberate use of K in a binary sense. Nor does this reference suggest the infamous "octal K = 512." Amdahl (1964) on the other hand clearly used K for 1024 as documented in Timeline_of_binary_prefixes. Tom94022 (talk) 16:52, 19 July 2024 (UTC)[reply]

References

^ Charles W. Adams (November 1962). R. L. PATRICK (ed.). "Computer Characteristics Revisited" (PDF). Datamation. Vol. 8, no. 11. FRANK D. THOMPSON. p. 34. Retrieved July 18, 2024.

[Datamation-1] Charles W. Adams (November 1962). R. L. PATRICK (ed.). "Computer Characteristics Revisited" (PDF). Datamation. Vol. 8, no. 11. FRANK D. THOMPSON. p. 34. Retrieved July 18, 2024.

[1]