Page 4 of 9 FirstFirst 123456789 LastLast
Results 61 to 80 of 166
  1. #61  
    Quote Originally Posted by tomvb2000
    FWIW (likely not much), I did some experimenting to get an idea of which apps used how much NVFS Cache. To set the baseline, I disabled all 3rd party apps which hook into the boot sequence (Butler, TreoGuard, etc). The table shows the result where the second column is how much was free after each app was added/enabled. Before I added/enabled the app, I did a soft reset.

    Baseline 8956K Apparently the OS and built-in apps take ~3M
    TreoGuard 8952K
    Butler 8947K
    ProfileCare 8832K
    GoodLink 1303K Takes 6.5M after GL initialization and data connection
    Causerie 965K

    I've run some of these a couple of times and the numbers seem pretty consistent. Most of them take up fairly little space with the notable exception of GoodLink. From this, it looks like I'm pretty much out of luck in terms of completely avoiding "out of (cache) memory" errors. Even if dbCache helps a little, it's not going to help the 6.5M tied up in GoodLink.

    The Treo700 better come with 64+M of memory without these cache size problems - this is too frustrating to live through again. I love everything else about the 650, but I'm beginning to miss my 600.
    Thanks for your investigation and details, but am I reading those numbers correctly? TreoGuard 8952K, dividing 8952Kilobytes by 1024 and I get 8.74MB? Are those numbers right? Are you talking Kilobytes in those values?
  2. #62  
    Quote Originally Posted by evilghost
    Thanks for your investigation and details, but am I reading those numbers correctly? TreoGuard 8952K, dividing 8952Kilobytes by 1024 and I get 8.74MB? Are those numbers right? Are you talking Kilobytes in those values?
    No, that's how much memoryInfo reported as Total Free NVFS Cache after each app was enabled. The delta used by TreoGuard was 8956K (Baseline)-8952K (after TreoGuard) = 4K .

    Bottom line is that if I wanted to maximize free cache, I'd have to dump GoodLink since it's the biggest hog. Unfortunately, it's also extremely useful for me. I expect dbCache will help a little, but mostly I'll just have to soft reset every time I get the out of memory error. I don't think I've got any other options.
  3. #63  
    Quote Originally Posted by tomvb2000
    No, that's how much memoryInfo reported as Total Free NVFS Cache after each app was enabled. The delta used by TreoGuard was 8956K (Baseline)-8952K (after TreoGuard) = 4K .

    Bottom line is that if I wanted to maximize free cache, I'd have to dump GoodLink since it's the biggest hog. Unfortunately, it's also extremely useful for me. I expect dbCache will help a little, but mostly I'll just have to soft reset every time I get the out of memory error. I don't think I've got any other options.
    I understand now, I'm sorry, I thought you were giving me the delta values not the available cache. Thanks for the clarification.

    Amazing that Goodlink has developed an application that so aggressively consumes available cache making the Treo unusable ;P
  4. #64  
    GL is a hog but then again it does a ton of stuff and nicely replicates Outlook functionality with full wireless sync. Non-wireless sync close equivalent was BeyondContacts. As I remember, it took 5-6M of memory on my 600 as well, 'course didn't have cache problems then.

    It seems equally amazing that P1 in their infinite wisdom gave us such as capable device with a huge handicap. Given all the bad press and customer support problems they've had over the last 6 months, I hope they are regretting their pinching pennies move to have such a measly amount of memory on the 650.
  5. #65  
    Quote Originally Posted by tomvb2000
    GL is a hog but then again it does a ton of stuff and nicely replicates Outlook functionality with full wireless sync. Non-wireless sync close equivalent was BeyondContacts. As I remember, it took 5-6M of memory on my 600 as well, 'course didn't have cache problems then.

    It seems equally amazing that P1 in their infinite wisdom gave us such as capable device with a huge handicap. Given all the bad press and customer support problems they've had over the last 6 months, I hope they are regretting their pinching pennies move to have such a measly amount of memory on the 650.
    I actually agree with you on this one, it's more than evident that an 8M cache is simply not enough or the caching method to execution isn't feasible. I think PalmOne just underestimated the amount of memory the Treo 650 will require to run with any kind of stability. Luckily I don't use Good and just use Snappermail with IMAP-SSL/SMTP-SSL.

    I will say that dbCache has made application switching faster with rock-solid stability without any of the ill-effects others have pointed out. Of course, I'm lucky in that I don't use those applications that are afflicted by dbCache Tool.
  6. #66  
    Quote Originally Posted by Treolo
    Xathros,

    Do you have SplashBlog installed? If so move it to the SD card and run it and view a few pictures. Then exit and you will see the Chatter is Shutting down message.

    Al
    No, Sorry I don't have SplashBlog. I do have GfxViewPro, AvantGo and a few other heafty apps but none of them seem to produce this behavior.

    -X
    Xathros

    SprintPCS 650 since Nov 2004
  7. #67  
    You can't help but think the only thing PalmOne and PalmSource had in common over the last year was "Palm" in the name - they definitely didn't work together well in the design and dev of the 650. Methinks that was also a factor in the PalmSource CEO resignation, buy-back of the Palm brand, etc.

    I've gone from Pilot->Visor->Treo90->Treo300->Treo600->Treo650 so I'm clearly addicted and in it for the long haul. Given it's almost June, it seems time for a new Treo700 rumour thread - just like last year
  8. #68  
    Wow! Nice work Tom! It's a nice thing to see and read some intelligent conversations here once in a while.

    -X
    Xathros

    SprintPCS 650 since Nov 2004
  9. #69  
    I am at 5 1/2 days without a soft reset. Previous record was just over 2 days (which is about average as well).
  10. #70  
    Quote Originally Posted by Xathros
    Wow! Nice work Tom! It's a nice thing to see and read some intelligent conversations here once in a while.

    -X
    X - all the credit goes to the ventriloquist
  11. fmcgirt's Avatar
    Posts
    229 Posts
    Global Posts
    294 Global Posts
    #71  
    Quote Originally Posted by tomvb2000
    You can't help but think the only thing PalmOne and PalmSource had in common over the last year was "Palm" in the name - they definitely didn't work together well in the design and dev of the 650. Methinks that was also a factor in the PalmSource CEO resignation, buy-back of the Palm brand, etc.
    There is another factor which may be in play here too. The 650s are built by a Taiwan company, Carrier Devices, who also build the Pocket PC iMate PDA2K and JAM. These PPC devices have a similar hardware memory design as the 650 and are beset with reset and GPRS connect problems. Both are very fragile with respect to the handling of memory and to some apps that when installed give rise to memory problems similar to the 650.

    My point is that perhaps there are hardware problems connected to the NVFS design that neither Carrier Devices or P1 are capable of dealing with in a timely manner. Or P1 is at the mercy of CD when trying to correct these problems. I and others have sent numerous emails to iMate and Carrier Devices about our problems (with no response) so they must know about the problems as I am sure that P1 is with the 650. I'll just bet that this hardware design was implemented without enough thought to all the software implications it generated and now Palm and all of us are all paying the price with our expensive, "almost" paperweights.

    Another thing that is somewhat puzzling is the decision by TMO to not market the 650 and to go with the next generation - unlike Cingular. Surely they know that they are missing out on a ton of sales and revenue. Could it be that they don't feel that trying to deal with consumer dissatisfaction with the 650 is worth the money?

    My GSM Treo 650 on TMO with FW 1.23 now does not reset at random and I have no MMS or GPRS connection problems but I soft reset both before and after my BackupMan backups each night. Also I have carefully culled out all apps that were causing resets - if I ever had a problem with one - out it went immediately. I know everyone can't do that because of corporate or business requirements.

    I just wish our iMate PPCs were in as good a shape as my 650.

    Frank
  12. #72  
    Well, I've tried DBCacheTool in conjunction with MemoryInfo (great app oscarc!). Even though I've tried using evil's settings, I still notice the NVFS memory slowly ebbing away, both the "Total Free" and the "Largest Free Chunk". Is this what DBCacheTool is supposed to prevent? So far, it isn't working for me (650 GSM w FW1.15). :-(

    What about us TCers who have it working correctly? As a test, can you try using MemoryInfo to observe whether your memory remains "fresh"?

    MemoryInfo is available through this thread:
    http://discussion.treocentral.com/sh...ght=MemoryInfo
  13. tmt
    tmt is offline
    tmt's Avatar
    Posts
    84 Posts
    #73  
    Quote Originally Posted by kugs10
    Can you explain why a full cache is better than an empty one? I understand this in theory, but based on what others are experiencing with DBCache, it seems as though the Treo functions better with a smaller cache.

    Also, does anyone have a link explaining how this cache works and why I receive out of memory errors while using blazer?

    Thanks.
    Here's a so-so PalmOne article: http://kb.palmone.com/SRVS/CGI-BIN/W...m_External2001

    The reason a full cache is better than an empty one is because it's a cache - a copy of something that's much more quickly accessed than the original. Unlike RAM-resident Palm databases, NVFS-resident apps cannot be executed in place, they must be copied to the cache. If your cache is empty, it means an access has to go all the way to NVFS, and for large apps this takes time. So your application startup may be slower.

    As for your Blazer errors, I would suggest reducing the Blazer cache (a different cache, but it's encountering a similar error). Another PalmOne article on that: http://kb.palmone.com/SRVS/CGI-BIN/W...m_External2001
  14. #74  
    Quote Originally Posted by tmt
    My opinion is that this article is virtually useless because it doesn't give you a credible, almost-always-useful solution. I can't help but think some poor writer was thinking "I know we underestimated the amount of cache we'd need and there isn't any way to fix it now, but I need to say something just so we have an answer to the question we get every hour".
    The reason a full cache is better than an empty one is because it's a cache - a copy of something that's much more quickly accessed than the original. Unlike RAM-resident Palm databases, NVFS-resident apps cannot be executed in place, they must be copied to the cache. If your cache is empty, it means an access has to go all the way to NVFS, and for large apps this takes time. So your application startup may be slower.
    True but if and only if the cache is large enough to keep the system processing. Once it's full, you're stuck and can't stuff any more into it. That's the problem some of us are having.

    System/chip architecture design is tricky because it's a constant tradeoff between processing/throughput, capacity and area/cost added by the cache and complexity of managing the cache with the rest of the memory system. I think it's fair to say they underestimated the size of the cache they'd need perhaps by wrongly assuming no one wouldn't add all the 3rd-party apps to the stock Treo that most of us have.
    As for your Blazer errors, I would suggest reducing the Blazer cache (a different cache, but it's encountering a similar error). Another PalmOne article on that: http://kb.palmone.com/SRVS/CGI-BIN/W...m_External2001
    This is good advice and certainly helps to some degree.
  15. #75  
    Quote Originally Posted by tmt
    The reason a full cache is better than an empty one is because it's a cache - a copy of something that's much more quickly accessed than the original. Unlike RAM-resident Palm databases, NVFS-resident apps cannot be executed in place, they must be copied to the cache. If your cache is empty, it means an access has to go all the way to NVFS, and for large apps this takes time. So your application startup may be slower.
    tmt, I know you're trying to help and contribute so please don't take this as an insult, but if this were true in practice, not just theory, then we would notice a significant slow-down when using DBCacheTool, however, the exact opposite appears to be the case. Application switching and application launching is actually MUCH faster than using the vanilla cached execution method without dbCacheTool.

    While practice shows that dbCache Tool decreased application load times, increases phone stability, and costs nothing I think I'll keep what I've got. The theory behind the caching may be sound, but caching is almost useless when the maximum cache size is so small and the phone is crashing left and right because the available cache resources have been depleted.
  16. #76  
    For me, it seems like dbCache is helping speed app switching and prolong the inevitable soft reset to reclaim cache, so it's a keeper for me as well. I do see gradual filling but can't tell for sure where it's coming from (memory leaks in some apps?).

    With a scheduled "maintenance" soft reset in the very early morning and typical app use, I can get through most of the day, sometimes a whole day, without filling up the cache. My biggest problem is that after boot up and app load, I start with very little free cache. Time to learn to live with it I guess.

    Did try UDMH but as expected, it only deals with dynamic heap, not nvfs cache.
  17. #77  
    I have two problems that I am experiening with this app. First, I still soft reset after using BackupMan and when ChatterEmail picks up (I have Chatter set to go to summary when the unit sleeps. Then, when a app that is stored on SD using ZL is being returned to the SD after use, for some reason, Avantage RX thinks that its a good time to prepare for hotsync. ANybody got suggestions or more detailed instructions on the app?
    La Vie En Diaspora: Enfin, une émission qui raconte votre vie aux Etats-Unis

    Treo 600 in December '03, Treo 650 in February '05, HTC TyTN Pro in August '06, and back to Treo 750 in January '07, find me at MyTreo.net

    About me: story of the 100thMonkey
  18. #78  
    dbCacheTool seems to be doing something to my Sprint data connection in connection with Chattermail. Since installing it, the data connection dies somehow and the phone portion needs to be restarted for data to flow again. Disabling the AUTO part of dbCacheTool has resulted in normal operation, ie, the data connection idles successfully and Chatter runs normally.

    Could dbCacheTool be removing parts of the TCPIP/CDMA data stack from the cache when it is normally necessary?
  19. #79  
    I removed the dbcache app since it was messing up my 650. It would randomly cause pxaclocker to stop working. I'd check every now and then and find that pxaclocker was turned off.

    I didn't see any point to leaving it on my 650 if I needed to turn off the auto function to get other programs to work correctly.
  20. #80  
    Hey folks, I downloaded it, it pick up some speed. Sorry if this has been posted already, I saw a pic of someone else's setting on this app, but as a Sprint Treo 650 CDMA what is the best settings for this app? Or what has worked for you? Thanks.....
    "A man who drinks only water, has something to hide to his fellow man."

    My beer blogs:

    Rev. Rhino on Flickr

    Rev. Rhino on Twitter

Posting Permissions