Database Develop

Wizard ROM Ported to BA - Performance Improvements

I've been working with the Wizard Port which mamaich has done, and have run into the 'normal' performance issues with WM2005 which most everyone has encountered.
Since our devices have so much RAM available, IMHO it should no longer be used for storage. Instead we can utilise huge SD Cards for all storage needs. We need one for the EXTROM installation anyways, and the Batteries will drain the same whether you're using 32Mb or 128Mb of your RAM.
My main focus has therefore been to improving RAM usage for Caching and Filesystem access (StorageManager). I'm trying things out to see if there are any improvements which can be done simply through registry changes. I'd felt I was relatively successful on my Himalaya (using BuzzROM 1.60c) with this style of performance tweak, so now it was time to try it out on the new Blue Angel.
I'm primarily concerned with stability and performance, as well as usability and resources. My focus has therefore been to make extensive use of the RAM Disk for all temporary elements (why make them persistant?), to add appropriate levels of caching and to set an appropriate number of buffers for all memory and filesystem access. My goal is to use the RAM to it's full potential - 32Mb for temp/ramdisk, and as much as beneficial for Cache/Buffers/Paging/etc. leaving the remainder (64Mb+) available for applications to use.
For this I've been scanning the forums and have gleaned the 'pearls of wisdom' from many developers who have been trying to improve the performance of their devices. For everything which I've found, I've researched the origins of the registry modification, and have verified (to the best of available information) that the flags/settings/values or other parameters as I've changed them in the attached registry files below, are legal and valid.
I've geared things to be a 'workhorse' device - i.e. the initial application open/start may be slightly slower (first run), but once the application is up and running, it responds very quickly. The point is then to keep all the commonly used applications running and using the RAM, not to try to have untold Mb of RAM free. All those 'Task OK Button Close' are a real waste when using WM2005 now.
If you do have some memory intensive application, then you may need to close applications, but with 64MB+ free I couldn't think of what you might want to run (except a game or something else 'useful'). The "Memory" Control Panel is all you'd ever need for this.
Ok ... enough rambling about what I've tried to achieve ... on to the details.
Device Configuration I'm using:
- mamaich Wizard ROM v2a (unmodified)
- Model No.: PH20B
- Model Name: iMate PDA2K
- ROM Version: 5.03.02 WWE
- ROM Date: 03/02/05
- Radio Version: Radio 1.15.00
- Protocol Version: 1337.45
- CPU: Intel(R) PXA263
- Speed: 400 Mhz
- RAM Size: 96 Mb
- Flash Size: 32 Mb
- Flash Chip Type: 28F128K3
- Storage Size: 60.30 Mb
Attached below are two principal registry files: Performance.reg, and Customize.reg
Performance is specifically for improving the Performance of the device.
Customize is specifically for setting 'default' customizations, which are user/owner preferences.
These can be imported using your favourite registry editor (I'm using Resco) and you can see what (if any) difference to performance they can make.
Code:
Performance.reg Details:
[HKEY_CURRENT_USER\ControlPanel\Phone]
- Disable Phone Sleep. May help with Bluetooth disconnect issues.
[HKEY_CURRENT_USER\ControlPanel\Sounds\TTSAnnounce]
- Move Voice Command Caller Identification into RAM Disk
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders]
- Move all of IE's Temporary Files into RAM Disk
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings]
- Give IE More Connections
[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main]
- Give IE More Threads
[HKEY_LOCAL_MACHINE\ControlPanel\WiFi]
- Slow down the WiFi Scanning Interval
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\QwertyKey]
- Improve Keyboard Responsiveness
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\WaveDev]
- Improve Audio Responsiveness
[HKEY_LOCAL_MACHINE\Security\Policies\Policies]
- Disable Signing
[HKEY_LOCAL_MACHINE\Software\HTC\XPanel]
- Move Volatile elements to RAM Disk
[HKEY_LOCAL_MACHINE\System\FileSys]
- Move all Temporary Items to RAM Disk
[HKEY_LOCAL_MACHINE\System\GWE]
- Disable Animation
[HKEY_LOCAL_MACHINE\System\GWE\Menu]
- Disable Animation
[HKEY_LOCAL_MACHINE\System\StorageManager\Filters\fsreplxfilt]
- Set the File & Directory Exclusions for the Filesystem Filter
[HKEY_LOCAL_MACHINE\System\StorageManager\...]
- Tweak all the StorageManager settings to improve performance
Code:
Customize.reg Details:
[HKEY_LOCAL_MACHINE\ControlPanel\AdminPassword]
- Enable Admin Password Control Panel
[HKEY_LOCAL_MACHINE\ControlPanel\GPS Settings]
- Move GPS Control Panel to Connections
[HKEY_LOCAL_MACHINE\System\GWE]
- Make THIN scroll bars (get a bit more screen space - I'm accurate with a stylus)
[HKEY_CURRENT_USER\ControlPanel\Backlight]
- Default Backlight Settings
[HKEY_CURRENT_USER\ControlPanel\Comm]
- Default USB Communications
[HKEY_CURRENT_USER\ControlPanel\Notifications\ShellOverrides]
- Set the Volume
[HKEY_CURRENT_USER\ControlPanel\PhoneExtendFunction]
- Set PAP and Class 8 (4 Receive, 1 Transmit) GPRS Settings
[HKEY_CURRENT_USER\ControlPanel\Sip]
- Set SIP Input Word Suggestion Defaults
[HKEY_CURRENT_USER\ControlPanel\SoundCategories\Ring]
- Set the Volume
[HKEY_CURRENT_USER\ControlPanel\SoundCategories\RingPreview]
- Set the Volume
[HKEY_CURRENT_USER\ControlPanel\Volume]
- Set the Volume
[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main]
- Set some IE defaults (Google, History, Zoom, etc.)
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings]
- Set some IE Messages
[HKEY_LOCAL_MACHINE\ControlPanel\Phone]
- Phone Flags
[HKEY_LOCAL_MACHINE\Explorer]
- Show all Files
[HKEY_LOCAL_MACHINE\Software\HTC\Camera\AppDefSettings\P3]
- Disable Recording Time Limit
[HKEY_LOCAL_MACHINE\Software\HTC\Camera\AppDefSettings\P4]
- Enable additional Contacts Photo Mode
[HKEY_LOCAL_MACHINE\Software\Microsoft\Inbox\Svc\SMS]
- Change the SMS Text Message Confirmation
[HKEY_LOCAL_MACHINE\Software\Microsoft\Obex]
- Disable OBEX
[HKEY_LOCAL_MACHINE\Software\Microsoft\Pocket MSN]
- Permit any email address in Pocket MSN
[HKEY_LOCAL_MACHINE\Software\Microsoft\Shell\TaskBar]
- Clock in Taskbar
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Internet Settings]
- ClearType in IE
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\AdvancedCPL]
- Enable Microphone AGC
*** NOTE: I forgot to mention to create the following directories in the RAM Disk in order to properly support things! ***
Cache
Cookies
History
Volatile
Improvements, comments, discussion and changes to these values (or adding more) is HIGHLY encouraged. We'll all benefit from faster machines, without needing to overclock them into instability. And if something is obviously WRONG in these settings, point out the mistake! 8)
Hope this helps others with their performance concerns.
Regards,
Tuatara.
*********************************************************
UPDATE: Version 2 of the Scripts: 5/Feb/2006
Performance:
1). Corrected the WaveDev Priority, and the QwertyKey Priority to values which will produce better performing results across all requirements.
2). Removed requirement for \Ram Disk32\Volatile since the \Volatile directory is NOT automatically created. This can lead to problems if the RAM gets corrupted and or is reformatted. Now all temporary (Volatile) Files have been placed in the root folder "\Ram Disk32\" instead.
NOTE: This means you DO NOT need to create any directories! All cache directories will automatically be created as required by IE on startup!
3). BufferSize has been reduced to a more 'sensible' value of 1024 buffers.
4). Added "EnableDataCacheWarm", "EnableFatCacheWarm", and "PathCacheEntries" to the filesystem specifications.
Customize:
1). Moved Key Deletion to END of registry script, since some registry imports fail to delete these keys properly. Can be done manually.
2). Changed Default Search Page to a more Mobile Friendly GOOGLE search page, which permits better searching of results.
3). Removed the /GWE elements which shrunk down the scroll bars, as I did begin to find it tiring to aim more carefully to scroll things.
4). Removed the OBEX Disable, since this would probably confuse more than help.

Filesys.exe and StorageManager Registry Settings
mamaich said:
Some registry settings regarding StorageManager profiles are read during the first stage of boot process from constant boot.hv file located in XIP section of a ROM, and not from the registry you've changed. For example all drivers that are loaded during "Bootphase" 0 or 1 may ignore all settings that are not present in boot.hv. For example you can change "MountFlags" value to anything, and it would be ignored. I also think that cache size settings for TRUEFFS_DOC and MSFlash are read from boot.hv, because setting the cache size in registry to 16Mb (you cannot allocate more than 32Mb in one chunk) does not decrease the free memory size. The same is for "XIP" and "Flags" settings. The filesystem driver may reread these settings from registry when it becomes available, but I don't think so.
The only filesystem driver that reads your changed settings is SD-Card driver. It is loaded after registry is fully functional.
By the way, it is possible to mount root directory of our device to SD-Card, similar to MPX200.
Click to expand...
Click to collapse
I've had a look into this, and from my understanding the StorageManager mounts the partitions (keeping all the flags, etc.) as from boot.hv, but once the filesystem is up and running, it appears to reload in the filesystem (not partition) registry keys from the user registry, when it mounts the portions of the user registry hive at the end of the process.
Filesys.exe Boot Process
http://msdn.microsoft.com/library/d.../wcemain4/html/cgconFilesysexeBootProcess.asp
Although I could be wrong about this ... it 'appeared' to have made a slight improvement. Very hard to say though if it is reloading the registry information.
A better answer might be to modify the boot.hv and then check the performance.
More on this shortly ...
Regards,
Tuatara

Thread Times and Quantum Theory ...
mamaich said:
Tuatara said:
...
Badly written code ... maybe ... most likely it's poor blocking / thread safety implementations which are causing the issues. Interrupt level and thread level access to the data buffers, taken from legacy 2003/SE code could be at fault here. ...
Click to expand...
Click to collapse
Occasionally I've found this page - http://blogs.msdn.com/sloh/archive/2005/05/27/422605.aspx
It has an interesting code at the bottom. I've already made a program that can hook system calls, I'll try to hook EnterCriticalSection and WaitForMultipleObjects and force them to use that code. Maybe this would reduce the occasional lockdowns.
I've also managed to find the value of default thread quantum on our device. It is 0x4b == 75 milliseconds (WinCE default is 100ms). I.e. we have about 13 task switches per second. Decreasing the value can potentially make our device more responsive, but would add some overhead.
Here is the address to patch in nk.nba (address: old_value new_value):
00207B94: 4B 20
this would set a thread quantum to 0x20 == 32 milliseconds, thread switching would be 31 times per second.
Currently I'm testing this patch, if it is efficient - i'll integrate it into newer ROMs.
Click to expand...
Click to collapse
Modifying the Quantum Times is an excellent thought. I remember when this was done for Win2K by SysInternals (tweaking Server into Workstation & vice-versa). Reducing the quantum (in theory) should improve the performance, unless there are too many 'busy' applications executing. Interrupt service requests, and thread unblocking to service them could really kill the 'Quantum Theory' if they come too 'thick and fast'.
It would mean that USB/GSM data is serviced quickly, but application responsiveness (user perception) actually goes down slightly overall.
BUT !!!! the upside of this would be that the dreaded 'lockup' events won't happen anymore, since data is ALWAYS serviced, and the application has (in effect) a lower priority timeslice in which to execute. You will never have a high-priority thread blocking for extended periods, locking the 'foreground' application while it's busy servicing the data requests.
Let me know your initial testing results - I'd then go ahead and modify my ROM if you feel there is any improvement of note. Similarly, I'd probably try to also go about modifying the boot.hv for StorageManager registry settings and see how far that can get things.
Cheers,
Tuatara

Re: Thread Times and Quantum Theory ...
Tuatara said:
mamaich said:
Tuatara said:
...
Badly written code ... maybe ... most likely it's poor blocking / thread safety implementations which are causing the issues. Interrupt level and thread level access to the data buffers, taken from legacy 2003/SE code could be at fault here. ...
Click to expand...
Click to collapse
Occasionally I've found this page - http://blogs.msdn.com/sloh/archive/2005/05/27/422605.aspx
It has an interesting code at the bottom. I've already made a program that can hook system calls, I'll try to hook EnterCriticalSection and WaitForMultipleObjects and force them to use that code. Maybe this would reduce the occasional lockdowns.
I've also managed to find the value of default thread quantum on our device. It is 0x4b == 75 milliseconds (WinCE default is 100ms). I.e. we have about 13 task switches per second. Decreasing the value can potentially make our device more responsive, but would add some overhead.
Here is the address to patch in nk.nba (address: old_value new_value):
00207B94: 4B 20
this would set a thread quantum to 0x20 == 32 milliseconds, thread switching would be 31 times per second.
Currently I'm testing this patch, if it is efficient - i'll integrate it into newer ROMs.
Click to expand...
Click to collapse
Modifying the Quantum Times is an excellent thought. I remember when this was done for Win2K by SysInternals (tweaking Server into Workstation & vice-versa). Reducing the quantum (in theory) should improve the performance, unless there are too many 'busy' applications executing. Interrupt service requests, and thread unblocking to service them could really kill the 'Quantum Theory' if they come too 'thick and fast'.
It would mean that USB/GSM data is serviced quickly, but application responsiveness (user perception) actually goes down slightly overall.
BUT !!!! the upside of this would be that the dreaded 'lockup' events won't happen anymore, since data is ALWAYS serviced, and the application has (in effect) a lower priority timeslice in which to execute. You will never have a high-priority thread blocking for extended periods, locking the 'foreground' application while it's busy servicing the data requests.
Let me know your initial testing results - I'd then go ahead and modify my ROM if you feel there is any improvement of note. Similarly, I'd probably try to also go about modifying the boot.hv for StorageManager registry settings and see how far that can get things.
Cheers,
Tuatara
Click to expand...
Click to collapse
I've done this modification on nk.nba and reflashed my device and i can't see any difference so far. Will do some more testing later.

"[HKEY_LOCAL_MACHINE\Software\Microsoft\Obex]
- Disable OBEX"
Why?

To which point are these tweaks actually noticeable?
Don't get me wrong, i appreciate greatly all the research done arround this, but last time i applied some reg settings (like cache, etc), that didn't improve wm5 speed to the point to find it usable..
I mean, time required to open tmail.exe, the lag in writing sms, lag before answering a call, wifi multitask use, and program responsiveness in general, can one say that with these tweaks the improvements are significative?
I mean, i've kind of given up on wm5 because of these things (although i've reflashed it many times, hope is last thing to die )

Will running some benchmarking software (before) and (after) the registry tweaking show any improvement?
I'm trying to find some (preferably free) benchtest software for WM5 right now. Will update this thread if I find it.
I'm using Wizard v2a on SX66 with Radio 1.15 myself.

Hmm, actually i can feel a little speed up, not much, but it is faster a bit indeed.

KTamas said:
"[HKEY_LOCAL_MACHINE\Software\Microsoft\Obex]
- Disable OBEX"
Why?
Click to expand...
Click to collapse
Ah - legacy stuff for the defaults I need here. Most of our users don't have Bluetooth Headsets, so by default it is disabled to extend battery life. I should have removed that before posting - but then again, maybe it's useful for someone.

d3vil said:
To which point are these tweaks actually noticeable?
Click to expand...
Click to collapse
As with anything which is NOT modifying the underlying issues, these registry tweaks will only produce SOME improvement in the performance. There is a limit to how much you can cache, buffer, move into RAM, or maintain available.
d3vil said:
Don't get me wrong, i appreciate greatly all the research done arround this, but last time i applied some reg settings (like cache, etc), that didn't improve wm5 speed to the point to find it usable..
Click to expand...
Click to collapse
Part of the reason for this is the abundance of mis-information about the registry tweaks. I've seen posts where for example the Flags settings for StorageManager have been specified in Hex, someone else copied them in decimal, and then these have been imported as hex again - leading to some 'random' FATFS configuration setting which would cause problems. Or other posts where the buffer sizes are set to 64Mb or larger?!!? And you would get no useful benefit from this.
d3vil said:
I mean, time required to open tmail.exe, the lag in writing sms, lag before answering a call, wifi multitask use, and program responsiveness in general, can one say that with these tweaks the improvements are significative?
Click to expand...
Click to collapse
For my expectations and usage, these tweaks do help the performance of applications. This does take into account some assumptions though - such as I do not 'Terminate' the application, but leave them running as intended. All temporary elements are placed onto the RAMDisk. All applications are attempted to be executed from RAM. etc.
d3vil said:
I mean, i've kind of given up on wm5 because of these things (although i've reflashed it many times, hope is last thing to die )
Click to expand...
Click to collapse
It all depends on your expectations. Mine are to have better Word, Excel, Outlook, and Exchange integration, incl. Push Email and ActiveSync support. Can't get that with WM2003, so I'm working with what I can, and making it run as smoothly/quickly/stably as possible.
Cheers,
Robert.

mr_ding said:
Will running some benchmarking software (before) and (after) the registry tweaking show any improvement?
Click to expand...
Click to collapse
Benchmarking software is unfortunately inherently flawed. It can only measure what it is attempting to execute - which in the majority of cases does not reflect real-life usage.
These tweaks aren't necessarily designed to speed up the first execution of an application, but are to keep that application ready and available for the next time it is needed and used.
It would be hard to design a benchmark which could replicate everyday usage. The best answer is ... if you've been using your device for a while, and have noticed a few problems ... try the registry settings and see if the issues are less pronounced, or are eliminated entirely.
mr_ding said:
I'm trying to find some (preferably free) benchtest software for WM5 right now. Will update this thread if I find it.
Click to expand...
Click to collapse
I've applied similar settings to my Himalaya and have had very good performance and results from them. I've barely needed to reset the device (maybe 5 times in as many months) and have adapted my usage, or configured my way around most of the flaws. Time to do the same for the Blue Angel Wizard v2a. (or b)
Anyways ... the next step on my list is to make a EXTROM which auto-configures the devices with all the settings and applications we need for our users. mamaich's cfg.txt makes this so easy to do. 8)
Regards,
Robert.

thank you for the work.
one little question, what do i do with the files?
and there is in the all settings the boot image ?

I'm not sure if it is mamaich's very new hexa editing in ROM or your tweaks but my problems with sound are back Will reflash the original Wizard2BA and do a hardreset i guess.

Tuatara said:
mr_ding said:
Will running some benchmarking software (before) and (after) the registry tweaking show any improvement?
Click to expand...
Click to collapse
Benchmarking software is unfortunately inherently flawed. It can only measure what it is attempting to execute - which in the majority of cases does not reflect real-life usage.
These tweaks aren't necessarily designed to speed up the first execution of an application, but are to keep that application ready and available for the next time it is needed and used.
It would be hard to design a benchmark which could replicate everyday usage. The best answer is ... if you've been using your device for a while, and have noticed a few problems ... try the registry settings and see if the issues are less pronounced, or are eliminated entirely.
mr_ding said:
I'm trying to find some (preferably free) benchtest software for WM5 right now. Will update this thread if I find it.
Click to expand...
Click to collapse
I've applied similar settings to my Himalaya and have had very good performance and results from them. I've barely needed to reset the device (maybe 5 times in as many months) and have adapted my usage, or configured my way around most of the flaws. Time to do the same for the Blue Angel Wizard v2a. (or b)
Anyways ... the next step on my list is to make a EXTROM which auto-configures the devices with all the settings and applications we need for our users. mamaich's cfg.txt makes this so easy to do. 8)
Regards,
Robert.
Click to expand...
Click to collapse
I guess you don't use the (SPB Plus) feature when pressing (x) button, it automatically closes the application, right?
I will try your tweak tonight/tomorrow and uninstall/disable SPBPlus feature on auto-closing application myself.
Typically I run Mapopolis (sometimes with BT GPS), phone, sudoku, and tcpmp (watch divx movies). Will it really be okay with all these applications running in the background without closing them?

KTamas said:
I'm not sure if it is mamaich's very new hexa editing in ROM or your tweaks but my problems with sound are back Will reflash the original Wizard2BA and do a hardreset i guess.
Click to expand...
Click to collapse
Interesting ... it could well be either at fault. The only change I've made for the Sound was to set the Audio Priority to a sensible value. You could readily change the value of Priority256 for the sound and see if that makes a difference.
Alternatively, with the quantum time for a thread being lowered, it is possible that there is not enough time for audio decoding to be performed per quantum, which will lead to stuttering as there are other waiting tasks to be serviced.
For the audio, you could try two things:
1). Change the value of Priority256 for HKEY_LOCAL_MACHINE\\Drivers\\BuiltIn\\WaveDev (lower = higher priority = serviced more often)
2). Change the quantum time to something larger (more audio processing per thread switch)
Try patching nk.nba (address: old_value new_value):
00207B94: 4B 64
This would set the thread quantum to 100 milliseconds (MS Recommended = 10 times per second)
You could even be so radical as to try 120 milliseconds (= 78, which would give you 8 1/3 switches per second)
You may find that the audio more responsive with larger processing time blocks, and higher priority. Again, it really depends on what your requirements are.
NOTE: A Hard Reset isn't required for these changes. This is only changing how things execute, not where things are executing from. There should be no need to hard reset & format.
Regards,
Tuatara.

Tuatara said:
KTamas said:
I'm not sure if it is mamaich's very new hexa editing in ROM or your tweaks but my problems with sound are back Will reflash the original Wizard2BA and do a hardreset i guess.
Click to expand...
Click to collapse
Interesting ... it could well be either at fault. The only change I've made for the Sound was to set the Audio Priority to a sensible value. You could readily change the value of Priority256 for the sound and see if that makes a difference.
...
Click to expand...
Click to collapse
I don't have sound issues. But I have Priority256 set to 0x80 (128). Tested on PocketPlayer, sound of incoming call, Toppler game (without Priority256=0x80 it had clicking sounds).
I recommend using 0x80, it is a well-tested value since GB-tweak for WM2003. In this case wavedev driver would not steal time from system services, and priority is high enough to eliminate sound pauses.
I'm still testing my patch, and had no occasional slowdowns yet. The device is responsive even when you are running CPU benchmarks. Previously it lost Activesync connection, ignored touchscreen taps, etc.

Re: Filesys.exe and StorageManager Registry Settings
Tuatara said:
I've had a look into this, and from my understanding the StorageManager mounts the partitions (keeping all the flags, etc.) as from boot.hv, but once the filesystem is up and running, it appears to reload in the filesystem (not partition) registry keys from the user registry, when it mounts the portions of the user registry hive at the end of the process.
Filesys.exe Boot Process
http://msdn.microsoft.com/library/d.../wcemain4/html/cgconFilesysexeBootProcess.asp
Click to expand...
Click to collapse
It is easy to find whether driver rereads registry or not. Just search for "SYSTEM/BOOTPHASE2" unicode string inside it. None of the drivers wait for this event, so we can assume none of them rereads registry. Only filesys.exe, devmgr.dll and pm.dll use this event.
I don't know when filesystem filters are loaded, but they may be loaded at the bootphase 2, so fsreplxfilt.dll can use your new settings. But this should be checked.
You can also try to set invalid values to some settings, so that device would have great slowdown or would not boot at all. Or you can set cache size to something near 32Mb, and check the size of used memory. If it would be decreased, or device would react on your settings (i.e. would not boot) - the driver rereads the registry.

mamaich said:
Tuatara said:
KTamas said:
I'm not sure if it is mamaich's very new hexa editing in ROM or your tweaks but my problems with sound are back Will reflash the original Wizard2BA and do a hardreset i guess.
Click to expand...
Click to collapse
Interesting ... it could well be either at fault. The only change I've made for the Sound was to set the Audio Priority to a sensible value. You could readily change the value of Priority256 for the sound and see if that makes a difference.
...
Click to expand...
Click to collapse
I don't have sound issues. But I have Priority256 set to 0x80 (128). Tested on PocketPlayer, sound of incoming call, Toppler game (without Priority256=0x80 it had clicking sounds).
I recommend using 0x80, it is a well-tested value since GB-tweak for WM2003. In this case wavedev driver would not steal time from system services, and priority is high enough to eliminate sound pauses.
Click to expand...
Click to collapse
I initially had the setting as 128 (0x80) as well, but had some occasional issues with Voice Command & pauses/delays. I increased the priority and the issue appeared to be resolved. However this is assuming short audio playback streams, not continuous ones, and I had changed things further since that issue arose. Time to retest.
Probably setting the value back to 0x80 in the registry is the best option as mamaich recommends. It would be a general solution for everyone. Similarly, I've found the keyboard better with the tweak, but this too could be reduced in priority - possibly 0xA0 (160) would be a more 'adequate' value to utilise.
Code:
Recommend to Change: Performance.reg to contain:
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\QwertyKey]
"Priority256"=dword:000000A0
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\WaveDev]
"Priority256"=dword:00000080
mamaich said:
I'm still testing my patch, and had no occasional slowdowns yet. The device is responsive even when you are running CPU benchmarks. Previously it lost Activesync connection, ignored touchscreen taps, etc.
Click to expand...
Click to collapse
Sounds good ... possibly the Priority256 setting for the WaveDevice was too high - especially with the smaller quantum value, leading to stuttering (somehow). Hopefully KTamas has some time to see which direction solves the problem in the audio.

Re: Filesys.exe and StorageManager Registry Settings
mamaich said:
Tuatara said:
I've had a look into this, and from my understanding the StorageManager mounts the partitions (keeping all the flags, etc.) as from boot.hv, but once the filesystem is up and running, it appears to reload in the filesystem (not partition) registry keys from the user registry, when it mounts the portions of the user registry hive at the end of the process.
Filesys.exe Boot Process
http://msdn.microsoft.com/library/d.../wcemain4/html/cgconFilesysexeBootProcess.asp
Click to expand...
Click to collapse
It is easy to find whether driver rereads registry or not. Just search for "SYSTEM/BOOTPHASE2" unicode string inside it. None of the drivers wait for this event, so we can assume none of them rereads registry. Only filesys.exe, devmgr.dll and pm.dll use this event.
I don't know when filesystem filters are loaded, but they may be loaded at the bootphase 2, so fsreplxfilt.dll can use your new settings. But this should be checked.
Click to expand...
Click to collapse
Haven't had the chance yet to decompose the ROM Image, but will get to that shortly - shame that MS doesn't make the process description clearer. I will try updating the boot.hv with changed settings and see what results that can bring.
mamaich said:
You can also try to set invalid values to some settings, so that device would have great slowdown or would not boot at all. Or you can set cache size to something near 32Mb, and check the size of used memory. If it would be decreased, or device would react on your settings (i.e. would not boot) - the driver rereads the registry.
Click to expand...
Click to collapse
From what I could tell in my experimenting, outlandish (or illegal) settings are limited by the driver itself. i.e. trying to set a CacheSize of 64Mb is met with an upper limit to the CacheSize of 2Mb anyways - regardless of the registry value. This is (partially) why some ridiculous values published by others still work, and additionally why increasing those values doesn't bring any further gains.
Each tweak I've done for StorageManager has increased the memory usage requirements, so I (strangely) still think that there is some mystical reloading of the registry information happening. Maybe it is solely the filters which affect this - maybe it is the loading of the filters which resets only the cache/buffer sizes (to limits), since the filesystems are already mounted.
Regardless, I will try the boot.hv, and the Quantum Time Change sometime soon.

jimp said:
This might be irrelevant, but I had most versions of wm5 on my BA (except the himalaya port). I'm having some issues with MS VoiceCommand.
The (leaked) original (slow) version worked ok.. The wizard port worked even better so did v2.. when i put v2a however (with 32M ramdrive), voice command started acting strange.
The whole device seems abit odd.. when i remove the device off its cradle its just SO SLOW.. as if its searching to sync.. anyway back to VC.
Its very wierd.. ie.. i say Call Harry .. and it matches NAT .. HOW ON EARTH!? Or I say.. call nicole.. and it matches TAXI! . This was NOT an issue with previous wm5 roms. I dont run any other software on the device so I dont know what's causing this. Could it be the ramdrive?
Note.. VC rarely gets the match right anymore.. where as before it RARELY got it wrong.
Click to expand...
Click to collapse
I'm still testing with VoiceCommand, and have had to change a few things to get suitable performance. I haven't as yet made the Quantum Timing change, but I'll evaluate that and see how it goes.
Anyways, you might wish to try the following CAB file. I can't remember who created it but I've been using it along with the RAM Disk for the CallerID Wave File Generation, and Voice Command has been working well. It makes a few registry entries, and I believe replaces some configuration elements - haven't disassembled it as yet.
jimp said:
Note2.. MP3 playback skipping like mad.. (just noticed) (and only on certain mp3s.. not all STRANGE).
Click to expand...
Click to collapse
Additionally, it would be recommended to keep the WaveDev Priority at 128, since KTamas has reported stuttering when it was set at 96 (as in the registry script in the first post)
(Time! I just need more time!!! )
Code:
[HKEY_CURRENT_USER\ControlPanel\SoundCategories\VoiceCommand1]
"AttenuationCategory"=dword:00000001
"InitVol"=dword:00000005
"Script"="p"
[HKEY_CURRENT_USER\ControlPanel\Sounds\TTSAnnounce]
"Sound"="\\RAM Disk32\\Volatile\\TTSCallerID.wav"
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\WaveDev]
"Priority256"=dword:00000080

Tuma 1.3 FATFS Cache Reg Tweak

I've recently been reading up on and testing different values for the following registry key :-
HKLM\System\StorageManager\FATFS\CacheSize
By default in Tuma 1.3 this key is set to 4096, which agrees nicely with the maximum value in the following MS document on FATFS registry keys.
http://msdn.microsoft.com/library/d...tml/wce50confatfilesystemregistrysettings.asp
Having read this I decided to try some higher power-of-2 values to see if 4096 really was a hard limit on cachesize. To my surprise, setting a value of 32768 does work, and shows an increase in memory use after boot. (~37mb with 32768 cachesize, versus ~23mb with 4096 cachesize)
NOTE The next highest power-of-2 (65536) caused corruption of the today screen, so that should obviously be avoided.
Does anyone know if the extra space is likely to be actually used as cache? Or does this just allocate memory that is never used?
My Qtek 9090 does seem to respond faster, once the cache is loaded with recent apps, but I also know it's easy to delude youself that such "tweaks" are having a real effect.
Could someone else confirm this for me?
Obvious disclaimer - don't edit your registry if you're worried about turning your phone into a useless hunk of plastic.

thingonaspring said:
I've recently been reading up on and testing different values for the following registry key :-
HKLM\System\StorageManager\FATFS\CacheSize
By default in Tuma 1.3 this key is set to 4096, which agrees nicely ...
Click to expand...
Click to collapse
Yes, this is delibrately done to not 'push the device into undocumented territory.
Does anyone know if the extra space is likely to be actually used as cache? Or does this just allocate memory that is never used?
Click to expand...
Click to collapse
The extra space is allocated, and it would be used - albeit rather slowly:
4096 = 2Mb, 8192 = 4Mb, 16384 = 8Mb, 32768 = 16Mb cache size. Applications (and data) need to fill this space to make it useful. Also, it's proven by your memory change from 23Mb to 37Mb = 14Mb ... exactly the difference between 16Mb and 2Mb (by coincidence? ;-))
Using more than 2Mb of cache space will in the short term possibly make your device run faster, however when the compaction thread needs to run (and stuff needs to get written back to flash), it will attempt to buffer as much as possible, and then take it's time while it 'locks up your device' and flushes 16Mb (possible) of data ... instead of 2Mb. Multiple smaller blocks will have less impact on the usability of the device - so there's been a careful balance done between performance and continuous usability. Sure you could make it faster in the short term ... but long term you'll hit those 10 second pauses.
In testing I've found 2Mb to be a good upper limit. Try 4Mb if you've got a lot of data intensive applications, but otherwise I can't see too much benefit in going larger. Also - the chance of losing something is greater ... a reset while things haven't been written to flash, and *poof* it's gone.

Excellent info Tuatara, that explains a lot about why my device was running in stops-and-starts ;-)

This is very interesting. I own a hx4700 device and rescently upgraded it to wm 5.0 (the nightmare begun). The information I found here is totaly oposite of what some wise heads are suggesting on other forums.. and this works. Lowering the cache (setting DataCacheSize to 0x100) made my device more responsitive when compaction runs (20 minutes every few hours!)
I have few questions about the compaction thread - Is the compaction process always taking constant time (depending on the size of the files on the device)?
Compaction always takes long time to finish - about 20-25 minutes on a 35megs free flash. Is this normal ? Block size of the flash reported by some hp utility is 128kb, in registry (and bootloader after lnb) shows 256kb. Could someone explain the exact logic of the compaction thread ?
I have another question - the msdn mentions that CacheSize is deprecated and should the folowing keys be used: FatCacheSize and DataCacheSize. Why are you still using the old reg key ?
If the compaction problem is solved in the hx4700 (and probably on the dell x50v) the device will be worth it's money.
Thank you for the great forums and the great community.

Performance ... what matters? The 'NOW', or the 'ALWAYS'?
orcish said:
This is very interesting. I own a hx4700 device and rescently upgraded it to wm 5.0 (the nightmare begun). The information I found here is totaly oposite of what some wise heads are suggesting on other forums.. and this works. Lowering the cache (setting DataCacheSize to 0x100) made my device more responsitive when compaction runs (20 minutes every few hours!)
Click to expand...
Click to collapse
It's a trade-off really. The total time required for the compaction is still going to be the same. For example, using up blocks of the flash memory is going to 'fragment' the space. When you need that space, the issue is: 'is it ALREADY available'?
By running the thread more often (to clear unused blocks back to being available), your device 'continuous over time' performance increases, but by doing the compaction 'all at once' your device's 'instantaenous performance' is higher.
Rant on.
Benchmarks love the latter ... users (should) love the former.
This is why in the new TuMa v1.4 ROM I'm working on, I've gone AGAINST all of the other 'benchmarks' and dumb short-term tweaks and so-called solutions, and looked at device performance overall, and over a long period of time. Performance is now 'managed' rather than 'peaked', so that things are kept at a good rate of continuous usage, rather than trying to maximize an instantaneous time. Benchmarks really should measure the device in two weeks of use ... not right after it's configured.
What good is a fast device right now, if in one weeks it's slow as mud all the time? Yes, the TuMa v1.3 is slowing down - but the degree of slowdown of that ROM isn't to the point of 'unusable' as is the case with some other WM5 versions (for very well known reasons now). Knowledge is always gained, and improvements are always made with enough time and patience.
This is the other point I raised for people trying out the "new ROMs" ... (which in truth haven't addressed ANY performance concerns when you look at the changes done). These "latest and greatest", "just released", "new and improved", and "better and faster than ever" - ROM release adopter junkies are just experiencing "new device syndrome". Of course it'll be faster - DUH - you've just given it a clean slate to start from! Your multi-week old device has just been cleaned of it's junk, and it WILL be so much faster with the new ROM. REGARDLESS. Shyeah ... think about it.
Sorry ... rant off.
I have few questions about the compaction thread - Is the compaction process always taking constant time (depending on the size of the files on the device)?
Click to expand...
Click to collapse
The time it takes is effectively a constant. It must erase the blocks of Flash, and organize the filesystem based on this. Erasing is slow ... which is why when it 'piles up' and there's a lot of work to do, the compaction thread really can't finish and return control to the device, until it's done the job. It's akin to stopping a defragment of your hard drive ... sure, some of it is clean & organized, but the remainder is still a disaster. Update that drive in the meantime, and it needs to start all over again.
Compaction always takes long time to finish - about 20-25 minutes on a 35megs free flash. Is this normal ? Block size of the flash reported by some hp utility is 128kb, in registry (and bootloader after lnb) shows 256kb. Could someone explain the exact logic of the compaction thread?
Click to expand...
Click to collapse
A lot of questions ...
1). 20-25 minutes is FAR too slow. There is definately something else taking up 'residence' or CPU time during this process. It sounds like you have an application installed, or a device driver, or you've twiddled priorities improperly, incorrectly using temporary storage, resulting in over-use of your flash. A hard-reset and careful re-installation of your applications MAY be warranted to fix this. *more below*
2). Block size is quite probably 256Kb. I think your device also uses the M-Systems DOC 64MB chips.
The DOC G3 64MB (512Mb) consists of two 32MB (256Mb) flash planes that consist of 1024 blocks each, organized in 64 pages, as follows:
Page (Storage Unit) – Each page contains 512 bytes of user data and a 16-byte extra area that is used to store flash management and EDC/ECC signature data. This is the SIZE of block which changes EACH TIME something gets saved to memory on your device.
Block (Erase Unit) – Each block contains 64 pages (total of 256Kb). A block is the minimal unit that can be erased, and is sometimes referred to as an erase block. This is the SIZE of block which must BE ERASED each time we need some more space on the device.
Note: Since the device works with multiple planes, the operational block size is actually 512Kb. This means each time 64KB of space needs to be erased, when a block can bee freed.
3). And now the hard question ...
The compaction thread is effectively attempting to move the random fragmented blocks of 512 bytes of data in each of the Storage Units around into larger blocks of 32KB (256Kb) Erase Units. Otherwise, you'd have parts of your data erased each time you needed more free space in the Flash to use. 8)
Essentially this comes down to a "defragmentation" algorithm, however the problem is that the device is still actively being used at the same time. To solve this obvious problem - the device NEEDS to be paused, the compaction run to completion, blocks are freed up for usage, and then the job can continue. It's quite obvious when you think about it.
For example ... 64 Erase Units, each has 1 Storage Unit usefully allocated in it. The compaction thread now can in theory take each of those 64 Storage Units and put them into one larger 'Erase Unit' Block space. To do this is needs to read ALL 64 units (32KB) into memory, maintain all the blocks UNFREED (since if you reset your device now you'd lose your data). Erase a new UNUSED Erase Unit, write all 64 Block Units into the new Erase unit. Then it can go through and mark in the FileSystem, where the NEW location of these Storage Units is. Once that's done, it can mark those other 64 Storage Units as being available for Erasure (or for reuse of any remaining Storage Units within it). If it detects that they are full, then those 64 Erase Units can be erased, and it goes ahead and does that. Natually all this 'shuffling' of data, with guarantees that you don't lose any in the process, needs to be done CAREFULLY and PROPERLY.
*RANT* ... For (insert deity of choice here) sake ... NEVER EVER HIT THE RESET PIN WHILE YOUR DEVICE IS BUSY COMPACTING!!! You can (and probably will!) lose your data ... have patience ... just wait ... it really is busy doing something VERY important. But otherwise, go ahead ... RESET away ... you'll probably be cursing that you're continually doing HARD-RESETs all the time, and that it's a sh*tty device you've bought. Well ... after all ... you NOW KNOW ... it really IS your OWN fault. :roll:
The issue comes when there is something which CAN'T be paused (a device driver, OS core, etc.). This will still need flash storage space while the compaction thread runs. This is possibly why your compaction takes 20 minutes or more. Remove the 'extra stuff' which could be doing bad things.
Also, there are those (I shouldn't use the word, but anyways) idiotic people who think that by forcing this to the "now" that they're making their devices better. For example - inapprorpiate use of Priority256 registry keys, in raising the priority of a task (to above real-time even!) in order to solve their immediate issue - they believe is a good thing!!??!!
This results in the compaction thread needing to 'back off', then the OS runs the 'real time task' which corrupts the defragmentation process, so when the compaction thread has an 'idle' chance again, it starts up ... starts cleaning ... tries ... gets interrupted ... (cycle repeats).
I'm trying to 'do away' entirely with this issue in TuMa v1.4 by forcing the compaction thread to run more often, at times when it can do so, just below application level requirements, but above idle. So barring any 'fixes' introduced by l-users ... it should maintain an even performance level over time - barring obvious issues, like when the Flash is too full for compaction to run!
In this way, through usage testing by knowledgable users, I have validated 'theory' in Alpha versions, and will now/shortly be moving into 'practice' in Beta testing with a lot more 'general' users becoming my 'unwitting' performance testers in releasing the TuMa v1.4 ROM. I believe theory will be put into practice, and as experienced by the alpha testers, performance should be continuous and stable. 8).
I have another question - the msdn mentions that CacheSize is deprecated and should the folowing keys be used: FatCacheSize and DataCacheSize. Why are you still using the old reg key ?
Click to expand...
Click to collapse
CacheSize is deprecated, and in TuMa v1.4 ALL keys are explicitly specifed, while in TuMa v1.3 FatCacheSize was not. The reason is two-fold. For the BA ROM (since it's unofficial and a patchwork of other ROMs), these ROMs were still using older drivers (WM2003SE) which did not support the new keys.
The explicit 'new' keys override the deprecated key. However, the old key is still kept in there for legacy reasons, or for applications or users who might 'insist' on twiddling them in the future. I'm now resorting to this, and trying to 'protect' people from their own performance tweaking "foibles".
If the compaction problem is solved in the hx4700 (and probably on the dell x50v) the device will be worth it's money.
Click to expand...
Click to collapse
If people are willing to put up with a slightly slower 'overall' device, but have continuous same-level performance ... then I can give them an answer (hopefully) right now, or soon if I ever get this TuMa BA ROM to a point I'm happy with it (probably AKU2).
If they want to be blind adrenaline junkies and need 'speed at any cost' ... just keep doing what they're doing, tweak caches, put off until later all the housekeeping, and then, when it hits the wall, go ahead and try to do it all in 20 minutes of device lockup when it's become all too much to handle.
If they want 'rocket-ship' speeds at all times, they'd better carry around a non-flash based device or a laptop. But they'll look REALLY dumb holding up one of those things to their ear when making a phone call. 8)
[flame retardant suit is on]
Thank you for the great forums and the great community.
Click to expand...
Click to collapse
Thanks for such a great set of questions ... let's me get the point out as well.
Now ... I wonder who else will actually read this post? Maybe it'll be Wiki'd? Maybe ... maybe it's better if not.

Whao! A reply beyond my expectations! Thank you!
Here is my questions:
Update that drive in the meantime, and it needs to start all over again.
Click to expand...
Click to collapse
Is this about the compaction thread or the disk defragmentation process? If it's about the compaction thread - probaly seting the Prio256 and PrioCrit256 to real time would make it almost interruptable (and make the device freeze for some time). If running time with critical priority takes effectivly less than my usual 20 minutes, it means that something is messing my compaction, right ?
1). 20-25 minutes is FAR too slow. There is definately something else taking up 'residence' or CPU time during this process. It sounds like you have an application installed, or a device driver, or you've twiddled priorities improperly, incorrectly using temporary storage, resulting in over-use of your flash. A hard-reset and careful re-installation of your applications MAY be warranted to fix this. *more below*
Click to expand...
Click to collapse
I'm not fiddling with the priorities, and have no running applications (except acbPowerMeter or/and SuperTask to monitor the activity). When compaction hits I just close everything and watch it complete. When acbPowerMeter reports about 380mA usage - it's the Compaction. filesys takes about 90% cpu (10% taken by the SuperTask when it refreshes the screen with new readings). Activesync is stopped, disabled and etc.
Is it possible to monitor disk .. err.. flash activity ? All read/write calls? Probably a filesystem filter? (about filesystem filters I have a question below)
Is it possible to take some information about the compaction process itself, % done, blocks freed and etc. I suspect that there is something wrong - probably trying to compact a bad block or something like this. I have seen people complaining about this in the platformbuilder newsgroup.
Something that may be conneted to this issue is the filesystem filters I found attached to my storage devices. I have fsdspy and fsreplxflt. What are they? Some information points that fsreplxflt is for replicating ram to rom and fsdspy as an example!? Are they needed actualy?
Thank you for your reply, I have more questions and when I clear them in my head, I'll be more than happy to ask them to you.

Hi Tuatara,
Great explanation - clears up a few questions I had.
One question, however, remains. What's the easiest way to tell your device is compacting and hasn't just hung? I've had a few times when my device seemed to just hang solid - nothing worked, no buttons, no touchscreen, nothing. So I soft reset the device to bring it back up with no data loss. I assume this was a crash not a compaction.
Is there any way in TuMa 1.4 that you could make a "Compacting" icon or similar so that we can tell when compaction is being undertaken?

orcish said:
Whao! A reply beyond my expectations! Thank you!
Click to expand...
Click to collapse
Well I aim to please ... or was that ... I'm pleased to aim ... *fire* ... eh ... whatever. ;-)
orcish said:
Update that drive in the meantime, and it needs to start all over again.
Click to expand...
Click to collapse
Is this about the compaction thread or the disk defragmentation process?
Click to expand...
Click to collapse
In the simplest terms for our devices it's both. Disk defragmentation is just the example everyone understands ... so I'm using this 'understanding' to explain it.
A flash disk doesn't need ANY defragmentation - it's indexed like RAM, and we can get at any data directly. No need to make any data contiguous like on a hard disk (which spins). So, that's why they use the word "compaction" instead of "defragmentation" ... but the principle is the same.
So ... putting it simply:
It really doesn't matter where it's stored to ACCESS it. But it does matter where it's stored if we need to ERASE it.
Remember we have 64 Storage Units per Erase Unit. This means that if we are actively using even one of those Storage Units, but need to erase the rest of the block to get more "free" space, we need to move the used Storage Unit somewhere else first, before we can erase that block, to use it again.
If you have an application writing to storage during this time ... well ... then the 'free' Storage Units in those nice-new-empty Erase Units can be used up, and the compaction thread has to start over again - trying to pack things in to make more available free space.
orcish said:
If it's about the compaction thread - probaly seting the Prio256 and PrioCrit256 to real time would make it almost interruptable (and make the device freeze for some time). If running time with critical priority takes effectivly less than my usual 20 minutes, it means that something is messing my compaction, right ?
Click to expand...
Click to collapse
Yes ... that would be true - although I have no idea what running the compaction thread at time critical would do to your device!!! I would probably set it to a NORMAL (0xfb / 251) priority ... maybe something at most "THREAD_PRIORITY_ABOVE_NORMAL" (or 0xfa / 250) at a highest value. It may be worthwhile to experiment and see what the result is. Backup your device before doing this though!
orcish said:
I'm not fiddling with the priorities, and have no running applications (except acbPowerMeter or/and SuperTask to monitor the activity). When compaction hits I just close everything and watch it complete. When acbPowerMeter reports about 380mA usage - it's the Compaction. filesys takes about 90% cpu (10% taken by the SuperTask when it refreshes the screen with new readings). Activesync is stopped, disabled and etc.
Click to expand...
Click to collapse
I can't answer this one unfortunately ... there are so many intricate details in the OS which could have an effect. Experiment with the priority settings if you wish to ... might be an option to see what the real cause is. If the compaction happens quicker, then we know it's due to flash usage collisions.
Thinking about it - change only the CritPrio256 values ... i.e. when the "s*it really has hit the fan" do it or else ... and see if it completes in less time. If you don't hit critical compaction - then try setting the standard priority as well.
orcish said:
Is it possible to monitor disk .. err.. flash activity ? All read/write calls? Probably a filesystem filter? (about filesystem filters I have a question below)
Click to expand...
Click to collapse
It would be possible - I think that mamaich may have written such a tool for himself, but it is just that - a tool, and not something which could (or should) be actively utilised.
orcish said:
Is it possible to take some information about the compaction process itself, % done, blocks freed and etc. I suspect that there is something wrong - probably trying to compact a bad block or something like this. I have seen people complaining about this in the platformbuilder newsgroup.
Click to expand...
Click to collapse
I'm not sure if this is possible ... part of the problem is - where would you put the result data? It would need to be a memory mapped file or something, which is locked exclusively in RAM, so as to not touch the flash, and then your reporting app would need to operate in a similar manner. Not sure ... maybe there is a way to get some info (from the TrueFFS driver) but I wouldn't know how to.
Along the "bad block" concept - the TrueFFS driver has management within itself to control bad blocks and to transparently reassign blocks which have been deemed 'bad'. It is possible that this logic is somehow failing - i.e. not working as advertised.
You could try changing the Read/Write and Verify methodology which the TrueFFS driver uses. Here are some registry entries which might help you track down the problem. You should have registry entries similar to:
Code:
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\TrueFFS???]
“VerifyWrite”: When using this parameter, TrueFFS performs an immediate read operation
from the flash after every write cycle.
The value of this entry can be as follows:
dword:0 - Sets TrueFFS to Optimized Verify Write mode. This is the default TrueFFS mode for
devices supported by INFTL, such as DiskOnChip Millennium Plus and Mobile DiskOnChip. In
this mode, a sector is assumed to remain valid after it has been verified as long as no sudden
power-down event occurs; therefore, no additional read operations (verifications) are performed.
When recovering from a power failure, TrueFFS gradually verifies the validity of additional
sectors as data is written to the disk partition. All the sectors on the disk are eventually verified,
at which point no further verification is done and peak performance is achieved (default).
dword:1 - Sets TrueFFS to Read Before and After Write mode. In this mode, each write
operation is preceded by a read operation verifying the flash area is indeed erased, and followed
by a read operation verifying the data was written properly. Only after both conditions are met is
the sector considered to be written properly. Selecting this option results in lower write
performance, but insures absolute data protection against power failures or any other event (such
as errors caused from noisy buses, faulty flash, or flash close to its end of life).
dword:2 - Sets TrueFFS to Standard mode. In this mode, a sector is considered written
successfully when the flash media reports that the write operation ended successfully. Additional
verification (using a read operation) is not performed, so TrueFFS works at peak performance
regardless of past power failure events. This is the default mode for devices supported by NFTL,
as these devices do not require additional verification for most applications.
“UseCache”: Enabling this option improves performance, but requires additional RAM
resources. The NAND Flash Translation Layer (NFTL, INFTL or SAFTL) uses a small part of
each flash unit and sector for control information that allows accessing the data stored on
DiskOnChip as a virtual block device. Setting this option to 1 enables caching this information in
order to improve performance.
dword:0
dword:1 (default)
“RemoveFatFilter”: The Windows CE TrueFFS driver contains a FAT filter that monitors file
system write operations to the FAT area. The TrueFFS driver uses this information to improve
performance by deleting sectors from the media when the corresponding file is deleted. Use this
entry to disable FAT filter operation.
dword:1
So I'd try “VerifyWrite” = 1, “UseCache” = 0, and leave the FatFilter enabled ... see if this helps 'eliminate' that possible bad block issue.
orcish said:
Something that may be conneted to this issue is the filesystem filters I found attached to my storage devices. I have fsdspy and fsreplxflt. What are they? Some information points that fsreplxflt is for replicating ram to rom and fsdspy as an example!? Are they needed actualy?
Click to expand...
Click to collapse
The fsdspy filter is used to monitor the filesystem - incl OS level and TrueFFS driver performance checking (and for hooking). For the fsreplxfilt filter I believe this is required for data replication ... but the inner details of what it does, I'm not sure either. You do need to specify WHICH directories and files are NOT included - so therefore I believe it to control which files should NOT be replicated to the Flash as soon as possible (i.e. they are maintained in RAM cache, and only flushed at a later date, or by a special seperate thread - things like the registry files, temp files, object store, etc.).
orcish said:
Thank you for your reply, I have more questions and when I clear them in my head, I'll be more than happy to ask them to you.
Click to expand...
Click to collapse
Heh ... I'll just need to find more time to answer then!

HiltonT said:
Great explanation - clears up a few questions I had.
Click to expand...
Click to collapse
You're welcome ... it's always better when things are 'demystified'.
HiltonT said:
One question, however, remains. What's the easiest way to tell your device is compacting and hasn't just hung? I've had a few times when my device seemed to just hang solid - nothing worked, no buttons, no touchscreen, nothing. So I soft reset the device to bring it back up with no data loss. I assume this was a crash not a compaction.
Click to expand...
Click to collapse
Compaction runs at a lower priority than other tasks, so if you have NO response from it for 10 - 20 seconds ... especially wait longer after having been IDLE for a while ... then it has definately crashed. Just give it enough time to see if it will recover though ... large block erases can take time - especially when the filesystem is in a 'transitional' state.
HiltonT said:
Is there any way in TuMa 1.4 that you could make a "Compacting" icon or similar so that we can tell when compaction is being undertaken?
Click to expand...
Click to collapse
We could have a 'task manager' which monitors the process list and then puts up a 'red light' when the CPU is being used for this task ... it may be a worthwhile project for someone to undertake. Unfortunately I don't know of anything like this at present ...

Tuatara said:
orcish said:
Talking about Compaction, Priority, and setting registry entries ...
Click to expand...
Click to collapse
And I made some recommendations to try ...
Click to expand...
Click to collapse
I was just re-reading things from Mike (http://blogs.msdn.com/windowsmobile/archive/2006/03/16/552996.aspx) and realized that no matter what you do to those Priority registry keys, they will have no effect. *sigh*
I'm changing those keys in the boot.hv (XIP section) in TuMa ROMs, so I do have the ability to change those priorities directly, but this is not an end-user Registry thing.
If I get the time, I may look into the 4700 ROMs and see if there is anything which can be corrected/adjusted for these - either that, or someone who can modify these ROMs is welcome to PM me, and I can send them the full registry dump (boot.rgu) and they can attempt to merge in the settings themselves and see how that goes.
Again ... apologies, but it appears MSoft has decided that you're not permitted to mess with these settings. The TrueFFS registry settings may follow the same rule, but then again - I'm not entirely certain of this.

Is your Kaiser gruesomely slow?

If it is, then other than the missing drivers, then the chances are that either a subset of Kaisers, or roms, or third party apps are causing some devices to be a LOT slower than others.
There are people claiming that their devices take three seconds to change orientation. They also claim that you can actually see the icons being "drawn" on the screen.
As a happy Kaiser owner, I have never experienced anything like that (except when syncing over USB - when the device pretty much stops responding for the first few seconds of syncing and then returns to normal.
Changing to landscape on mine take approx 0.3 seconds (I say approx as its too quick to actually time).
Now I made a horrible error. I tried to point out to the defensive people over on the classaction thread that if their device was really that bad, they could try a different rom and see if that makes their device better. I didnt argue that "the" drivers weren;t missing or that their devices would be fine without them. All I did was try to get some research to see if there was an obvious group of devices or roms or apps that was causing the problem.
If like me, you prefer to sort these things out - rather than wait for a year for a class action - then try the benchmarking test in my sig and post your results and rom details. Hopefully, we can find the cause of the major differences in performance.
My device scored 1643 overall.

He's right, people should start blaming the device for everything. Bring back the days when you'd clean up your device when you'd feel it being slow.
Mine is in 1680 or so as well.

Unwired 4,
Can you perhaps provide a detailed list of all the applications you have on your phone?
I ask you this because I don't have alot of apps on my phone; mainly Googlemaps, livesearch, TCPMP, Dutty 1 calc, HTC Album, Opera mini and Palringo.
I don't have any SPB products clogging up my today screen with its numerous shortcuts. I haven't tweaked my clock appearance and I'm using the original windows blue background on my today screen.
My phone looks pretty similar to when it was bought yet I have noticed a lag, even when it comes to changing the screen orientation from portrait to landscape. It takes roughly one second. Sometimes opening an application takes forever, and closing it down to.
I had an issue with video playback, but the member 'Audio' and co offered settings which greatly improved movie playback. So that’s one tiny area fixed
What are you doing on your device which is causing your phone to run so fluidly?

I was happy with my device running the stock Orange Rom. It was quicker than my Hermes running the Black Majik rom. I recently flashed the V3 Dutty Rom and its a little faster - not much though.
I have a 4gb microsd card that I install most apps on. I use the HTC Home screen - with no other plug ins.
See below for screen grabs of installed programs.

Underwired 4,
Thanks for the response. I have an 8GB memory card, and I install all my applications on this card, and not on the device memory. The only thing I've installed on the device memory, that I can recall, is the PIE fix, and the slight fix for the camera. That is all. Everything else goes onto my 8GB storage card, of which I have over 5GB of memory left over. From the looks of it, I have more device storage memory than you do, but slightly less programme memory than you.
My free storage memory reads: 112.76 MB
My free programme memory: 48.54 MB
I’m left scratching my head...

Graphics Test 1 1060
Others Test 2 1730
JPEG Test 3 2246
Games Test 4 1261
Sound Test 5 0669
Final Score: 1393

246810 said:
My free storage memory reads: 112.76 MB
My free programme memory: 48.54 MB
I’m left scratching my head...
Click to expand...
Click to collapse
I have scratched my head about this before too. I tested this last night and if you take the card OUT, you will see a BIG increase in your memory.
My feeling is that maybe if you have shortcuts on the phone TO those apps on the card, at boot time, the phone reads all of those and maybe that is what does it? Or 1 or 2 of those apps on the card load (somehow) on the boot up.
I hope I explained that correctly

Here's my list (doesn't have all I have installed) and it's not slow whatsoever.
My VSbenchmark overall result is 1600-something.. I'm really using it, and Kaiser is coping with it with no problems.. my Wizard would beg for mercy at this point.

MirrorminD said:
Graphics Test 1 1060
Others Test 2 1730
JPEG Test 3 2246
Games Test 4 1261
Sound Test 5 0669
Final Score: 1393
Click to expand...
Click to collapse
Thanks Mirror. Where are you? What device is it (ie tilt, tytn2 vario3) and which rom?

246810 said:
Underwired 4,
Thanks for the response. I have an 8GB memory card, and I install all my applications on this card, and not on the device memory. The only thing I've installed on the device memory, that I can recall, is the PIE fix, and the slight fix for the camera. That is all. Everything else goes onto my 8GB storage card, of which I have over 5GB of memory left over. From the looks of it, I have more device storage memory than you do, but slightly less programme memory than you.
My free storage memory reads: 112.76 MB
My free programme memory: 48.54 MB
I’m left scratching my head...
Click to expand...
Click to collapse
Have you run any tweaking programs to set page pools etc? Such as Kasier Tweak or Shaps advanced config tool?

Mines a bit random.
Sometimes about 1 second, sometimes more. Sometimes it redaws off center and has to draw again. Seems to take longer when sliding the keyboard back in than it does the other way.
Can't say it really annoys me too much... I just wait for it

unwired4 said:
I was happy with my device running the stock Orange Rom. It was quicker than my Hermes running the Black Majik rom. I recently flashed the V3 Dutty Rom and its a little faster - not much though.
I have a 4gb microsd card that I install most apps on. I use the HTC Home screen - with no other plug ins.
See below for screen grabs of installed programs.
Click to expand...
Click to collapse
Since you seem to be on a mission, please provide us video of your screen rotation. Actually 2 videos; one with only today screen showing and one with any program open on it. If im on Today, the screen rotates in about a sec, but if I have i.e. Opera Mini open it takes 3 sec at least.
I just said on the classaction.org thread that i had a friends Ipaq 6915 for few days and the difference in speed, i.e. opening programs menu is obvious.
Im still running Duttys WWE lite rom with Spb Pocket Plus + Diary + weather, S2U2, WkTask, TC, Office, Live etc installed. On my today i have only 4 quick launch icons and the Spb Diary.
BTW. Its a joke playing even Spb Arkball on the Kaiser...

foobar1977 said:
Sometimes it redaws off center and has to draw again. I just wait for it
Click to expand...
Click to collapse
Yes, that happens, especially if there is some program running....

graphics: 1084
others: 1831
jpeg: 2286
games: 1284
sound: 0681
final score: 1433
Stock Tilt Rom, without the AT&T software.

The only mission I am on is to imporve the plight of the unhappy Kaiser owners.
Despite accusations of being an HTC spy etc etc, I just want to back up that my happiness with my device is due to it responding as fast as I need it to- which may also explain why HTC think the device is fast enough.
(Am trying to shoot vids now. Opera Mini will always take longer to redraw as its a java app inside a midlet mgr).

Sane said:
I just said on the classaction.org thread that i had a friends Ipaq 6915 for few days and the difference in speed, i.e. opening programs menu is obvious.
Click to expand...
Click to collapse
Just for the record, my fiancee's Wizard (used to be mine) is a faster when opening menus and redrawing the screen. Why? It's running WM5 stock ROM with almost nothing on it but basic functions. The today screen is empty. Only thing it has is S2U2 running on background (so that her purse doesn't keep calling me).
My Kaiser is filled with stuff, as you can see screenshots on my previous post in page 1.. and it's a it slower.. delay of 0.4 seconds doesn't bother me.

sharpja said:
graphics: 1084
others: 1831
jpeg: 2286
games: 1284
sound: 0681
final score: 1433
Stock Tilt Rom, without the AT&T software.
Click to expand...
Click to collapse
It seems that reflashing to Dutty's v3 ROM makes it a bit faster. And, splitting hairs, replacing ati_d3d.dll to the one from LG seems (judging by VS benchmarks) to make it a tiny little bit faster as well.

Really bad quality videos... sorry! Did them in a rush on my old sony digital camera. Focussing would have helped...
Switching in today - portrait to landscape is faster than I am! Back to portrait takes nearly a second.
Switching and scrolling through emails.

My "stock" Kaiser - ATT Tilt -with a few apps installed and running Hotsynch to get my corporate mail, I scored the following:
Test 1 - 1067
Test 2 - 1772
Test 3 - 2176
Test 4 - 1244
Test 5 - 0786
Final Score - 1409
I got 1441 after soft reset with HotSynch running to synch mail wirelessly, then removed hotsynch and got 1509.
So, I guess I need to go ahead and flash my ROM.
I am new to the site and have to start reading the threads and getting familiar, but to jumpstart me, is there a "best" or "most used" ROM and Cab config that is popular and stable amongst the group? I saw a touchflow video on youtube - do many of them have that?
Tom

pearsth said:
I am new to the site and have to start reading the threads and getting familiar, but to jumpstart me, is there a "best" or "most used" ROM and Cab config that is popular and stable amongst the group? I saw a touchflow video on youtube - do many of them have that?
Tom
Click to expand...
Click to collapse
Welcome, Tom =)
Most used ones are probably Dutty's v3 ROM and Alex's Home ROM. Also, many of our "most famous" cooks are testing and creating stable ROMs that run WM 6.1.. so if you want, you can just wait for a bit and reflash 6.1 ROM.

Rom With Ramdisk Preconfigured

Ram disk is a very nice addition to the hd, with the amount of spare ram it has. just the program is a pain to set up everytime you hard reset. would be a lovely additiomn to wm6.1 preconfigured to store temp files, cache storage,temp internet files, system files, bluetooth etc. Will have a go tomorrow in the kitchen, limited on skillz in the reg area, may need help.
ps. why are there no roms with ram disk???

Hardqs said:
ps. why are there no roms with ram disk???
Click to expand...
Click to collapse
I don't know, I have also thought about it, but since my device isn't here yet, I can't do anything . What do you mean by "system files" or "bluetooth"? The other ones are quite clear.

well there is a bluetooth app which redirects the dir, so recieved bt files will go there,should spped things up in terms of the pda should reveives at the same speed but writes faster.
systems files, would be good if the feature of being able to use the feature of ramdisk, to have programs preloaded in a folder into the ram and is not deleted but written to cahce before shutdown and reloaded on start up. could keep favorite programs you wish to run faster in there. maybe startup system files but no sure about that??? to much space??? to complicated..

bluetooth dir - http://forum.xda-developers.com/showthread.php?t=277187
ram disk - http://forum.xda-developers.com/showthread.php?t=382944

I don't think that putting received files in a ram disk is very bright, because you will have to move them, before making a soft-reset, else they will dissappear.
Putting cache files into a ram disk will really improve the speed of the browser, but on the other hand you will loose your cache with each soft-reset. On static sites, where a browser can make heavy use of caching functionalities this will also be an advert effect, which will cost money, because you have to download the same content again and again.

Running a custom ROM? Minimize memory leaking by tweaking this tweak!

Most chefs have optimized their custom ROMS with a large "file system cache" to, in theory, increase performance. After much experimentation, I have found so far that this seems to directly correlate with some of the memory leaking we see in these ROMS! (perhaps the WM6.5 file caching algorithm is faulty?)
Anyway, you have nothing to loose but time, so please consider this simple tweak...
If your ROM has a HKLM\System\StorageManager\FATFS\CacheSize of a large value (4096, or 0x1000 in hex, seems to be common) change this instead to 0x100 (256) and soft-reset.
Now, use the phone a bit, and notice how much free RAM you get back after closing everything down. Even if the free RAM doesn't initially jump right back up to almost where it was at boot, you'll notice that CleanRAM does a *much* better job of getting it right back there.
To me, the phone doesn't feel slower in any way with this small of a file system cache. Turning it off completely did feel a bit slower, but I could have just been imaging things.
Either way, I've had a cache value of 0x100 since my last reset several hours ago, and have had Opera, CorePlayer, IE, YouTube, Adobe Reader, and several other things opening and closing and running concurrently, and once I shut them all down, I am right back to about where I was at boot. The one time it didn't get there, cleanRAM gave me back 18MB and there I was!
Try it !
* UPDATE: I don't claim this will completely fix memory leaks -- I'm sure there's many factors at play here -- but it does seem to really help!

i just tried it and it dropped down to 52% after i was at 70%. it feels a bit slower for me but nothing to major.
thanks for sharing

Tried it on NRG's Latest, changed from Auto to 256k (using Schaps advanced config).
Mem Usage seems to stay a little lower, and the performance seems similar.
Just my experience.
Dave

will try it and report back

attached a cab

This really does work... I even noticed sometimes if I leave my phone alone the memory usage will go down a little bit now instead of leak. No performance issues. Using dotcompt's latest ROM. Works great, hangs around 65% memory in use now even with heavy use. I changed my cache setting to 128kb.

I tried this tweak with the 6.5 stock ROM from HTC on a unbranded model. De default value was 0, i changed it to 128 and now i'm hoping for some action
I will report back tomorrow if i notice any change.
Thx for the tip ^.^

Hi all, well i tried this tweak. It does seem to slow things down a bit. I saw there was an option to disable the cache, i'm going to test this now.
For me 128 was the best value.
Grtz,
FeareX

I'll give it a try at 128kb .... let's see
edit: After first reset upcoming appointments and weather forecast in home tab were missing ( -> changed mem size to 256kb ... let's see

when i went to try this out, my cache was set to 0, so i changed it to 256 and didn't notice any change and the same thing occurred when changing to 128

does this work?

titan427m said:
when i went to try this out, my cache was set to 0, so i changed it to 256 and didn't notice any change and the same thing occurred when changing to 128
Click to expand...
Click to collapse
zero means that windows mobile takes what ever it wants/needs. If you want zero you should disable the cache.

also watch out for this: http://wiki.xda-developers.com/index.php?pagename=Windows_Mobile_6_Standard
I also played around with the maximum buffer size for HTC Sense. Found somewhere in HKLM\Software\HTC\ResProxy
Some Custom ROMs already have a lower value. In Advanced Config you also find a setting for the glyph cache.
And I kicked out many tabs. For example the music tab is locking memory once it is used.
But keep in mind that caching is done for speed. And the best tweak is not to even use HTC Sense! ;-) But a blank today screen is not very useful, so I am still looking for a good solution and testing alternatives.
At least Windows Mobile devices should have much more RAM

I changed mine to 256, rebooted and 2 things i notice. SMS that comes in does not display the caller name. It only displays the number. I can view the SMS from the tab but when i tap on the sms and goes into the sms compose window, no sms is displayed at all
Changed back to 0. It's probably just me but FYI

unclemiltie said:
yes you can
blocks are the same to the mechanical parts are simple, out with the old in with the new.
You'll need a tune in the 9-3 that knows about the new engine though. Fortunately the usual suspects can do that for you.
(Oh, and that's exactly what was in the 9-3 Viggen, a B235R)
Click to expand...
Click to collapse
Even though the Viggen has the same motor. That monster must have more to it. Viggen is the fastest Saab I know of. I own a 2002 convert.
---------- Post added at 05:44 PM ---------- Previous post was at 05:41 PM ----------
jsmith8858 said:
Most chefs have optimized their custom ROMS with a large "file system cache" to, in theory, increase performance. After much experimentation, I have found so far that this seems to directly correlate with some of the memory leaking we see in these ROMS! (perhaps the WM6.5 file caching algorithm is faulty?)
Anyway, you have nothing to loose but time, so please consider this simple tweak...
If your ROM has a HKLM\System\StorageManager\FATFS\CacheSize of a large value (4096, or 0x1000 in hex, seems to be common) change this instead to 0x100 (256) and soft-reset.
Now, use the phone a bit, and notice how much free RAM you get back after closing everything down. Even if the free RAM doesn't initially jump right back up to almost where it was at boot, you'll notice that CleanRAM does a *much* better job of getting it right back there.
To me, the phone doesn't feel slower in any way with this small of a file system cache. Turning it off completely did feel a bit slower, but I could have just been imaging things.
Either way, I've had a cache value of 0x100 since my last reset several hours ago, and have had Opera, CorePlayer, IE, YouTube, Adobe Reader, and several other things opening and closing and running concurrently, and once I shut them all down, I am right back to about where I was at boot. The one time it didn't get there, cleanRAM gave me back 18MB and there I was!
Try it !
* UPDATE: I don't claim this will completely fix memory leaks -- I'm sure there's many factors at play here -- but it does seem to really help!
Click to expand...
Click to collapse
If the transmission is good in the 95. I would use it and swap ecus. Have to make sure the motor mounts are in the same location. I would also use the CV shafts from your 95. I have thought about that when we still had our 2001 93. Going with a newer motor to get out of the sludge year Ect. 93 would be a sleeper though. Vroom vroom!!!