[MDA III, XDA III, PDA2k, 9090 Software Upgrading] Tuatara:
Hey ... well I guess I could be classified as a Kiwi now ... although I'm actually a Canuck living 'down under'. :D

Yeah - it's a lot more stable, and somehow has a better compatibility with everything. Avcrp & A2DP is readily possible to integrate into the BA ROM (v1.4 proved it) - so we have all the features working ... just the $%@##$@!#! thing turns off. *grumble*

Hmmm ... I've been doing all of my testing with 1.15, but I have two BA's here - so I think I'll flash one with 1.13 and see if that makes any difference. While playing with the radio ROMs previously I noticed little difference between the two - so by 'number' I chose to use the later version.

On the Himalaya though - v1.17/1.18 had proved unusable for me in WM5, so I've been using 1.08 ... although with the new flightmode application - 1.18 is usable and supposedly gives better performance. It's all a mystery - but it's time to see if we can fix this.

Thanks - checking it out now ...

If I do manage to find anything - the world will know about it for sure, and it'll be released in a ROM as example for everyone to use in the future. If I do find some interesting things, I'll PM you anything of note.

Well ... I'd have to say 'yes' and 'no' to that one.

Yes, it could well perform faster at a lower setting, and you might notice an even further increase in setting the cache lower - if you're not using large quantities of data. If you begin to run any data intensive applications though - like a large number of emails, big spreadsheet, or GPS Mapping software - you'll notice that the larger cache actually helps to speed up the device due to the read-caching which is ocurring.

It really is a trade-off though, and one which is VERY hard to get right. That's why Microsoft (in their infinite wisdom) say to let the OS manage it. In some ways they might be right - but ... using the default settings is only as good as the OS decides at boot time. It never seems to re-allocate the buffer size during operation (as far as I can tell) which leaves the cache at the same size, since I believe it must be contiguously allocated in memory.

I decided (after experimentation) that a value of 0x0400 was actually the best (512Kb cache) ... but then experienced no further gains (or losses) by going larger with the testing I was doing (1Mb spreadsheet, 1.4Mb word document, movies, and images loading/display).

Since the BA has so much RAM available, allocating 2Mb seemed like the most practical solution. More would be far too much, and less had performance losses for these extremely large elements.

I've now tweaked the compaction thread timings and priority levels - and this seems to have made another difference in performance. It still needs to be tested further, but by having the compaction thread running more often, it appears to write the information to flash a bit more regularly. By shrinking the cache size, you may be "artificially" creating this same scenario - data must be written now, to provide more cache space. But, by tweaking the priorities, it appears to have the benefit of turning the cache into primarily a 'read-ahead' cache, and keeps the applications (and data) readily available, while still performing the writes as required.

This performance tuning is really a 'black art' and everyone will have different 'best settings'. Since I'm trying to ensure that everything will run and work on the BA, I'm trying to handle the 'worst case' scenarios which people will throw at their devices and expect them to just "deal with it". I'm one of those ab-users myself. 8)

It'd be great to have feedback on GPS mapping applications, and/or large data sets work betetr with larger cache or smaller cache sizes ... but maybe the answer is, we tailor the ROMs for the predicted usage, and make some CABs which provide tuning for each individual users' preferences. Not sure what would be best ...

Anywho ... back to some ROM hacking now ... AKU2.2 seems to have only a few new things ... 8)