Author Topic: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?  (Read 17688 times)

0 Members and 1 Guest are viewing this topic.

Offline JV1234

  • Newbie
  • Posts: 4
So I can't get use to this Kibi/Mibi/Gibi-byte thing.  Are they catching on, are is it a failed redefinition by IEC / SI?

I've been reading forums (on this forum, from 2013, and a hijacked post here: http://www.tomshardware.com/forum/282404-32-wanted-backup-strategy), and I don't see a good reason for using KiB/MiB/GiB.

And how many people are using KiB when they use to use KB today?
Comments?
« Last Edit: September 13, 2014, 04:20:51 am by JV1234 »
 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5549
  • Country: us
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #1 on: September 13, 2014, 04:26:26 am »
Plenty of comments here

https://www.eevblog.com/forum/chat/kibibyte-and-mebibyte-wtf/

also it showed up on a metric discussion.

At least in the gaming industry we still use kilobytes as 1024 bytes and I don't see any sign of change other than unix kernel messages to the user.
 

Offline marshallh

  • Supporter
  • ****
  • Posts: 1462
  • Country: us
    • retroactive
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #2 on: September 13, 2014, 04:33:14 am »
Overly pedantic types love it.
And those of us with things to get done just move on.
Verilog tips
BGA soldering intro

11:37 <@ktemkin> c4757p: marshall has transcended communications media
11:37 <@ktemkin> He speaks protocols directly.
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4624
  • Country: au
  • Question Everything... Except This Statement
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #3 on: September 13, 2014, 05:05:23 am »
Why not argue to have file sizes represented in scientific notation? e.g. 2x2^10

for every extra 10 powers it is equivalent to the argued decimal order or magnitude, e.g. x1024,

It then becomes immediately apparent whether or not your file will fit, at least basing off the discussions from the other thread,
 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5549
  • Country: us
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #4 on: September 13, 2014, 05:10:47 am »
Can someone link the JEDEC standard referred to?

JEDEC still defines 1024 as a kilobyte, we are safe :)
 

Offline JV1234

  • Newbie
  • Posts: 4
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #5 on: September 13, 2014, 05:52:03 am »
You can look here http://en.wikipedia.org/wiki/Kibibyte to see a reference to the JEDEC standard.
 
And miguelvp, thanks for the link.  Yeah I read a bunch of those comments. 

After reading all the comments that I have, I just don't understand why we don't just treat K/M/G/... as Base-10 numbers (1000^1/2/3) only if they are not prefixing a computer term such as bits or bytes.  Otherwise K/M/G/... are Base-2 numbers (1024^1/2/3) for computer terms. 
Seems pretty cut and dry, with no confusion. 
It is just when the marketing people go and use Base-10 numbers to try and make their HDDs look bigger, or perhaps when the Telecom industry uses Base-10 numbers to try and make their data rates look bigger (1.5 Gbps, 44kbps, etc) that things get confusing. 
After all, lots of symbols in science and math have multiple meanings based on context, so why can't K/M/G/... ? http://en.wikipedia.org/wiki/Greek_letters_used_in_mathematics,_science,_and_engineering

Wouldn't this be simple, less confusing, and sound better (compared to speaking KiB)?


 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5549
  • Country: us
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #6 on: September 13, 2014, 06:01:52 am »
because 1000 doesn't have a good binary representation so programmers won't use it.

1000 decimal in binary is 00000011 11101000
1024 decimal in binary is 00000100 00000000

1000000 in binary is 00001111 01000010 01000000
1024x1024 (1MB) in binary is 00010000 00000000 00000000

so 1024 is 1 shifted left 10 positions or 2^10
and 1024x1024 is 1024 shifted left 10 positions or 2^20

Leave metric to base ten stuff and leave our base two stuff alone  >:D

And we don't use KiB , we use KB and it means 1024 like the JEDEC standard says.

Edit, after all a byte is not decimal it's 8 bits with 256 values [0-255], makes no sense to treat it as a decimal like the metric table in that wiki page does.

Maybe they are going to force the byte to only go from 0-99 wasting the rest of the storage so it fits neatly in the decimal metric system.

« Last Edit: September 13, 2014, 06:07:51 am by miguelvp »
 

Offline Artlav

  • Frequent Contributor
  • **
  • Posts: 750
  • Country: ru
    • Orbital Designs
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #7 on: September 13, 2014, 09:45:51 am »
Well, it allows the HDD manufacturers to cheat with disk capacities.
Giga- means 1e9, right? So here you go with 500 Gigabytes HDD, and we keep the extra 36 Gb you were supposed to get.

Even SSD makers start doing such shenanigans nowadays, despite playing it fair in the earlier days.

Seriously, it's like with + and - in electricity now.
It would have been great to make the electron's charge positive as it should be, but there is not enough magic smoke left in the world to survive the change, and confusion would last for generations.
Hacking the universe since 2008
Having a life since 2013
 

Offline Tinkerer

  • Frequent Contributor
  • **
  • Posts: 346
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #8 on: September 13, 2014, 03:53:02 pm »
I think we are safe and that kilo, mega, etc will stand. They have been in use fo decades now and they are in no way changing over night.
If any kind of standard like this is going to change, it would need to basically take an instant worldwide revolution on understanding of something, some sort of massive disaster leaving only a few people to make decisions for the future, or 50+ years(or some long time period like that).
 

Offline Richard Crowley

  • Super Contributor
  • ***
  • Posts: 4310
  • Country: us
  • KE7GKP
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #9 on: September 13, 2014, 04:32:47 pm »
It is a pedantic solution to a pedantic "problem".  Most of us don't care and have better things to worry about.
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2287
  • Country: nz
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #10 on: September 13, 2014, 06:49:46 pm »
I have problems with this at work. We have various different storage system, and when I create a 2TB disk I end up with somewhere between 2x10^12 and 2^40 (a 10% difference) depending on which storage system and user interface (GUI, CLI, script...) I use.

The only other time it gets annoying for me is with bandwidth - 1 Mb/s is always 1,000,000 bits per second, never 1,048,576 bits per seconds... so if I need to transfer 1Gb over a 1Gb/s link it will take 1.07 seconds.
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Offline saturation

  • Super Contributor
  • ***
  • Posts: 4788
  • Country: us
  • Doveryai, no proveryai
    • NIST
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #11 on: September 13, 2014, 08:28:45 pm »
It will catch on but it will take decades as its taught in schools and used for many academic papers.

However, a practical need today is insure you are aware of the quota on your dataplans contract, if you have one.  In the USA, Verizon will charge $0.25 per mebibyte above your plan quota or escalate you to the next tier once over the quota.   

So to insure you don't truly go over your quota be sure you check what exactly your cellphone dataplan really means in terms of gigabyte or gibibytes.

For example, in those 2 terms the difference is 72MiB or $18.50 in surcharges/month.  Or if your contract calls for a next tier clause, then at 1GiB+ 1 byte you pay an extra $10 up to 2 GiB, another $10 when you exceed 2 GiB etc.,

FWIW Verizon does define what megabyte means, which is a mebibyte.


Best Wishes,

 Saturation
 

Offline JV1234

  • Newbie
  • Posts: 4
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #12 on: September 14, 2014, 04:39:15 am »
Good point "saturation".

And I agree it does seem to be a very fussy solution to a problem that didn't really seem to be a problem.

And I still don't understand why they [IEC/SI/Gov.] don't just treat K/M/G/... as Base-10 numbers (1000^1/2/3) only if they are not prefixing a computer term such as bits or bytes.  Otherwise K/M/G/... are Base-2 numbers (1024^1/2/3) for computer terms.
That would cover software, hardware, technical specs / marketing specs... everything.  If it was made law, there would be no confusion and no need for Verizon to "define" their terms.  And no HDD marketing tricks that would result in a law suit.

Seems pretty cut and dry, with no confusion.

Anyway, that is how I currently treat it.. and I :palm: when I run into people not doing this.
 

Offline vk6zgo

  • Super Contributor
  • ***
  • Posts: 5373
  • Country: au
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #13 on: September 14, 2014, 05:06:39 am »
The problem was driven by the obsessive need by IT people to mess with perfectly good definitions .
1024 was "pretty close to" 1000,so why not?--sloppy,but what do you expect from geeks?

It didn't really matter when "everyone knew what was meant".----it just annoyed RF techs & EEs who weren't part of the "in" group.
When the "general public" got their hands on it,the disparity became a problem,& got all the IT guys "knickers in a twist".

I'd like to see the IT people brought to task for their incorrect usage of the term "bandwidth",but that will never happen,the general public love it,as do the "tech savvy" (read "know nothing") Politicians! >:(
 

Offline rs20

  • Super Contributor
  • ***
  • Posts: 2188
  • Country: au
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #14 on: September 14, 2014, 05:19:48 am »
I love all this emotional "awww, people got upset and so they changed it". OK, the metric system is dumb because "awww, people couldn't figure out imperial units, diddums". Use logic, for goodness' sake.

Quoting JEDEC as one's justification for defining kilo- as 1024 a is pretty telling stretch because JEDEC's core focus is memory and flash chips (I can't stress this enough, chips, not HDDs and SSD modules). The chips are obviously addressed and built in powers of 2, so 1024 is so obviously what is meant by kilo- in that context.  There's no ambiguity in that space, so spending an hour at JEDEC's board devloping a resolution use kibi- is obviously a waste of time -- for JEDEC and its members. Where one makes a huge and stupid leap is when they appeal to JEDEC's standard when describing the quota on their 2TB hard drive, or attacking the concept of kibi-. The IEC are far more broadly focussed and relevant to our everyday lives than JEDEC, the unit "has been accepted for use by all major standards organizations, and is part of the International System of Quantities", it's just another option on your plate. Appealing to JEDEC is cherrypicking.

Whenever you use KiB, MiB, etc, you make your reader's life easier because they immediately know what you mean. All you have to do is hit the "i" key, and a cloud of ambiguity vanishes. Of course, if you mean power-of-10 (kB, MB), the same ambiguity still exists (these days), but the hope is that those usages will erode over many years. Change aversion is so cute.
 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5549
  • Country: us
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #15 on: September 14, 2014, 05:24:58 am »
Don't blame IT, our IT department knows what 1KB is and what 1Kbps is and what 1MB means on drives compared to Memory.
IT never messes with things they just work with what it is.

It's always been a marketing ploy.

For me IT is there for a reason, they know more than you think they do.

Edit: And don't get me started with mega pixel where they treat each RGB component separate, so if a display had say 4leds per pixel for some kind of better color rendition they will multiply each pixel times 4 instead of 3.
Meh, it's all marketing, that's why on displays you gotta look at resolution, same with cameras where all the Mega Pixel started when 1 Mega Pixel is really 1 Million pixels divided by 3 instead of 1024x1024 full color.
« Last Edit: September 14, 2014, 05:31:44 am by miguelvp »
 

Offline Fsck

  • Super Contributor
  • ***
  • Posts: 1157
  • Country: ca
  • sleep deprived
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #16 on: September 14, 2014, 05:26:01 am »
Good point "saturation".

And I agree it does seem to be a very fussy solution to a problem that didn't really seem to be a problem.

And I still don't understand why they [IEC/SI/Gov.] don't just treat K/M/G/... as Base-10 numbers (1000^1/2/3) only if they are not prefixing a computer term such as bits or bytes.  Otherwise K/M/G/... are Base-2 numbers (1024^1/2/3) for computer terms.
That would cover software, hardware, technical specs / marketing specs... everything.  If it was made law, there would be no confusion and no need for Verizon to "define" their terms.  And no HDD marketing tricks that would result in a law suit.

Seems pretty cut and dry, with no confusion.

Anyway, that is how I currently treat it.. and I :palm: when I run into people not doing this.

networking processors/ASICs is where your terminology is truly useful for absolute clarity.

your interface has a transfer rate in base 10 and you have memory in base 2. you're going to be using both so might as well state them in no uncertain terms.
"This is a one line proof...if we start sufficiently far to the left."
 

Offline rs20

  • Super Contributor
  • ***
  • Posts: 2188
  • Country: au
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #17 on: September 14, 2014, 05:44:02 am »
Meh, it's all marketing, that's why on displays you gotta look at resolution, same with cameras where all the Mega Pixel started when 1 Mega Pixel is really 1 Million pixels divided by 3 instead of 1024x1024 full color.

You mean 1000x1000 full colour  :)
 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5549
  • Country: us
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #18 on: September 14, 2014, 05:46:58 am »
Meh, it's all marketing, that's why on displays you gotta look at resolution, same with cameras where all the Mega Pixel started when 1 Mega Pixel is really 1 Million pixels divided by 3 instead of 1024x1024 full color.

You mean 1000x1000 full colour  :)

No I don't :)

Edit: but it seems a 640x480 camera is 0.3 Mega pixel so I guess they did stop doing that even they are rounding down 307,200 pixels would be 0.3072 Mega Pixel base 10, or 0.29296875 base 2 using 1024 instead of 1000.



« Last Edit: September 14, 2014, 06:03:35 am by miguelvp »
 

Offline rs20

  • Super Contributor
  • ***
  • Posts: 2188
  • Country: au
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #19 on: September 14, 2014, 06:09:45 am »
You mean 1000x1000 full colour  :)

No I don't :)

Edit: but it seems a 640x480 camera is 0.3 Mega pixel so I guess they did stop doing that even they are rounding down 307,200 pixels would be 0.3072 Mega Pixel base 10, or 0.29296875 base 2 using 1024 instead of 1000.

Have megapixels ever meant 2^20 pixels?
 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5549
  • Country: us
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #20 on: September 14, 2014, 06:27:40 am »
Nope but it should have been in my opinion.

Now 1K on TVs is 1920x1080 and 4K is 4 times that.
How is 2073600 pixels 1K?

Edit: That's actually 1024*2025 it's like IBM times HAL.

Marketing just confuses things, well not really since it doesn't really matter, we can adjust to any new form of counting easily.


« Last Edit: September 14, 2014, 06:30:27 am by miguelvp »
 

Offline rs20

  • Super Contributor
  • ***
  • Posts: 2188
  • Country: au
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #21 on: September 14, 2014, 06:51:54 am »
Nope but it should have been in my opinion.

Now 1K on TVs is 1920x1080 and 4K is 4 times that.
How is 2073600 pixels 1K?

Edit: That's actually 1024*2025 it's like IBM times HAL.

Marketing just confuses things, well not really since it doesn't really matter, we can adjust to any new form of counting easily.

 :o Why would you endorse even more confusion by saying that megapixels should be 2^20 pixels? Pointing out that marketing people make up crap does not justify you making up crap, that's just terribly perverse.
 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5549
  • Country: us
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #22 on: September 14, 2014, 07:00:44 am »
It was a tongue in cheek comment, I really don't mind any of it at all. No matter what I'll adapt.

But I would like my pay to be in 1024 K not those decimal 1000 K, wait it's thousands an millions, hmm they better get into changing those as well

stop using milions billions and trillions, they mean different things in different countries, use Mega Giga and Tera and be consistent!

Yup the units are all weird but somehow we just cope with what ever it is.
 

Offline vk6zgo

  • Super Contributor
  • ***
  • Posts: 5373
  • Country: au
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #23 on: September 14, 2014, 07:40:52 am »
They stuffed up "pixels" too!

Pixels date back to photographic practice,where resolution  was measured with "resolution lines"

These were the smallest detail which the medium could produce.
If a standard "3x4"picture could resolve say,1000 vertical lines & 750 horizontal lines it was said to be able to display  750,000 "picture elements" (hence "pixels"),as the horizontal & vertical resolution of photographic film is equal.

TV with CRTs messed things around a bit,as the vertical resolution (how many horizontal resolution lines it could display) was limited by the number of "scanning lines" making up the picture,whereas the horizontal resolution was limited by the bandwidth (occupied spectrum) of the system used.

Ideally,horizontal & vertical resolution should be equal,but that was not often the case,so "pixels" instead of being nice squares like in film,became rectangles.

Up to this point,pixels were really just a concept,not something real,but with the advent of modern camera & display technology,the individual elements of the display or camera sensor,in fact,became the pixels.so you could,in theory,if you have the time,a good magnifying glass & memory,count the pixels on your display.

So far,so good,but then you have the "tech savvy" halfwits of the popular media referring to a TV as having "so many" horizontal pixels & "some other number" of vertical pixels.

To technically informed Greybeards this is gibberish!

 

Offline JV1234

  • Newbie
  • Posts: 4
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #24 on: September 14, 2014, 09:04:16 pm »
Good point "saturation".

And I agree it does seem to be a very fussy solution to a problem that didn't really seem to be a problem.

And I still don't understand why they [IEC/SI/Gov.] don't just treat K/M/G/... as Base-10 numbers (1000^1/2/3) only if they are not prefixing a computer term such as bits or bytes.  Otherwise K/M/G/... are Base-2 numbers (1024^1/2/3) for computer terms.
That would cover software, hardware, technical specs / marketing specs... everything.  If it was made law, there would be no confusion and no need for Verizon to "define" their terms.  And no HDD marketing tricks that would result in a law suit.

Seems pretty cut and dry, with no confusion.

Anyway, that is how I currently treat it.. and I :palm: when I run into people not doing this.

networking processors/ASICs is where your terminology is truly useful for absolute clarity.

your interface has a transfer rate in base 10 and you have memory in base 2. you're going to be using both so might as well state them in no uncertain terms.

Yeah, I guess some group would have to change to make things consistent (or perhaps we just needed to inform everyone about the inconsistencies).  So either:
1) Use K / M / G ... in a context sensitive way consistently (or at least in an informed inconsistent way)
2) Or introduce a new term Ki / Mi / Gi ...

I would have preferred the 1st option, instead of IEC's 2nd option, as it would have caused less confusion since we were already pretty much doing this.  The general public that were not in the 'know' in either case would have to learn something new. 

Btw, it took a while for me to figure out the bandwidth was not 'supposed' to be reported in base-2 values.  For a while, in my beginning career, I was reporting my bandwidth values in base-2 K/M/G values.  I bet I confused some people...  :rant:

(btw the rant emoticon is pretty funny)
 

Offline David Hess

  • Super Contributor
  • ***
  • Posts: 11250
  • Country: us
  • DavidH
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #25 on: September 15, 2014, 03:45:01 am »
Let me know when I can buy 32.768k x 8 EPROMs with a part number something like 27C256144.
 

Offline rs20

  • Super Contributor
  • ***
  • Posts: 2188
  • Country: au
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #26 on: September 15, 2014, 04:04:34 am »
Let me know when I can buy 32.768k x 8 EPROMs with a part number something like 27C256144.

... or just don't be dumb and buy 32KiB x 8 EPROMs with the same part number it's always been.  Yours is just ridiculous logic.
 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5549
  • Country: us
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #27 on: September 15, 2014, 06:04:00 am »
Let me know when I can buy 32.768k x 8 EPROMs with a part number something like 27C256144.

... or just don't be dumb and buy 32KiB x 8 EPROMs with the same part number it's always been.  Yours is just ridiculous logic.

I don't see any mention of KiB in the datasheet

http://download.siliconexpert.com/pdfs/2011/10/12/23/41/53/625/atm_/manual/at27c256r-15jc.pdf

It does mention "organized as 32K by 8 bits."

Edit: which is good because at work we don't use KB we use just K and we all know it means 1024
« Last Edit: September 15, 2014, 06:06:39 am by miguelvp »
 

Offline David Hess

  • Super Contributor
  • ***
  • Posts: 11250
  • Country: us
  • DavidH
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #28 on: September 15, 2014, 06:43:23 am »
Let me know when I can buy 32.768k x 8 EPROMs with a part number something like 27C256144.

... or just don't be dumb and buy 32KiB x 8 EPROMs with the same part number it's always been.  Yours is just ridiculous logic.

I picked an old well known old part as a simple example but it applies just as well to new ones.  There is a distinct lack of 67.108864 Mbit SRAM and 4.294967296 Gbit DRAM on the market.
 

Offline rs20

  • Super Contributor
  • ***
  • Posts: 2188
  • Country: au
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #29 on: September 15, 2014, 06:58:49 am »
Let me know when I can buy 32.768k x 8 EPROMs with a part number something like 27C256144.

... or just don't be dumb and buy 32KiB x 8 EPROMs with the same part number it's always been.  Yours is just ridiculous logic.

I picked an old well known old part as a simple example but it applies just as well to new ones.  There is a distinct lack of 67.108864 Mbit SRAM and 4.294967296 Gbit DRAM on the market.

And there's a whole lot of 64 Mib SRAM and 4 Gib DRAM on the market. What's your point? You seem to think that you're being forced to use base-1000 notation when you're actually just being asked to disambiguate whenever you use base-1024. I think taking the latter option, by pressing the 'i' key on your keyboard, is a lot more sensible than stating the capacity in base-1000 with 9 decimal places.  Also, since JEDEC oversees SRAM and DRAM, feel free to adopt JEDEC's standards and call it 64 Mb SRAM as a third option, I'm not going to pedantic and say that that's wrong.  Again, where you go wrong is if you were to think that JEDEC's standards are more relevant and applicable than the IEC's in, let's say, every single context other than RAM and flash chips.
 

Online lpc32

  • Frequent Contributor
  • **
  • Posts: 437
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #30 on: September 15, 2014, 11:47:06 am »
I don't use it because it sounds stupid. If a new notation, my vote is for MB^2 and MB^10, etc.

I never got the cries about "HDD manufacturers are cheating". Base 10 is the most natural one by default, and it's always been used by HDDs.

 

Offline rs20

  • Super Contributor
  • ***
  • Posts: 2188
  • Country: au
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #31 on: September 15, 2014, 01:23:27 pm »
I don't use it because it sounds stupid. If a new notation, my vote is for MB^2 and MB^10, etc.

I never got the cries about "HDD manufacturers are cheating". Base 10 is the most natural one by default, and it's always been used by HDDs.

Even I (a strong supported of KiB, MiB, etc) don't particularly like saying or writing "kibibyte". But I think that's fine; written language is often more precise and unambiguous than spoken English (where there's a chance for the listener to clarify). So if I'm taking notes at a meeting, and someone says "64 megabyte file", I'll write down "64 MiB file" (if that's what was meant). When asked to read it back out, I'll say "64 megabyte files". No-one has to say weird words, but the record is completely unambiguous.

The question of notation is completely orthogonal to the question of pronounciation/how it sounds. So I don't really understand your first two sentences.

I fully concur that while HDD manufacturers were doing it for marketing reasons, they're also doing exactly the right thing.
 

Offline David Hess

  • Super Contributor
  • ***
  • Posts: 11250
  • Country: us
  • DavidH
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #32 on: September 15, 2014, 05:55:58 pm »
I don't use it because it sounds stupid. If a new notation, my vote is for MB^2 and MB^10, etc.

I never got the cries about "HDD manufacturers are cheating". Base 10 is the most natural one by default, and it's always been used by HDDs.

The HDD and other mass storage manufacturers did *not* always use base 10.  I distinctly remember when they made the transition one manufacturer at a time.  There were even heated debates about it online (such as it existed) with the more cynical concluding it was for marketing reasons.  Not long after the change, the whole "formatted versus unformatted" capacity meme was used to justify the difference in numbers even though the discrepancy was insignificant before the change to base 10.

This was all before Eternal September and the rise of the web so supporting documentation is largely offline in paper form.
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 5835
  • Country: nl
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #33 on: September 16, 2014, 02:16:38 pm »
Kilobyte will always mean 1024. To ensure that the new definition fails I started a rival standard where kibibyte = 1000 bytes. Confusion, uncertainty and doubt will destroy it.
nonsense the same argument would then go for kilogram, I can assure you that is never going to change anymore. Better get used to it or make some mistakes in the near future because a smarter colleague did use the right abbreviation.
 

Offline David Hess

  • Super Contributor
  • ***
  • Posts: 11250
  • Country: us
  • DavidH
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #34 on: September 16, 2014, 03:46:06 pm »
Before the IEC got involved, one interesting place where I ran across 1000 versus 1024 is in oscilloscope record lengths but for a different reason it was irrelevant.

All of my DSOs have record lengths that are multiplies of 1024 which would be awkward without a power-of-2 number of points per display division (*) but dividing the standard 1-2-5 sequence into a power-of-2 would also be awkward.  Who wants 31.25, 62.5, or 156.3 nanoseconds per point?

Their solution was to use a power-of-10 number of points per displayed division, 50 or 100 (254 points per inch!) is typical but I have seen modern lower resolution (!) displays with 20 or 25, so 10 divisions of 50 or 100 points yields 500 or 1000 points across the display width and the extra 24 points from the power-of-2 waveform record are displayed through overscan which is rather oddly convenient even if it initially looks like an error.

The only place I have been tripped up by 1000 versus 1024 is when dealing with interfaces where the sample rates were not explicitly specified and they used 1024 or some mixture of 1000 and 1024 instead of 1000.  I am used to dealing with non-power-of-2 data length in power-of-2 length buffers or the reverse to avoid associative cache problems.

(*) Some modern DSOs suffer from aliasing produced when the acquisition record is displayed which is doubly annoying when they advertise huge record lengths as the solution to aliasing.
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 5835
  • Country: nl
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #35 on: September 17, 2014, 12:22:57 pm »
Instead of trying to re-write history and millions of pages of documentation and code, I'm just using KiB to mean multiples of 1000 and keeping the original meaning of KB.
You don't need to rewrite history to be forward compatible you just say from now on it is no longer backwards compatible.
So if you read pre 2009 documents you have to think for yourself if kB is 1000 or 1024 (which was screwed up many times in the past anyway) and for newer documentation just hold on to the standard.
You know if you read roman literature that IV means the numeral 4 and that it means the Initialization vector if you are reading about aes cbc mode encryption.
What you are doing is saying oh darn we were wrong in the past but lets continue to be wrong in the future and really be wrong this time since it has another value.
 

Offline amyk

  • Super Contributor
  • ***
  • Posts: 6822
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #36 on: September 17, 2014, 12:52:12 pm »
I don't use it because it sounds stupid. If a new notation, my vote is for MB^2 and MB^10, etc.

I never got the cries about "HDD manufacturers are cheating". Base 10 is the most natural one by default, and it's always been used by HDDs.

The HDD and other mass storage manufacturers did *not* always use base 10.  I distinctly remember when they made the transition one manufacturer at a time.  There were even heated debates about it online (such as it existed) with the more cynical concluding it was for marketing reasons.  Not long after the change, the whole "formatted versus unformatted" capacity meme was used to justify the difference in numbers even though the discrepancy was insignificant before the change to base 10.

This was all before Eternal September and the rise of the web so supporting documentation is largely offline in paper form.
The 10MB drive in the IBM XT was 306 cylinders, 4 heads, and 17 sectors/track, holding 10653696 bytes. This would be "10.16MB" or even "10.2MB" if they were marketed today.

Manufacturers tended to be even more generous back then - a common size was the 615/4/26 "30MB" drive, that actually contained slightly over 31MB.

If anyone made a 1TB drive that actually contained 2^40 bytes (or more), and marketed it as "1 true TB", at the same price as other "1TB" drives, I'd bet they could gain a lot of marketshare. The difference between a binary/decimal TB is 99,511,627,776 bytes - more than the size of an entire drive several years ago, and good for storing a huge amount more data. They could be clever and say things like "now with bonus 90GB for the same price"!
« Last Edit: September 17, 2014, 01:00:35 pm by amyk »
 

Offline rs20

  • Super Contributor
  • ***
  • Posts: 2188
  • Country: au
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #37 on: September 17, 2014, 01:04:14 pm »
...and marketed it as "1 true TB"...

Also known as 1 TiB...
 

Online lpc32

  • Frequent Contributor
  • **
  • Posts: 437
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #38 on: September 17, 2014, 01:36:04 pm »
Well, that's interesting. When did HDDs transition from MB2 to MB10?
« Last Edit: September 17, 2014, 01:37:40 pm by lpc32 »
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 12135
  • Country: gb
    • Mike's Electric Stuff
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #39 on: September 17, 2014, 02:26:20 pm »
I think a major problem is it just sounds silly.
Until the hard disk manufacturers' marketing dickheads messed things up, you could tell the meaning unambiguously from context - kilobyte = 1024, kilo<anything else> = 1000
 
 
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline SirNick

  • Frequent Contributor
  • **
  • Posts: 589
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #40 on: September 17, 2014, 07:44:22 pm »
A "fix" for a non-problem that invites more confusion (because existing material uses the "wrong" term now) is not a fix for anything.  K, M, G, T, etc., are meant to provide "orders of magnitude" values.  If you want exact amounts, don't use a multiplier.  Specify in bits, bytes, pixels, whatever.

ls -l vs. ls -lh.

There.  No ambiguity.  1,000,000 bytes is 1,000,000 bytes in everyone's parlance.  If you say 1MB, I know you mean "approximately 1 million bytes -- give or take".  Will it fit on a 1MB disk?  I dunno.  Specify that in bytes and see which is larger.  Problem solved, can we stop being ridiculously pedantic now?  ;)
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 5835
  • Country: nl
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #41 on: September 17, 2014, 08:05:41 pm »
  K, M, G, T, etc., are meant to provide "orders of magnitude" values.
K? Oh you mean k.  ;)
 

Offline SirNick

  • Frequent Contributor
  • **
  • Posts: 589
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #42 on: September 17, 2014, 09:01:25 pm »
I'll kut you.  ;D
 

Offline rs20

  • Super Contributor
  • ***
  • Posts: 2188
  • Country: au
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #43 on: September 18, 2014, 12:42:14 am »
I think a major problem is it just sounds silly.
Until the hard disk manufacturers' marketing dickheads messed things up, you could tell the meaning unambiguously from context - kilobyte = 1024, kilo<anything else> = 1000

Also network interfaces? One Mbps is unambiguously 1000000 bps, right? Is One MBps 1048576 Bps? It strikes me that the only thing that does use 1024 is binary address RAM and flash, and a few operating systems that have inappropriately extended this idea on to reporting HDD sizes?

A "fix" for a non-problem that invites more confusion (because existing material uses the "wrong" term now) is not a fix for anything.  K, M, G, T, etc., are meant to provide "orders of magnitude" values.  If you want exact amounts, don't use a multiplier.  Specify in bits, bytes, pixels, whatever.

ls -l vs. ls -lh.

There.  No ambiguity.  1,000,000 bytes is 1,000,000 bytes in everyone's parlance.  If you say 1MB, I know you mean "approximately 1 million bytes -- give or take".  Will it fit on a 1MB disk?  I dunno.  Specify that in bytes and see which is larger.  Problem solved, can we stop being ridiculously pedantic now?  ;)

Not sure if trolling, but this is ridiculously inconsistent. You'd be the sort of person that opposed the introduction of the metric system; that caused *real* problems, but I think we can agree it was the right thing to do in the long run. Make up your mind, is precision important or not?  If you think that it's a good idea for G to unavoidably imply a +/- 10% error, why are you getting so upset about existing material using the "wrong" term now? The existing material was always vague, right, so what difference does it make?

This is one thing that confuses me about all this whinging. The current situation is pretty messed up, but we all get by, I concur. All the IEC is saying is, "here, take this extra available set of prefixes: MiB, GiB, etc". They shall always means precisely 1024, 1048576. What MB means now is completely fuzzy, messed up, and context specific, and of course it will remain so. Anyone who requests a 4MB page from linux and expects a 4,000,000 byte page is an idiot. But what's the problem with introducing a new, parallel, unambiguous option? Saying that kB and MB "will get messed up" is just :palm:
 

jucole

  • Guest
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #44 on: September 18, 2014, 01:32:10 pm »
I don't like KibiByte but then I'm not really one for arranging my food tins in the cupboard with 10mm spacing.
 

Offline rs20

  • Super Contributor
  • ***
  • Posts: 2188
  • Country: au
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #45 on: September 18, 2014, 01:46:35 pm »
I don't like KibiByte but then I'm not really one for arranging my food tins in the cupboard with 10mm spacing.

Real nice. Run out of logic, resort to name-calling.
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 5835
  • Country: nl
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #46 on: September 18, 2014, 01:54:20 pm »
Real nice. Run out of logic, resort to name-calling.
+1  but seeing his nick I was afraid to hear something like "do you feel lucky Punk?"  :-DD
 

jucole

  • Guest
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #47 on: September 18, 2014, 04:41:57 pm »
I don't like KibiByte but then I'm not really one for arranging my food tins in the cupboard with 10mm spacing.

Real nice. Run out of logic, resort to name-calling.

yes because it defies logic;  so what are the benefits of adding a new set of SI units as opposed to making the hard disk manufacturers simply print a correct label?  Which in my case for the drive sat on my desk should just read 465.7 GB and not 500 GB.



 

jucole

  • Guest
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #48 on: September 18, 2014, 04:45:13 pm »
Real nice. Run out of logic, resort to name-calling.
+1  but seeing his nick I was afraid to hear something like "do you feel lucky Punk?"  :-DD

Classic film, but not right!  you're not thinking 4th dimensionally ;-)
 

Offline SirNick

  • Frequent Contributor
  • **
  • Posts: 589
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #49 on: September 18, 2014, 06:45:17 pm »
Not sure if trolling, but this is ridiculously inconsistent.
The second one.  By that I mean I'm trolling you.  (Or do I...?  Could go either way.)

You'd be the sort of person that opposed the introduction of the metric system
And you would be the sort of person who is wrong.  I would like to see it as a worldwide standard, which would mean changing some of my own habits.  I'm a'ight with that.  The difference is, an inch would still be an inch, not "supposedly an inch but maybe a cm".

Make up your mind, is precision important or not?
Of course it is.  That's why, when I need a precise number, I leave off the postfix, and state the real number.  The only time the value is still precise with a SI postfix is when it's a perfect multiple (1.0M), or you specify the value out to the required number of decimal places (32.768k).  If you have to specify more than two or three decimals, you probably shouldn't be shifting scales that lose precision.

But, there are ample times when I need to convey the general quantity of something -- like a 10k resistor, for example.  We understand it may not (and probably won't be) 10,000.000 ohms.  It has a tolerance, also specified if it matters, and we all agree to accept any error one way or the other.  And, we also understand that a 5% error on a 100R resistor is closer to the actual value than 5% on a 1M resistor.  Yet, no one is proposing new units for resistors...

If you think that it's a good idea for G to unavoidably imply a +/- 10% error, why are you getting so upset about existing material using the "wrong" term now? The existing material was always vague, right, so what difference does it make?
I'm not terribly upset about it being "wrong" now, I just find it unhelpful to say there's now an unambiguous unit for 2^x, but the 10^x unit is still just as ambiguous as ever -- except now, it's "supposed to be" accurate too.  The only way you'd know for sure is if someone left a footnote saying "actual MB, not MiB" -- and if it mattered either way, why not footnote with "MB = 1,000,000" as we're doing now?  In most scenarios, "MB = ~1 million" is good enough, so... as I said... it's a non-fix for a non-problem.
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2287
  • Country: nz
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #50 on: September 18, 2014, 11:01:52 pm »
Just to share my pain - customer asks for 250GB disk. I provision 258 GB within the SAN. VMware sees it as 240 GB. I then go back and provision 268 GB.

Then the problem is what do we bill the customer.. sigh!
« Last Edit: September 18, 2014, 11:03:44 pm by hamster_nz »
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Online Monkeh

  • Super Contributor
  • ***
  • Posts: 6423
  • Country: gb
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #51 on: September 18, 2014, 11:09:11 pm »
Just to share my pain - customer asks for 250GB disk. I provision 258 GB within the SAN. VMware sees it as 240 GB. I then go back and provision 268 GB.

Then the problem is what do we bill the customer.. sigh!

You bill them for 250GiB and tell VMWare to fix their crap.
 

Offline SirNick

  • Frequent Contributor
  • **
  • Posts: 589
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #52 on: September 18, 2014, 11:40:15 pm »
Yeah, something's not adding up.  258 * 1,000,000 = 246 * 1024 * 1024.  So either some of the volume size is being reserved elsewhere (by the SAN?) or VMware is screwing up the calculation.  How big does the OS say that LUN is?

(Also, what SAN do you use?  Just curious.)
 

Online Monkeh

  • Super Contributor
  • ***
  • Posts: 6423
  • Country: gb
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #53 on: September 18, 2014, 11:44:38 pm »
Yeah, something's not adding up.  258 * 1,000,000 = 246 * 1024 * 1024.  So either some of the volume size is being reserved elsewhere (by the SAN?) or VMware is screwing up the calculation.

VMWare's not the one screwing up the calculation. It's just using the wrong prefix. 258GB is 240GiB, give or take.
 

Offline SirNick

  • Frequent Contributor
  • **
  • Posts: 589
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #54 on: September 18, 2014, 11:58:40 pm »
Doh. :palm:  I seemed to have misplaced a few zeroes.
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2287
  • Country: nz
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #55 on: September 19, 2014, 12:22:42 am »
(Also, what SAN do you use?  Just curious.)
This SAN is based on Cisco MDS switching (I've got a few I look after), and has storage from a few different vendors on it - in this case the storage is an IBM XIV Gen2 (http://en.wikipedia.org/wiki/IBM_XIV_Storage_System).
« Last Edit: September 19, 2014, 12:24:37 am by hamster_nz »
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Offline timb

  • Super Contributor
  • ***
  • Posts: 2528
  • Country: us
  • Pretentiously Posting Polysyllabic Prose
    • timb.us
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #56 on: September 19, 2014, 01:22:40 am »
You know, I always thought hard drive sizes being in b10 made sense, as there's nothing inherent to a mechanical disk which makes it have to store data the way memory does.

So, I think it makes a lot of sense to have the *ibi prefix to denote b2 measurements. It makes things a lot clearer. What's the harm?

Quit being so adverse to change, you old codgers.


Sent from my Smartphone
Any sufficiently advanced technology is indistinguishable from magic; e.g., Cheez Whiz, Hot Dogs and RF.
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2287
  • Country: nz
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #57 on: September 19, 2014, 02:36:57 am »
You know, I always thought hard drive sizes being in b10 made sense, as there's nothing inherent to a mechanical disk which makes it have to store data the way memory does.

Except 512 byte or 4096 byte sectors - which is important for memory-mapped I/O and virtual memory.  :)

However, at a basic level even that is flexible. On IBM AIX systems you have to reformat disks from 512 bytes/sector to 522 bytes per sector before you can use them with some hardware RAID controllers.

And in the distant past there were 80 column and 96 column punch cards...
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5549
  • Country: us
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #58 on: September 19, 2014, 02:57:08 am »
And in the distant past there were 80 column and 96 column punch cards...

I still have around 3 unused 80 column ones that I used as book place holders :)
 

Offline rs20

  • Super Contributor
  • ***
  • Posts: 2188
  • Country: au
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #59 on: September 19, 2014, 06:18:58 am »
yes because it defies logic;  so what are the benefits of adding a new set of SI units as opposed to making the hard disk manufacturers simply print a correct label?  Which in my case for the drive sat on my desk should just read 465.7 GB and not 500 GB.

The status quo is that whenever you see MB, you have to infer from context what that actually means. With the introduction of this new set of prefixes, writers have the new option of MiB to unambiguously state a power-of-two size, if that makes sense. In many cases (not just HDD manufacturers, but data bandwidths, 100Mbps ethernet, 1 Gbps ethernet, all of the posts in this thread demonstrating miscommunications with customers, I mean come on you're not so naive to think it's only HDD manufacturers using the SI unit correctly), the MB unit will still be used, and this is just fine, because often the decimal prefix makes more sense. Just like before, you have to infer from context what MB means. Let me put it this way:

Before IEC: See MB, infer meaning from context.
After IEC: See MB less often, infer meaning from context. Sometimes, you'l see MiB, and you'll instantly unambiguously understand what's meant.

As a reader, you go through the same process as before, except you can short-circuit your judgement if you see MiB. This is faster, unambiguous, less error-prone. Perfectly logical. Oh no, MB still requires knowledge of context to understand. Guess what? Unless someone's going to go through every PDF on the internet, and check and modify it, that's never going to change. MB is broken forever. Saying that MiB doesn't fix MB is a strawman argument, because no-one is saying that it does. All we're saying is that now that MiB is available, things are better. Understand it when you read it, feel free to use it as appropriate when writing unless you want to be deliberately perverse.


The difference is, an inch would still be an inch, not "supposedly an inch but maybe a cm".

A MB is already "maybe 1000000 bytes, maybe 1048576 bytes". MiB doesn't fix that, sure, but it isn't the cause of the problem. Focus on what's new, rather than saying the status quo is broken (Which I agree with).

That's why, when I need a precise number, I leave off the postfix, and state the real number.  The only time the value is still precise with a SI postfix is when it's a perfect multiple (1.0M), or you specify the value out to the required number of decimal places (32.768k).  If you have to specify more than two or three decimals, you probably shouldn't be shifting scales that lose precision.

But, there are ample times when I need to convey the general quantity of something -- like a 10k resistor, for example.  We understand it may not (and probably won't be) 10,000.000 ohms.  It has a tolerance, also specified if it matters, and we all agree to accept any error one way or the other.  And, we also understand that a 5% error on a 100R resistor is closer to the actual value than 5% on a 1M resistor.  Yet, no one is proposing new units for resistors...

I don't get why you're talking about decimal places and significant figures. Tolerances are completely irrelevant here because hard drives have a precise number of bits. Why would the fact that resistors have a tolerance of 5% suggest the need for different units? I just can't make any sense of what you're saying here. Shifting scales do not lose precision, 12.7642pF is precisely 0.0000000000127642 farads. Leaving off the postfix does not help with gaining precision. 32KiB = 32.768kB = 32768B. I'm not going to write 2000000000 bytes instead of 2GB if I meant precisely 2GB.

I'm not terribly upset about it being "wrong" now, I just find it unhelpful to say there's now an unambiguous unit for 2^x, but the 10^x unit is still just as ambiguous as ever -- except now, it's "supposed to be" accurate too.  The only way you'd know for sure is if someone left a footnote saying "actual MB, not MiB" -- and if it mattered either way, why not footnote with "MB = 1,000,000" as we're doing now?  In most scenarios, "MB = ~1 million" is good enough, so... as I said... it's a non-fix for a non-problem.

As I mentioned above, you're right that expecting MB to mean 1000000 bytes is unreasonable. A simple footnote or note in the introduction will make it so, but as you say, for all historical documents, you need to use your judgement and infer what's meant from context. This is the same, before and after the introduction of MiB. But the introduction of MiB as another option is a great tool for clarity for writers, a boon to readers when they encounter it, and a definite step in the right direction. That's all I'm saying.
 

Offline SirNick

  • Frequent Contributor
  • **
  • Posts: 589
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #60 on: September 19, 2014, 07:28:58 pm »
I don't get why you're talking about decimal places and significant figures. Tolerances are completely irrelevant here because hard drives have a precise number of bits. Why would the fact that resistors have a tolerance of 5% suggest the need for different units? I just can't make any sense of what you're saying here. Shifting scales do not lose precision, 12.7642pF is precisely 0.0000000000127642 farads. Leaving off the postfix does not help with gaining precision. 32KiB = 32.768kB = 32768B. I'm not going to write 2000000000 bytes instead of 2GB if I meant precisely 2GB.
I'm talking about it because most (but yes, not all) of the time, when a postfix is warranted, the "tolerance" of the number you're trying to express makes the difference unimportant.  When you have to go out several decimal places to convey the significant value, you're defeating the point of using a postfix with high magnitude.  0.001M = 1k.  Why not just write 1k then?  If you need to know if that's 1.001k or 1.000k, why not just say 1000?  That way, there's no assumption required.  Is 1k a precise figure, or a ballpark figure?  Well, 1000 leaves no question.  (Unless of course 0.001 matters, in which case you might need to say 1000.000.)

The gist is this:  I just bought a few 3TB HDDs for my NAS.  It doesn't matter at all if that's 3,000,000,000,000 bytes even, or not.  (Hope I counted zeroes correctly this time.)  3TB == in the rough neighborhood of 1 buttload of data.  They're replacing a batch of 2TB HDDs, which were also roughly 1 buttload of data, but 3TB is something near 50% more of a partial buttload, and that's all I need to know.

Another example:  I often have device firmware images on Compact Flash cards.  If I made an image of one... say, 1GB card... I would not expect it to fit precisely on another 1GB card, unless they were the same part number from the same manufacturer.  This has turned out to be the case as often as not.  I honestly don't know if it was 1GiB vs. 1GB, or if it was just a difference in spare sectors, or what.  Doesn't matter.  The takeaway is that I have to check, and when they don't match, I have to either ensure the target is larger, or resize the filesystem to fit.  Either way, I check the real size in number of 512 byte sectors, or Bytes.  That has never left me confused.

In the case of the SAN guy carving out storage for a customer, there you probably need to say "we sell in increments of 1GB, where GB = 1 billion bytes".  The customer can decide if the accuracy is relevant to their needs, but most people won't care either way.  They'll ask for some arbitrary round number of GB and call it a day.  When I managed SANs, and needed to know precisely how much space was allocated, I would change the unit-of-measure to bytes, or at least kB.  Only time that really made a difference was to clone a disk of a certain size.  Having exactly equal byte counts made it possible to image the volume rather than do filesystem-level copies.  Every other time, nobody cares.

As I mentioned above, you're right that expecting MB to mean 1000000 bytes is unreasonable. A simple footnote or note in the introduction will make it so, but as you say, for all historical documents, you need to use your judgement and infer what's meant from context. This is the same, before and after the introduction of MiB. But the introduction of MiB as another option is a great tool for clarity for writers, a boon to readers when they encounter it, and a definite step in the right direction. That's all I'm saying.
I do see what you're saying, and I get it.  I just don't agree on the importance.  Having two slightly different units of measure only helps in relatively rare cases.  The rest of the time it's pedantic and doesn't convey information that's useful to the reader.  I assume you disagree with that, and that's fine.  *iB is here now.  Some will use it, some won't.  I'll probably continue to specify in (e.g.) MB when the exact figure is unimportant, and specify either "MB=1,000,000" or in Bytes when it is.  Either way, the point comes across clearly, which is all that matters.
 

Offline David Hess

  • Super Contributor
  • ***
  • Posts: 11250
  • Country: us
  • DavidH
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #61 on: September 19, 2014, 08:31:27 pm »
You know, I always thought hard drive sizes being in b10 made sense, as there's nothing inherent to a mechanical disk which makes it have to store data the way memory does.

Except 512 byte or 4096 byte sectors - which is important for memory-mapped I/O and virtual memory.  :)

Or 2048 byte sectors for some optical media.

Quote
However, at a basic level even that is flexible. On IBM AIX systems you have to reformat disks from 512 bytes/sector to 522 bytes per sector before you can use them with some hardware RAID controllers.

I forget exactly what the extra bytes were used for but wasn't the data size as far as the application was concerned still some multiple of 2?

NAND Flash memory uses writable sector sizes slightly larger than the power of 2 number to store ECC and meta information like for remapping.
 

Offline David Hess

  • Super Contributor
  • ***
  • Posts: 11250
  • Country: us
  • DavidH
Re: Will Kibibytes catch-on or can we turn things back to the JEDEC standard?
« Reply #62 on: September 19, 2014, 08:34:47 pm »
Well, that's interesting. When did HDDs transition from MB2 to MB10?

Connor Peripherals and Micropolis were still around.  When the change started happening it was discussed in various computer magazines like Byte.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf