Take my iTB HDD for example. It's actually 931.5GB or 1,000,204,886,016Bytes. I'm gettting an extra 195.3945 MiB for free, if you want to look at like that. The platters are made up of (from smallest to largest) Sectors, Heads and Cylinders. To make exactly 1 Billion bytes on the drive they would have been waiting space. I'm not even certain it could function without the exact number of bytes in each sector, but I really don't know.
edit: The Wikipage below may more effectual in explaining it:
But that's a hard drive platter, being based on a very different type of technology, even if the end result does look the same to a computer, being comprised of S, H & C numbers. Silicon-based storage chips are simple power of two systems, far more often than not. lfmorrison does offer some suggestions on what might be happening to the extra bits, but it's hard to verify or disprove.
4GB iPod Total Capacity t 3.8 GB (4,095,737,856 Bytes)
128MB CF card: Total Capacity t122.3 MB (128,188,416 Bytes)
256MB CF card: Total Capacity t246.0 MB (257,949,696 Bytes)
512MB CF card: Total Capacity t488.7 MB (512,483,328 Bytes)
2GB CF card Total Capacity t 1.9 GB (2,048,901,120 Bytes)
1GB SD card: Total Capacity t 968.8 MB (1,015,808,000 Bytes)
Quote:
Originally Posted by JeffDM
But that's a hard drive platter, being based on a very different type of technology, even if the end result does look the same to a computer, being comprised of S, H & C numbers. Silicon-based storage chips are simple power of two systems, far more often than not. lfmorrison does offer some suggestions on what might be happening to the extra bits, but it's hard to verify or disprove.
They are using the same marketing for capacity that HDDs do. The numbers you posted attest to that. For instance, if they actually went to 4GiB the number of bytes would be listed as 4,294,967,296 and not 4,095,737,856. That is where the confusion lies.
If you wondering how they can do that, the numbers from your SSD are all evenly devisable by at least 256KiB. Best I can figure, once the manufactures got to the decimal equivalent of bytes they stopped adding SSD chips. I wonder if we can tell which of these devices are newer based on the number of extra bytes, as they may indicate the density of the chips used to my the drive?
They are using the same marketing for capacity that HDDs do. The numbers you posted attest to that. For instance, if they actually went to 4GiB the number of bytes would be listed as 4,294,967,296 and not 4,095,737,856. That is where the confusion lies.
If you wondering how they can do that, the numbers from your SSD are all evenly devisable by at least 256KiB. Best I can figure, once the manufactures got to the decimal equivalent of bytes they stopped adding SSD chips. I wonder if we can tell which of these devices are newer based on the number of extra bytes, as they may indicate the density of the chips used to my the drive?
No, your confusion lies at the fact the full drive capacity is an aggregate of user drive space and device/OS reserved space. Even HDs with the GiB/GB issue still have lower data available. There are registries, block identifiers, directories and block health bits in FLASH which are valid parts of the total 8GiB capacity. RAM doesn't need those at all because it is considered volatile and the memory controller maintains any necessary info in itself. The problem is even worse when you format a HD because hen you have to also sutract the block preamble and postamble bits as well as account for bad-blocks from the start.
Usable space in FLASH starts with true GiB numbers and then subtracts the necessary operating overhead to give the user accessible space. HDs start with base-10 GB numbers, subtracts all the operating overhead and then the OS reports the usable space in GiB further reducing the appearance/perception of the number.
And I don't know what it has to do with the fact that the OS on the phone is about 700 MBs.
Nothing. It is about 700MiB and has been advertised as such from the beginning.
If you would have read the post I was replying to you would have seen that poster was arguing the OS was only 160GB because that was the size of the download. hen he hypothesized the difference from 700MiB was because of base changes.
So frakking read what you are posting about before going of and trying to start another doomed flamewar, because this time I might actually agree with what you want to say if you would pay attention.
Like that has ever convinced you of anything, someone who is true to their handle. Open your eyes and look around for yourself.
So you you don't have anything to back up your claims? I've searched and can't find it. You apparently know it's as fact and state that it's "advertised" as such so it shouldn't be hard for you to locate your source... if you are telling the truth.
Apparently I'm part of a not-quite-mass delusion then. That's fine, I don't need you approval to exist happily.
It's not about my approval or proving you wrong, it's about having the correct answer. It's about having as much data as possible If you make a statement—whether it be a best guess or facts based on another's best guess or actual fact—you should be backing it up twith some reference or train or thought to add validity to it.
I made my assumption of 200MB based on all the data I had at hand and after exhausting every Google search I could think of. If you can shed some fact-based light on the issue then please do. If your next reply is going to reiterate your inability to make your statement credible then I suggest you don't reply at all.
It's not about my approval or proving you wrong, it's about having the correct answer. It's about having as much data as possible If you make a statement—whether it be a best guess or facts based on another's best guess or actual fact—you should be backing it up twith some reference or train or thought to add validity to it.
I made my assumption of 200MB based on all the data I had at hand and after exhausting every Google search I could think of. If you can shed some fact-based light on the issue then please do. If your next reply is going to reiterate your inability to make your statement credible then I suggest you don't reply at all.
Your assumption sucks. The kernel and extensions alone are a little over 300MB. Then add a few frameworks, including WebKit, and a external GUI acceleration API for another couple hundred MB. i'll take a miniscule little hit because the installed apps count towards the 700MB too, but less than 200MB.
Your searching skills need some work because not all the places that have info such as this are dark/gone.
Your assumption sucks. The kernel and extensions alone are a little over 300MB. Then add with a few frameworks and a external GUI acceleration API. Your searching skills need some work because not all the places that have info such as this are dark/gone.
Then show proof of the err of my ways instead of trying to write abusive posts. If trying to insult is all your here for and if that is what you enjoy, then by all means keep it up. I won't even report you for personal attacks. I think I handle the abuse of a nameless internet poster. But if your superior googling skills would be so kind to show me how where my rudimentary calculations "suck" then by all means do so. I am only here for the facts. Nothing more, nothing less.
But that's a hard drive platter, being based on a very different type of technology, even if the end result does look the same to a computer, being comprised of S, H & C numbers. Silicon-based storage chips are simple power of two systems, far more often than not. lfmorrison does offer some suggestions on what might be happening to the extra bits, but it's hard to verify or disprove.
We now have evidence that, at least, Apple and SanDisk use GB instead of GiB when marketing SSD capacities.
Example:
64MB CompactFlash Card consists of 490 Cylinders, 8 Heads, 32 Sectors [&] 512 Bytes per Track.
This equates to: [ (490) X (8) X (32) X (512) ] = 64,225,280
We now have evidence that, at least, Apple and SanDisk use GB instead of GiB when marketing SSD capacities.
I thought that part was settled. My question was not about that anymore, but as to exactly what they're doing with the bits that aren't available to the user.
I thought that part was settled. My question was not about that anymore, but as to exactly what they're doing with the bits that aren't available to the user.
I really have absolutely no iea what bits, or bytes, you are talking about. Could you clarify what you mean as one of us is missing something.
I really have absolutely no iea what bits, or bytes, you are talking about. Could you clarify what you mean as one of us is missing something.
I've already explained it several times, but you were reading something else into it.
The core components of solid state storage is the chips. Most storage chips are made such that their capacity can be represented in simple powers of two. That makes it easy to address arrays of chips for contiguous binary addressing, should the designer want to do that. An 8GB iPhone should have chips such that it actually has 8 589 934 592 bytes in raw storage, before formatting. The difference between that and the actual unformatted storage is around 500MB. That's quite a lot to lose.
I've already explained it several times, but you were reading something else into it.
The core components of solid state storage is the chips. Most storage chips are made such that their capacity can be represented in simple powers of two. That makes it easy to address arrays of chips for contiguous binary addressing, should the designer want to do that. An 8GB iPhone should have chips such that it actually has 8 589 934 592 bytes in raw storage, before formatting. The difference between that and the actual unformatted storage is around 500MB. That's quite a lot to lose.
The SanDisk example above show that they are using 4Mebibit (power of two) tracks. Those are then combined until they reach the desired size in actual Bytes. I'm looking into it furthur to see if the Sectors and Heads also have to be powers of two, but the Cylinders clearly do not. (22^2 = 484, not 490 as listed above)
I recall reading some articles about higher density of Flash from time to time. I'll try to locate those as I recall those list the Mebibit sizes.
Edit:
Everything has to be a power of two except the number of cylinders...
For a SanDisk 128MB card:
— Bytes per sector: 512
— Sectors per track: 32
— Tracks per cylinder: 8
— Sectors per cylinder: 256
— Number of cylinders: 978
— Number of sectors: 250,368
— 250,368 x 512 = 128,188,416B = 128.19GB = 122.25GiB
You realize SanDisk doesn't manufacture their flash, they package other manufacturers flash? Also the sector/track/block nomenclature is purely virtual. The memory is a true 2-dimensional array, and SanDisks controller accesses the array in a fake hard drive style. This means SanDisk can take shortcuts by building up a flash-drive out of several non-identical chips and not actually put a full set of " Gi-bits" into the drive package. They get to screw you by buying old smaller capacity chips and putting them together in a way advantageous to them.
Now to school your ignorance and unwillingness to search for a relevant answer, the iPhone itself uses Samsung K9MCG08U5M NAND flash chips.
Quote:
The K9LAG08U0M is a 16,384Mbit(17,179,869 bit) memory organized as 1,048,576 rows(pages) by 2,112x8 columns. Spare 64x8 columns are located from column address of 2,048~2,111.
my bold
Quote:
basic operations of K9HBG08U0M and K9MBCG08U5M are same with K9LAG08U0M except some AC/DC charateristics
Note that the die has 2 full GiB (1,048,576 x 2048 x 8) of NAND flash RAM plus the spare capacity to handle failed cells. The iPhone uses 4 of these die inside one package to make 8GiB. Can we quit making up crap based on poor analogies and research into other non-relevant products?
Nothing. It is about 700MiB and has been advertised as such from the beginning.
If you would have read the post I was replying to you would have seen that poster was arguing the OS was only 160GB because that was the size of the download. hen he hypothesized the difference from 700MiB was because of base changes.
So frakking read what you are posting about before going of and trying to start another doomed flamewar, because this time I might actually agree with what you want to say if you would pay attention.
That's very nice Hiro, except that you seem to have missed the beginning of the conversation.
That's very nice Hiro, except that you seem to have missed the beginning of the conversation.
How exactly? The post I quoted and replied to WAS from the beginning of the conversation (13of99), and it was the first one to talk about relative sizes of the OS. Can't get much earlier than that.
The earlier portion of the thread, and your points, I happen to agree with. The gross mathematical screw-up of 160MB vs 700MB being due to base conversion and the effect that would have on the possible contents of the OS was what I was addressing originally. A 160MB OS install would have put serious limitations on your position that the frameworks were included from the beginning with an eye towards an eventual SDK.
Unfortunately that then had to turn into a misplaced and incorrect holy war mis-stating iPhone NAND flash sizes, Another point that needed cleaning up lest the "Apple is screwing us with less memory than advertised" call gain any traction.
How exactly? The post I quoted and replied to WAS from the beginning of the conversation (13of99), and it was the first one to talk about relative sizes of the OS. Can't get much earlier than that.
The earlier portion of the thread, and your points, I happen to agree with. The gross mathematical screw-up of 160MB vs 700MB being due to base conversion and the effect that would have on the possible contents of the OS was what I was addressing originally. A 160MB OS install would have put serious limitations on your position that the frameworks were included from the beginning with an eye towards an eventual SDK.
Unfortunately that then had to turn into a misplaced and incorrect holy war mis-stating iPhone NAND flash sizes, Another point that needed cleaning up lest the "Apple is screwing us with less memory than advertised" call gain any traction.
The earlier portion of the thread, and your points, I happen to agree with. The gross mathematical screw-up of 160MB vs 700MB being due to base conversion and the effect that would have on the possible contents of the OS was what I was addressing originally. A 160MB OS install would have put serious limitations on your position that the frameworks were included from the beginning with an eye towards an eventual SDK.
Unfortunately that then had to turn into a misplaced and incorrect holy war mis-stating iPhone NAND flash sizes, Another point that needed cleaning up lest the "Apple is screwing us with less memory than advertised" call gain any traction.[/QUOTE]
The beginning was in post #9, where I first mentioned the size of the OS. My point later on was that the discrepancy (if any) of the bases used for the calculations was besides the point. I don't see them as being correct, or large enough to account for what was being stated as a reason for the OS being as small as was otherwise averred to. I later mentioned the possibility as well, that some of the space was being used by the apps.
In post #13, Solipsism didn't mention the download. He simply said that he believed the OS was 160MBs because of the base conversion. I don't know why you said I wasn't paying attention to the posts. The download was mentioned later. It's quite clear as to how the discussion proceeded.
I don't want to get into an argument about what is on record.
Comments
Gotcha.
Take my iTB HDD for example. It's actually 931.5GB or 1,000,204,886,016Bytes. I'm gettting an extra 195.3945 MiB for free, if you want to look at like that. The platters are made up of (from smallest to largest) Sectors, Heads and Cylinders. To make exactly 1 Billion bytes on the drive they would have been waiting space. I'm not even certain it could function without the exact number of bytes in each sector, but I really don't know.
edit: The Wikipage below may more effectual in explaining it:
But that's a hard drive platter, being based on a very different type of technology, even if the end result does look the same to a computer, being comprised of S, H & C numbers. Silicon-based storage chips are simple power of two systems, far more often than not. lfmorrison does offer some suggestions on what might be happening to the extra bits, but it's hard to verify or disprove.
4GB iPod Total Capacity
128MB CF card: Total Capacity
256MB CF card: Total Capacity
512MB CF card: Total Capacity
2GB CF card Total Capacity
1GB SD card: Total Capacity
But that's a hard drive platter, being based on a very different type of technology, even if the end result does look the same to a computer, being comprised of S, H & C numbers. Silicon-based storage chips are simple power of two systems, far more often than not. lfmorrison does offer some suggestions on what might be happening to the extra bits, but it's hard to verify or disprove.
They are using the same marketing for capacity that HDDs do. The numbers you posted attest to that. For instance, if they actually went to 4GiB the number of bytes would be listed as 4,294,967,296 and not 4,095,737,856. That is where the confusion lies.
If you wondering how they can do that, the numbers from your SSD are all evenly devisable by at least 256KiB. Best I can figure, once the manufactures got to the decimal equivalent of bytes they stopped adding SSD chips. I wonder if we can tell which of these devices are newer based on the number of extra bytes, as they may indicate the density of the chips used to my the drive?
They are using the same marketing for capacity that HDDs do. The numbers you posted attest to that. For instance, if they actually went to 4GiB the number of bytes would be listed as 4,294,967,296 and not 4,095,737,856. That is where the confusion lies.
If you wondering how they can do that, the numbers from your SSD are all evenly devisable by at least 256KiB. Best I can figure, once the manufactures got to the decimal equivalent of bytes they stopped adding SSD chips. I wonder if we can tell which of these devices are newer based on the number of extra bytes, as they may indicate the density of the chips used to my the drive?
No, your confusion lies at the fact the full drive capacity is an aggregate of user drive space and device/OS reserved space. Even HDs with the GiB/GB issue still have lower data available. There are registries, block identifiers, directories and block health bits in FLASH which are valid parts of the total 8GiB capacity. RAM doesn't need those at all because it is considered volatile and the memory controller maintains any necessary info in itself. The problem is even worse when you format a HD because hen you have to also sutract the block preamble and postamble bits as well as account for bad-blocks from the start.
Usable space in FLASH starts with true GiB numbers and then subtracts the necessary operating overhead to give the user accessible space. HDs start with base-10 GB numbers, subtracts all the operating overhead and then the OS reports the usable space in GiB further reducing the appearance/perception of the number.
And I don't know what it has to do with the fact that the OS on the phone is about 700 MBs.
Nothing. It is about 700MiB and has been advertised as such from the beginning.
If you would have read the post I was replying to you would have seen that poster was arguing the OS was only 160GB because that was the size of the download. hen he hypothesized the difference from 700MiB was because of base changes.
So frakking read what you are posting about before going of and trying to start another doomed flamewar, because this time I might actually agree with what you want to say if you would pay attention.
Nothing. It is about 700MiB and has been advertised as such from the beginning.
Advertised where? Please post some links to credible sources.
Like that has ever convinced you of anything, someone who is true to their handle. Open your eyes and look around for yourself.
So you you don't have anything to back up your claims? I've searched and can't find it. You apparently know it's as fact and state that it's "advertised" as such so it shouldn't be hard for you to locate your source... if you are telling the truth.
Apparently I'm part of a not-quite-mass delusion then. That's fine, I don't need you approval to exist happily.
It's not about my approval or proving you wrong, it's about having the correct answer. It's about having as much data as possible If you make a statement—whether it be a best guess or facts based on another's best guess or actual fact—you should be backing it up twith some reference or train or thought to add validity to it.
I made my assumption of 200MB based on all the data I had at hand and after exhausting every Google search I could think of. If you can shed some fact-based light on the issue then please do. If your next reply is going to reiterate your inability to make your statement credible then I suggest you don't reply at all.
It's not about my approval or proving you wrong, it's about having the correct answer. It's about having as much data as possible If you make a statement—whether it be a best guess or facts based on another's best guess or actual fact—you should be backing it up twith some reference or train or thought to add validity to it.
I made my assumption of 200MB based on all the data I had at hand and after exhausting every Google search I could think of. If you can shed some fact-based light on the issue then please do. If your next reply is going to reiterate your inability to make your statement credible then I suggest you don't reply at all.
Your assumption sucks. The kernel and extensions alone are a little over 300MB. Then add a few frameworks, including WebKit, and a external GUI acceleration API for another couple hundred MB. i'll take a miniscule little hit because the installed apps count towards the 700MB too, but less than 200MB.
Your searching skills need some work because not all the places that have info such as this are dark/gone.
Your assumption sucks. The kernel and extensions alone are a little over 300MB. Then add with a few frameworks and a external GUI acceleration API. Your searching skills need some work because not all the places that have info such as this are dark/gone.
Then show proof of the err of my ways instead of trying to write abusive posts. If trying to insult is all your here for and if that is what you enjoy, then by all means keep it up. I won't even report you for personal attacks. I think I handle the abuse of a nameless internet poster. But if your superior googling skills would be so kind to show me how where my rudimentary calculations "suck" then by all means do so. I am only here for the facts. Nothing more, nothing less.
But that's a hard drive platter, being based on a very different type of technology, even if the end result does look the same to a computer, being comprised of S, H & C numbers. Silicon-based storage chips are simple power of two systems, far more often than not. lfmorrison does offer some suggestions on what might be happening to the extra bits, but it's hard to verify or disprove.
We now have evidence that, at least, Apple and SanDisk use GB instead of GiB when marketing SSD capacities.
We now have evidence that, at least, Apple and SanDisk use GB instead of GiB when marketing SSD capacities.
I thought that part was settled. My question was not about that anymore, but as to exactly what they're doing with the bits that aren't available to the user.
I thought that part was settled. My question was not about that anymore, but as to exactly what they're doing with the bits that aren't available to the user.
I really have absolutely no iea what bits, or bytes, you are talking about. Could you clarify what you mean as one of us is missing something.
I really have absolutely no iea what bits, or bytes, you are talking about. Could you clarify what you mean as one of us is missing something.
I've already explained it several times, but you were reading something else into it.
The core components of solid state storage is the chips. Most storage chips are made such that their capacity can be represented in simple powers of two. That makes it easy to address arrays of chips for contiguous binary addressing, should the designer want to do that. An 8GB iPhone should have chips such that it actually has 8 589 934 592 bytes in raw storage, before formatting. The difference between that and the actual unformatted storage is around 500MB. That's quite a lot to lose.
I've already explained it several times, but you were reading something else into it.
The core components of solid state storage is the chips. Most storage chips are made such that their capacity can be represented in simple powers of two. That makes it easy to address arrays of chips for contiguous binary addressing, should the designer want to do that. An 8GB iPhone should have chips such that it actually has 8 589 934 592 bytes in raw storage, before formatting. The difference between that and the actual unformatted storage is around 500MB. That's quite a lot to lose.
The SanDisk example above show that they are using 4Mebibit (power of two) tracks. Those are then combined until they reach the desired size in actual Bytes. I'm looking into it furthur to see if the Sectors and Heads also have to be powers of two, but the Cylinders clearly do not. (22^2 = 484, not 490 as listed above)
I recall reading some articles about higher density of Flash from time to time. I'll try to locate those as I recall those list the Mebibit sizes.
Edit:
Everything has to be a power of two except the number of cylinders...
Now to school your ignorance and unwillingness to search for a relevant answer, the iPhone itself uses Samsung K9MCG08U5M NAND flash chips.
The K9LAG08U0M is a 16,384Mbit(17,179,869 bit) memory organized as 1,048,576 rows(pages) by 2,112x8 columns. Spare 64x8 columns are located from column address of 2,048~2,111.
my bold
basic operations of K9HBG08U0M and K9MBCG08U5M are same with K9LAG08U0M except some AC/DC charateristics
Note that the die has 2 full GiB (1,048,576 x 2048 x 8) of NAND flash RAM plus the spare capacity to handle failed cells. The iPhone uses 4 of these die inside one package to make 8GiB. Can we quit making up crap based on poor analogies and research into other non-relevant products?
iPhone teardown
NAND flash specifics
Nothing. It is about 700MiB and has been advertised as such from the beginning.
If you would have read the post I was replying to you would have seen that poster was arguing the OS was only 160GB because that was the size of the download. hen he hypothesized the difference from 700MiB was because of base changes.
So frakking read what you are posting about before going of and trying to start another doomed flamewar, because this time I might actually agree with what you want to say if you would pay attention.
That's very nice Hiro, except that you seem to have missed the beginning of the conversation.
That's very nice Hiro, except that you seem to have missed the beginning of the conversation.
How exactly? The post I quoted and replied to WAS from the beginning of the conversation (13of99), and it was the first one to talk about relative sizes of the OS. Can't get much earlier than that.
The earlier portion of the thread, and your points, I happen to agree with. The gross mathematical screw-up of 160MB vs 700MB being due to base conversion and the effect that would have on the possible contents of the OS was what I was addressing originally. A 160MB OS install would have put serious limitations on your position that the frameworks were included from the beginning with an eye towards an eventual SDK.
Unfortunately that then had to turn into a misplaced and incorrect holy war mis-stating iPhone NAND flash sizes, Another point that needed cleaning up lest the "Apple is screwing us with less memory than advertised" call gain any traction.
How exactly? The post I quoted and replied to WAS from the beginning of the conversation (13of99), and it was the first one to talk about relative sizes of the OS. Can't get much earlier than that.
The earlier portion of the thread, and your points, I happen to agree with. The gross mathematical screw-up of 160MB vs 700MB being due to base conversion and the effect that would have on the possible contents of the OS was what I was addressing originally. A 160MB OS install would have put serious limitations on your position that the frameworks were included from the beginning with an eye towards an eventual SDK.
Unfortunately that then had to turn into a misplaced and incorrect holy war mis-stating iPhone NAND flash sizes, Another point that needed cleaning up lest the "Apple is screwing us with less memory than advertised" call gain any traction.
The earlier portion of the thread, and your points, I happen to agree with. The gross mathematical screw-up of 160MB vs 700MB being due to base conversion and the effect that would have on the possible contents of the OS was what I was addressing originally. A 160MB OS install would have put serious limitations on your position that the frameworks were included from the beginning with an eye towards an eventual SDK.
Unfortunately that then had to turn into a misplaced and incorrect holy war mis-stating iPhone NAND flash sizes, Another point that needed cleaning up lest the "Apple is screwing us with less memory than advertised" call gain any traction.[/QUOTE]
The beginning was in post #9, where I first mentioned the size of the OS. My point later on was that the discrepancy (if any) of the bases used for the calculations was besides the point. I don't see them as being correct, or large enough to account for what was being stated as a reason for the OS being as small as was otherwise averred to. I later mentioned the possibility as well, that some of the space was being used by the apps.
In post #13, Solipsism didn't mention the download. He simply said that he believed the OS was 160MBs because of the base conversion. I don't know why you said I wasn't paying attention to the posts. The download was mentioned later. It's quite clear as to how the discussion proceeded.
I don't want to get into an argument about what is on record.