Page 1 of 2 12 LastLast
Results 1 to 20 of 21
  1.    #1  
    So instead complaining about how bad everything is, I'm proposing solutions for P1/PS if for no other reason than to show it can be done, and done with just an OS upgrade. In all honesty they've probably already thought of these and I hope they'll implement them or something similar.

    Disclaimers: I am a software engineer but I do not work for P1/PS or have any special knowledge of the Palm OS internals. I do think these are real problems but I'm still going to get a 650 and I'm going to enjoy the hell out of it.

    There are two steps backward with the 650 and they're both due to NVRAM: speed and memory bloat.

    Speed

    The 650 has a faster processor than the 600 so the only thing that can be slowing it down is the RAM-NV swapping. Reading from NV to RAM before execution is usually an unavoidable delay. However, writing it back can be handled much better.

    The SD card benchmarks that have been posted here show that writing is an order of magnitude slower than reading, and NV should be similar. I'm guessing they're using the simple, easy to implement way of just writing everything back when a program closes and then starting the new program. Since writing is slower, the delay in switching is probably caused by the old program closing much more than the new program opening. They should be caching the write and doing it in the background.

    So this is the new scenario. There's a write cache in RAM. Like on a desktop computer, when anything looks to the disk the OS first checks the cache and then goes to disk if it's not there, so there's no risk of reading something outdated before the write takes place. So the new program starts immediately (or rather, starts moving from NV to RAM immediately) without the write, which should remove most of the delay. The cache is emptied in idle time in the background, so it doesn't slow down the executing program.

    The cache is tied into the memory manager, so when it needs more RAM, it dumps part of the cache to NV immediately to get the RAM it needs. This prevents the cache from keeping memory from applications because it will only be in effect if there's extra RAM available. This would cause a slowdown since the app would have to wait for this write, but it shouldn't happen nearly as often because most apps won't suck up all available memory right away. Also, you can get away with only dumping part of the cache immediately, so it will still be faster than the old way. When it's working in the background during spare processor time, cache dumps should start happening right away so you lessen the chances of this situation coming up. You only want the cache to exist before it gets time to dump it, you don't want to try to do write combining and risk unnecessarily forcing an app to wait for it to empty.

    So there you go. Faster execution due to delayed writing that doesn't keep memory from the applications. It won't be as fast as pure RAM only, and there will be times when the app has to wait for NV writing, but it should be greatly reduced. It just requires the programmer effort to be put in.

    The NV to RAM read delay isn't a completely unavoidable, but caching would have much less of an effect. It should probably still be done, though. A read cache can store unchanged data at an even lower priority than the write cache. So if you load app A and switch to app B, app A and its data don't drop from memory until it's needed by another application or the write cache. So if you go back to app A while it's still in the cache, it doesn't have to be read again. If the memory manager needs memory, it takes it from the read cache (no performace hit) then the write cache (has to wait for a write) before giving up. After the write cache puts something on disk, that memory block can go straight into the read cache. The performance increase will be smaller, though, which is why this isn't as important although it still should probably be done.

    Memory Bloat

    Memory is bloating because they're mapping records directly to the 512-byte sectors. Again, they're using the simple, easy to implement way. Need a record, read the sector. Save a record, write the sector. Easy.

    Since we're now seeing that in many programs records are too small and numerous for this to be practical, they need to go to sub-sector record sizes.

    This will hurt performance a bit, because while reading is the same, writing means they have to read in the sector before updating it and writing it back to disk. They have to get the data that's stored on the rest of the sector because they can't write in smaller increments.

    The caches described above should alleviate this somewhat. If the application isn't using all of the available memory, the sector might still be in the read cache so you can avoid this extra read. Even if it isn't, having writes cached and executed in the background means the fact that they would be even slower wouldn't matter as much. It would only be noticable when applications have to wait for the write cache to be dumped, which shouldn't be the rule.

    So there it is. Caching, plain and simple. Lessens the performance hit, which in turns lessens the drawback to getting rid of the memory bloat. Tying it into the memory manager means it never keeps memory away from the applications. These aren't esoteric ideas, they just need the programming effort to be put in, and they can all be done behind the scenes with an OS upgrade.

    Please do not flood Peter Skillman with this. I'll send him one copy, not because I think they didn't come up with it already, but just so you don't all take it upon yourselves to do so and possibly swamp his inbox.
    Last edited by GregV; 11/21/2004 at 09:35 PM.
  2. #2  
    I don't no what you said but, "YOU'RE HIRED!"
  3. #3  
    you're fired.

    F1 has no need for innovative thinking.

    However, an OS upgrade is virtually unheard of on PDAs, let alone Smartphone (or any phone for that matter).

    Minor bug fixes, maybe, if you are lucky. But for something like this? NFW.

    Nice try.
  4. #4  
    I will pay you twice as much as cglaguna, your hired with benefits. Jk!
  5. #5  
    GregV, great post.

    I do think P1 did make a mistake in releasing the 650 with only 32mb, especially when they knew there would be implications as a result of the new NVRAM, but it's also great to see someone apply some positive thinking and outline a possible software solution.

    I have one question. The PalmOS (at least the 5.x version found in the 650) is not multithreaded. It's my understanding that your caching solution would require a background thread to clean the cache during periods of inactivity. I'm wondering how easy/possible this is to implement with the PalmOS architecture (of which I'm not familiar at all.)
    Oh, so they have internet on computers now!
    --Treo 650 unlocked/unbranded with Rogers
  6. alee's Avatar
    Posts
    410 Posts
    Global Posts
    805 Global Posts
    #6  
    One question I have is whether the next generation PalmOS, with updated internal applications, will have a data structure that better utilizes the cluster segments. The answer may already be there... remember, we were all expecting PalmOS 6.0 for the Treo 650; however, the decision was made to do 5.4 instead.
  7.    #7  
    I remember reading somewhere that Palm OS did have limited threading capabilities, but it wasn't robust enough to allow applications access to it. It's there, but it's only used internally and thus can be used by the OS.

    Even if it isn't there, you can do it in idle time the same way people did it on Windows 3.1. When the application's event loop empties, the function that gets the next one will not return until a new event occurs. In this situation, the OS can write one sector, check for messages, write one sector, check for messages, and when they finally get one, return to the application with it. It will continue dumping the next time the event queue is empty.
  8. #8  
    Quote Originally Posted by mikec
    you're fired.

    F1 has no need for innovative thinking.

    However, an OS upgrade is virtually unheard of on PDAs, let alone Smartphone (or any phone for that matter).

    Minor bug fixes, maybe, if you are lucky. But for something like this? NFW.

    Nice try.

    Dude, why do you keep calling PalmOne "F1"? If you want to call it P1, fine..! but F1 just doesn't work. It makes me think that you just found out that the Treo is made by something call FunOne or some F like that.

    Al
  9. #9  
    Quote Originally Posted by mikec
    you're fired.

    F1 has no need for innovative thinking.

    However, an OS upgrade is virtually unheard of on PDAs, let alone Smartphone (or any phone for that matter).

    Minor bug fixes, maybe, if you are lucky. But for something like this? NFW.

    Nice try.
    Dude you don't know what you are talking about. Palm used to give full OS upgrades from OS 3.1 to OS 3.2 and that was why many people liked Palm, because they had Flashable ROM and the OS could be upgraded. And that was why so many Visor users were so unhappy with their non-flashable ROM.
    You don't even know how to spell PalmOne so that means YOU ARE FIRED..!

    Al
  10. #10  
    PalmOne has sufficient software expertise both locally and whereever they outsource programming to that thy are well aware of every single method to "fix" this and have been for a long time.

    Their resources are dedicated to The Next Big Thing with showstopper bug fixes handled as they come in. Unless someone On High says "This is a showstopper" you can be SURE an extensive fix is NOT in the cards this time around.
  11. 1SFG's Avatar
    Posts
    191 Posts
    Global Posts
    201 Global Posts
    #11  
    just curious - on what are you basing this conclusion? have you had a similar problem develop in a previous palm product where the outcome is as you describe below? i've never had an issue with any of their devices below, so i'm curious as to what specific examples you are referencing that have led you to this conclusion.

    Quote Originally Posted by SeldomVisitor
    PalmOne has sufficient software expertise both locally and whereever they outsource programming to that thy are well aware of every single method to "fix" this and have been for a long time.

    Their resources are dedicated to The Next Big Thing with showstopper bug fixes handled as they come in. Unless someone On High says "This is a showstopper" you can be SURE an extensive fix is NOT in the cards this time around.
    1st SFG (A)

    if at first you don't succeed - RELOAD!
  12. #12  
    I'm sure P1 are well aware of the 650 Mem Bloat 'Phenomenon' (MBP) - and they probably don't give a monkeys about pleasing existing T600 customers. A large percentage are probably going to buy the 650 regardless.

    What interests P1 are new customers - those who have never had a Treo and therefore know nothing about the MBP.

    P1 are not going to throw untold resources at this but no harm dreaming...
    www.gsmworld.com
  13. #13  
    Does this make it sound like this type of caching is already going on? From the P1 support FAQ page:

    Solution ID: 32904


    'Out of Memory' (during VersaMail's 'Get Mail' function with large email accounts)


    Downloading a large number of messages at one time may result in an "Out of Memory" error in VersaMail.

    Why does it happen?
    Your Treo 650 smartphone includes non-volatile memory, which requires a new caching method in the file system. When the volume of email exceeds 7MB to 10MB (7,000KB to 10,000KB), this error occurs

    What should I do?
    Press Applications to exit VersaMail. Then launch VersaMail again. Tap the Get or Sync button to finish manually downloading your remaining email.
  14. #14  
    Quote Originally Posted by 1SFG
    just curious - on what are you basing this conclusion?
    I have more than 20 years solid day and night experience (since Computer Science graduate school) working with software in a variety of environments especially in tightly-controlled "managed" development environments.

    That's all!
  15.    #15  
    Quote Originally Posted by SeldomVisitor
    PalmOne has sufficient software expertise both locally and whereever they outsource programming to that thy are well aware of every single method to "fix" this and have been for a long time.

    Their resources are dedicated to The Next Big Thing with showstopper bug fixes handled as they come in. Unless someone On High says "This is a showstopper" you can be SURE an extensive fix is NOT in the cards this time around.
    Nonsense. This isn't just an issue with the 650, it's an issue with all their NVRAM-based products, which seems to be what they're doing going forward. So this affects their future products as well. There are only two possible ways to ignore this.

    1. Load up all their future products with enough memory that bloat isn't an issue. The speed impact will still be there because it's an issue of memory speed, and solving the speed issue removes the drawback to solving the bloat issue.

    2. Ignore it because it's OS 5 and they're moving to OS 6. I've seen somewhere in this forum that when pressed, they gave the impression that OS 6 still has a long ways to go. And this issue may still need to be addressed there as well.
  16.    #16  
    Quote Originally Posted by zamiv
    Does this make it sound like this type of caching is already going on? From the P1 support FAQ page:

    ...

    Downloading a large number of messages at one time may result in an "Out of Memory" error in VersaMail.

    Why does it happen?
    Your Treo 650 smartphone includes non-volatile memory, which requires a new caching method in the file system. When the volume of email exceeds 7MB to 10MB (7,000KB to 10,000KB), this error occurs
    I think this is simply it running out of conventional RAM, since there's only 10MB of that on the 650. There's no equivalent to virtual memory to compensate.
  17.    #17  
    Oh, and Peter forwarded it to the SW guys. So while there's no guarantee of anything, the idea is at least out there if it wasn't before.
  18. #18  
    Quote Originally Posted by acajigas
    Dude, why do you keep calling PalmOne "F1"? If you want to call it P1, fine..! but F1 just doesn't work. It makes me think that you just found out that the Treo is made by something call FunOne or some F like that.

    Al

    I think anyone who reads TC enough (too much? ;-) ) knows what "F1" means.

    I will continue to use it per my resolution in another thread.
  19. #19  
    Quote Originally Posted by acajigas
    Dude you don't know what you are talking about. Palm used to give full OS upgrades from OS 3.1 to OS 3.2 and that was why many people liked Palm, because they had Flashable ROM and the OS could be upgraded. And that was why so many Visor users were so unhappy with their non-flashable ROM.
    You don't even know how to spell PalmOne so that means YOU ARE FIRED..!

    Al
    Duuuuuuuuude, I do know whay I am talking about.

    I have had Palms since they first came out; I know you could upgrade 3.1 to 3.2. Big whoopie! It wasn't like 3.x to 4.x, or 4.x to 5.x, etc.

    Also, when was that? 8 years ago? Maybe I should have said it is "currently" unheard of". It certainly never happened with the Treo (other than small bug fixes).

    And as I recall, there were a lot of happy Visor owners...who became Treo owners.

    I can spell just fine...you don't know how to read...so F1 and....
  20.    #20  
    It would have to be a crash that completely shuts down the OS without warning. Since the OS is still functional enough to put the error message on the screen, it should still be functional enough to empty the cache, as the code for it would be completely separate from the application.
Page 1 of 2 12 LastLast

Posting Permissions