Page 1 of 2 12 LastLast
Results 1 to 20 of 23
  1.    #1  
    The 650 memory structure issue had me wondering if I should scrap the idea of passing my 600 down, and replace it with a 650. To determine the effect of the memory issue, I came up with an Excel spreadsheet to estimate what the memory footprint of my 600 installation might look like on a 650.

    The spreadsheet took the size of all of apps and data, as reported in my 600 by FileZ. It then calculated how many 512b blocks each app would take, and calculated the resulting memory required for each app. Then it totals the memory footprint of my installation from there.

    I have a pretty good mix of apps (I can't think of anything else I want - for now <grin>). I don't have a huge amount of data, but it covers what I need in there.

    The results of my calculations seem to show very little difference between the two methods of memory utilization. It showed only about a 1% increase of total memory used. It doesn't seem to be all that big a deal in my case.

    So what am I missing?

    This doesn't address any other memory concerns there might be with this new scheme (i.e. speed, app incompatibilities etc, why didn't P1 include more memory anyway).

    I attached a PDF showing the results. If anyone is interested, I can provide the Excel spreadsheet so someone could show me what I did wrong in the calculation to come up with this crazy conclusion.

    PG
    Attached Files Attached Files
  2. #2  
    I think people are trying to do way too much with a cell phone. Have these same people had problems with the 600?
    I have never come close to running out of space nor has the 600 ever given me any speed related problem.
    Just my 2 cents but clearly it seems those that find it an issue in in the minority. Not a slam on anyone, just high expecations for a phone.
    Eric
  3. alee's Avatar
    Posts
    410 Posts
    Global Posts
    805 Global Posts
    #3  
    I think the issue is database files are consuming 1 cluster per record, creating a lot of slack. Assuming each record is 64 bytes, where you could normally fit a theoretical 8 records in 512 bytes, you now consume the equivalent of 8 clusters = 4096 bytes or 4kb.
  4. #4  
    yeah.... Your missing the whole concept. You didnt take the current block size into consideration which is I believe about 12bytes. The other thing to consider is that those sectors are used per file not neccessarly per app. So if an app that is now taking 120bytes but there are 2 file types involved, it will now take 1024bytes. That calculates to a 1,000% increase in size. That is the extreme and normally doesnt happen, but you will see most apps almost double in size.
  5. #5  
    Your method could only add at most 511 bytes per file. It is not taking into account how many records are in each file and the sizes of these records.

    In short, you don't have the information needed to do this correctly.
  6. #6  
    Quote Originally Posted by Albert C. Lee
    I think the issue is database files are consuming 1 cluster per record, creating a lot of slack. Assuming each record is 64 bytes, where you could normally fit a theoretical 8 records in 512 bytes, you now consume the equivalent of 8 clusters = 4096 bytes or 4kb.
    Thats what I think is happening also. Can someone with a 650 test it out. If you create a playlist in PocketTunes a file is created called PocketTunesPL-Untitled001 (where 001 is the number of playists you have).

    The playlist file has a db record for each song in the playlist. A three song playlist on my 600 went from 363b to 439b when I added 1 song. The record count went from 3 to 4. I'm curious as to how the playlist file size would change on the 650, my guess would be 4 * 512b = 2k as opposed to 439b on the 600.
  7. #7  
    Quote Originally Posted by TreoHappy
    The results of my calculations seem to show very little difference between the two methods of memory utilization. It showed only about a 1% increase of total memory used. It doesn't seem to be all that big a deal in my case.

    So what am I missing?

    ...snip...
    Your calculations are way off. In order to determine how much space an application's data will consume, you need to take into account the 512-byte size of each allocation unit (or cluster) in the NVFS memory file system.

    Normally, a Palm OS device is very efficient in handling memory (i.e. 14 bytes only consumes 14 bytes). But in the case of the Treo 650's NVFS memory scheme, each time you write new information to memory, the File Allocation Table (FAT) utilizes a new 512-byte cluster.

    For example, if I need to store a contact that consumes 52 characters (52 bytes), the Treo 650 will allocate a memory cluster (512 bytes) and put that 52 bytes in that cluster. The remaining 460 bytes in that cluster goes unused (but unable to be used for anything else). On my Treo 600, I have 1116 contacts in my address book (AddressDB aka Contacts). This consumes 213.82KB (kilobytes), which is 218956 bytes according to Filez.

    Now since that database is internally organized into 1116 records, and each record on a Treo 650 would be required to allocate one of the 512-byte clusters, that database would consume at a minimum 558 Kilobytes (1116 records * 512 bytes = 571392 bytes. Divide by 1024 = 558 Kilobytes). So my 1116 contacts would consume 558KB instead of 214KB. This assumes that each contact (record) takes no more than 512 bytes and that two records cannot share a 512-byte cluster.

    If applications write to memory the same way thay always have, then two records cannot share a 512-byte cluster. Applications would need to be rewritten so that they combine records for more efficient storage in a 512-byte container. Until now, applications didn't have to worry about it, but now they do (IF they want to utilize the space more efficiently).

    If MY calculations are off, anyone please feel free to tell me. I hope this explains it better.
    --Inspector Gadget

    "Go Go Gadget Pre!!"
    Palm Pre on Sprint

    Palm V--> Palm IIIc--> Visor Prism--> Visor Phone--> Treo 270--> Treo 600--> Treo 650-->
    Treo 700wx--> HTC Touch Diamond--> Palm Pre & HTC EVO 4G.
  8. #8  
    Question is, is this allocation/file format issue fixable in software?

    I.E. could a patch redo the file system or will it take hardware changes?
  9. #9  
    Quote Originally Posted by cschmelz
    Question is, is this allocation/file format issue fixable in software?

    I.E. could a patch redo the file system or will it take hardware changes?
    On hard drives, a File Allocation Table (FAT) has a maximum number of entries. In the old FAT-16 used on MS-DOS that limit was 65536 entries. In FAT-16 a two Gigabyte hard drive (2147483648 bytes) would be divided up into 65536 clusters with a cluster size of 32768 bytes each or 32KB each. Meaning that on that hard drive a file (whether it's 1 byte or 32000 bytes) would take up a minimum of 32768 bytes of space on the hard drive.

    If Palm's NVFS memory scheme follows this logic, then what would be required is to re-write the File Allocation Table (FAT) so that it is not hard-coded to a particular number of records and to use a dynamic memory allocation scheme.

    Currently, it appears that the 32MB of memory is divided into 512-byte clusters, which would mean that there are 65536 memory clusters (32MB = 33554432 bytes. 33554432 / 512 = 65536 clusters just like the old MS-DOS FAT-16 scheme).

    Since the FAT is merely a method of organizing the data, it is conceivable that IF a better scheme is used (or a lot more records are added to the table), then a smaller cluster size could be utilized, which would waste less memory. Keep in mind that if the number of records remains the same, then adding memory to the Treo 650 would mean that the cluster sizes would have to get BIGGER to accomodate the extra space.

    The FAT, itself is written to memory just like any other data, but the algorithm for it is hard coded in the operating system, so an update to the OS would be necessary. This is like upgrading from MS-DOS (which only understood how to write a FAT with 65536 clusters---16 bits) to Windows 95 (which knows how to write a FAT with 4294967296 clusters---32 bits).
    Last edited by Insp_Gadget; 11/22/2004 at 05:04 PM.
    --Inspector Gadget

    "Go Go Gadget Pre!!"
    Palm Pre on Sprint

    Palm V--> Palm IIIc--> Visor Prism--> Visor Phone--> Treo 270--> Treo 600--> Treo 650-->
    Treo 700wx--> HTC Touch Diamond--> Palm Pre & HTC EVO 4G.
  10. alee's Avatar
    Posts
    410 Posts
    Global Posts
    805 Global Posts
    #10  
    Quote Originally Posted by cschmelz
    Question is, is this allocation/file format issue fixable in software?

    I.E. could a patch redo the file system or will it take hardware changes?
    In theory, I see 4 different ways this could go:

    1. You can reinitialize the flash to use smaller cluster sizes, and have the OS write to smaller clusters, at a cost of speed.

    2. You can write applications that support writing multiple records into 1 cluster, thereby using space more effectively, at an expensive of expectations from each developer to make such considerations.

    3. Write some sort of file system driver that attempts #2 on the fly, at the risk of creating unusual compability issues from 3rd party applications.

    4. Release a new unit with more memory, at a cost of marketing, rebranding, and damage control from whiners that kept their 32mb units beyond the 30 day return period and still insist they are entitled to free upgrades.
  11. #11  
    5. Sell off stock, close the doors, and retire to the Bahamas.

    That's what I would do....
  12. #12  
    Quote Originally Posted by kirkeric
    I think people are trying to do way too much with a cell phone.
    If it's just "a cell phone," then yes - you're probably right. But it's supposed to be a converged device, a "smartphone" if you will. And being a "smartphone," some of us have expectations that it will be somewhat "smart," and not just a "phone."

    30% less memory that the old model is just not "smart" enough, and hence it is just "a cell phone" for most purposes. I can get "just a phone" for $650.99 less than the Treo 650, so what's that extra cash I'm spending gonna give me???

    just my 2c
    Treo 755s in good condition available on ebay for $50-$75. No need to pay for insurance or buy a Pre.
  13. #13  
    Quote Originally Posted by Albert C. Lee
    In theory, I see 4 different ways this could go:

    1. You can reinitialize the flash to use smaller cluster sizes, and have the OS write to smaller clusters, at a cost of speed.

    2. You can write applications that support writing multiple records into 1 cluster, thereby using space more effectively, at an expensive of expectations from each developer to make such considerations.

    3. Write some sort of file system driver that attempts #2 on the fly, at the risk of creating unusual compability issues from 3rd party applications.

    4. Release a new unit with more memory, at a cost of marketing, rebranding, and damage control from whiners that kept their 32mb units beyond the 30 day return period and still insist they are entitled to free upgrades.
    Print up some yellow "Now with 64mb memory" stickers, slap em on the box -- marketing done!

    lol rwerks
  14. #14  
    Quote Originally Posted by Joad
    30% less memory that the old model is just not "smart" enough, and hence it is just "a cell phone" for most purposes. I can get "just a phone" for $650.99 less than the Treo 650, so what's that extra cash I'm spending gonna give me???
    FORM FACTOR!! http://discussion.treocentral.com/im...ilies/wink.gif
  15. #15  
    Oh yeah... 'form factor'. THAT'S the entirety of what makes a 'smartphone' more than a phone.

    Guess I'll toss the old Treo 600, nearly $700 and half of my data for this 650 upgrade, as clearly the 650's "FORM FACTOR" makes it all worthwhile.

    I'll bet the kids who 'improve performance' by installing green LED fans into their cases are really happy with the brains in the 650. Better increase Johnny's allowance.
    Treo 755s in good condition available on ebay for $50-$75. No need to pay for insurance or buy a Pre.
  16. #16  
    I have a 600 working good. No way in hell am I breaking for the 650 at this point.
  17. #17  
    Quote Originally Posted by Joad
    Oh yeah... 'form factor'. THAT'S the entirety of what makes a 'smartphone' more than a phone.
    Ya know I was being sarcastic right?
  18. #18  
    Quote Originally Posted by JTREOB
    I have a 600 working good. No way in hell am I breaking for the 650 at this point.
    Me too.
    Shneor
    Pre 3 on T-Mobile, 32gb Touchpad
  19. #19  
    I missed that joebar was being sarcastic, and I apologize. I keep wishing the 650 memory issue were just a bad dream and someone will discover a way to hack it to 128MB one of these days so I can use it.
    Treo 755s in good condition available on ebay for $50-$75. No need to pay for insurance or buy a Pre.
  20. #20  
    You DO NOT have to start from scratch.. Just DO NOT sync this file: PhoneCallDB.PDB It isn't huge but takes up ALL MEMORY. I have over 3000 contacts and am having no problems at all.
Page 1 of 2 12 LastLast

Posting Permissions