Misplaced Pages

Revision as of 09:28, 9 August 2008

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.

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: