Paging Dr. RAM

re: Paging Dr. RAM

Mike Dimmick — Sat, 01 Apr 2006 13:14:13 GMT

I'm concerned that if you start using Persistent Storage - built-in flash - for paging out modified writeable pages, you'll wear out the flash that much faster, even with wear-levelling. I would expect you to do it only when memory was very tight, rather than eagerly, as the desktop does, minimising the amount of dirty page writes rather than maximising the amount of free memory.

As has often been said, it may be better to actually close applications when the user taps the 'close' button rather than keep them running in the background; this relies on the application genuinely implementing save-state functionality to resume at the point that the application was closed. It might be necessary to implement something like the 'resolution-aware' resource for the application to indicate that it really can resume in the same state if closed, and keep 'smart-minimise' functionality for applications which don't opt-in.

re: Paging Dr. RAM

Chung-Ho Liu — Sat, 01 Apr 2006 18:41:39 GMT

Since the price of flash rom is getting lower and lower, maybe OEM can think about putting more flash ROM into WM5 devices. Then the problem of so-called wear-leveling won't be an issue if the rom size is more than 1GB. The other advantage is memory card is not necessary to be inserted if we already have GB of flash rom in our devices.

re: Paging Dr. RAM

surur — Sat, 01 Apr 2006 22:57:56 GMT

I posted this over at Jason Langridge's blog, but hopefully I can get an answer here.

We know the OEM has certain reasons for giving us the amount of RAM they do. Despite this many of us desire more RAM, and would pay more to get it if the option was available. In the past this was possible through RAM upgrades (e.g. upgrading the Imate jam to 128MB). With WM5 this has not been possible so far. PPCTechs tried this with the 32MB Treo 700w, but even after adding in a 64MB SDRAM chip only 32MB was visible to the system. I believe this is due to the partitioning information being hard-coded in the ROM, which would essentially mean that the ROM would need to be modified to make this ram visible. I understand this involved just changing 2 bytes in the ROM image.

There are 1000's of people with Treo 700w's who would love to upgrade the ram (at their own risk of course). Could you provide us with some more information on the schema of how the ram is specified, and which areas may need to be changed. I'm sure there are plenty of hackers who would be able to use this information to make their devices work better.

Surur

re: Paging Dr. RAM

tmarkoski — Mon, 03 Apr 2006 13:34:50 GMT

Great..<rolliing eyes>

We get another worthless post from the head apoogist at MS explaining that WM5 is really a pig but it's not their fault.

re: Paging Dr. RAM

solnyshok — Mon, 03 Apr 2006 13:46:41 GMT

Mike,
how would you comment a tweak on aximsite as described below:

...hack to move temp file to Storage card instead of FlasROM as recommended by Shsmith:
"... On WM5 most of these now go to \Application Data\Volatile, which is in your (slow) flash memory...Open a registry editor and navigate to HKEY_LOCAL_MACHINE\System\FileSys and edit the TempPath key.I changed mine to \SD Card\Volatile. You need to manually create the Volatile folder on your SD card."

re: Paging Dr. RAM

little_john — Mon, 03 Apr 2006 17:47:00 GMT

how would you comment a tweak on aximsite as described below...

I'd like to hear the answer to this one as well.

re: Paging Dr. RAM

Dan S — Mon, 03 Apr 2006 18:59:21 GMT

I think memory paging on a mobile device is probably a bad idea for a lot of the reasons Mike laid out, but the biggest is the hit to performance.

The easiest solution is for OEM's to include more RAM on their devices. 64 should be the minimum and 96 would probably be the sweet spot on today's devices. I'd love to see a 128 MB RAM device that the OEM partitioned to use 64 MB as "storage" for the OS and related programs, as that would eliminate the lag we find in using persistent storage ROM. They'd have to find a way to mirror this RAM back to flash on a regular basis however so data wouldn't be lost if the battery's run out.

Any chance this is possible with the OS in it's current state?

re: Paging Dr. RAM

Dylan Greene — Tue, 04 Apr 2006 06:25:03 GMT

On some devices the device must be turned off to remove the memory card because the card slow is behind the battery.

Why not have a reg setting to let the OS use the memory card for the PagePool/PageFile in these situations.

Or always let the card be used, and when the user ejects its, halt all applications, put a warning on the screen saying "Insert Card to Conitnue" like the old days of DOS boot disks. How often are users swaping their memory cards anyway?

Translations of your blog entries

Bukovansky Richard — Tue, 04 Apr 2006 20:38:22 GMT

Dear Mike, I have a little question about your
Would you please approve me to translate your articles from this site to my native language (more people will read your posts and will understand WM5).

Thanks for info.

PS: Sorry for bugging here, but I can't find your e-mail address. :-(

Richard Bukovansky

re: Paging Dr. RAM

badbob001 — Wed, 05 Apr 2006 20:56:16 GMT

The x51v can be upgraded to 128MB ram so the Treo 700w's ram limitations may be a design "feature" of the hardware. Remember that Palm probably shoehorned WM5 onto PalmOS-specific hardware.

re: Paging Dr. RAM

Solnyshok — Mon, 10 Apr 2006 14:09:41 GMT

Mike,

people do some crazy registry tweaking to improve WM5 performance on their machines. Is there a chance we get an article on it or at least a thread to discuss it with the "fathers" of Windows Mobile?

Solnyshok

re: Paging Dr. RAM

MikeCal — Tue, 11 Apr 2006 03:15:34 GMT

Surur, here's how it works for all OEMs, Palm and otherwise.

The RAM start address and length are put into the system's "table of contents" at the time when the image is made. If the OEM doesn't do anything else, the system will boot with that amount of RAM visible. However, the OEM has the ability to, at boot time, do something to discover there's more RAM available and tell the system to use it.

If the OEM knows he's going to ship multiple RAM sizes for a piece of hardware, he's likely to write the code to do this.

However, if the OEM doesn't expect to release a version of the same hardware but with more RAM, he's unlikely to write that code. Even if he later decided to add a SKU with more RAM, he could always add the code then. So the code not being there is going to be typical anytime there's only one version of the hardware available.

Finding the location of the RAM length in the table of contents after the fact would be relatively challenging. The location changes based on the size of the OEM's code, so I can't tell you where it is. You need the OEM to tell you. In this case, PPCTechs would need to work with Palm to get the best means to change the value.

Mike

re: Paging Dr. RAM

MikeCal — Tue, 11 Apr 2006 03:19:32 GMT

Solnyshok, can you post a link to the axim site that talks about the things that point to Volatile? I'm not familiar with that key and will need to do some research.

Here's an article that talks about the compaction thread:
http://blogs.msdn.com/windowsmobile/archive/2006/03/16/552996.aspx

and here's one that talks about moving some caches to an SD card:
http://blogs.msdn.com/windowsmobile/archive/2005/07/20/441038.aspx

Mike

re: Paging Dr. RAM

MikeCal — Tue, 11 Apr 2006 03:37:23 GMT

Dan, there's a large range between writing every changed bit to flash immediately, caching some amount and writing it later, and caching it all and writing it all at one time. The tradeoffs are performance and data integrity. The more you cache, the faster the device will run, but the more the user will lose when he pulls his battery.

Many phone users don't bother to press the power button. They just pull the battery and put it back to turn the device off. Everyone reading this might not do that, but we have to design our code to find the right balance between performance and protecting those users.

OEMs and Mobile Operators prefer protection over performance, because the user who pulls his battery and loses data makes expensive product support calls. I've literally had long meetings where OEMs yelled at me that, if they changed a setting and pulled their batteries in less than 2 seconds, the setting wasn't persisted. There are no easy answers here.

What you're describing is moving farther toward performance and farther away from data integrity. It's certainly possible for an OEM to do, but I don't expect them to.

Mike

re: Paging Dr. RAM

MikeCal — Tue, 11 Apr 2006 03:41:22 GMT

Richard, if you'd like to go to your own blog, post a link to this blog, say something like, "Here's what he said," and translate it, you're welcome to. Just make sure people understand that it's your translation and not mine.

Mike

re: Paging Dr. RAM

badbob001 — Wed, 12 Apr 2006 02:07:32 GMT

There isn't much discussion on moving the temp folder to external storage, but it may have been first mentioned here:
http://www.aximsite.com/boards/showthread.php?p=926592

The registry key is:
HKEY_LOCAL_MACHINE\System\FileSys\TempPath

I've tried it and it usually works. I suspect when an app still writes to \temp, it may have that setting hardcoded.

re: Paging Dr. RAM

badbob001 — Wed, 12 Apr 2006 02:14:03 GMT

Another possible item to move to external storage is:

HKCU\Software\Microsoft\MediaPlayer\Preferences\DownloadCache

re: Paging Dr. RAM

Solnyshok — Wed, 12 Apr 2006 11:19:18 GMT

Mike

There are discussion on aximsite, brigthand and mobilitysite and a slew of other sites, all around same issues - performance of WM5 on Dell X50v and hx4700.

Main topics - compaction thread, cache optimization, white screen of death on wakeup, CF cards disappearing on wakeup. Please see this thread below to see what people are doing to speed up WM5 performance on the PPCs. Maybe some of tweaking that we do, results in other problems that we experience.

http://www.aximsite.com/boards/showthread.php?t=104366

While fake activesync server seems pretty safe tweak, filesys is something we can do nothing about except for installing programs to cards.

Tweaks on file system cache seem risky. People change some flags without knowing what they stand for, e.g. Cache Flags, PNP unload delay, etc. (same aximsite link above) .

Also, many people experience problems with CF cards. Cards that worked flowlessly under WM2003SE, disappear on wake up in WM5, and no one found solution yet. This is especially annoying problem, since we are forced to keep our programs on cards and if card is gone on wakeup, programs quit too.

Link to problem description here
http://www.aximsite.com/boards/showthread.php?t=112638

Please note post by PeteSleeman on CF bus timings (11-11-2005)
http://forums.us.dell.com/supportforums/board/message?board.id=dellpda&message.id=34231

Regards,
Solnyshok

re: Paging Dr. RAM

surur — Wed, 12 Apr 2006 20:09:48 GMT

Mike, Thanks for the reply. I hope PPCTechs find a much needed solution.

Surur

re: Paging Dr. RAM

William — Wed, 12 Apr 2006 21:38:32 GMT

How do the Windows Vista do that? Can we use the same mechanism to WM?

re: Paging Dr. RAM

MikeCal — Thu, 13 Apr 2006 03:25:46 GMT

badbob and Solnyshok, thanks for the info. I'm asking around about some of those registry keys.

As for the CF card disappearing, I'm at something of a loss. The CF card detection is done by a driver written by the OEM. So it would be pretty easy to assume that Dell changed something there and broke it. However, the fact that you can fix it by disabling ActiveSync is very confusing.

I read a bunch of the "Disable AS" thread and have a theory, but it's just a theory. It sounds to me like the CF driver runs the risk of dying every time the device turns on. If AS is trying to sync every 5 minutes and is waking the system up to do it, then the system will turn on a lot more times a day with it running than without it. That makes the CF issue more likely to happen.

If I'm right, then any app that causes the device to turn on frequently would cause the same problem.

My part of the world is phones. I don't have much interaction with the non-phone devices. I'm not sure why AS defaults to wake up so often on a non-phone device. It makes a lot of sense on devices where you can sync over the air, but not on an un-connected device like the Axim.

Mike

re: Paging Dr. RAM

MikeCal — Thu, 13 Apr 2006 21:13:12 GMT

Okay, I've done my research, and here's what I've found.

That axim site suggested that you change these registry keys:
HKEY_LOCAL_MACHINE\System\StorageManager\Filters\fsreplxfilt\ReplStoreCacheSize=4096
HKEY_LOCAL_MACHINE\System\StorageManager\Profiles\MSFlash\FATFS\DataCacheSize=0x1FA0(4096)
HKEY_LOCAL_MACHINE\System\StorageManager\Profiles\MSFlash\FATFS\Flags=0x28(40)

That will have no effect for the same reason changing the CompactionPriority keys have no effect (see the "What about these registry keys" section of http://blogs.msdn.com/windowsmobile/archive/2006/03/16/552996.aspx).

If you could change the keys (which you can't), the sizes are pretty large. 0x1FA0 is 8K, not 4, and would result in burning 4M of RAM. And the RepleStoreCacheSize is measured in records, not bytes, so 4096 is really excessive. 256 is a more reasonable number.

Setting these two keys:
HKEY_LOCAL_MACHINE\System\StorageManager\FATFS\CacheSize=4096
HKEY_LOCAL_MACHINE\System\StorageManager\FATFS\EnableCache=0x1(1)

Will have an effect, but probably not the effect you expect. Those are the default values that are used if there's no specific value overriding them. THe MSFlash keys override those values for internal flash (assuming internal storage is using MSFlash and not some other filesystem). So, most likely, those two keys will only affect CF/SD cards. By the way, setting those two values to that amount will consume 2 megs of RAM. So make sure you understand the tradeoffs before changing them.

Setting the TempPath registry key should work. You can point it to an SD card, or a RAMdisk you've installed. (Hey, if you're willing to set your device to have 6M of caches, maybe a RAMDisk is a good idea...)

Mike

re: Paging Dr. RAM

Solnyshok — Fri, 14 Apr 2006 17:15:26 GMT

Thanks Mike. I will do some more testing with this new information.

CF card disappearing from the systems seems unrelated to Active Sync. It happens even if one switches machine off/on couple of times. It happens on computers fresh after hard reset - no tweaks, no additional software installed. If it is done by OEM, seems that HTC (they made both Dell X50(v) and hx4700 ) not getting it right...

re: Paging Dr. RAM

MikeCal — Sat, 15 Apr 2006 00:12:27 GMT

It's pretty hard for end users to tell who is responsible for what on a Windows Mobile device. There are usually 4 different groups providing code for the device.

I should write a blog about that.

One of the parts, though, that is definitely owned by OEMs is the drivers that make the hardware work. CF/SD, touch screen, buttons, display, audio, headset, the cell radio, bluetooth, wifi, etc.

Now, while these drivers are their responsibility, when they break isn't always their fault. Sometimes we change something from one version of our OS to the next that makes their code stop working. It's possible that something like that happened here (though I don't remember us changing CF/SD for WM5).

But, in the end, if the driver is what is causing the problem, only the OEM can fix it. We don't have access to their code.

Mike

The Mobile Minute 137

Nino.Mobile — Wed, 19 Apr 2006 09:02:42 GMT

&nbsp;&nbsp;..just a few tonight as I get back in the groove. My new project kicked off this week here...

re: Paging Dr. RAM

Trev T — Fri, 21 Apr 2006 01:19:02 GMT

Hey Mike,
Thanks for writing this blog, definately clears things up for me.
I still believe that in some ways, this would be a useful addition to WM5, at least for me it would. In my case, i rarely remove the SD card storage as it contains most of my programs running on my ETEN M600, so removing it would cause problems.
Thanks anyway, and i look forward to reading more of your articles.

re: Paging Dr. RAM

Solnyshok — Wed, 03 May 2006 10:42:55 GMT

Hi Mike,

could you point me in direction of RAMDISK programs to use with WM5?

Solnyshok

re: Paging Dr. RAM

MikeCal — Mon, 08 May 2006 23:53:55 GMT

Solnyshok, I searched a bit for RAMDISKs when researching this:

http://blogs.msdn.com/windowsmobile/archive/2005/07/20/441038.aspx

But didn't find many. Someone posted a link to one in the comments of that entry, though.

Mike

CacheSize

Lat — Fri, 12 May 2006 19:55:10 GMT

Hi Mike - Thanks again for your blog entries; I along iwth many others find them quite informative.

Anyways, seeing as you've done research regarding the CacheSize and whether or not it'd best be tweaked, I'm just curious as to what you'd think would be the best.

Should we stick with the formula at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcecomm5/html/wce50tskconfiguringfatfscacheparametersforthesmbserver.asp , in respect to our SD/CF Card sizes to determine optimal CacheSize? Should we manually set it to a "known to be good" 4096? Should we leave it at 0 so that it dynamically allocates?
Should we just leave the cache completely off?

In terms of RAM usage, I think most of us would be okay loosing 2MB for more snappiness in general usage.

re: Paging Dr. RAM

MikeCal — Mon, 15 May 2006 19:31:01 GMT

Lat, personally, I leave the SD cache size to whatever the OEM set it to. The kinds of problems people have been describing are with the internal flash, not external SD cards. Unless you installed a lot of applications to the SD card, and you're using them frequently, and they seem sluggish, I wouldn't expect changing the SD card cache size to have much effect. I certainly wouldn't expect changing the SD cache size to make things in the internal flash any more snappy.

Mike

re: Paging Dr. RAM

Neil — Sun, 11 Jun 2006 06:06:39 GMT

You say that pagefiles can't go on removable storage, is this a Windows Mobile limitation?

The Nokia 770 device comes with 128MB ROM, 64MB RAM and Nokia have just released OS 2006 Beta (which is based on Debian Linux) that adds official support for virtual memory (swap file, aka pagefile) on removable memory (Reduced Size MMC, up to 1GB). I would imagine that this being Linux, and the virtual memory being a standard swap file (sizeable up to 64MB), that both code and data will be stored on the removable memory when the OS considers it necessary to do so.

I just wondered what your thoughts were on this development, as Nokia seem to consider any risks associated with a swap file/pagefile on removable memory as being acceptable. Assuming the user is made aware of any risks associated with a pagefile on removable storage, I don't see what stops Windows Mobile from adding such support.

Cheers
Neil

re: Paging Dr. RAM

MikeCal — Mon, 12 Jun 2006 18:59:48 GMT

I haven't looked into their implementation, but I see a few possibilities:

1) It's only code, not data. In that case, it doesn't really matter if the card is ejected, because you can always get the code back if you need it (it'll just take longer).

2) It's got data, but it's a write through cache. In that case, any changed data is immediately written back to storage. At that point, the cache is really only used for reads, not writes. This is a reasonable thing to do, but it takes away a lot of the value of the cache (writes aren't sped up at all).

3) It's a standard code and data cache, and if you eject your card at the wrong time, the system will either lose the data on it, or halt and force you to put the card back in.

4) Some sort of neat scheme where there are multiple caches and certain things are stored in an internal cache but other things are stored in the external cache. That would be complicated, but could work well.

I hope for their customers that it's option 4. If there's a 5th option I'm not thinking of, I'd love to hear about it.

I'm going to need to look more into what Nokia is doing with Linux. However much they like to call it an industry consortium, Nokia is the primary driver of the Symbian OS. And Symbian is the 800 pound gorilla in the smartphone market. Are they abandoning it to go to Linux? Or are they just releasing a small number of Linux phones for the highly technical market? If I knew that the only people buying my phones were software developers, I'd feel comfortable giving them restrictions like, "You can't unplug your storage card while the system is running." But if it was a mass market device, that would never fly.

Mike

re: Paging Dr. RAM

Menneisyys — Mon, 12 Jun 2006 20:32:33 GMT

I've benchmarked the effect of tweaking HKEY_LOCAL_MACHINE\ System\ StorageManager\ FATFS\ CacheSize in the hx4700. You may want to give the report a read at http://www.pocketpcmag.com/blogs/index.php?blog=3&p=903&more=1&c=1&tb=1&pb=1 .

re: Paging Dr. RAM

Neil — Mon, 12 Jun 2006 23:33:34 GMT

Hi Mike - thanks for replying.

First of all, the Nokia 770 is *NOT* a phone! :)

Just about everyone makes this mistake - they see a device made by Nokia and automatically assume it's a cell phone :) Nokia reasoned that if they were to include phone capability in the 770 they would need to get the 770 certified in every country which takes a long time, and by leaving out phone capability time to market is reduced and people can instead carry a cheap Bluetooth phone of their choice - this logic works just fine for me.

Here's a marketing page showing the 770 and the latest OS 2006 (released a few days ago, in beta form) http://europe.nokia.com/nokia/0,,75030,00.html

Since the 770 isn't a phone I don't think there is much risk of Linux replacing Symbian any time soon.

To the best of my knowledge, the swap is a regular Linux swap file (and not a partition) - code & data will be swapped out. Personally I can live with the limitation of option #3, although others might not but then using a swap file is a user choice so I would only have myself to blame for whipping out the card at the wrong time!

Since the OS has only been out a few days I haven't actually tested removal of the card, will try that later and post an update.

re: Paging Dr. RAM

MikeCal — Tue, 13 Jun 2006 00:18:03 GMT

Thanks for the link, Neil. That's an interesting device. Kind of UMPC (Origami) like. I'm sure those guys are paying close attention to it.

I browsed around on the site a bit and read the OS section of the FAQ, and it seems to say that you can't put applications on the storage card. It's wierd that you can put the pagefile on the storage card but can't put apps there. Is putting the pagefile there a configuration you can do from the UI, or are you able to do it because you have the source and you changed it yourself?

Either way, it'll be interesting to see how the device does and how many people move their pagefiles to storage cards. While there are certainly people who can understand the tradeoffs associated with putting pagefiles in various places, I wouldn't expect the mass market to be making pagefile decisions.

Mike

re: Paging Dr. RAM

Neil — Tue, 13 Jun 2006 05:06:30 GMT

Hi Mike

It's a UI configuration option - there are three tabs in the Control Panel->Memory section - Device, Memory Card and Virtual Memory. The
Virtual Memory tab gives the option to create a swap file, with a list box containing the permitted sizes between 8 and 64Mb. The comment on the Virtual Memory tab is "Memory card can be used as additional virtual memory for opening more applications" so it appears to be code-only, but then again the text may be designed so as not to confuse too much!

I've just installed xterm and when running "free" I can see I have 64Mb of swap available (some of which is in use). If I remove the memory card, all swap disappears (it's a swap file, not a partition, so this is reasonable - I'd expect a hang if it were a swap partition) and when I re-insert the memory card the swap is recreated but no swap is now in use suggesting whatever swap had been in use previously has been lost/discarded. If it were uncommitted data, tough (on me!), but if it were only code it's no big deal. I'm not sure if Nokia are restricting swap to code only - it's not stated explicitly, and would probably require some kernel tweaks to support such a feature. Perhaps any limitations imposed by the swap file, or even it's technical implementation, will become clearer as the OS nears it's release (within the next 2 to 3 months I'd imagine).

Not sure how accurate the FAQ is - one of the hacks on the current OS 2005 firmware permitted the root filesystem to be extended onto the memory card, allowing apps to be installed on the memory card as if it were device memory (in which case the device could be made to think it had several hundred megabytes of internal "ROM" memory!) I'd say the FAQ is technically incorrect. :) In fact it was this community originated hack that led to Nokia including the Virtual Memory feature.

Interesting that you mention the UMPC, as I'm not sure how similar it is to the Nokia 770 although it had crossed my mind they are both attempting to define a new product category.

The 770 was released in November 2005 (announced in May 2005 or thereabouts), so pre-dates the UMPC/Origami by a significant margin (certainly in terms of hard availability - 9 months+?), and to be honest the form factor of the 770 is what the UMPC _should_ have been.

For me, the UMPC is too big/heavy/expensive, the battery doesn't last long enough and it's too close to being a laptop/TabletPC to be seen as anything else (particularly when you consider the price of a cheap laptop these days). The Nokia 770 on the other hand is everything the UMPC is not - it's small, light and cheap (the price is about $390 from CompUSA), and the battery can easily last 6 or 7 hours with moderate to heavy usage.

Admittedly the 770 doesn't have anywhere near as many apps as Windows/UMPC, but they're coming thick and fast, and since OS 2006 is based on a standard Debian distribution existing apps can be ported quite quickly, not to mention downloaded directly to the device using the built in Debian apt-get based Application Installer (this is a _seriously_ cool feature indeed... scroll through one of the many available software catalogs, find an app you like and click "Install", that's all there is to it!) And with Google now on board, who knows what will happen in the future.

I have to say, if anyone should be paying close attention, it should be Microsoft keeping tabs on what Nokia are doing! ;) I can quite easily see the next version of the 770 - with more memory and a more powerful CPU - beginning to close the gap on the UMPC without significantly increasing cost, or size.

Many thanks for your time - I'm happy to discuss more, but would be even more interested in your opinion of the 770 if you were to get one to "have a play" :) The Beta for OS 2006 can be downloaded from www.maemo.org, this is a community development site created by Nokia for the 770 (and future devices).

re: Paging Dr. RAM

MikeCal — Wed, 14 Jun 2006 00:16:30 GMT

Thanks for all the info, Neil. A device that large but without a hardware keyboard or cell data isn't very interesting to me. But that's just me. I'm sure other people (yourself included :-) will like it.

Mike

re: Paging Dr. RAM

Neil — Wed, 14 Jun 2006 03:47:07 GMT

Hehe - can you tell?! :)

Large? It's the same size as my iPAQ HX4700.

I like to choose my phone separately from my "PDA", so the Nokia approach suits me down to the ground - whenever I need "phone" (ie. modem) functionality I can connect over Bluetooth. My current phone (a Sony Ericsson T610) is getting a bit long in the tooth, so I'll soon upgrade to the new Sony Ericsson W950i with 4GB flash for MP3s - my 770 won't change as a result though, and can still do stuff the W950i can't. All-in-one devices are the jack of all trades - master of none, and this applies to phones in my opinion (browse the web on a phone? No thanks!)

As for hardware keyboards - there are Bluetooth keyboards, same one's that can be used with PocketPC's.

Go on, you know you want one! ;)

re: Paging Dr. RAM

Juhani Suhonen — Mon, 24 Jul 2006 12:25:39 GMT

If found even more interesting suggestion... does anyone know if and what do these values do ?
[HKLM\System\StorageManager\FATFS]
"BufferSize"=dword:00000040
"CacheSize"=dword:00002000 (at the cost of 2 Mb RAM)
"DLL"="fatfsd.dll" (use strings.exe from sysinternals to see these params)
"EnableCache"=dword:00000001
"EnableCache4Way"=dword:00000001
"EnableCacheWarm"=dword:00000001
"Flags"=dword:00001006 (writethrough bla bla)
"MaxCachedFileSize"=dword:00020000 (don't cache >128Kb files)
"Paging"=dword:00000001 (ALWAYS 1!!)
"PathCacheEntries"=dword:00000064
"UpdateAcces"=dword:00000000 (I don't need access time stamps)

[HKLM\System\StorageManager\Profiles\FlashDrv\FATFS] (could differ)
"CacheSize"=dword:00000200 (at the cost of 256 Kb RAM)
"EnableCache"=dword:00000001

re: Paging Dr. RAM

geenen — Fri, 01 Dec 2006 21:10:37 GMT

Mike,

I know this is an old thread, but I have a very specific question about "paging" that I would love to have you blog about. I've been working with PocketPCs since CE 2.11. During that time our applications have always run from the memory card of the device. When CE 4 came out, we saw a problem where our app would crash mysteriously after coming out of suspend. After much discussion with HP and MS the suggestion was to turn "paging" off using a registry entry. That solved the problem. I can't say I understand exactly why, but it had something to do with the delay (3-4 second) after resume where the memory card was not available and the OS was trying to access some part of the code (resources possibly) when it wasn't there. I am now working on a WM5 device and the same problem occurs. I even comfirmed it with a simple MFC app. It will crash when you try to use it after resuming. I found a registry key that appears to turn off paging and that seems to solve the problem. If you had time, I would love to have you blog about a) how running an app off the memory card could crash due to paging, b) how to turn paging off, and c) what am I losing when I turn paging off.

Thanks.

re: Paging Dr. RAM

MikeCal — Fri, 01 Dec 2006 22:13:54 GMT

Hi geenen,

Generally issues like the one you're describing aren't related to paging. The issue is something we call the "PnP Unload Delay." Here's the general issue.

Say you've got handles open to files on a storage card. When you suspend the device, the SD bus is powered down. While it's powered down, you could concievably eject your current card and replace it with a different one. When you turn the device back on, the handles will no longer be pointing to valid files.

Our original solution to this problem was to always unmount the card whenever the SD bus was powered down. That wasn't a very good solution, though, because most of the time people don't swap cards when the system is powered off. The normal case is that users buy one card and leave it in all the time.

The newer solution is to have a delay before we unmount storage cards. If the card appears to be gone, we'll wait a few seconds before we unload it. If the card comes back within the time of the delay, we just keep running like normal. If it doesn't, we unload it and then reload it when the card DOES come back. If we unload it, all handles are closed.

The trouble is, we don't know how long it's going to take to power up the SD bus and have the card respond to requests from it. The bus time itself is going to vary from OEM device to OEM device, so we made the length of the delay something OEMs can configure. Unfortunately, the timing is also somewhat dependent on the speed of the card itself, and varies from card to card. So an OEM can tune his delay to what seems to work for all of the cards he can find, and then you can plug in a slower card that takes longer than the delay.

Fortunately, the delay is a registry key that you can modify yourself if you'd like.

HKEY_LOCAL_MACHINE\System\StorageManager\PNPUnloadDelay

Typical numbers are a few seconds, and I believe the value is in milliseconds. It should be clear when you look at the current value.

So, why not just set the number to something large that's guaranteed to work? The trouble there is that this delay is also invoked when a user ejects the card. The card won't be unmounted for the time of the delay. An easy way to see this is to go into file explorer, see the "Storage Card" there, eject it, and notice that it doesn't disappear for 3 seconds. We've literally had Mobile Operators refuse to ship our phones because in that very scenario, the "Storage Card" folder didn't disappear fast enough. So OEMs are forced to make the delay as small as they possibly can. That results in it sometimes being too slow for certain situations or cards.

I believe that your problems will go away if you increase the delay. Please let me know if they don't.

Mike

re: Paging Dr. RAM

geenen — Sat, 02 Dec 2006 00:31:00 GMT

Mike,

Thanks for the detailed post. However that solution doesn't work in my situation. I remember the issue with the open file handles, and we went through the code very carefully when this first came up a few years back to make sure were were not holding any handles open when the application is "static". We open files from the memory card, read them into RAM and then close them right away. The problem I am seeing is happening when the app is running, but not being used. The full sequence for making it happen is 1) Set power timeout to 1 minute, 2) let device suspend on its own, 3) turn on power and run our app, 4) let device suspend on its own, 5) turn on power and tap anywhere on the app window. Crash.

One interesting clue is that if your inital tap in step 5 is on one of the menus, the menu doesn't look right. In code we disable and remove a number of menu items based on the state of the app. But in this instance, the menu shows all the items from the menu resource. The app will show that menu, then as soon as you tap off of it, the application just quitely disappears. Also, I have not disabled error reporting, but I don't get the error reporting dialog coming up either.

I tried your method. I set the value of PNPUnloadDelay to 3000 (it was 1500) and then I tried 5000. In both cases, the problem was still present. I went back and reset that value to 1500, then I changed \HKEY_LOCAL_MACHINE\System\StorageManager\FATFS\Paging to a value of 0. That seems to solve the problem. When we did this same thing in CE 4.x, the registry key was a little different. In that version of the OS, we were told by someone ate Microsoft to change \HKEY_LOCAL_MACHINE\System\StorageManager\Profiles\SDMMC\FATFS\Paging to 0. That solved the problem back then. Do you know if these keys are doing the same thing?

re: Paging Dr. RAM

MikeCal — Sat, 02 Dec 2006 04:31:32 GMT

Geenen, my apologies. I went and talked to the filesys guys and found out that I gave you bad information. Everything I said about the pnpunload delay was correct, and the filesys guys believe that it is indeed the problem you're facing. What I didn't know is that it's impossible for an end user to change the pnpunload delay. The actual value is stored in an unchageable part of the registry and is loaded before the rest of the registry is loaded. What you're seeing is kind of a reflection of the real key. And changing it has no effect. Only the OEM can change that value. I'm going to have to stop telling people about this key.

For your case, it's not that your program has files open on the storage card. It's that your program itself is a file that's open on the storage card. When your program hits code that hasn't been loaded yet, the system demand pages it in. If the pnpunload is set too low, that can happen right after a suspend, which will cause the page-fault handler to raise an exception. Your workaround works because it forces the file to not be demand paged. On load, all of your code will be loaded into memory, so the card being removed shouldn't cause a crash.

The better solution would be a fixed pnpunload delay, but, like I said, you can't change that. As a result of this discussion, we're going to look into making the system reload pnpunload after the registry comes up so that it's end user configurable. Thanks for the feedback!

Mike

re: Paging Dr. RAM

geenen — Tue, 05 Dec 2006 16:11:20 GMT

Mike,

Thanks very much for clearing that up. The pnpunload key is very confusing because if I change it in the registry, the changed value stays there, even through a soft reset. So it "looks" like it's being used, but I have not seen any evidence that changing it helps.

Now the bad news... I have still seen a few crashes, even with the "Paging" key set to 0. I'm wondering if I have the correct registry key. Can you tell me if the value I stated (HKEY_LOCAL_MACHINE\System\StorageManager\FATFS\Paging) is correct, or if I need to possibly create a new value elsewhere in the registry?

One other interesting tidbit. In another discussion related to accessing files on a memory card, someone noticed that when a device resumes, if File Explorer is showing the contents of a memory card, it will switch to show main memory. On my system, with the above "Paging" flag set to 0, after a soft reset, this is true. This is also the mode where I can start my app, suspend, then resume and still get a crash sometimes. But, if I resume and it switches to main memory once, and I immediately switch back to the memory card... after that, Windows Explorer will never switch to main memory on resume (until another soft reset.) I just can't quite explain this behavior, and it seems to have some correlation with these lingering crashes. Just thought it might be another clue.

Thanks.

re: Paging Dr. RAM

Sonny Cavazos — Mon, 18 Dec 2006 20:41:31 GMT

Is there any solution to the PNPUnloadDelay problem yet? I have an HTC 6700 phone and I don't believe they will update their WM5 files past AKU2.2. Would this be an end user solution? I would like to know, B/C there are many of us who have the same problem with the WM5 phone.

Also on disabling paging on SD cards would help keep the unit from DSOD by not storing system paging info on the SD unit while it unloads right?

-Sonny Cavazos

Mike Calligro from the Windows Mobile Team blog

Patrick Steele's .NET Blog — Mon, 08 Jan 2007 20:12:06 GMT

After getting my new phone in November, I started searching all over for information about mobile development.

re: Paging Dr. RAM

Ugur Akar — Wed, 10 Jan 2007 10:58:02 GMT

I have JASJAR (XDA exec) I have been trying to solve sdcard unmount problem about two months. Because I am reading PDFs on 4gb SD card. I have a lot of PDF to read. But this unmouinting problem is boring too much.

Nothing worked for me

1- I increased pnpunloaddelay to 8192

2- I inactivated activesync

3- I decreased CPU speed

4- DSK1:=2

5- I red everything on every forums and I did everything.

but still my jasjar sometimes (not every-time) unlooad sd card before wake-up. It is not always. it's unstable.

******Probably we need to find a way to keep cpu off and sdcard on. I beleive sd-card doesn't drain too much battery. but registry dsk1: tweaks doesn't work. *********

Many forums waiting for your end-user pnpunloaddelay change.

I have AGL 4gb. I am planning to buy 150x (faster) SD card. But i am not sure if it solves the problem.

Thank you !

re: Paging Dr. RAM

David Fitzpatrick — Wed, 24 Jan 2007 01:52:08 GMT

I would like to see implemented a "non-removable-SDcard" driver switch for OEMs to use (not changeable by users).

This would allow OEMs to put microSD slots under the battery (to prevent active removal) which can then be used as you would a typical desktop PC hard drive (including pagefiles), the switch would be used by software to know that the card is fixed.

it would also mean that single SD slot devices could access all their software/data whilst using an SDIO add on.

Having no internal card present would make the OS behave as wm5 does

I don't know how you'd fix low battery issues (you lose SD card functionality at low battery) particulary with a data based pagefile on the card (maybe empty and stop using pagefile at battery <=10% switch off sd functions at battery <=5%)

Also keep the multi-partition reading abilities (I use a Jasjar with a 4Gb SD partitioned into 1,1&2 Gbs) http://www.pocketpc-live.com/partition-sd-cards-2.html

Can rom be used as ram ? - Aximsite

Can rom be used as ram ? - Aximsite — Wed, 29 Aug 2007 20:14:20 GMT

PingBack from http://www.aximsite.com/boards/x50-x51-forums/217556-can-rom-used-ram.html#post1059146333

Virtual Memory - Aximsite

Virtual Memory - Aximsite — Wed, 12 Sep 2007 22:11:13 GMT

PingBack from http://www.aximsite.com/boards/x50-x51-forums/218184-virtual-memory.html#post1059150149

RAM, ROM and Task Managers « Hadrys’s Weblog

RAM, ROM and Task Managers « Hadrys’s Weblog — Sat, 29 Mar 2008 12:23:54 GMT

PingBack from http://hadrys.wordpress.com/2008/03/29/ram-rom-and-task-managers/