Database Develop

What is the best way to speed up my phone?

Hello,
I recently purchase a T-Mobile MDA. I love the phone but, it seems that the processor is just plain slow. It takes seconds between application launches. I have hear that I may be able to send my phone to some one who can speed it up memorywise?
My question is is this a good idea and how much does it cost?
As well as is there a way I can get a program to remove what is taking up space in my phones memory, storage and memory?
I am also confused about what a ROM is? Is this something I should consider?
I would appreciate any help, thanks.

You can send the phone and pay for someone else to do the same thing you can do, there is no hardware upgrade only software/registary tweaks.
There are several things you can do to speed things up, they have been discussed here extensively I would suggest doing a search.

Thanks man. Appreciate it.

I think the best way is to overclock...

I tried overclocking but to tell you the truth the best performance gains came from removing software (Anti-Virus) and reg tweaking.

Upgrade to a stable latest ROM could be a big step-up in speed as well, among some other improvements

first, upgrade to the newest ROM version.
second, run Omapclock to overclock your Wizard to a maximum of 260MHz. (240MHz is preferred)

Are there any drawbacks to this omapclock and over clocking mechanism?
eg. loss of memory space/storage space?

reduced battery life + possibly instability depending on how far you go.

I think some big differences need to be explained about speed and responsivness.
Speed is how fast the thing actually runs, responsivness is more what it sounds like this guy wants.
In our case, speed will help us squeeze another 2-3 fps out of our video players, where responsivness will make a program load in 1 or less seconds. Your standard reg tweaks and hacks will help with responsivness. If you have a video file that is kinda skipping or laggy, then overclokcing will help.
You will get little to NO performance difference with a few mhz overclock on your main OS.... I would be suprised if it did anything and not surprised if it slowed down.
In the end, look about the forums, there are MANY hacks and tweaks here posted and on other websites off of google which will help with your responsivness problems.
Some search items to look for:
GDI, animated menus, fat or fat32, cache
Thats off the top of my head, those should make you run pretty fast.

Let's do better
Here goes :
Speedup Display :
[HKEY_LOCAL_MACHINE\System\GDI\GLYPHCACHE]
Limit=8192
Disable menuanimations :
[HKEY_LOCAL_MACHINE \SYSTEM\GWE\Menu]
AniType=0
Speedup filesystem:
[HKEY_LOCAL_MACHINE\System\StorageManager\FATFS\]
CacheSize=4096
EnableCache=1

I don't understand this post. How do I use these links?

Sevenpelicans said:
I don't understand this post. How do I use these links?
Click to expand...
Click to collapse
they aren't links, they're registry changes
you'll need to find a registry editor to do them

Okay, I have a registry editor, as in memmaid, and resco explorer. Can someone explain how I perform these registry changes?

The are probably better and more detailed explanations but basically:
1) Launch the registry editor
2) Navigate the tree structure to the appropriate part (like using explorer for files)
Then either,
3) Edit the appropriate value (i.e. 'Anitype' is already a variable in \System\GWE\Menu) - select the variable (tap) then enter the corrected value (i.e. from above DWORD value is '6' change to '0')
or
4) Insert a new variable with the precisely correct spelling, then enter the appropriate value(s).
NOTE: You have to enter the correct type of variable, but generally you are adding:
Key (like a new folder)
String Value (has a name and then a 'string' value)
DWORD Value (has a name and 'DWORD' value, usually in dec not hex)
Hope that helps... like i said, there are better explanations out there...
PS you should often have to re-start your device for the changes to take place!

Sevenpelicans said:
Okay, I have a registry editor, as in memmaid, and resco explorer. Can someone explain how I perform these registry changes?
Click to expand...
Click to collapse
Open the Resco Registry Editor, search the key which is between the [] and adjust the values as suggested above.

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.

Cing 8125 users: looking for input on next ROM

Howdy,
In about a week (assuming that G.W.B. can resist starting WWIII for that long), I'm going to build another ROM. This time I'd like to get some input on what to include.
A few things to keep in mind:
1) The goal is to include apps and hacks that appeal to the widest audience and are useful. If it's something that's not useful to a lot of people, then there's no reason to put it into a ROM. I can add more themes and ringers as well, but they should appeal to as broad a group as possible.
2) I won't include any commercial apps. Not even in an unregistered state. I might consider things that have been extracted from other ROMs, but I'm debating that with the voices in my head and will decide later.
3) Apps should be mature, not beta, if possible. I don't want to have to rebuild the ROM every time a new beta version of an app comes out.
4) If possible, attach registry hacks in the form of .reg files to your request. Or at least post the registry entry in you message.
5) It would we swell if someone could take the lead on tallying up the suggestions and help to prioritize. I'll shoot for building the ROM in about 10 days.
If we can keep the additions under 5 Megs total I think we'll be OK.
Here's what will be in there as of now (which is in the current custom ROMs)
-Oregami themes
-digital, cellular, and electronic ringers
-.NET Compact Framework 2
-A2DP/AVRCP
-Wireless Today screen plugin
-enable multi-select/delete contacts
-a hidden treasure map providing the precise pinpoint location of $2.33 in pennies that I previously buried when I was perhaps 7 or 8

First I want to say thinks for the bang up job you have done on putting together these roms for us.
The only things that I would like to see that I can think of would be the registery hack that makes GPRS/EDGE stay on all the time. And I would also like, if it is possible, anything that would make the phone us a WiFi connection, when present and turned on, instead of GPRS/EDGE.
I am not sure if it is possible to do that or not.

Usefull apps
Well I would like to have these applications in the next ROM
1) Smartkeys - http://forum.xda-developers.com/viewtopic.php?t=41060&highlight=smartkeys
2) Wakeapp - to easily setup OmapClock and other event-driven applications. http://www.kent7.com/holly/wakeapp/ , download EN version at http://kent7.sakura.ne.jp/holly/wakeapp/wa_arm021_e.zip
3) SMSDeliveryFix - to show SMS recipient name in a delivery report - http://forum.xda-developers.com/viewtopic.php?t=42696&highlight=sms+delivery+fix
4) WM5NewMenu - similiar to WM2003 "New" button - http://forum.xda-developers.com/viewtopic.php?t=40088&highlight=wm5newmenu
5) WM5torage - PDA acting as a memory card reader without ActiveSync - http://www.modaco.com/WM5torage-t238545.html
6) Some software for sending and receiving vCard via SMS.
Thank you for the great effort :wink:

The correct E or G icon
Caps, Num, lock indicators
ability to set OMPA and forget it.
smaller scroll bars

the three reptile themes at this site, I think everyone would like these, grey, blue, and red.
http://www.zombienexus.net/portal/GL_SubDirectory.asp?SEC=3&CatID=70
TCPMP-media player
Total Commander-file explorer/reg editor
Agile Messenger-great messaging app aol,msn,icq etc.
I think these are good apps that everyone could use.

the only thing i think would be beneficial would be adding all the reg edits that reg wiz adds to speed up our device, so we don't have to do it each time we clear storage. THAT would be awesome. i could care less about apps being included, i can install them just fine; but it's a pain in the ass every time i clear storage/flash new rom, that i have to redo all the reg tweaks.

I haven't found a way, but more emphesis on Storage Memory than Program memory would be good for me. I use alot of storage memory with Contacts, Email (even with moving my attachments to storage) and Calendar databases.
I used the much cleaner 2.17 RUU rom without the ringtones but did copy over a couple of them from the 2.17 with RT and OC. Also copied the OMAP clock and it's shortcuts.
A clean Rom without much of the extras would be good.
I also have customized my Cingular connection to use isp.cingular and [email protected] instead of the built in wap.cingular and [email protected] connection. I also turned of the proxy as it was interfeering with my AKU2 push from my Exch2K3-SP2 box.
Is there anyway to use the EXT ROM or add a slider bar like in WM2003SE?
J-Man5
p.s. thanks for the ROMs. I just got my 8125 about 2 weeks ago and have been having mucho grande fun with it.

ROM additions
How about:
- Total Commander
- ?? some sort of free registry editor (PHM RegEdit?)
- smartskey, I agree, but I think it's ini file needs to be in the same directory and it's small so this may not work
- RegWizard (the xda developer forum developed list of hacks), although actually i don't think this is necessary because it along with its framework requires over a meg, and you can just delete it once you install the desired reg hacks. . .
- Magic Button or some other similar task manager thing
I don't think more themes or ringers would be uniformly useful.
jason

Can you add something to truly shut down apps?
I've gotten in the habit of shutting down apps through the running programs tab under memory. Is there any way to make this easier such as putting a direct link in the Start menu to this page or on the Today list.
You know, summiter, you could just fix it so that the programs actually close when you hit the X.

Re: Can you add something to truly shut down apps?
sbuff said:
I've gotten in the habit of shutting down apps through the running programs tab under memory. Is there any way to make this easier such as putting a direct link in the Start menu to this page or on the Today list.
You know, summiter, you could just fix it so that the programs actually close when you hit the X.
Click to expand...
Click to collapse
Not unless he is going to rewrite the way Windows Mobile works. Thats a M$ thing. And also why apps such as vBar and Magic Button and InClose exist.
Summiter may be a ROM compiling wizard but lets not lay too many burdens at his feet to fix.
I'm just really happy push email is working.
J-Man5

Suggestions:
TCPMP with plugins http://tcpmp.corecodec.org/about
tGetFile.dll http://tillanosoft.com/ce/tgetfile.html
PocketNotepad http://tillanosoft.com/ce/pnotepad.html
PocketTweak http://tillanosoft.com/ce/ptweak.html

Adobe Reader 2.0 is huge and belongs in ROM. But is it popular enough? http://www.adobe.com/products/acrobat/readstep2_mobile.html#pocketPC

Continued Bluetooth Fixes
I have notice several still having Bluetooth issues with the lack of support; specifically, SSP over bluetooth. This opens up additional application possibilities not available today. I wouild like to run Bluetooth GPS with receivers such as the Holux 236 GPSlim, but the lack of SSP makes this almost impossible.
Just a thought

I'd like to see common registry hacks already applied and perhaps a txt file explaining the ones included with the new ROM. For example, the ones I listed below are from my own notes so when I re-flash I can re-apply them.
Regarding software, I'd almost prefer to see CAB files instead of pre-loaded software. Since CABs disappear once installed, we could make the choice of installing or deleting, and thus possibly save space but also gain the benefit of having them ready-to-install. You could even use different subdirectories for free vs the ones requiring a registration code to help keep the surprise / disappointment factor down (when we find out it costs money). This would also prevent a problem of competing solutions for some who prefer one plugin over another if they both serve a common function.
Along the same lines, I believe registry hacks can be applied via CAB files or maybe even .reg files (or maybe not - I'm still educating myself with all of this). You could stick with what you have for the current ROM but load it up with optional extras which could be deleted if we just didn't want them.
I think what you're doing is great and applaud your efforts!
I just started configuring my 8125 today, these are the hacks I applied so far (after stepping up to your 2.17 ROM):
Enable scrolling in IE with 4-way button
HKLM\SOFTWARE\Microsoft\Internet Explorer\Navigation\4-Way Nav
Change Value from 1 to 0.
____________________
Slide-out Keyboard Status Indicator
\HKCU\ControlPanel\Keybd
Create entry EnableIndicator and assign DWORD value of 1(decimal)
____________________
Increase your 8125 speed
HKEY_LOCAL_MACHINE\System\StorageManager\FATFS\
Change "CacheSize" value from "0" to "4096".
Assign a value of 1 to EnableCache
HKEY_LOCAL_MACHINE\System\StorageManager\Filters\f sreplxfilt\
Assign a value of 4096 to ReplStoreCacheSize
____________________
Disable menu animation – removes menu animation which uses up system resources
HKEY_LOCAL_MACHINE\SYSTEM\GWE\Menu
Change "AniType" from "6" (default) to "0" (disabled).
____________________
Change the width of the vertical scroll bar and the height of the horizontal scroll bar so they take less room on the screen:
HKEY_LOCAL_MACHINE\System\GWE
Change cxVScr to (say) 9 to make vertical scrollbar narrower. Default value is 13
Change cyHScr to (say) 9 to make horizontal scrollbar narrower. Default value is 13
____________________
Enable 802.11g
[HKEY_LOCAL_MACHINE\Comm\TNETWLN1\Parms]
"dot11SupportedRateMaskG"=dword:00000008
"dot11SupportedRateMask"=dword:00000001

TCPMP
TCPMP definitely, I use this more than any other app on pocketpc devices.

I think you should also consider a paired down ROM. One without any Cingular addons that aren't required to make the device work on Cingular. Basically only the ones that set up MMS and the GPRS settings. I'd even leave out the proxy if thats possible.
But in this paired down ROM I'd still include a few extras like some extra themes and ringers.
And I'd put in the two programs I don't think anyone can live without, SmartSkey and TotalCommader.
Thats basically the setup I have now, but I'm wasting space in my extended ROM and other areas because there are things on my device that I can't remove and I'm not using.

azagahl said:
Adobe Reader 2.0 is huge and belongs in ROM. But is it popular enough? http://www.adobe.com/products/acrobat/readstep2_mobile.html#pocketPC
Click to expand...
Click to collapse
Is Adobe reader prefered over the ClearviewPDF Reader that is already in the ROM?

Re: Continued Bluetooth Fixes
jlsenter said:
I have notice several still having Bluetooth issues with the lack of support; specifically, SSP over bluetooth. This opens up additional application possibilities not available today. I wouild like to run Bluetooth GPS with receivers such as the Holux 236 GPSlim, but the lack of SSP makes this almost impossible.
Just a thought
Click to expand...
Click to collapse
I'm not familarwith SSP. Is it a profile? What does it enhance/enable?
Do you know if there are any WM5 devices which have it? (perhaps it can be ripped out and added to the Wiz)

knight4led said:
I think you should also consider a paired down ROM. One without any Cingular addons that aren't required to make the device work on Cingular. Basically only the ones that set up MMS and the GPRS settings. I'd even leave out the proxy if thats possible.
But in this paired down ROM I'd still include a few extras like some extra themes and ringers.
And I'd put in the two programs I don't think anyone can live without, SmartSkey and TotalCommader.
Thats basically the setup I have now, but I'm wasting space in my extended ROM and other areas because there are things on my device that I can't remove and I'm not using.
Click to expand...
Click to collapse
haha this is at least the second message that goes something like: "how about a ROM stripped of everything, but add this and that and oh yeah add this too". I say this in good fun so don't take offense. It just indicates that everyone has quite unique needs.
I will create a barebones ROM as well. But I don't want to have too many ROMs out there because I don't want to have to rebuild them all when something changes.
As far as using the Extended ROM for other purposes..as of now it can't be done. It's locked in some way that prevents effectively using as storage space. (if you try to manipulate it, it becomes corrupted). So the only use for it is to install stuff at first boot.

Well I might as well put in my two cents....but first....Summiter....marry me! I'll tell my wife to divorce me and she can take her nokia phone with her!
-Ok definitely Smartskey in the same folder as Omapclock so smartskey.ini file can tell omapclock to clock me at 216 everytime after soft reset.
-Please take out the stupid SIP keyboard...i'ts useless and can only be used by leprechauns with little fingers.
-A way to easily change splash screens.
-Hide SIM contacts
HKCU\ControlPanel\Phone
new DWORD value named "ShowSim" and set it to 0
1. Disable menu animations to increase performance:
"HKEY_LOCAL_MACHINE \SYSTEM\GWE\Menu"
Change "AniType" from "6" (default) to "0" (disabled).
- Add vibration instead of sound to keypresses in the phonepad for better tactile feedback:
for i = 0 to 9
Give an example for "i" Button:
[HKEY_CURRENT_USER\ControlPanel\Sounds\Dtmf "i"]
1. Rename Standart DWORD parameter "Sound" to "Sound1"
2. Create new String Parameter "Sound"
3. Assign value *vibrate* to this new parameter.
For this there is also a cab file available.
***this is a cool registry tweak
- oh and this is a must have, all these pda phones lack in the phone department...people on the other side of a phone call can barely hear us until you put this registry tweak in.
\\\registry\HKLM\Software\HTC\AUDIOGAIN(x)\
changed RECEIVE_UPLINK_VOLUME and EARPHONE_UPLINK_VOLUME values to CC. after that change, microphone sensitivity got better and didn't receive any more complaints.
Though i wish someone knew a way to improve the sound mic quality during speakerphone.
And there are so many ringtones in your rom summiter...they all sound alike lol. put the You've got mail.wav file for incoming mail, i have it if you want. how bout some funny ringtones or music ringtones instead?
k that's all

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!!!

[APP][EXPERIMENTAL] MobileBooster v.a1 [UPD.:21-03-2010]

(Current version: alpha 1) DISCONTINUED!
MobileBooster is an experimental CPU-booster tool (experimental as if it may have no effect at all in worst case).
In theory this application can improve the speed and responsiveness of your device in high-load scenarios. It has no settings and is completely invisible.
Features:
- simple and clean installation and uninstalation
- boosts your multitasking capabilities by managing process priorities
- slightly boosts active application speed at the expense of background tasks
- supports all HTC devices
Requirements:
- 275kb of free space
- 148kb of RAM
- Microsoft .NET Compact Framework 3.5
Installation:
- download and install the CAB to your device
- soft reset and you're all set!
Uninstalation:
- uninstall using Remove Programs, no reset is required
- be aware that you DO need to soft reset to eliminate all boosting effects (for benchmarks/comparing speed)
The usual disclaimer:
This application is provided as-is. I take no responsibility for any damages that may occur by misuse or bugs in this software.
Project goal:
This is experimental concept and it may have no effect at all save for consuming CPU cycles. If you download and test this, please post back your impressions and opinions. You may experience increased fluidity of your device during normal use and better responsiveness under heavier load. You may experience nothing at all. You may experience decreased speed. Whatever this does for you, uninstall will wipe the application clean so this should be a risk-free test.
Note that your device is less responsive immediatelly after soft reset - this is normal WM behavior. Give it a few minutes before testing.
.

let's give it a go on my TP2 with AthineOS 23549
first impression: Opera 10 seems to render the xda forum pages much quicker. Now lets's play BoingGLES

Yeah... "SEEMS" is the keyword here, Opera indeed seems to be working faster for me, especially with running background tasks and Sense is a bit more responsive, but even though the theory behind this is valid and time proven on single-core PCs, it may all be just a placebo effect.
That's why I posted it for others to see and judge

It could just be a roll of the dice, but gscroll is actually working perfectly (on ereader) with this running. I probably shouldn't have said anything, cuz it'll decide to take a lunch-break soon.
Can't tell much else, but it doesn't seem to break anything.

each restart of the HTC HD2 it gives error cant start this application,
so i unistalled

On my TP works fine, actually seems the whole system actually speeded-up. I had an error once but never happened again. It takes 624k of RAM, so it's quite something but oh well... keep up doin this good job!

Well it's not exactly optimized for memory or CPU usage, neither does it properly handle runtime errors... this is just experimental proof of concept
I have been testing it extensively and from my experience:
1) it definitely does not slow things down.. if it seems so, it's probably because your device is still booting
2) it has little to no effect when you use only 1 application
3) it seems to help a little with concurrency of 2 or more processes
that can be seen during heavy background network traffic or heavy concurrent tasks
- Opera loading pages and rendering at the same time
- you can notice increased responsiveness while playing music in background and doing stuff
- rotating screen in various scenarios also seems a bit faster
- sound cracking under heavy load should be reduced
- basically the more things you run at once, the better improvement you should see; well until you hit the ceiling of your CPU
... I'm not talking huge improvements here but every little bit helps
4) keep on mind that part of the effect is persistent until you soft reset, even if you uninstall or kill the booster you need to soft reset if you want to bench/compare

Thanks nik3r for the app I tried it installed and uninstalled easy with no errors.
Unfortunately, it greatly slowed down my TP performance. Opera rendering was sluggish, opened apps were windows media player, contacts, WLM, tasks, calendar, activesync. As for opening and using other programs , i did not notice a dip or increase in speed.

i'll try it o my htc touch pro 2 and my HTC mogul...

Could you please post the name of your ROM and pagepool size if you know it? I think that pagepool may have huge impact on the ability to multitask.

I'm not 100% sure it has to do with mobileboost, but I've been having some issues with writing to the sd card. (This is actually kind of funny, lol). Last night, I created a shortcut to mobileboost.exe and put it on my sd card, where I have a second copy of my start menu that I access with the XTask file manager (I put stuff I'm testing out there instead of the real start menu). This morning, I scanned my sd card with Scandisk, and it found an error in the folder where I put the shortcut. Ok, no big deal. Today, I was running some SK Tools benchmarks with mobile boost, and I copied them to my sd card (and created a new folder) while MSB was running. After soft resetting and running some tests w/o it running, I looked in the sd card and the folder with the benchmarks wasn't there. I scanned the disk, and the files were recovered as .chk files. I guess it could be happening because I'm using caches applied to the sd card as well as writeback. But, I've never seen this happen before.
Code:
[HKEY_LOCAL_MACHINE\System\StorageManager\Profiles\SDMemory\FATFS]
"EnableWriteBack"=dword:00000001
"BitmapCacheSize"=dword:00000100
"FatCacheSize"=dword:00000400
"DataCacheSize"=dword:00000c00

Definitely unrelated, MobileBooster installs to the device no matter what you chose and it autostarts (from \windows\startup folder).
Make sure you safely disconnect from PC when you're in flash drive mode and don't connect/disconnect the device in flash mode during any transfers

OK, here are some benchmarks with SK Tools. The first two compare benchmarking w/ and w/o mobileboost running, each after a soft reset. I ran three tests, took the average of each three and show the standard deviations.
W/O the boost:
Test AVG STDEV Units
Integer 329.2143667 2.620626281 Moves/25 usec
Floating point 7.595333333 0.022590558 MWIPS
RAM access 537 31.48015248 Speed index
Draw bitmaps 638.6666667 7.637626158 Speed index
Main storage (write) 2366.656667 29.27902036 KB/sec
Main storage (read) 6871.67 770.7838631 KB/sec
Storage Card (write) 3385.506667 131.6158236 KB/sec
Storage Card (read) 4341.836667 1005.563271 KB/sec
File List 2606.666667 139.2850794 Items/s
FL: Storage Card 2424.666667 26.57693235 Items/s
SKTools loading 2185 86.79285685 ms
Click to expand...
Click to collapse
With the boost running:
Test AVG STDEV
Integer 329.7313333 2.010925713
Floating point 7.614 0.031240999
RAM access 442 1
Draw bitmaps 653 4
Main storage (write) 2420.056667 27.17658244
Main storage (read) 7459.18 177.8904416
Storage Card (write) 2712.48 215.2829438
Storage Card (read) 5341.15 928.2778203
File List 2512.333333 68.23733094
FL: Storage Card 2340.666667 67.82575715
SKTools loading 2187.666667 27.53785274
Click to expand...
Click to collapse
These two are really pretty similar. In my experience, there's a lot of variance in how well the RAM access and bitmap tests run; they aren't consistent at all, so seeing the faster ram access without the boost running probably means nothing.
Next, I ran a set of .mp3's over WMP and did the tests (3 for each, w and w/o the boost, with a soft reset in between the tests). This was to test multi-tasking performance. I ran the same two songs for each test (takes about 5 min per test).
W/o boost:
Test AVG STDEV
Integer 289.113 23.80731014
Floating point 7.300333333 0.015143756
RAM access 531.6666667 10.96965511
Draw bitmaps 729.3333333 4.509249753
Main storage (write) 1840.866667 46.8405992
Main storage (read) 7033.93 267.0015249
Storage Card (write) 2730.49 189.3420405
Storage Card (read) 4724.97 997.641275
File List 2279.333333 34.58805189
FL: Storage Card 2196 40.03748244
SKTools loading 2320 57.61076288
Click to expand...
Click to collapse
W/ the boost:
Test AVG STDEV
Integer 241.0114 13.07119076
Floating point 7.227333333 0.007023769
RAM access 543.6666667 13.0511813
Draw bitmaps 727.6666667 3.055050463
Main storage (write) 1898.493333 59.4344196
Main storage (read) 6885.55 481.199009
Storage Card (write) 2708.99 39.82972383
Storage Card (read) 5276.103333 174.1402014
File List 2342.333333 44.23045708
FL: Storage Card 2057.333333 43.01550108
SKTools loading 2286 11.35781669
Click to expand...
Click to collapse
The integer test is a lot faster w/o the boost running, and the floating point is slightly faster (not a ton). Both take a hit compared to not running WMP, which is a major resource hog. The RAM and bitmap tests are both faster, and this just goes to show that they're pretty random tests and I wouldn't ever get too excited about results with these two tests (unless they're consistently awful, I suppose). The only benchmark (besides the first two tests, which basically measure processor speed or effectiveness) that I care about is the last one, which is the SK Tools boot-time (you have to close the app and re-start to get different measurements). It's pretty good in all cases, and doesn't change that much.
Long story short, I'm not seeing much benefit in these tests, but if it helps to get gscroll to work (not sure 100% yet), then I might use it.

nik3r said:
Definitely unrelated, MobileBooster installs to the device no matter what you chose and it autostarts (from \windows\startup folder).
Make sure you safely disconnect from PC when you're in flash drive mode and don't connect/disconnect the device in flash mode during any transfers
Click to expand...
Click to collapse
Yeah, I dunno if it's related or not, but I was doing all the file transfers with total commander on the device. I didn't use the cab to install mobilespeedbooster, I dumped the contents with sk tools and then started it manually with a shortcut (that I made w/ TC). So, it wasn't running from startup.
Edit: now that I think about it, I've also got these keys applied to the sd card:
Code:
[HKEY_LOCAL_MACHINE\System\StorageManager\Profiles\SDMemory\FATFS\Filters\CacheFilt]
"Dll"="CacheFilt.dll"
"Order"=dword:2
"FileCacheWriteBackPriority256"=dword:FE ;shadrac's settings
"FileCacheWriteBackTimeout"=dword:A
I have a feeling that mobileboost was messing with the writeback thread, and that's why I wasn't seeing files writing properly to my card.

Thanks for the tests, even though synthetic benchmarks on WM are inherently imprecise and this app is more about perceived speed than actual raw speed. Your SD problem at least gave me more ideas, I should really treat system services separately with higher priority and try to decrease the thread scheduling overhead, which may cause the differences in benchmarks.

where can I find the setting app?
cause I cannot find it on System settings and start program....
or just install it without setting and anything else...?

There's no settings, the core is fully automated - just install and soft reset and it's online.

Improved performance on my phone
I'll like to start off by thanking you for this great app I usually just read other people who post and if it looks good I download it and I never post back but I really liked this app so I felt like it deserved some feedback. I've noticed my TP run smoother and faster esp when I'm listening to music . Also I don't know if its from your program but my phone would just go to a white screen for 5 sec when I try to go back to my home screen, but thats about the only issue I've seen so far. Keep up the good work

Mine is Exquisite ROM 4.06 ... and i think the pagepool size is 0... as the thread says...

Torakiki83 said:
Mine is Exquisite ROM 4.06 ... and i think the pagepool size is 0... as the thread says...
Click to expand...
Click to collapse
and i forgot, sense 2.5