Page 1 of 2 12 LastLast
Results 1 to 20 of 26
  1.    #1  
    Just looked at the link from TreoCentral to PalmOne's NVFS document. It is full of contradictory statements. The biggest one I see is the statement:

    As a general rule, add about 33 percent to the existing occupied memory on your previous device. This allows for the larger data files of your Treo 650's NVFS, including PIM application data (your Contacts, Calendar, Tasks and Memo items) that will occupy a larger space, as well as third-party applications that will probably not grow as much. Because the exact amount of data expansion depends on the number of records and how full they are
    , this is only a rough estimate; your experience will differ.
    Well later in the article they show the following increases in NVFS compared to old way for PIM functions:

    Old Way New Way
    Total 252KB 950KB

    That seems to be almost a 400% increase in all of the PIM apps. Correct me if I am wrong, but wasn't the original concept behind the PDA is for PIM apps? This should be what the Treo is best at and store the most efficiently. Now, due to PalmOnes own late understanding of how NVFS works, PalmOne, and now the investors have realized that putting in the same memory in the 650 as the 600 may not have been smart, especially when the user base finds this out after they have purchased them.

    What I am really starting to think is that after the merger happened, the T5 engineering group already was going in this NVFS direction, and management told the Treo line to follow suit. The Treo Engineers/Managers, not knowing anything about NVFS other than they had to use it assumed that it was as efficient as the old way. They probably realized their mistake after the product specs were shipped to manufacturing, and decided to wait and see if anyone would notice, hoping they wouldn't. Why else would the tech article have been released only after the stock dropped?

    What this whole incident shows is that the internal testing process for new devices at PalmOne is seriously broken. This should have been caught in pre-production testing. Maybe it was and the company and/or Treo group decided to sit on it and hope to save a couple of bucks. All that would be needed to fix the situation is make a running change in production and replace the existing 32 MB NAND with a 48, or 64 MB NAND (M-sys does make both of these sizes).

    The other interesting thing to note is that the RAM used in conjunction with the New NVFS should have been at least 48 MB, instead of the 32 MB used in both the 650 and the T5. The T5 will have problems running any program that will use over 10 to 11 MB of RAM, and Palm already has a list of known apps that have problems. PalmOnes solution is for developers to redevelop their apps to work with the NVFS know this limit. An extra 16 MB of RAM would have given 26 to 27 MB of usable RAM area and probably would have prevented these application issues.

    The more I find out about NVFS, the more I become worried by the fact that it seems that PalmOne's own Engineers either didn't know it well enough to properly spec the devices, or that Management decided that they were going to use NVFS come hell or high water and that they could skimp on the hardware. No matter which one happened, it is not good. Based on the information that I have seen, the 650 and T5 should have at least 48 MB of RAM, and the 650 should have had at least a 64 MB NAND chip installed. Instead of spending the minor price per unit to ship out an improved product, they have shipped out products that are going to have serious compatibility issues with some older programs, and give 650 early adopters a 128 MB SD card (probably just to get the useless things out of their warehouse for a tax right off). PalmOne make a running production change now, and fix this issue.

    I would just like to say as a final note that I am an Engineer and do testing on network hardware to verify manufacturers claims. I know that both Engineers and Testers make mistakes, and I have made them before too. But I feel that this issue is so fundemental to the way the device works it should have been caught and not made it to the market in its current form. A Bluetooth issue would have been much more acceptable and understandable than for some users not being able to port everything from a 600 to 650 without having to do a memory scrub. I am using PalmOnes own information in the assessment, and it is my opinion.
  2. #2  
    Quote Originally Posted by lnichols
    The Treo Engineers/Managers, not knowing anything about NVFS other than they had to use it assumed that it was as efficient as the old way.
    Correct me if I'm wrong, but wouldn't the current memory issue be more PalmSource's problem. Isn't it more of an OS/software issue, not a hardware issue?

    One has to assume that the same memory problem exists on the T5, it's just not as noticeable with 256mb of memory.


    What this whole incident shows is that the internal testing process for new devices at PalmOne is seriously broken.
    I can't argue the with testing issue. It's almost as if any and all testing was done with "out-of-the-box" setups, and little or no "real-world" setups.
    .
    .....
    MarkEagle
    .....<a href="http://discussion.treocentral.com/tcforum/index.php?s=">TreoCentral</a> | <a href="http://discussion.visorcentral.com/vcforum/index.php?s=">VisorCentral</a> Forum Moderator - Forum Guidelines
    .....Sprint PCS Treo 650
    .....God bless America, my home sweet home...
  3. #3  
    PalmOne undoubtedly ran into the "memory issue" a LONG time ago - never underestimate the power of the Marketing Department - THE ones who drive development.
  4. #4  
    I'm sure they knew about the issue, they just didn't think it would affect most of their users. By their thinking, 250k->950K sucks, but on a 23MB device is manageable. That means you can have ten times the amount of data as what they think of as average and still have room for a few other apps.

    They should have known, though, that by having this bloat the people who use all of the memory will be pissed when they find out they can't do the same thing on the 650. The impression I got from one guy at the roadshow was that power users would be using SD cards anyway.

    I think they should have upped the memory, but that's their rationale.
  5. #5  
    Quote Originally Posted by lnichols
    Just looked at the link from TreoCentral to PalmOne's NVFS document. It is full of contradictory statements. The biggest one I see is the statement:



    Well later in the article they show the following increases in NVFS compared to old way for PIM functions:

    Old Way New Way
    Total 252KB 950KB

    That seems to be almost a 400% increase in all of the PIM apps. Correct me if I am wrong, but wasn't the original concept behind the PDA is for PIM apps? This should be what the Treo is best at and store the most efficiently. Now, due to PalmOnes own late understanding of how NVFS works, PalmOne, and now the investors have realized that putting in the same memory in the 650 as the 600 may not have been smart, especially when the user base finds this out after they have purchased them.

    What I am really starting to think is that after the merger happened, the T5 engineering group already was going in this NVFS direction, and management told the Treo line to follow suit. The Treo Engineers/Managers, not knowing anything about NVFS other than they had to use it assumed that it was as efficient as the old way. They probably realized their mistake after the product specs were shipped to manufacturing, and decided to wait and see if anyone would notice, hoping they wouldn't. Why else would the tech article have been released only after the stock dropped?

    What this whole incident shows is that the internal testing process for new devices at PalmOne is seriously broken. This should have been caught in pre-production testing. Maybe it was and the company and/or Treo group decided to sit on it and hope to save a couple of bucks. All that would be needed to fix the situation is make a running change in production and replace the existing 32 MB NAND with a 48, or 64 MB NAND (M-sys does make both of these sizes).

    The other interesting thing to note is that the RAM used in conjunction with the New NVFS should have been at least 48 MB, instead of the 32 MB used in both the 650 and the T5. The T5 will have problems running any program that will use over 10 to 11 MB of RAM, and Palm already has a list of known apps that have problems. PalmOnes solution is for developers to redevelop their apps to work with the NVFS know this limit. An extra 16 MB of RAM would have given 26 to 27 MB of usable RAM area and probably would have prevented these application issues.

    The more I find out about NVFS, the more I become worried by the fact that it seems that PalmOne's own Engineers either didn't know it well enough to properly spec the devices, or that Management decided that they were going to use NVFS come hell or high water and that they could skimp on the hardware. No matter which one happened, it is not good. Based on the information that I have seen, the 650 and T5 should have at least 48 MB of RAM, and the 650 should have had at least a 64 MB NAND chip installed. Instead of spending the minor price per unit to ship out an improved product, they have shipped out products that are going to have serious compatibility issues with some older programs, and give 650 early adopters a 128 MB SD card (probably just to get the useless things out of their warehouse for a tax right off). PalmOne make a running production change now, and fix this issue.

    I would just like to say as a final note that I am an Engineer and do testing on network hardware to verify manufacturers claims. I know that both Engineers and Testers make mistakes, and I have made them before too. But I feel that this issue is so fundemental to the way the device works it should have been caught and not made it to the market in its current form. A Bluetooth issue would have been much more acceptable and understandable than for some users not being able to port everything from a 600 to 650 without having to do a memory scrub. I am using PalmOnes own information in the assessment, and it is my opinion.
    One thing though: Palm can't just increase the NAND buffer. They need to talk to M-Systems. Or better yet, they need to dump NAND Flash and go back to regular RAM and the execute in place model.
  6. #6  
    Quote Originally Posted by MarkEagle
    Correct me if I'm wrong, but wouldn't the current memory issue be more PalmSource's problem. Isn't it more of an OS/software issue, not a hardware issue?

    One has to assume that the same memory problem exists on the T5, it's just not as noticeable with 256mb of memory.


    I can't argue the with testing issue. It's almost as if any and all testing was done with "out-of-the-box" setups, and little or no "real-world" setups.
    Analogy:

    If a car manufacturer outsources an engine that's a bad design and then tries to link it with a bad transmission, chances are there will be problems. First test drive, any experienced engineer will realize the problems. In fact, using modelling + knowing the characteristics of each component should have allowed the engineer to predict the problem well before anything was actually built.

    Back to Palm:

    Palm has to take responsibility for this mess. PalmSource didn't release the Treo 650 - Palm did. Palm made the decision to use NAND Flash. Palm beta tested the Treo 650 until the point it decided it was "ready for prime time". Palm had at least a year* to get he kinks worked out.

    There is absolutely NO WAY Palm was previously unaware of these issues. To imply that they just cropped up is grosly underestimating the intelligence of the audience here.

    Palm tests the hell out of its devices, including using "real world" setups. I'm sure you already know this. Let's cut out all this Palm apologist nonsense before more Treocentral readers start getting suspicious.

    Did Palm threaten to stop supplying your store if you didn't cut down on the negative posts here?


    *Unless, of course, the delay in Cobalt is what created all these headaches. Hmmmm... that would explain a lot. The truth will eventually come out: As it currently stands, PalmOS 5 was not meant to handle NAND Flash.
  7. #7  
    Quote Originally Posted by lnichols
    Old Way New Way
    Total 252KB 950KB

    That seems to be almost a 400% increase in all of the PIM apps.
    Everyone is more worried about the side effects of the 512b blocking factor, as well y'all should. But that problem can ultimately be solved by just throwing more memory at the problem, however inefficiently.

    Perhaps the more worrying problem is the 10Mb working memory issue (and the whole issue of the need for a separate working memory in the first place). That design places severe restrictions on the size of single programs, and the working architecture of programs. It will also pose problems as PalmOS moves towards a multitasking environment (is PalmOs going to swap to flash ? ugh).

    All in all, despite the advantages of NVFS, I think that in the final analysis, at least as designed, it is a mistake. It is not worth the benefits that it provides. Plenty of other devices, Palm and not Palm, have dealt with the battery changing, non-volatile memory issues with reasonable success. I judge that the added benefits of NVFS in this regard do not outweigh the problems that it is causing and will continue to cause...
  8. #8  
    Quote Originally Posted by neurocutie
    Everyone is more worried about the side effects of the 512b blocking factor, as well y'all should. But that problem can ultimately be solved by just throwing more memory at the problem, however inefficiently.

    Perhaps the more worrying problem is the 10Mb working memory issue (and the whole issue of the need for a separate working memory in the first place). That design places severe restrictions on the size of single programs, and the working architecture of programs. It will also pose problems as PalmOS moves towards a multitasking environment (is PalmOs going to swap to flash ? ugh).

    All in all, despite the advantages of NVFS, I think that in the final analysis, at least as designed, it is a mistake. It is not worth the benefits that it provides. Plenty of other devices, Palm and not Palm, have dealt with the battery changing, non-volatile memory issues with reasonable success. I judge that the added benefits of NVFS in this regard do not outweigh the problems that it is causing and will continue to cause...
    Palms have alway had restrictions on size of programs running. Ever heard of "heap"?

    Cobalt is supposed to better support NAND Flash. Only problem is there are no shipping Cobalt devices. And Cobalt is still in beta, (alpha?) anyway.

    Switching to Nand Flash was a humongous mistake. Palm needs to dump this turkey before it's too late.
  9.    #9  
    Quote Originally Posted by The Zen of Palm
    One thing though: Palm can't just increase the NAND buffer. They need to talk to M-Systems. Or better yet, they need to dump NAND Flash and go back to regular RAM and the execute in place model.
    What Palm needs to do is to use a larger capacity NAND chip on the 650. The 64 MB version will work with the OS just fine, the T5 is using the 256 MB version. All they are doing with the NAND is creating a virtual ROM area that acts as the ROM to the Palm OS, and another virtual area for the apps. On the T5 their is a 3rd virtual area that looks like external storage to the OS. The T5 has 55 MB available to apps. I don't think anyone would have complained about the 512 byte NVFS issue if the 650 had 64 MB of NAND and fit everything plus a little more than their 600.

    A major flaw I see in both the T5 and 650 is the 32 MB of RAM that the applications are actually dumped to when they are ran. Only 10 to 11 MB of the 32 MB is available for the applications to actually use. They should be putting in at least a 48 MB RAM chip and this probably would have prevented any issues with memory in the RAM being totally used up.
  10. #10  
    Switching to Nand Flash was a humongous mistake. Palm needs to dump this turkey before it's too late.
    Ahhhhh... Treo 650....turkey! NOW I understand the rationale for delaying release of the Treo 650 until this week!!
    Kind of a commemorative thing.


    Happy Thanksgiving, and have that Treo 650 with cranberry sauce, it's delicious!
    Treo 755s in good condition available on ebay for $50-$75. No need to pay for insurance or buy a Pre.
  11.    #11  
    Quote Originally Posted by MarkEagle
    Correct me if I'm wrong, but wouldn't the current memory issue be more PalmSource's problem. Isn't it more of an OS/software issue, not a hardware issue?

    One has to assume that the same memory problem exists on the T5, it's just not as noticeable with 256mb of memory.
    This is not a PalmSource issue based on my understanding from what I have read. This is a NAND functionallity issue. The NAND is more like a solid state hard drive and stores info in 512 byte chunks. Palmsource is simply storing data like they have always done but the byte boundary used to be 14 bytes with the old method. So now a record that would have only taken 14 bytes will now take 512 bytes. A simple solution would be to create a single database for all the PIM functions that would grow in size as you added records, then the 512 bytes wouldn't be a houge issue because each entry wouldn't add 512 bytes, it would only increase the size of the total database which may or may not have up to 512 bytes of "pad" for the last part of the database. This would require a complete re-write of the PIM applications.

    PalmOne changed the hardware but made it look like the old hardware for the OS by creating a virtual ROM and virtual data storage on the NAND. The PalmOS is simply treating these devices like it would if it were the old setup, and NAND is storing thise data in 512 byte chunks instead of 14 byte chunks. PalmOne is selling a device using the PalmSource OS, so in the end, they are responsible for making sure it all works to the consumer.
  12. #12  
    wow. the more i read, the more depressing this is. This is truly a MAJOR blunder. Even if new customers to the treo don't notice; even if upgraders grin and bear it without much fuss; the fact that this problem exists shows there was a serious lapse at PalmOne.

    In an industry which moves as fast as this one, this mistake is all the worse. I feel really bad right now and will definitely be waiting for the next device. Treo 700 or whatever.

    I'll tell you what else bothers me. It's the low bar PalmOne has set for itself. To continue to dismiss the enormity of its misjudgement by effectively blaming the "power user" community for pushing the device too hard is unacceptable. If this were still the same company that simply made a glorified electronic planner, such an attitude could be understandable, but after being pulled by MSFT, Palm has wholeheartedly entered the market for "power" PDA devices. Voice recording, gaming, VIDEO RECORDING, ring tones, etc. THESE ARE ALL POWER ACTIVITIES.

    I feel like this memory issue shows there are still some people at PalmOne who have not acknowledged the new industry in which this company now competes. Rather than using "power users" as an excuse, rather than blaming us, PalmOne should be trying to create more of us.

    Put MORE RAM on than you think people will need, not just enough for the average user to get by. Go with 128MB of RAM and define the category. ENCOURAGE and support your developer community (which creates so much value for the Palm Economy) rather than shoving them into the unhappy juggling world of SD card loading.

    I would feel more excited about a company that didn't whine about memory usage but encouraged it. I think that's what disappoints me the most. I feel like PalmOne isn't really pushing as hard as it could, and it's slip on this memory issue may expose a larger strategic confusion within the company about just what it's up to
    - ag47
  13. #13  
    Quote Originally Posted by The Zen of Palm
    There is absolutely NO WAY Palm was previously unaware of these issues. To imply that they just cropped up is grosly underestimating the intelligence of the audience here.
    I don't believe I ever stated they were unaware of the problem... I was asking a simple question that I didn't know the answer to, and made no implication otherwise.


    Let's cut out all this Palm apologist nonsense before more Treocentral readers start getting suspicious.
    I don't believe I was apologizing for anyone, and you shouldn't underestimate the intelligence of this audience either.


    Did Palm threaten to stop supplying your store if you didn't cut down on the negative posts here?
    Now you're the one making implications. Just because I'm a moderator, I'm supposed to toe some company line (if one even exists) and not have any opinion of my own? All I did was ask a question.
    .
    .....
    MarkEagle
    .....<a href="http://discussion.treocentral.com/tcforum/index.php?s=">TreoCentral</a> | <a href="http://discussion.visorcentral.com/vcforum/index.php?s=">VisorCentral</a> Forum Moderator - Forum Guidelines
    .....Sprint PCS Treo 650
    .....God bless America, my home sweet home...
  14.    #14  
    Quote Originally Posted by agnok47
    I would feel more excited about a company that didn't whine about memory usage but encouraged it. I think that's what disappoints me the most. I feel like PalmOne isn't really pushing as hard as it could, and it's slip on this memory issue may expose a larger strategic confusion within the company about just what it's up to
    Exactly. PalmOne would be able to entice more developers if they weren't all competing for the same memory space. By only putting such small amount of memory in the 650, and even worse making less of it available than on the 600, they have not provided much incentive for the developers. Now developers have to compete with the PIM apps to be more useful. I don't see where this gives any new developers an incentive to develop apps if the 650 may not even be able to fit on all of the existing apps on the 600. Some improvement should have been made in the amount of useable memory. If developers don't have the room on a device to even fit their apps without the user having to sacrifice a possible useful app, this dimishes the justification for creating an app because that new app has to be sooo much better than an existing app to get rid of the existing app.
  15. #15  
    This is getting absurd. I am truly tired of your "Palm Apologist" conspiracy. Your a kook, and not even an amusing one.
    Go here if you're tired of being .
    It'll be fun.
  16. #16  
    Quote Originally Posted by The Zen of Palm
    One thing though: Palm can't just increase the NAND buffer. They need to talk to M-Systems. Or better yet, they need to dump NAND Flash and go back to regular RAM and the execute in place model.
    First of all, I assume mimicry should be viewed as a form of flattery. However in this case, I'd say you need a bit more imaginiation or originality lest you are purposefully to confuse!

    Second of all, why can't Palm just increase the Nand buffer? Currently Treo 650 and T5 have a 10 MB DB Cache Area, and 6 MB for Dynamic Heap. Why couldn't, as lnichols stated, increase both of these? Or is the issue more to due with the way NVFS handles data (512 kb chunks) and its efficiency?
    _________________
    aka Gfunkmagic

    Current device: Palm Pre
    Device graveyard: Palm Vx, Cassiopeia E100, LG Phenom HPC, Palm M515, Treo 300, Treo 600, Treo 650, Treo 700p, Axim X50v, Treo 800w



    Please don't PM me about my avatar. For more info go here.

    Restore your Pre to factory settings using webos doctor and follow these instructions
  17. #17  
    Quote Originally Posted by lnichols
    It is full of contradictory statements.
    As a general rule, add about 33 percent to the existing occupied memory on your previous device.
    <snip>
    That seems to be almost a 400% increase in all of the PIM apps. Correct me if I am wrong, but wasn't the original concept behind the PDA is for PIM apps?
    There's no contradiction: for a typical application, the bloat is around 30 to 35%, sometime much less, and in rare cases more than this figures.
    For databases, on the other hand, it all depends how big a typical record is. For the PIM databases, the records are very small, and very numerous, so the bloat is much higher. For other databases, the bloat is usually much less than 400%...
    All in all, if you take all your apps and databases, the bloat is indeed around 35%, although the actual figure depends from which apps you're using. The PIM databases sure bloat like hell, but they're not very big when compared, say, with GPS navigation maps, for instance, so the overall impact on memory usage is limited.

    There's no excuse for PalmOne not to have expanded the memory size on the Treo 650, though, but I think that most people tend to overestimate the bloat resulting from the switch to NVFS! And anyway, nobody forces you to upgrade to the 650 (now, that's a tough decision to take: forget hires and bluetooth because of this mess with memory... <sigh>)
  18. #18  
    Quote Originally Posted by The Zen of Palm
    As it currently stands, PalmOS 5 was not meant to handle NAND Flash.[/B]
    Don't get me wrong, I'm as upset as anyone else about the fact that P1 didn't put at least 64MB user memory in the 650, or didn't include Cobalt instead of Garnet. But from what I understand (after reading the NVFS stuff on Ben Combee's blog), the way the NAND Flash is handled by Garnet is the same as the way it's handled by Cobalt. All PalmSource did was to make this memory architecture support available sooner as an OS 5.4 option, instead of having to wait for OS6... I guess that it's more a case of PalmOne being reluctant to include 64MB of memory in the 650 because they probably have a Treo 700 planned sometime in the future and wanted to make sure people would upgrade... or maybe they thought that the average user wouldn't reach the 32Mb (23, actually) memory limit!
  19. #19  
    Quote Originally Posted by lnichols
    All they are doing with the NAND is creating a virtual ROM area that acts as the ROM to the Palm OS, and another virtual area for the apps. On the T5 their is a 3rd virtual area that looks like external storage to the OS.
    To be more acurate, the ROM that is stored in the Flash memory is a compressed ROM (compressed to save space, as even in uncompressed form if wouldn't have been usable 'as is', because the NAND Flash memory isn't "XIP" (eXecute In Place). That's why PalmOne uses 16MB or the actual volatile RAM to create an uncompressed ROM image that will actually get used during the PalmOS boot. So in normal operation (i.e. all the time except during the initial boot after a hard reset) the ROM portion of the NAND Flash is unreachable by the user or system, and unused.

    I don't think anyone would have complained about the 512 byte NVFS issue if the 650 had 64 MB of NAND and fit everything plus a little more than their 600.
    I think that some would have complained anyway, but a vast majority of users would have been happy indeed.

    A major flaw I see in both the T5 and 650 is the 32 MB of RAM that the applications are actually dumped to when they are ran. Only 10 to 11 MB of the 32 MB is available for the applications to actually use. They should be putting in at least a 48 MB RAM chip and this probably would have prevented any issues with memory in the RAM being totally used up.
    I agree with you, with applications like maps, for instance, people might pretty soon need databases bigger than 10MB. For now, it's probably enough, but by the time they release Cobalt devices they'd better increase that space!
  20. #20  
    Quote Originally Posted by lnichols
    What Palm needs to do is to use a larger capacity NAND chip on the 650. The 64 MB version will work with the OS just fine, the T5 is using the 256 MB version. All they are doing with the NAND is creating a virtual ROM area that acts as the ROM to the Palm OS, and another virtual area for the apps. On the T5 their is a 3rd virtual area that looks like external storage to the OS. The T5 has 55 MB available to apps. I don't think anyone would have complained about the 512 byte NVFS issue if the 650 had 64 MB of NAND and fit everything plus a little more than their 600.

    A major flaw I see in both the T5 and 650 is the 32 MB of RAM that the applications are actually dumped to when they are ran. Only 10 to 11 MB of the 32 MB is available for the applications to actually use. They should be putting in at least a 48 MB RAM chip and this probably would have prevented any issues with memory in the RAM being totally used up.
    I don't think you know what you're talking about. I assume you found an article somewhere on the Internet on NAND Flash (Red-Mercury, perchance?) and are now parrotting what you think it's all about. As it now stands, NVFS is inefficient, but not too horribly slow. The RAM buffer used should be fine for all but a very few applications.. Besides skimping on absolute chip size, Palm made the right compromises needed if they insist on using this crappy memory.
Page 1 of 2 12 LastLast

Posting Permissions