Talk:394: Kilobyte

The drivemaker's version here does 'depreciate' their kilobyte, indeed, but rather than based on slipping food-standards (which are often highly regulated) I think this is actually based upon the actual age-old practice of them sometimes using 10³ⁿ (1,000s, 1,000,000s, etc) measures of byte-multiplies in preference to 2¹⁰ⁿ ones (1,024, 1,048,576, etc) in order to get a better figure. For example 20MB drives (back in the old days, this is) with 971,520 bytes (almost 1Mb, by either measure) less than the true binary-matching 20MiB value which various computer OSes would work with. (Or a 'binarily' 20MB drive gets advertised as "20.1MB" one.) On the other hand, something that "needs 20Mb of installation space" might have deliberately been given the binary-divisible version of the unit to make it look marginally less resource-hungry than the decimalised measure would have indicated. Minor differences in their own right, on a bad day when the competing standards mesh badly you might find yourself just short of storage space when you thought you'd be Ok.

Although in real-life the difference between any given unit's interpretation has not changed, as equipment capacities increases and we start to use increasing degrees of prefix upwards, any discrepancy becomes more significant. 1KB is plus or minus 24 bytes (~2%), 1MB is plus or minus around 48KB (~5%), 1GB is plus or minus 73MB (~7%) and 1TB could be very nearly 100Gb short (~10%). For those that care about these things that's at the very least annoying. Like with CRT monitor sizes that were often more an indicator of tube-end size than the true size of the visible/illuminatable portion, giving them an inch or two less of effective display than you might expect. 178.98.31.27 13:55, 18 June 2013 (UTC)

Just to follow-up to myself, based upon a unit capitalisation discrepancy that I only spotted post-posting, but that I won't bother fixing, there's also the old confusion between "kilobits-per-second" and "kilobytes-per-second" (and mega- and giga- versions, more recently with broadband and more advanced ethernets/etc) when it comes to bandwidths and expected speeds. Although you don't necessarily expect to exactly hit the stated limit (with contentions and collisions and latencies and overheads), getting a factor of 8 less than you might have expected has caught people out before, thinking they're getting a far poorer service than advertised... (Not that this has much to do with the above comic, just saying. And, oh lookie here on my desk. A 28,800 'Sportster' PCMCIA faxmodem card (V34, V32bis) with an XJACK® pop-out socket. Why have I still got that?) 178.98.31.27 14:16, 18 June 2013 (UTC)

This table fails to mention, of course, that while a Baker's Kilobyte is 1152 bytes normally, it's 1125 on leap years. Hppavilion1 (talk) 23:21, 26 October 2017 (UTC)

What is the source of the "official" definition of the kilobyte?

From the article at time of creating this topic: "the official definition now states that 1 kilobyte is 1000 bytes". This is official according to whom exactly? I may have missed a citation somewhere but I think this clause needs a citation in the text of the the article. AzureArmageddon 13:50, 3 October 2023 (UTC)

Well, SI and IEC either state or 'recommend' that a kilobyte (kB) is 10³ bytes, while tradition has tended to use KB (capital-K) for 2¹⁰ bytes (obviously open for confusion) while IEC defines this as a 'kibibyte' (KiB). There's several possible cites for that, one really would need to decide which look best/official.

As a general hint to people, though, I think that makes it probably best to just always use explicit KiBs, and mibi/gibi/tebi/etc equivalents, in full or as unit abbreviations, because there might be people who haven't got the memo/don't know whether you got the memo, otherwise. And at least there's a chance that even those unaware of "FOObibytes" will try to find out what these are... unless they just mistake them for typos or read them unconsciously wrongly, but then there's probably more problems than just assuming the wrong base-multiple... ;) 172.70.86.54 17:26, 3 October 2023 (UTC)

I agree with you on that best practice for sure. I don't feel qualified to determine which authority is most authoritative, though. Hoping someone with relevant industry credentials can make a qualified opinion. AzureArmageddon 15:56, 5 October 2023 (UTC)