Related
From some trial and error I managed to find a way to get a few more megs of ram available for everyday use.
First and foremost, when disabling the Phoneskin on a WM5 device makes a big difference, disables the phonepad dial and speeds up the device. Still, by looking within the services running, the I noticed that the PhonePad dll files are still registered in memory and taking up space even if the skin is actually disabled.
Thus removing the HKLM/SERVICES/PhonePad key freed up some extra RAM.
I suggest making a copy of the key if you ever need to use the PhonePad later.
After a reset the PDA should have a few more megs ram available
Let me know of how much ram it freed up for you
Hey eman,
What exactly is the phone pad? The soft keypad in the phone application that mimics a regular phone pad? Seems right, I'm just double checking.
Cheers.
No difference for me. Also I was still able to dial numbers on the regular phone pad so I cannot see what this registry is about?...
yeah what does this do? do u mean u cant se the telephone on screen pad??
I think it means that instead of loading the phone operator's skin for the phone it uses the default one from HTC. I had disabled the operator skin a while back but I'm trying this now.
First of all this is a well-known hack for a long time. If somebody need it look after it in this forum.
This hack just turns out the customisable graphical dialler skin but you have left the original HTC dialpad which you can see always when you enter your pin-code if your SIM-card needs it when you turn it on.
And yes, it is true, that it gives us some free megabytes to the RAM, but it has to be noticed that after this hack you have to forget the video-call function, because this is a skin-related function.
I've been using this hack since I bought my universal. It worths for me.
I have usually from 21MB to 27MB RAM without soft reset with installed lots of application and I can increase it when it is lower with 'refresh today'-function and Oxios Hibernate (the earlier version, because it is faster without the screen note) application.
So, if in your country video calling is not a famous service you should activate this hack.
Oxios Hibernate
Would you share the old Oxios version or can you post a valid link? I couldn't locate it on the net.
What tool do you use to refresh the today screen? SK, Mortscript or something standalone?
Thanks
http://www.oxios.com/memory/
There is 1.4 version now. I suggest to use an earlier version, because this new is more complicated, and when you push the shortcut you created, the execution takes a bit longer than with that previous version, and it writes to screen in a small window the released memory which is unneccessary, because all of us are using a today meter for memory i'm sure. So that was enough in the version i use just pushing the shortcut and receiving more memory without anything to do.
I refresh todayscreen with Dinarsoft HandyMenu.
http://www.dinarsoft.com/handymenu/summary.html
free memory
Is memorymaid the kind of application, or am i wrong?
none memory difference detected
Requests/suggestions please for WM 6.1 cookers considering their next release:
- 64 MB Program Memory
- Absolute bare skeleton WM 6.1
- essential candidates for removal:
> customer feedback
> windows live
> any windows help & support related bloatware
> error reporting
> search
> windows media player
> any animated items, icons, etc..
> junk items under \windows; unnecessary gif,jpg,bmp,png
etc, text files
- single boot screen, no splash, animations etc..
minimize WM 6.1 boot time
- removal of other misc bloatware, vaporware that are not
core to the function, speed and stability of WM 6.1
======================================================
To the site Administrators:
-------------------------
- can we initiate a donation bucket in which people may contribute
and pool donations?
- 1 month period (or other) in which donations can be collected and
cookers may submit their best releases
- the people (users) vote during the period on what they find to be
the most efficient, stable, fast, clean and best performing rom.
- at the end of the period the donation pool is distributed to the top 3
most voted cookers, e.g. 60%/25%/15% respectively.
======================================================
Suggestions, ideas, recommendations, criticism etc certainly
welcome.
Thanks to all
--kara
64M program memory mean No WM.
why?
is there a maximum?
Thanks,
ks1781 said:
why?
is there a maximum?
Thanks,
Click to expand...
Click to collapse
you are really someone )
Trinity have only 64MB build in , how come it have 64MB program memory ? DId you have brain ?
--yes,
if the device has 64 MB SDRAM, why is it that most cooked roms
generally present approx. 50 MB of that?
is this a limitation or is missing 14 MB used for a special purpose?
Thanks for any advice.
?? because it takes up space to install the operating system.. even a 'bare bones' operating system is still an operating system..
did you ever wonder why there's space missing from your hard drive after you install windows xp?
http://www.htc.com/www/product.aspx?id=470
Memory ROM: 128 MB
RAM: 64 MB SDRAM
What is the ROM 128 MB designated for?
Thanks for your patience with me.
--kara
if i understand him correctly, he is referring to the program memory i.e. RAM not ROM. the 128MB ROM is meant for installation of OS (WM) where the 64MB RAM is the execution power. we normally get ~20MB-25MB RAM free out of 64MB total. i believed the rest (64MB - 25MB) was used for other services once WM started.
yes, that is what i'm trying to understand..
in this p3600 specification from HTC:
http://www.htc.com/www/product.aspx?id=470
it lists>
128 MB ROM
64 MB RAM
=================================================
for the 128 MB ROM
I assume the 128 MB ROM contains the OS installation, with
some component of this ROM hidden/reserved.
E.g. some cooked roms released have 'Big Storage'
~70 MB available to the user for NV storage
the remaining 58 MB comprises OS installation and a reserved
area.
=================================================
for the 64 MB RAM
This is the volatile memory available for the OS to boot & run, and
for program execution.
However, on most cooked roms I have used, under
Settings -> System -> Memory
'Program Total' is reported as ~50 MB.
So my question is - where is the remaining 14 MB RAM??
as dum as it sounds i've wondered about that too
even formatting issues aside (like how hard drive capacity is always lower than reported), 14MB seems like a lot to 'go missing'.
why doesnt WM even report it? because its being used by the system for services? so then why does it ALSO report itself using around 20MB of what's left?
that way, it's like 14 MB used (hidden) + approx. 20MB reported (shown) = approx. 34MB total? :/ hmm
ks1781 said:
So my question is - where is the remaining 14 MB RAM??
Click to expand...
Click to collapse
OK - You have a PC with 1GB of RAM say. Once say windows xp has booted up - your AV started etc. you probably have 684MB say of RAM left, so Where did the other 340MB of RAM go to?
Think about it.
wtf i still don't get it... dont be mad
i mean mine reports 2096236 KB... a full 2048MB of RAM
BUT of course 100-300 minimum will always be in use for the system itself
whereas in WM, it reports like 48MB total, AND say approx. 20MB in use
ok so the 20MB minimum in use will ALWAYS be in use because of windows mobile itself. FINE.
but why does it only represent 48MB as available?
and if that is the case, there's that missing unreported 12MB, PLUS that minimum 20MB always in use
that's what im curious about
Just think that Windows XP takes 250/300 mb of ram space....
PS: Please edit your title... Someone could understand that you really have a 64mb free ram rom......
joncgde2 said:
wtf i still don't get it... dont be mad
i mean mine reports 2096236 KB... a full 2048MB of RAM
BUT of course 100-300 minimum will always be in use for the system itself
whereas in WM, it reports like 48MB total, AND say approx. 20MB in use
ok so the 20MB minimum in use will ALWAYS be in use because of windows mobile itself. FINE.
but why does it only represent 48MB as available?
and if that is the case, there's that missing unreported 12MB, PLUS that minimum 20MB always in use
that's what im curious about
Click to expand...
Click to collapse
Maybe it is for the Radio Rom etc...or maybe Microsoft are stealing Ram and stockpiling it....lol
This is actually a valid question.
The system has 64MB of ram, some how 14MB of this ram is allocated away before the OS loads. This leaves 50MB of ram left for the OS, which uses about 20 MB and leaves 30 MB of ram for applications.
I think everyone understands this part.
The question is, what part of the phone is pre-allocating 14MB of ram.
My only guess is the videocard, if not that then it might be the pagefile.
tetsuo55 said:
This is actually a valid question.
The system has 64MB of ram, some how 14MB of this ram is allocated away before the OS loads. This leaves 50MB of ram left for the OS, which uses about 20 MB and leaves 30 MB of ram for applications.
I think everyone understands this part.
The question is, what part of the phone is pre-allocating 14MB of ram.
My only guess is the videocard, if not that then it might be the pagefile.
Click to expand...
Click to collapse
Does it really matter where it goes? Obviously if that memory hasn't been exploited yet by the excellent cookers etc in here....then it can't be of any benefit.
I concur with tetsuo55.
The reasoning proposed by Andych and others still does not quite
correlate.
i.e. 64 = 14 (OS) + ~20 (progs) + ~30 free
the ~20 is supposedly attributed to basic progs,
e.g. phone, filesys, mail etc..
A listing of such process summates to approx. 8 MB total.
That still leaves 12 MB of unaccounted for basic function
and userland process consumption.
Regarding the ATI video chip, general investigation and
settings check of tcpmp would suggest at best it is a
4 MB chip (whether dedicated or shared)
I cant see the 'remaining ~14 MB' that I'm searching for
being used for paging. Paging is part of overall virtual memory,
and involves page outs/ins to a location on some type
of physical media. Additionally, with the usual ~ 30 MB
ram free, in the context of these devices, a swap requirement
is unlikely given the 'free' memory available.
Although 14 MB may seem peanuts compared to standard desktop
ram configurations today - with a p3600 + WM, recovering the
14 MB (if possible) would provide a much welcomed bonus to
the trinity.
--kara
ahh now we're onto something good work ks1781...
i fully agree with the need to just find out the answer to this... most likely it's something that will be perfectly explainable and make sense and we won't be able to do anything once we find out
but it sure would be nice to know
OK I have the 'answer' - straight from a Windows Mobile blog - I'll post it here cos it's all straight to the point and interesting (somewhat) Link is HERE
The Page Pool
Applications use RAM in two ways. There is code that runs, and there is data that is created while it is running. On a NOR device, the code can run directly from the ROM and not be loaded into RAM first. This process is called XIP (eXecute In Place). NAND devices can't XIP, so their code is loaded into RAM and executed from there. If you don't have a Page Pool, this code is loaded into normal RAM. The Page Pool is a mechanism to limit how much code is loaded into normal RAM. With a Page Pool, we can unload code that hasn't been used in a while and reload it later if we need to. We can't do that without a Page Pool.
On a typical NAND-based WM5 device, the Page Pool is 4.5M.
The Radio Stack
Devices with a Cellular Radio have a complicated bunch of code to make their radios talk to cell towers. On some devices, the radio is a self-contained module with its own RAM and ROM. On others, the radio code is stored in the normal system flash. If so, it either needs to XIP, or it needs to be run in RAM. If it's run in RAM, that RAM is taken away from the system.
A typical radio stack takes 4M.
DMA Buffers
Some hardware can write directly into RAM without using the CPU to do it. This is called "Direct Memory Access" or DMA. DMA is very efficient and lets you get a lot more data transferred in the same amount of time, usually for less power. But it's best to set aside your DMA buffers before the system boots. This guarantees that they're there when you need them. PocketPCs have been doing this for a decade. But, back in the old days, the main use for DMA was audio capture. Audio data is small, so the DMA buffers are also small. Video, on the other hand, is big. More data requires bigger DMA buffers.
An OEM will tune the size of the pre-allocated DMA buffers based on what the device is intended to do. If the main goal is still photos, you can use a much smaller buffer. If the goal is recording video, it needs a much larger buffer. If the goal is video conferencing, it needs a bigger buffer still.
DMA buffers range in size between 300K and 6M. For a video capture device, it's likely to use around 4M.
XIPKernel
There are portions of the deepest parts of the OS that have to XIP. If you're on NOR, that code just XIPs like everything else. Not so on NAND. For a NAND system to boot, it needs to load this code into RAM first and then run it from there. When the system is running, it can't really tell if it's running from RAM or ROM, so it assumes it's running from ROM and doesn't count this space.
The XIPKernel region tends to be between 1.5 and 2M.
The Frame Buffer
There is a chunk of RAM set aside to hold everything that's on the screen. (If you want to know more about it, read this.) On most devices, every dot on the screen needs two bytes. A typical Pocket PC has 240x320 dots. That would be 300K. If you have a 640x480 screen, it's 600K. Sometimes, for performance reasons, devices will have two frame buffers. So this could take up to 1.2M.
Click to expand...
Click to collapse
Thanks joncgde2 - good find which provides a sufficient explanation as to the 'hidden' 14 MB.
There is still another question.
WM reports ~24 MB in use (per earlier screen captures) - where 'in use'
is attributed to running applications.
Checking a process listing via task manager shows the total
apparent RAM in use by these 'running applications' to be ~8 MB.
Can anyone provide an explanation to account for the
remaining ~16 MB??
after i got an idea of what is a pagepool, i have some questions to clarify it, especially that i'm trying to figure my problems wich is maybe related to internal rams.
so i'm using garmin xt and during or when closing garmin i got a msg "your system is runing low memory", and when i'm playing need for speed undercover, i got my car distorted and the sky got some black mappings, but cars got distorted lines and triangles.
i checked the system memory and see that ther is storage and program
storage total:181.47, in use : 104.85, free : 76.63
program total:336.93, in use : 144.65, free : 192.28
now which one is the rom and which one is the ram?
when i run in low memrory does that mean low storage memory or low program memory?
is there a way to maximize it in order to not run low memory. (knowing that i do clean ram, and close all running apps)
does the page pool solve this problem and make better performance?
if i change page pool should i got a different ratio btw storage and programs memory other than 181.47/336.93, i changed all 4mb, 6mb and 12 mb and readings stay the same. should they not change?
any help please
Check here
http://www.modaco.com/content/i900-...khuanchai-windows-mobile-6-5-research-thread/
Q: What is pagepool?
A: Page pool is an area of RAM which is set aside to hold the next block of code the processor is likely to need to execute. It prefetches this from ROM as it executes the program. If the next step of the program needs something that's not in the page pool, the processor goes to the ROM to get it. ROM access is slower than RAM access. So generally, as you increase the page pool size, the chances of the required code being in the page pool increases and speed increases. There is a limit beyond which you won't see any increase in performance.
Click to expand...
Click to collapse
thanks gianton for the link, but really it's not what i want, if someone just can give me answers on each queston will be very helpfull.
thanks again for any help
Hello to all of you.
I have read a lot about setting the Pagepool Size. I know the microsoft commentar on this and the differnet speed tests done by variuos users. Most of them not showing a big increase in speed, but a lot of people reporting a "smoother" UI. But finally all of this seems to be still a mystery for me,.... and of course for others too. There is no final conclusion to me how large the pagepool should be. My question is: How can I determine the optimal page pool size for my usage, without try & error? As I said, the benchmarks did not show a clear improvement, and UI smoothness is difficult to evaluate between the different pagepool settings.
As I understand, the pagepool area is only used for program code and NOT for program data. But the question is: Is this restricted to "user program" code or does also the system processes use this RAM area? If only the user programs are using the pagepool, can I then determin the "best pagepool" size for my usage by starting the taskmanager and summing up the mean RAM usage of all my user programs usally running during using my phone?
So for example if Samsung Taskmanager reports:
Opera Mobile 1,34 MB
Active Sync 0,43 MB
moTweets 3,89 MB
====================
Summary: 5,66 MB
Would then 6/7MB be the best pagepool size for this case? Or is this method inaccurate? Are there any experiences?
Currently I have the pagepool at 4MB. I use Windows Standard CHome with a light ROM. With these settings I habe 97-98 MB of available RAM. So my options would be:
98MB RAM / 4 MB PP
94MB RAM / 8 MB PP
90MB RAM / 12 MB PP
86MB RAM / 16 MB PP
...
Does Pagepool speed up also the programs or just the User Interface? And should I try 16MB? Or do you think this would be too high and therefore only wasting RAM?
Best regards,
Chris
I want to share with you some findings on how the size of the paging pool influences the usability of a WM device.
Setup:
Device: HTC Tornado (Smartphone, original WM5, 64MB RAM, 64MB ROM, TI OMAP 850, DiskOnChip from M-Systems)
ROM: my WM6 build (based on Nitrogen's WM6 - see my signature)
ROM Kitchen: OS Builder 1.48
Paging Pool changer: PPSmartchanger (adapted for use without ULDR partition)
Method:
Create builds with OSB selecting the relevant imgfs compression options:
lzx and xpr
with and without having the code sections of modules uncompressed
Change Paging Pool with PPSmartchanger (works only for devices with M-Systems DiskOnChip - so old stuff only - changed with pdocwrite)
retrieve boot-time via devhealth call after device has rebooted to selected standard (for all tests) - 2 repeats have proven enough as there is very little deviation between reboots.
I have taken the boot time because this is easily repeatable and devhealth delivers standardized results.
Results:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
lzx delivers the smallest ROM builds but also takes longest time to boot
xpr delivers reasonable sized ROM builds and is the fastest
lzx with uncompressed code sections of modules has large ROMs (larger than xpr) and takes longer time to boot
xpr with uncompressed code sections of modules has giant ROMs (had to cut out all optional parts not impacting the procedure) and is not faster than xpr for all modules
Discussion of the results:
You may ask why that setup first? To learn about the paging pool, look also here.
The Paging Pool serves as a dedicated (limited) area of RAM where the current executed code sections of the loaded modules reside. During boot a lot of modules are loaded. While the boot process continues, the demanded use of the paging pool will intermittently exceed its size and pages (parts of the code sections) are discarded to make room for new code to be loaded to the paging pool. As the discarded pages can easily be re-read from their original location on the imgfs - this is no loss of information.
The time it takes to read a module from imgfs, decompress it (lzx, xpr or no compression) and load it to the paging pool for execution determines the total of the boot time. So if you have an unlimited paging pool or you can afford to switch off the demand paging - then your boot time is limited only by read + decompress.
If now the paging pool is smaller than the maximum sequentially loaded modules need it to be, then the discarding of pages in the paging pool will eventually require a re-load of pages for active modules from the imgfs again. The probability for this to happen will increase with a smaller paging pool, so the boot-times will rise with a smaller paging pool. This is what you see for all 4 setups.
Why is lzx imgfs slower than xpr? lzx files are smaller than xpr on imgfs, so they should be read faster from imgfs! True, but obviously the overhead of the decompression to the paging pool is taking more time over all here for my device. So lzx takes more CPU than xpr for decompression.
Why is xpr + uncompressed code sections slower than if the whole imgfs is xpr? The saved overhead of decompressing the code sections should give an advantage here! So here you see that there needs to be balance of imgfs-read performance and CPU power to decompress. For this device it seems that uncompressed larger code sections are no advantage as they take longer to read from imgfs.
Your device's results may vary, but it seems that you only need to measure for one paging pool setup to judge the different options of OS Builder.
Nice comparison. Which boot time marker did you look at?
Just the first in the summary:
<Perf Gates>
<Gate Name=Bootup>27813</Gate>
<Gate Name=Memory>33894400</Gate>
<Gate Name=Storage>13049856</Gate>
</Perf Gates>
This is the same as later:
Bootup Time Markers (Milliseconds):
Available RAM on boot = 34242560
Calupd: Exiting = 30226
Initialized appt ssupdate = 29832
Initialized msgcount ssupdate = 29764
SSUpdate: Thread now in message loop = 29231
Calupd: Starting = 28781
SSUpdate: Shell Ready = 28717
Start Menu Icons Fetched = 28687
Appman: Finished Fetching Icons = 28664
Appman: Started Fetching Icons = 27831
Home Painted = 27813
Cprog: Done Booting = 25188
Last Boot Type = 2
I intend to use that setup also to look a little deeper in the devhealth memory report later, to possibly learn about differences that other OSB options are setting to relevant memory allocation of modules - especially dealing with code that can be paged out or not.
From the MSDN/Kernel Blog articles I have read, there are also other (internal) properties of the code that determine if paging may occur or not. Usually SW production tools set the relevant flags of those automatically so you don't have to care yourself.
I am not enough expert to judge here, but from a glance at the devhealth reports I see that e.g. gwes.exe process has no pageable parts (due to OSB setting it like that?) while other processes (e.g. home.exe) do have pageable code.
I was thinking of e.g. setting rilgsm.dll on the list of modules to prevent demand paging (to have the device immediately respond to incoming calls), but I noticed in the report that it already has no pageable (p) pages listed.
To avoid urban legends I wonder if there is a way to determine or even guide which modules/files are candidates for the list of advanced operations in OSB. It could also help to indicate which are clearly not taking any benefit of those.
From what I understand, OSB has a bunch of options that deal with demand paging one or the other way:
Set Kernel Flag 0x00000001 (MSDN: Demand paging is disabled when the first bit of ROMFLAGS is set. When demand paging is disabled, a module is fully loaded into RAM before running. For OEMs that need real-time performance, turning off demand paging eliminates page faults that can cause poor performance.)
Disable demand paging list (need to find out how this is done - dump directory files are still identical to the SYS folder) - I suspect that relevant code section properties are set here. gwes.exe is internally added automatically (see your build log).
imgfs compression options (see the initial compare in the first post) with the related setting to not compress code sections in modules. It may be helpful to balance the ROM size with potential benefit here if there was option to select the modules where the code sections should stay uncompressed. As seen from below comparison it is no benefit for me - but it may for others.
paging pool size (bigger is better - if you can afford it - even set to "unlimited")
In the context of above I still think that wealthy devices with variable use (like smartphones) better profit from PP = 0 than from Kernelflag = 0x00000001 because an "endless" PP still has the potential recovery of paging out when RAM limit is reached while disabled demand paging prevents further loading of modules at all. The latter may be suitable for fixed purpose devices like navigation devices
Nice, I found this useful. I'm looking forward to your future benchmarks.
I'm wondering how much lzx does impact loading applications after the device has booted-up.
Jackos said:
I'm wondering how much lzx does impact loading applications after the device has booted-up.
Click to expand...
Click to collapse
As long as applications just have to start it does not matter much imho. For such cases I even prefer to UPX these to get even more compression than with the imgfs itself. Here just one time read+decompress has to be taken into account.
The key to the boot-time (and related other module loading and discarding pages later from the paging pool) is that this will happen repeatedly and automatically without you able to steer it.
---------- Post added at 11:37 AM ---------- Previous post was at 11:30 AM ----------
tobbbie said:
I am not enough expert to judge here, but from a glance at the devhealth reports I see that e.g. gwes.exe process has no pageable parts (due to OSB setting it like that?) while other processes (e.g. home.exe) do have pageable code.
I was thinking of e.g. setting rilgsm.dll on the list of modules to prevent demand paging (to have the device immediately respond to incoming calls), but I noticed in the report that it already has no pageable (p) pages listed.
Click to expand...
Click to collapse
I looked up the devhealth report of an old build and the gwes.exe is just the same (from first glance). So I suspect that devhealth is just depicting the current state of the device and not which pages could be paged out (or not). On first fast search I have not found resources to clarify on that yet.
You don't need to run devhealth to get the boot-time, just look at HKCU\Performance\millisecondstoidlethread.
I actually run a mortscript that records each time I reset my device, and how long it takes (there's a shortcut to it in the startup folder). This is the script, if you want to try something similar. It's kind of nice; I've had a few times where my startup time increased a lot, and I like being able to tell when it happened.
Code:
MkDir("\Performance")
If(FileExists("\Performance\bootlog.txt"))
writefile("\Performance\bootlog.txt","^NL^",True)
writefile("\Performance\bootlog.txt",RegRead("HKLM","Comm","BootCount"),True)
writefile("\Performance\bootlog.txt"," boots, booted ",True)
writefile("\Performance\bootlog.txt",FormatTime("m:d:Y:H:i:s a"),True)
writefile("\Performance\bootlog.txt",", reboot time ",True)
sleep(30000)
writefile("\Performance\bootlog.txt",RegRead("HKCU","Performance","Millisec to idle thread"),True)
else
writefile("\Performance\bootlog.txt",RegRead("HKLM","Comm","BootCount"))
writefile("\Performance\bootlog.txt"," boots, booted ",True)
writefile("\Performance\bootlog.txt",FormatTime("m:d:Y:H:i:s a"),True)
writefile("\Performance\bootlog.txt",", reboot time ",True)
sleep(30000)
writefile("\Performance\bootlog.txt",RegRead("HKCU","Performance","Millisec to idle thread"),True)
endif
If(FileExists("\Performance\ramlog.txt"))
writefile("\Performance\ramlog.txt","^NL^",True)
writefile("\Performance\ramlog.txt",RegRead("HKLM","Comm","BootCount"),True)
writefile("\Performance\ramlog.txt"," boots-reset, RAM ",True)
writefile("\Performance\ramlog.txt",FreeMemory(MB),True)
writefile("\Performance\ramlog.txt"," MB, ",True)
writefile("\Performance\ramlog.txt",FormatTime("m:d:Y:H:i:s a"),True)
else
writefile("\Performance\ramlog.txt",RegRead("HKLM","Comm","BootCount"))
writefile("\Performance\ramlog.txt"," boots-reset, RAM ",True)
writefile("\Performance\ramlog.txt",FreeMemory(MB),True)
writefile("\Performance\ramlog.txt"," MB, ",True)
writefile("\Performance\ramlog.txt",FormatTime("m:d:Y:H:i:s a"),True)
endif
This is what the output looks like (the time is milliseconds, so we're looking at~45 seconds per boot):
2 boots, booted 08:11:2011:12:24:24 pm, reboot time
3 boots, booted 09:04:2011:08:04:31 am, reboot time 49245
4 boots, booted 09:04:2011:09:18:14 am, reboot time 46642
5 boots, booted 09:04:2011:13:39:35 pm, reboot time 42994
6 boots, booted 09:12:2011:15:31:33 pm, reboot time 45625
7 boots, booted 09:12:2011:17:30:11 pm, reboot time 45564
Click to expand...
Click to collapse
Edit: Oops, I forgot, only the top part writes the boot log. The second part logs the device free ram whenever I wake it up. I just like to follow that for the hell of it. It's pretty cool to have that log when you go 24 days between soft resets, lol.
...thanks for the scripts - maybe useful as these take very little time to execute. I do a reset every night on my device - so long time RAM "loss" is easily worked around this way. Need to adjust for the keys present in my \performance path though (old WM5 Native Kernel with WM6 OS on top) - have not seen the one you read from there.
I wanted to utilize the devhealth logs later as well to compare more between different settings - this is why I had chosen devhealth to read it for me.
I noticed that some performance gates are linked to the amount of appointments or tasks. These log entries are after "Home painted". So for my compare I simply picked the devhealth selection of "Home painted" as the performance gate for bootup.
This is not the true time until you can use your device, but a good one to compare the influence of a single parameter (the PP size or the imgfs compression).
BTW: I checked if the latest XIP compression from OSB takes an influence on boot time - it does not I have only applied it as recommended to the 2 big ones in my XIP - not sure yet if I want to squeeze the remaining bytes from there.
The following post was initially done in the OSB thread, but I thought it is off topic there, so moved it here:
I read about the use of the paging pool in this blog post but in essence I thought that mostly modules code would be candidates for that memory region. Looking at the output of devhealth there are also other parts (aside modules) marked as "p" which I suspect to bei either "paged out" or "pageable" (have not found a description here).
For me the relevant question are:
Can normally loaded executables (from imgfs as files or elsewhere, e.g. storage card) be utilizing the paging pool? I guess yes - as the OS acts according to the information present in the executable's structure, just like it does for the modules. So if this is the case - what is difference then regarding the use of the paging pool if a certain dll/exe is in "module" format or as a file? Are sections' attributes in a file incarnation set differently regarding the use of paging pool?
Does a potential UPX compression of a file (exe/dll) then impact the utilization of the paging pool and later performance of the exe/dll when paging applies? In a wild speculation and linked to the analogy of imgfs decompression needed when reading LZX compressed code sections parts to be paged in again: would a upx-ed exe/dll need to be re-read and decompressed from storage in case paging of code would apply? I guess no as this would severely impact performance and I have not noticed it for my UPXed (usually BIG) files.
So I wonder if I sacrifice OS memory management flexibility when I UPX compress a large executable, like Opera, that it e.g. needs more RAM and that parts maybe page-able if not UPX-ed and not page-able when UPX-ed. My guess (and hope) is that dll/exe files do not have page-able sections that are compressed. Possibly something to discuss with the UPX-team.
Can I do any tests myself to find out? I could use e.g. Opera and load it one time as UPX-compressed file and another time as normal file. Will the devhealth memory report be suitable to compare these cases? Is the "p" in the devhealth report telling that these pages in memory are "pageable" (so could be paged out if needed) or that they are "paged out" at the time of report?
tobbbie said:
Can I do any tests myself to find out? I could use e.g. Opera and load it one time as UPX-compressed file and another time as normal file. Will the devhealth memory report be suitable to compare these cases? Is the "p" in the devhealth report telling that these pages in memory are "pageable" (so could be paged out if needed) or that they are "paged out" at the time of report?
Click to expand...
Click to collapse
...well I just tried it (using PocketPlayer from Conduits) and the differences are there - and they are as expected:
The normal exe delivers a map that has most memory parts marked either as "-: reserved" or "p-page" and the exe ends at a size of 2 882 088 bytes
The UPX-ed exe delivers a map where executable parts are marked as "E" but ending at a size of 2 775 552 bytes
Strange to notice that the devhealth dump delivers maps that are missing certain memory regions within the sequence of the report. So for the normal report the lines for 2e160000, 2e200000, 2e240000, 2e470000, 2e850000 are missing - compared to the UPX-ed. No clue what these "gaps" mean actually - probably memory that is simply not allocated to the process.
I cannot interpret any detail here, but the obvious difference is that the UPX-ed version seems to allocate the memory in a fixed way (i.e. it cannot by dynamically reclaimed by the OS), while the "normal" version seems to allocate memory in a way that allows "paging" to happen.
UPX:
plus side: no paging happens for the main executable parts - much similar to the OSB module option "exclude from demand paging".
minus side: in total more RAM is required as the whole executable size is loaded (to RAM?).
Normal:
plus side: less RAM is needed as the executable seems to utilize the paging pool
minus side: the paging pool is used, so it should be dimensioned to cope with the parallel use of all normal running applications, not just the modules from ROM.
My speculations are based on the assumption that the "p" indication of the DevHealth report is depicting the utilization of the paging pool. If so then the total number of "p" must not exceed the defined paging pool size. I have no easy way to count these "p" and skip others in the report - so now way to confirm that.
Take-home message: UPX your dll/exe if you want to exclude them from demand paging.
See attachment with the relevant excerpts from the DevHealth reports.
tobbbie, too long way to disable paging for selected exe. You just have to set "unpageable" flag on all sections using apps like LordPE.
ultrashot said:
tobbbie, too long way to disable paging for selected exe. You just have to set "unpageable" flag on all sections using apps like LordPE.
Click to expand...
Click to collapse
Well - for the pro's that only want to have demand paging disabled your suggested way to hack the exe/dll is viable as well. The UPX method has a positive side effect however - the main purpose of UPX is to make the exe/dll smaller - and it does it very well. So you have smaller footprint, faster load time and exclusive RAM with just one activity - and this can be done by anyone, without hacking!
The real downside for those with tight memory (like myself) is that such exclusive memory allocation eats much more precious RAM than if you have the exe/dll allow their code to be paged. So you have to balance the snappy application behavior (UPX) with the number of concurrent running applications demanding memory.
For my part (small RAM) I have taken the following conclusions:
Free RAM is not the goal to optimize for. A small paging pool makes free RAM grow, but it limits the amount of paged-in parts of concurrent running programs.
UPX.ing dll/exe is only useful in case you have plenty of RAM to always keep the whole code in (virtual) memory. So if you have LARGE programs (like my example Pocket Player or Opera) it is advisable NOT to UPX them, despite their storage footprint will be larger. Get these programs on the memory card instead and accept longer loading times. Their RAM footprint will be lower as the OS loads the code to the paging pool (not normal RAM) and it can discard non accessed code parts from the paging pool and reload them from the file again if needed.
Optimize the size of the paging pool to the usually running concurrent programs. This does not mean to minimize the paging pool so that you can still somehow "use" your device, but find a balance for the case that all your concurrent applications are loaded. Mind that any UPX-ed programs (or such marked to be excluded from demand paging) do not count here on the paging pool as their code is put elsewhere! So make sure first that your programs are loaded from a non UPX-format file.
Sigh - all my efforts to get the smallest ROM footprint were done in vain as the price paid is simply the amount of RAM used when such exe/dll are loaded. I need to re-think many optimizations and do a better balancing of ROM size with RAM use.
It is really worth to note that all normal loaded applications have their CODE part loaded to the paging pool, while their other demand for memory (data, heap) is put to other virtual memory. The OS demand paging utilizes this limited amount of RAM (real RAM, not just virtual memory) in an optimal way for the concurrent running programs. So while these execute (and the instruction pointer passes along the memory pages reading the code for execution) the pages have to be in RAM. The overall minimal RAM use (without paging activity) is thus defined by the active code-traces along the memory pages only. All code that is NOT accessed when the programs run can be on discarded pages (so they occupy no RAM).
Now for a mysterious part (to me): The allocations of memory are done for "virtual memory". As you know, each process has 32MB of contiguous virtual memory in its assigned slot - but how does that map to used RAM? So how can I tell how much of precious real RAM is utilized for a certain process? I guess the RAM use for the paging pool is easy understood and also visible in the devhealth report (the "p" - if my assumptions are true), but what about RAM outside the paging pool? Is it just that any part marked in the devhealth report (except the "-" for reserved, as I would count this for discarded code pages) is mapping virtual memory to real RAM 1:1 - so the advantage for the application is just the contiguous address space which in reality may be put on RAM pages that are located anywhere in real RAM address space. From other OS you may remember that there are "paging files" which could also be utilized for mapping virtual memory - but this is not present in WinCE - so is it just 1:1 VM allocation to RAM allocation?
I remember reading that modules loaded from several processes are not loaded several times in the relevant process slot but just referenced from all the processes to their slot1 - so what about the applications data in their slot?
I would really like to learn more about the DevHealth report meaning for the various symbols used when drawing the virtual memory maps. Any hints for me to MSDN or other sources?
I remember reading that modules loaded from several processes are not loaded several times in the relevant process slot but just referenced from all the processes to their slot1 - so what about the applications data in their slot?
Click to expand...
Click to collapse
All module sections except r/w occupy only one space in VM (higher slots on 6.5 kernel, slots 1/0 for older kernels). R/W section is copied to every process using this dll (if that r/w section isn't shareable), but, unfortunately, every process NOT using it will still have this memory reserved.
btw, if you want to read some more interesting reading, here is a nice link
ultrashot said:
All module sections except r/w occupy only one space in VM (higher slots on 6.5 kernel, slots 1/0 for older kernels). R/W section is copied to every process using this dll (if that r/w section isn't shareable), but, unfortunately, every process NOT using it will still have this memory reserved.
Click to expand...
Click to collapse
...well but reserved pages eat no real RAM. It just keeps the process from allocating contiguous memory where the reserved pages are located in VM. As the dlls go top-down and the process bottom up - they have 32MB of VM in the middle. A very nice tool to see this visualized is here: http://www.codeproject.com/KB/windows/VirtualMemory.aspx The "source code" link at the top of the article also contains compiled versions - otherwise I could not have used it.
ultrashot said:
btw, if you want to read some more interesting reading, here is a nice link
Click to expand...
Click to collapse
...oops - looks like a source rip of an old wiki of 2007 - quite hard to get something from it. I found however what I needed on DevHealth here:
https://evnet.svn.codeplex.com/svn/C9Classic/WebSite/Wiki/WikiBases/CEDeveloper/BSPVMDevHealth.wiki
tobbbie said:
...well but reserved pages eat no real RAM.
Click to expand...
Click to collapse
exactly.
10 char
ultrashot said:
exactly.
10 char
Click to expand...
Click to collapse
instead of 4k page size, or?
Ultrashot, if you feel bored sometime you could further give insight to the VM use of a running device's memory snapshot with your devhealthanalyzer tool. The following could as well be discussed in the linked thread of yours if you prefer that. For me it is still linked to the paging pool mainly - so I have it here for a start.
I guess the sum of all "p" give the currently committed pages from the paging pool and so you can see the current percentage of paging pool utilization (as you know the total size from the header of the report. Usually this should be 100% (or close) but if you have huge paging pools it may be less.
I noticed that the devhealth output already reports on the pages utilized per module and process - even giving totals for the system. The use for a 5MB paging pool (1285 pages) is 1267 pages, so 98.6% for a sample I took.
Now the problem is to put that utilization in ratio to the potential demand. You could tell this by comparing the total code size of all loaded exe/dll with the given paging pool how the ratio is between these two.
Evaluating even per loaded exe/dll the ratio of "total code / loaded code to paging pool" could tell how much RAM you would loose/gain if you decide for excluding that from demand paging.
Furthermore the ratio of code (utilizing the paging pool) and other data (stack, heap) eating remaining memory may give advice on the recommended ratio of paging-pool to RAM for a given devhealth snapshot. I think that on average this ratio should be a guide for dimensioning the paging pool - like "reserve 20% or your available RAM for the paging pool".
I don't know which pages from the report should be put in relation to estimate on the above. I had guessed the ratio of "- reserved" to "p" could do it, but the reserved pages are also listed outside the areas which I would attribute to potential paging pool use.
Would not the following be a way to guide a potential finding?
I can grow the paging pool as long as no other memory demand would be limited for my use-case. I know that some applications (video playback, web browsing) have dynamic needs for RAM, but that would be visible in the snapshot taken with devhealth. For an honest report you must not use any memory cleanup tools before taking the snapshot, obviously.
Growing the paging pool beyond the size that all loaded code needs makes no sense and is wasting RAM for a pool that is not exploited.
Shrinking the paging pool to sizes where even the OS (and fancy UI for newer devices) fight for allocated RAM in the paging pool on their own behalf is the lower limit and makes no sense either.
My fault was to assume that you should go as small as possible - but what does it help to have a small paging pool which makes your device slow due to a lot of OS demand paging activity if you still have RAM available that your loaded processes do not utilize for heap and data?!
There are several means to manipulate memory use (mark R/W sections as shared) and avoid the paging pool use (kernel flags, paging pool size = "0", exclude from demand paging - via section flags or simply UPX). I think that only a tool based evaluation of the devhealth output allows to discuss the consequences. Side-by-side compare of different devhealth reports are hard to get insight from - at least for non-pros like myself.
Your module report already gives something but I wonder what conclusion to take from what you list there (module - in use - size - pageable[Y,N,Partly]). Not that much detail as I would need to answer the questions raised further up.