We listen many times about ROM & RAM but what is the difference between those two words ?
There are a big different between ROM & RAM
ROM stands for "Read-Only Memory", it is a type of built-in memory which be used in computers, Mobiles and other electronic devices and as its name indicates, it is used only for reading data from it, You can not write to it or change it. The manufacturers use it to store devices data.
RAM stands for "Random Access Memory", it is opposite of ROM as it is used for reading and writing so this memory is available for operating systems, programs and processes to use when the computers is running.
That was a brief about the difference between ROM & RAM. I hope it was useful and you can learn more information about this by searching for "ROM & RAM" on Google :good:
Difference Between RAM and ROM
RAMROMRAM is volatile memory, which could store data as long as power is supplied.ROM is a nonvolatile memory, which could store data permanently.RAM is read-write memory, data can be retrieved and altered.ROM is read-only memory, data can be read-only, we cannot alter the data.RAM is faster in speedROM is slower in speedRAM is expensiveROM is cheaper than RAMThe CPU can access data stored in RAMThe CPU can not access the data stored in ROM unless data is stored in RAMRAM is used as cache memory in the computerROM is used as firmware by microcontrollersRAM consists of four components which are memory matrix, address decoder, input buffer, and output bufferROM consists of two components which are Decoder and OR gates
Read this article to learn the difference between RAM and ROM.
RAM is Random Access Memory, it's fast temporary storage, used by applications and the operation system. ROM is Read Only Memory, the EEPROM chip, Electronically Erasable Programmable Read Only Memory, the BIOS, basic input and output system, is stored on it, the control panel that has the drivers used to communicate with all hardware firmwares, gets signals from them, and sets certain variables, based on the customization stored on the CMOS Battery and the signals being watched for, some flash a different BIOS on the EEPROM chip in order to enable and disable settings to allow for a having a virtual layers, allowing for virtual drivers/kexts and hardware spoofing, in order to install Mac OS on PC hardware, it'd be called a Hackintosh. However, in Android terms, the ROM is the operating system image, like Windows has an ISO file، developers have it customized to add and remove apps and features on the on the stock OS image. I hope this was helpful
Related
Hi, is there a way to adjust the memory usage for the program, like adjust the storage and give it to program. Not like xda, the prophet does have a slider for the memory but could not be adjusted. Is there anyway how to go over this ?
Prophet, as well as many new WM5 devices have (physically) separate program and storage memories. And thus there is no built in way to adjust the amounts of the two.
The Prophet has a 64MB Ram and a 128MB Flash Size with a storage size of 42.55. Where did the 44.01 MB program came from? Is there a way to increase the MB size for the program? Because I believe that even though you can install several program using the storage, a portion of the program memory gets filled up until at the critical level, which will later play an important part once you start running a program which needs a higher memory. Any remedy to this?
The 64MB RAM is what I think should be called 'box figure'. It's what's printed on the box.
In reality you get 50+ actual RAM at leas 10 of which go to various OS functions and the rest is left for running programs to use.
Under WM5 non of it is used for files, but when you run programs, even built-in ones there are sometimes memory leaks which means that even though you closed the program some of the memory (sometimes more them 1MB) remains occupied.
The only known way to fully reclaim memory is to soft reset the device. I do it on my Jamin once a week when I am left with 12-10MB free.
Unfortunately, there is no way to add RAM to device.
Forgive my stupidity, but I was wondering why the forum is not abreast with talk about using internet virtual storage in WM6, thereby giving near limitless storage for data, films, music, video, tomtom maps etc.
I realise there will be access speed limitations, but apart from media I would not have thought that would be a problem.
If this has all been achieved already, then can any of you users make any recommendations?
Thanks.
Do you mean just for storing files, or more than that, such as having files associated with programs or executables and relating *.EXEs on the device with associated files (*.dll, *.sys etc.) online?. This would sound very complicated to me. Maybe possible with full blown Windows on a Desktop or Laptop ( I don't know how realistic this idea is, or whether it's out there already somewhere).
For file storage, I can't see a problem. Access would be considerably slower than a Windows PC for example due to the system and OS. This is obvious. But it would certainly be possible to "host" your files online. Personally I would make sure I'm using a very well known web based file storage service with the best reliability and a flawless wi-fi connection or unlimited data plan for it to be completely viable.
Personally, I've never had a WM device that holds a good wi-fi connection, but that's for another thread!
Apologies if I've misunderstood what your asking and barking up the wrong tree!!!
My idea was mainly a virtual storage for files.
However, we are all wishing for SD access. SD cards can have various performance characteristics. Slow SD memory doesnt fail - the computer simply waits until the data is loaded. As a further example, remember the floppy disk drive? That was slow, but we could use it for file storage such as tomtom maps without the slow access causing system problems.
So the idea I envisage is a virtual external drive. (I.e not virtual CPU memory).
The concept seems sound to me. And if people here can achive liberation, gps access, and phone access on the Shift, I would have thought virtual storage would be within the ability of these talanted people.
I would love someone to get tomtom working on such a virtual storage drive.
I should know this by now , but I dont.
512 rom leaves us with roughly 190mb for App storage depending on cache correct ?
What about free memory in task killer Showing only 66mb free. With only a few apps running. Is the new OS that heavy ?
KOF33 said:
I should know this by now , but I dont.
512 rom leaves us with roughly 190mb for App storage depending on cache correct ?
What about free memory in task killer Showing only 66mb free. With only a few apps running. Is the new OS that heavy ?
Click to expand...
Click to collapse
Android isn't like Windows. It maximizes the use of whatever memory you have. It's very rare that you'll ever see a lot of free memory (I never have on the G1, even after a reboot). The reason why, is that Android keeps the apps in memory until it starts to run out of room, then frees up memory as needed. This also makes it much faster if you end up opening up an app that's already in memory. In short, don't worry... 66mb free is a good thing.
Actually, the current firmware does not support the full 512Mb. It only supports about 200Mb.
A future kernel update will allow access to more of this (also, radio/screen/etc take some of the physical memory).
bbsydney said:
Actually, the current firmware does not support the full 512Mb. It only supports about 200Mb.
A future kernel update will allow access to more of this (also, radio/screen/etc take some of the physical memory).
Click to expand...
Click to collapse
Can you link to where you got this information?
Roughly 220MB is available to userspace in the shipping build (ERD79).
Quite a lot of memory is dedicated to the radio firmware (41MB), dsp firmware (32MB), display surfaces (32MB), gpu (3MB), camera (8MB), a/v buffers (41MB), and dsp buffers. Much of this needs to be set aside for these specific tasks due to hardware requirements of very large physically contiguous buffers which can be difficult or impossible to obtain after boot once the physical memory space gets fragmented.
The big limitation though is that the Linux kernel needs to do a 1:1 physical:virtual map of general purpose memory used by the kernel and userspace (which excludes the special purpose stuff described above). This eats into the available kernel virtual address space, which is also needed for cross process shared memory used by the binder, etc. Run out of virtual memory and things get unhappy.
In 2.6.32, HIGHMEM support for ARM will allow us to avoid this requirement for a 1:1 mapping which will allow us to increase memory available to userspace without running the system out of virtual memory adddress space.
swetland said:
Roughly 220MB is available to userspace in the shipping build (ERD79).
Quite a lot of memory is dedicated to the radio firmware (41MB), dsp firmware (32MB), display surfaces (32MB), gpu (3MB), camera (8MB), a/v buffers (41MB), and dsp buffers.
Click to expand...
Click to collapse
Thats like 200mb already. What about older phones with only 192mb and 256mb of ram?
I assume older phones will use less ram in the radio firmware and dsp firmware. So why does the N1 require so much more in the radio firmware and dsp firmware etc..?
The radio firmware is also 41MB on all previous devices.
The QSD8250 uses a new DSP which requires an additional 32MB (the 7k devices do not have this requirement). Due to the display having ~2.5x the pixels, window bitmaps are larger and that region grew from 16MB to 32MB to compensate. 720p h264 decode with the new DSP requires quite a lot of memory (41MB worst case, thus the a/v buffer size).
THANK YOU for the clear explanation. So, a later kernel/ROM release should make the unit even "faster" (that is, able to use more RAM and possibly have more things cached), correct? If so, that's sweet.
Sorry if these are DUH questions, but while I've been working with computers since the mid 80's, I'm fairly new to the smart phone game and unfamiliar with the way they work internally.
Is the RAM on these phones a physical chip (like a PC) or is it a software defined allocation (virtual)?
Also, and more importantly, if it is software defined, is it possible to allocate more of the phones internal storage memory to RAM?
I've noticed that while I'm only using about 7% of the internal storage, RAM is typically running at about 80% used.
The device is rooted, running 2.3.2 and currently running the stock VZW rom.
Any insight on this would be appreciated.
Thanks!
I imagine android uses virtual addressing instead of physical addressing but I'm not sure.
I CAN tell you, though, that android (specifcally the dalvik vm) is designed to keep things in memory instead of freeing it to reduce load times, etc. If it starts to run out of memory it unloads things, probably on a LRU basis.
I see. So then the amount of available RAM really doesn't matter as it works more like cache?
It's not really much different in windows... if your usage is under certain limits, very little will be paged out. 99% mem in use is fine in windows. 101% is not.
I guess the main difference is that closing an app is not as integral to android as it is to windows, so those of us who are accustomed to closing apps to save memory feel a bit odd.
Sent from my DROID2 using XDA App
True, but a windows system with twice the memory of another, will usually run better. Which is what prompted me to ask this question to begin with. I figured if there was a way to re-appropriate some of the unused portion of the storage area to the frequently used area of RAM, it would make the system run faster and smoother. I just don't know if it's possible or if it even makes a difference with the Android/Linux OS.
You may have noticed the ~1 GB cache partition on 3rd gen HDX devices that was used as temporary work space for chunky FireOS OTA updates. Typically <5% is used by Android which leaves a sizable block of space completely wasted. While it is possible to adjust partition boundaries to to expand either the System or Data partition that task is not for the faint of heart on an Android based device.
One option is to utilize a portion of the Cache partition for eMMC backed swap, especially since the stock kernel does not support zRAM. This can be attractive for those who run large or numerous apps that consume the 1.8 GB of available RAM. While Android's LMK will typically prevent OOM (out-of-memory) conditions under heavy pressure the constant recreation/reloading of killed activities can be annoying.
It is pretty easy to create a swap file in the Cache partition with an app like App2SD (just an example; not an endorsement). Suggest starting with 128 or 256 MB. You may want to crank down the swappiness value (default on most ROMs is 60) to limit write activity to eMMC which has a finite lifespan. Tuning LMK is also part of the game; lots of apps can handle that including the fan favorite L Speed or any of the popular Kernel Manager apps (EK Kernel Manager, Kernel Adiutor, etc).
eMMC backed swap has its pros and cons. While experimenting won't hurt you'll probably want to do a little research before making swap a permanent part of your config.
Enjoy!
edit: A tool like DiskInfo can help illuminate how partitions are allocated/utilized on your device.
FWIW - the following values returned acceptable results for my typical usage scenario:
- LMK thresholds (in MB): 16/32/48/64/80/96
- swappiness: 40
- vfs cache pressure: 70
Edit 04/18: Over time I have stopped twiddling with most VM parameters (accepting default values) as there was not a sustained, meaningful difference in performance to justify maintaining custom settings. However, I have found increasing the LMK "empty app" threshold provides a noticeable increase in response time with light to moderate multi-tasking. New LMK settings as follows:
LMK thresholds (in MB): 16/24/32/48/64/128.
I have found these values work well on most devices equipped with ~2 GB of RAM. In fact setting appropriate LMK values can all but eliminate the benefits of file based swap on this device. Obviously YMMV.
Quick follow-up: The config outlined in the OP remains on my daily driver and continues to enhance the overall enjoyment of this device. Over time I refined a few tunings for my workflow. Difference are subtle but yield better resource utilization. YMMV.
- swappiness: reduced to 20 to further discourage cache file writes
- VFS cache pressure: restored device default (100)
Davey126 said:
Quick follow-up: The config outlined in the OP remains on my daily driver and continues to enhance the overall enjoyment of this device. Over time I refined a few tunings for my workflow. Difference are subtle but yield better resource utilization. YMMV.
- swappiness: reduced to 20 to further discourage cache file writes
- VFS cache pressure: restored device default (100)
Click to expand...
Click to collapse
Hello Dave, I've follow your posts and managed to get 256MB for swap space but used only about 50KB. Is it work or not? How to check does a swap helps a system as android?
BR!
iksel said:
Hello Dave, I've follow your posts and managed to get 256MB for swap space but used only about 50KB. Is it work or not? How to check does a swap helps a system as android?
BR!
Click to expand...
Click to collapse
Likely working...give it time. You will see swap file utilization slowly creep up but will likely remain at a small fraction of the available space. Note: the swap file is reset (flushed) on reboot.
Setting swappiness to 20 discourages the use of the swap file except under high memory pressure. In most cases that is what you want as RAM is several magnitudes faster than eMMC. The benefit kicks in under high memory loads:
- older content in the memory cache can be (quickly) written out to the swap file freeing up RAM for current demands
- context of loaded but less frequently accessed apps is likely to be fully/partially retained avoiding a complete restart
Bumping swappiness to 40 or higher will increase swap file utilization and also change the composition of swapped contents. The default on many devices, especially on low RAM configs and/or those with zRAM, is 100. That aggressive setting will likely hurt overall performance on a 2GB device with no zRAM support (like the HDX).
Keep in mind the swap file resides in an area of permanent storage that goes largely unused on a HDX fitted with a custom ROM (FireOS uses this area for processing OTA updates). If that file were taking space away from the data partition this tweak would be of questionable value.
Davey126 said:
Likely working...give it time. You will see swap file utilization slowly creep up but will likely remain at a small fraction of the available space. Note: the swap file is reset (flushed) on reboot.
Setting swappiness to 20 discourages the use of the swap file except under high memory pressure. In most cases that is what you want as RAM is several magnitudes faster than eMMC. The benefit kicks in under high memory loads:
- older content in the memory cache can be (quickly) written out to the swap file freeing up RAM for current demands
- context of loaded but less frequently accessed apps is likely to be fully/partially retained avoiding a complete restart
Bumping swappiness to 40 or higher will increase swap file utilization and also change the composition of swapped contents. The default on many devices, especially on low RAM configs and/or those with zRAM, is 100. That aggressive setting will likely hurt overall performance on a 2GB device with no zRAM support (like the HDX).
Keep in mind the swap file resides in an area of permanent storage that goes largely unused on a HDX fitted with a custom ROM (FireOS uses this area for processing OTA updates). If that file were taking space away from the data partition this tweak would be of questionable value.
Click to expand...
Click to collapse
Good to know, thanks again!
Davey126 said:
Quick follow-up: The config outlined in the OP remains on my daily driver and continues to enhance the overall enjoyment of this device. Over time I refined a few tunings for my workflow. Difference are subtle but yield better resource utilization. YMMV.
- swappiness: reduced to 20 to further discourage cache file writes
- VFS cache pressure: restored device default (100)
Click to expand...
Click to collapse
Yet another update. After making modest tweaks to dirty/dirty background ratios I noticed a subtle increase in momentary (<1 sec) lag switching between previously loaded apps. Such behavior is symptomatic of increased memory cache pressure and potentially unnecessary swapping and/or LMK activity. Flushing the cache cured that (for awhile) but is clearly not the ideal solution. Ultimately bumping swappiness to 40 addressed the problem. Guessing the previous value (20) allowed stale application pages to remain in memory a bit too long increasing cache pressure which became evident when actively multitasking.
Bumping this thread as reminder/reinforcement of the beneficial effects for some workflows. In short, a small static swap file significantly improves the multitasking UX if returning to previous app context is important. Newer devices leverage zRAM for this purpose; HDX kernel doesn't support that.
Over time I have gravitated back to defaults for swappiness, dirty timeouts, cache pressure, etc as custom values did not yield significant measurable (or subjective) improvement to warrant changing. Less knobs to turn/tweak which is always good thing in my book!
This is what I usually do - just resize and move the extra space to userdata partition. If only the days of roms that are installed by simply extracting the files on to system partition still continues, we could get some space of the system partition out too :silly:
pipyakas said:
This is what I usually do - just resize and move the extra space to userdata partition. If only the days of roms that are installed by simply extracting the files on to system partition still continues, we could get some space of the system partition out too :silly:
Click to expand...
Click to collapse
Yep - done that too on some devices. Resizing partitions is not for the faint of heart which is why I opted to excluded it from the guide.
I had kown how deal with it ,we can rest our disk partition to make it change to data
I had kown how deal with it ,we can rest our disk partition to make it change to data or system to use!!!
Davey126 said:
Yep - done that too on some devices. Resizing partitions is not for the faint of heart which is why I opted to excluded it from the guide.
Click to expand...
Click to collapse
Why not provide that info? It is no different than flashing custom roms. You are warned by the devs that doing so brings a risk of bricking your device...proceed at your own risk.
I think it would be valuable to those that want to use that wasted space or optimize the use of the storage space available.
Hopefully you will reconsider.
droiduzr2 said:
Why not provide that info? It is no different than flashing custom roms.
Click to expand...
Click to collapse
lol - not comparable, at least with the vast majority of mobile devices that I have been exposed to. Including this one. Those who wish to muck with resizing Android partitions will find copious detail on the net...usually from those who have spent 100X the initial resizng effort trying to recover their device. Because, ya know, it is no different than flashing custom ROMs.
Davey126 said:
lol - not comparable, at least with the vast majority of mobile devices that I have been exposed to. Including this one. Those who wish to muck with resizing Android partitions will find copious detail on the net...usually from those who have spent 100X the initial resizng effort trying to recover their device. Because, ya know, it is no different than flashing custom ROMs.
Click to expand...
Click to collapse
I am pretty sure everyone on here that goes to flash a rom (change from stock) read the disclaimer and assume the risk that they can brick their device. If there were a tool or clear directions to optimize the use of storage space considering we are stuck with 16gb (no usb otg support, no external sd card) then being able to use every Mb much less Gb seems to be a helpful thing imo.
Also it's not about mucking around with just any Android device, it's about this specific device and what one would have to do.
If you are saying it is not an easy task then so be it.