Related
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.
How to install more programs when 256 MB of ROM are full. Can I install more programs on microSD cards? And how?
Constantinff said:
How to install more programs when 256 MB of ROM are full. Can I install more programs on microSD cards? And how?
Click to expand...
Click to collapse
Well when you run .cab on phone it asks for place to install choose Storage Card.
Also as a rule i use only Device Memory for programs that load on startup or need fast access and Movie player to take load off Storage Card. Keeping as much space on Device memory as possible so the device runs @ optimum.
Hope that helps.
Hope that helps.[/QUOTE]
It does indeed help ! And though I didn' have a problem, since I "behave" z same as you "instructed" up here, since ages, but I needed to say BIG THANK YOU for your instant & redundant help to others in this freakin'-sweet community Stylez, God bless you Bro
tauriq said:
It does indeed help ! And though I didn' have a problem, since I "behave" z same as you "instructed" up here, since ages, but I needed to say BIG THANK YOU for your instant & redundant help to others in this freakin'-sweet community Stylez, God bless you Bro
Click to expand...
Click to collapse
You probably meant "instant and ready help"... redundant means useless! Sure you didn't mean that
moonray said:
You probably meant "instant and ready help"... redundant means useless! Sure you didn't mean that
Click to expand...
Click to collapse
Oh sometimes i feel a bit redundant
Thankyou tauriq for kind words
stylez said:
Also as a rule i use only Device Memory for programs that load on startup or need fast access and Movie player to take load off Storage Card. Keeping as much space on Device memory as possible so the device runs @ optimum. ...
Click to expand...
Click to collapse
So Stylez, do you use Schaps Advance Config? If you do, under locations do you change any of the default locations to point to the mem card (besides of course My docs, pics, vids, downloads)
You seem to be quite the expert so I value your opinion about how to set up my device.
abovenbeyond said:
So Stylez, do you use Schaps Advance Config? If you do, under locations do you change any of the default locations to point to the mem card (besides of course My docs, pics, vids, downloads)
You seem to be quite the expert so I value your opinion about how to set up my device.
Click to expand...
Click to collapse
I keep everything as is
My Pictures get stored to SD nothing else is really space concious... Downloadz always to SD
More important is the cleaning of device temp files etc, Clear Temp using on a regular bases... Along with sktool Free RAM (silent) running every 6 hours, also use MTreeSize to view file system for anything that's taking up space and unwanted.
No expert just too much time on my hands
Hi all, been lurking for a while now. Fantastic community here, lots of useful advice, files etc
I've been playing with ramdisks on my desktop lately and was wandering if there is such a thing that works well on xperia, and if its a worthwhile thing to do. I've seen a few cabs about the net, but most seem to be rather old and under-developed.
Is there a ramdisk utility that has been test with xperia? this thing has plenty of ram and i would expect dedicating 32mb or so to caches / temp files would be useful, reduce checkerboard effect on browser, help with buffering vid's etc.
thanks all.
What good is it if the software isn't looking/optimized for it?
X1 has 256MB, far more than most WinMo phones. How is putting a virtual drive in RAM going to make things faster? You'd just be lowering system RAM. The whole idea seems pointless...even on desktops nowadays.
This is actually a good way to improve Opera's performance if you tell it to use the RAM disk as cache.
JKingDev said:
This is actually a good way to improve Opera's performance if you tell it to use the RAM disk as cache.
Click to expand...
Click to collapse
...as opposed to?
WhyBe said:
...as opposed to?
Click to expand...
Click to collapse
He didn't insinuate a comparison, why do you ask for one? Jking just said it's a good way to deal with Opera loading, nothing else. Smartass.
Angelusz said:
He didn't insinuate a comparison, why do you ask for one? Jking just said it's a good way to deal with Opera loading, nothing else. Smartass.
Click to expand...
Click to collapse
lol thanks. Opera uses storage memory (which is flash memory) as cache when loading webpages. Therefore uing a RAMdisk is faster than regular storage.
Angelusz said:
He didn't insinuate a comparison, why do you ask for one? Jking just said it's a good way to deal with Opera loading, nothing else. Smartass.
Click to expand...
Click to collapse
Yes he did, because he is talking about using RAM disk technique which isn't currently used by Opera. The comparison was implied...dumbass!
JKingDev said:
lol thanks. Opera uses storage memory (which is flash memory) as cache when loading webpages. Therefore uing a RAMdisk is faster than regular storage.
Click to expand...
Click to collapse
Do you think internal RAM would be that much faster in this case? I think the data connection is the bottleneck when it comes to web browsing, not RAM speed. Besides, you're going to sacrifice system RAM in order to have the RAM disk. So would you even be getting a net gain in speed?
WhyBe said:
Yes he did, because he is talking about using RAM disk technique which isn't currently used by Opera. The comparison was implied...dumbass!
Do you think internal RAM would be that much faster in this case? I think the data connection is the bottleneck when it comes to web browsing, not RAM speed. Besides, you're going to sacrifice system RAM in order to have the RAM disk. So would you even be getting a net gain in speed?
Click to expand...
Click to collapse
I've been using ramdisk on my rom since half year ago (v2.x). And both IE and Opera could take advantage of it after some tweak. RAM is definitely a lot faster if you did some benchmark on both. And if you really understand how caching works, it won't help in your first visit where data connection is the bottleneck. But it does help if you reload/revisit the same page since caching from ram is faster from flash memory.
And there are side benefit like security (all content/cookie are gone after reset), and prolong yr flash memory life (flash memory is not as good for I/O wearing but may not be a big deal since most of us change phone so often).
After all, X1 has 256mb of ram which is a lot for mobile device and I selfdom running out of it. Then why not making good use of them? Maybe seeing big chunk of free memory (and slow everything down) make you feel happy? Unlike desktop, the main component contribut to speed is CPU where free memory only contribute for how many program/process you can open concurrently. Seeing lot of free memory without utilize them is simply stupid.
BTW, I use 3Gig ramdisk on my 8Gig Vista64 and it HELPS a GREAT DEAL in rom cooking since rom cooking involved lots of read/write over thousands (TF3D alone is ~ 2000) of small files. A cooking process that takes 3 mins with HD reduces to 1 mins with ramdisk in my experience. The same reason I listed above holds true for desktop + using ramdisk for /Temp helps a lot for IE and winrar since they use /TEMP to process the files.
^^^ OK, I understand what you are saying. But if RAM disk were really an advantage in mobiles, why wouldn't mobile browser developers utilize their own RAMDisk routines in their browsers (since speed seems to be the main comparison between browsers)?
for me totally none use!
WhyBe said:
^^^ OK, I understand what you are saying. But if RAM disk were really an advantage in mobiles, why wouldn't mobile browser developers utilize their own RAMDisk routines in their browsers (since speed seems to be the main comparison between browsers)?
Click to expand...
Click to collapse
It could be they are developing a "generic" browsers that serve PDAs with different size of RAM. And many of the older devices still have 64mb physical memory and 20-30mb left after boot (e.g. My P525 and x51v) . Those machines simple don't have any ram left for that.
And they can simply use malloc (C programming) to allocate a chunk of memory and don't have to use external driver like ramdisk to accomplish this. But if the browser itself don't support this feature and we know we have enough ram to spend, we can take advantage of it if needed.
Developers always have priorities in features and there are other means to speed things up to more users (e.g. server side compression like Opera 9.7)
i might be way off on this but im just being cautious. I decided i was gonna replace the 4gig class 2 sd that comes w/ the nexus with the 4gig class 6 i had in my g1. i decided to use my g1 to format the nexus sd card but noticed 1 thing i guess i just dont understand. When i dropped into parted with the nexus sd card i typed "print" just to see if it was only 1 partition but what i seen was this
Number___Start_______End_________Size______Type_____File System
___1____4194kB_____3965MB_____3961MB_____Primary______fat32
can someone explain to me what would be from 0-4194kB and also how the end size is bigger than the complete size. If that is how its supp to be and im just misunderstanding then please update me on how it actually works or if ive noticed something that needed to be pointed out.
Thanks, veritasaequita
3961MB + 4194kb = 3965MB, the "End" Size is just an Index. Partition starts at 4M, is 3961 MB in size, so it ends at 3965M
About the missing 4M at the start, I'll take a quick look at it.
EDIT:
Looks like all zero to me, if you substract the mbr from the first 4MB. Perhaps somebody at google did some clever aligning? but then 4mb would be huuuuuge
thats kinda what i was thinking, actually my first thought was if it was a 4mb sorta kinda "swap type partition" for performance....prolly not though. im a perfectionist so im not gonna swap cards until i can fig out what or where those 4mb are and have them on my new card....i dunno my ears are smoking now...lol
veritas
well you can always just dd the old card to the new one and then enlarge the fat partition (or in your case: just omit the last step )
but why make such a fuss about 4mb of zeros? i've seen lots of strangely partitioned usb-sticks/flash disks --and-- a lot of people use other cards in ther n1's (because of the crappy size the n1 ships with). if you must you can always make a dd to a new card or store the dump somewhere for restore later (or just put the old card somewhere safe?).
but still, that seems paranoid and not perfectionistic... don't worry so much
ps: yeah, swap with 4mb wouldn't help much and on the other hand they would just mark it as "swap" in the partition table if it were the case.
im following, thanks for the insight bro
veritas
Just a guess, but most modern hard drives have a hardware cache at the start of the disk. i.e 8MB, 16MB, 32MB etc.
Maybe your SD card uses 4MB.
Also, the manufacturers use the non-technical "Billion Bytes" instead of "Giga Bytes" in the fine print. 4000000000 B (Billion Bytes) = 3814 MB
nope, cache would be invisible by definition.
also the 4mb are there just not allocated to any partition. this has nothing to do with how you calculate the size of the disk.
Just out of curiosity could there ever be a possible way someone like perhaps google could store something hidden to everyone else in that 4mb for maybe like a factory backup of the file system or a backup bootloader? Just exercising my brain, thats all...lol
It's nothing basically, all the hard drives in your PC will have a few meg space you can't partition.
veritasaequita said:
Just out of curiosity could there ever be a possible way someone like perhaps google could store something hidden to everyone else in that 4mb for maybe like a factory backup of the file system or a backup bootloader? Just exercising my brain, thats all...lol
Click to expand...
Click to collapse
well of course you can store something there and if the IPL of the phone can access the sd card it certainly could execute that or flash something. there is a broad range of possibilities what you could and couldn't to with the 4 meg (a factory backup would be a little bigger ) and a backup bootloader wouldn't make sense, because you can feed something to the current loader directly. if you do anything worse to the phone like erasing the IPL, well thats what JTAG is for, just program the chips directly.
so of course this could be an evil tracking cookie and we all could get even more paranoid, but still its all zero's and not really "hidden" in any way, just not allocated and directly visible.
what i want to say: every facebook or other kind of web 2.0 shouldn't be worried about 4 unexplainable megs on some sd card
Learned last night from Patriot Memory what I already knew without realizing it...with 32GB (only) SD cards on what appears to be any version of Android, the cluster size -must- be 32KB (I had tried both 64KB for performance and 4KB to reduce slack wastage) or you *will* encounter corruption (possible root cause for some of our SD-card-booting brethren?).
Google has no fix according to Patriot and this is a widespread problem (across phones and tablets), though I can't for the life of me figure out why.
Is this a kernel-level issue with the filesystem? Any idea of whether this is something that might get fixed for CM7 to make it even more compelling than it already is?
Rodney
Rodney, I think the answer is no, unless we were to go to NTFS which is not robustly supported. here is a reference for FAT32 cluster sizing and formatting. Informative but some what dated.
http://www.infocellar.com/hardware/harddrive-cluster-sizes.htm
anyway, for 32gb disk , 32k clusters are mandated.
FAT32 offers efficient 4KB clusters for partitions up to 8GB. The cluster size increases with the size of the partition, up to 32 KB for partitions over 32GB
DigitalMD said:
anyway, for 32gb disk , 32k clusters are mandated.
Click to expand...
Click to collapse
Microsoft seems to think differently, as they offer a number of different cluster sizes for that partition using FAT32, all of which work (on their OS). If you're saying it's the Linux FAT32 VFS that's busted, that's fine...but it's still busted.
Rodney
It's not busted, its just the way Fat32 works for compatability. That's why Linux has ext3 and Windows has NTFS. Fat32 is old, but universal.
It is busted, and there is no such "compatibility" rule. The web page you referenced is mistaken.
The _only_ valid rule, in Microsoft's own code, is as follows (assuming 512-byte sectors):
FAT32: 65,526 < Number of clusters < 268,435,446
So for a 32GB device, let's look at the number of clusters we create with various cluster sizes...
64KB: 500,000
32KB: 1,000,000
16KB: 2,000,000
8KB: 4,000,000
4KB: 8,000,000
2KB: 16,000,000
1KB: 32,000,000
512: 64,000,000
(no cluster size smaller than this because a cluster can't be smaller than a logical sector)
All of the above cluster sizes *are* supported by Microsoft, and *should* be supported by any "compatible" implementation of FAT32...thus, there is an _in_compatiblity with Linux's VFS implementation of FAT32 that does not adhere to the standard, and thus causes data corruption.
Don't believe me? Format a 32GB SDcard with 16KB clusters on a Windows box. Copy 100 100MB files to it, mounted directly to Windows, and check each for corruption. Repeat the test after inserting the SDcard into an Android device and USB-mounting it to the same PC. You _will_ see corruption, that _is_ specific to the Android device. I imagine it would be seen under other Linux distributions as well, but I've seen no anecdotal evidence and can't be bothered to test since the evidence is pretty clear.
Obviously, if 32KB were the only permitted/possible cluster size, Patriot wouldn't have had to warn all its customers about the risk of data corruption when _not_ using that cluster size.
All I wanted to know is whether anyone had even looked at it, cared to do so, or were even aware (within the dev community), so that a bit of attention might *possibly* be paid to it to save the long-term pain of users having (silently) corrupted data. It's the worst kind of data loss, and if it's an easy fix, worth doing...don't you think?
Rodney
P.S.: I'm not going to get into any further semantics wars. I am continuing to tire of the ego-positing on the forum. There's nothing wrong with being wrong (I know - I do it a lot!), but continuing to defend your position beyond that is both hopeless and counterproductive.
P.P.S.: It's worth noting this defect does _not_ exist for 16GB and smaller FAT32 partitions in Android. For those playing along at home, many of the files Android creates itself - and many I store on SDcards - are smaller than 32KB, so the whole point of the exercise in adjusting the cluster size downward is to avoid wasting space.
whatever man... just chill
DigitalMD said:
whatever man... just chill
Click to expand...
Click to collapse
Misinformation bugs me (no pun intended), because it leads to defects just like this. There are a great many resources on the Internet that are Just Plain Wrong(TM), Wikipedia notwithstanding (which I personally think gets a bad rap, but that's a whole different subject). If it weren't for the fact that this bug trashes user data without notice, I wouldn't care so much, but I pity the fools that come after me that format their SDcards with smaller cluster sizes thinking they are being clever about space usage only to find a large number of their files are toast. It's not fun.
Rodney
What are you going to do with the sd card?!
If you put 10000 files on it you will only gain 7,8 MB with a 16kb cluster size.
TDO said:
What are you going to do with the sd card?!
If you put 10000 files on it you will only gain 7,8 MB with a 16kb cluster size.
Click to expand...
Click to collapse
Actually, 10,000 1KB files with a 32KB cluster will result in 310MB of wastage - moving to a 16KB cluster size reduces the slack to 150MB. In practice, I have a -lot- more than 10,000 1KB files, largely emulator files...in fact, it's a bit worse, because each of those 1KB ROMs is zipped down considerably, so the real wastage is ~315MB for those files alone. Yes, this does represent only 1% of the total storage, but that's also a single directory.
Besides, I'm anal.
Rodney
http://support.microsoft.com/kb/314463
Maximum cluster size for FAT32 is 32K, but otherwise, sounds like something is busted.
Hard to believe since the FAT32 code should be coming from Linux mainstream which is pretty old at this point.