Feature Request : Support of Dynamic Cache Size for RAM.

eBoostr Beta Program Forum » Suggestions

Feature Request : Support of Dynamic Cache Size for RAM.

(13 posts) (5 voices)

Started 2 years ago by Rajiv
Latest reply from mradr

Tags:

No tags yet.

Rajiv
Member

I am using ebooster 4 beta for a few days and do find it useful. However I would like to make a suggestion.

Currently ebooster supports only a fixed cache size for RAM. If I allocate 1 GB on a 2 GB system it will be fixed at 1 GB without giving any importance to free physical memory available on my system. I would like to suggest to have some kind of dynamic cache option so that ebooster automatically allocate memory based on free physical memory. For e.g.. in the above system it may allocates 1.25 GB on boot if 1.5 GB of free physical memory is available. It should reduce the cache size if free physical memory drops below a certain threshold for the above e.g.. we can make it 256 MB. Similarly it can increase the cache size again if more physical memory gets available subsequently.

This way one can get the benefit of big cache size when enough free physical memory is available and still be able to recover RAM as and when needed by the system and this could prevent slowdown due to shortage of RAM.

Thanks,
Rajiv

Posted 2 years ago #
medeni73
Beta Veteran

+1

Posted 2 years ago #
mradr
Member

I do too, but I find theres a problem when doing that. From what I know about how the files are setup in eboostr, this would make you "rebuild" the cache everytime it needed to change size sadly. Also, eboostr would have to sorta preknow if your about to open something up that took alot of ram or space.. Other wise you would still get that notice "Out of memory, please add more to your pagefiles." Why? The system will try and hurry up and fill the ram as fast as it can befor it relizes it out of memory... or as far as I know anyways...

Posted 2 years ago #
Rajiv
Member

mradr wrote:
I do too, but I find theres a problem when doing that. From what I know about how the files are setup in eboostr, this would make you "rebuild" the cache everytime it needed to change size sadly. Also, eboostr would have to sorta preknow if your about to open something up that took alot of ram or space.. Other wise you would still get that notice "Out of memory, please add more to your pagefiles." Why? The system will try and hurry up and fill the ram as fast as it can befor it relizes it out of memory... or as far as I know anyways...

I think it can be easily archived. A copy of cache is already made on the system drive. So the application can build this cache to the maximum possible size allowed by the RAM once. Then while windows load it should load the most important contents to the RAM. (Maybe 512 MB on a 2 GB system). After completion of boot it can adjust the RAM dynamically. I think checking the available RAM periodically should not be a problem as we already have tons of application which monitor physical RAM in real time. To prevent Windows from running out of RAM I have specifically recommended to keep some RAM free. (256 MB in my above e.g.), and as soon as it goes below this level. eBooster can release RAM to get to a minimum free level of RAM.

Thanks,
Rajiv.

Posted 2 years ago #
mradr
Member

So your saying eboostr should make a few copys of the cache and load and unload them as needed?
Aka
3 GB ram system
1. a Max- user define (say 512mb) - low memory use
2. half of that user define (256mb) - middle memory use
3. then another half for when the user really needs it.. (128mb) - high memory use

Would this not slow it down tho cause it has to unload one and reload another?

They do have programs that check periodically the ram size, but does not do anything other then just report and usally is lag by a few millsec (or smaller). Like I said befor, the OS will fill the ram befor it even knows that its full, so checking alone will not help 100%. Would need some way of knowing befor hand to unload the cache and put in a new smaller one to fix the needs.

One way I think would work, is have the page system of the computer to act like a sorta warning system that the computer had to use some of its VPage to make room, then eboostr can know to make less room for its cache size and make windows put the files that were just VPage back into ram.

Posted 2 years ago #
pro-logic
Member

It would actually be easier then what you are talking about.

EB would need to have to store a mapping of most popular files and file size. When it detects that ram is running low, even say a 20MB threshold, it will start delelting the files at the bottom of the priority list, untill enough ram is freed.

From a conceptual point of view its not hard, say you open an application, EB will just need to trim X MB of ram, so it will start removing the least used application in the ram until it removes X MB or more. This way it will be far more fluid.

When EB detects that that ram is free, it will reload just those files.

Posted 2 years ago #
Rajiv
Member

mradr wrote:
So your saying eboostr should make a few copys of the cache and load and unload them as needed?
Aka
3 GB ram system
1. a Max- user define (say 512mb) - low memory use
2. half of that user define (256mb) - middle memory use
3. then another half for when the user really needs it.. (128mb) - high memory use

Would this not slow it down tho cause it has to unload one and reload another?

They do have programs that check periodically the ram size, but does not do anything other then just report and usally is lag by a few millsec (or smaller). Like I said befor, the OS will fill the ram befor it even knows that its full, so checking alone will not help 100%. Would need some way of knowing befor hand to unload the cache and put in a new smaller one to fix the needs.

One way I think would work, is have the page system of the computer to act like a sorta warning system that the computer had to use some of its VPage to make room, then eboostr can know to make less room for its cache size and make windows put the files that were just VPage back into ram.

Your point No. 1.
No I am not saying that EB should make copies of different cache sizes, I am saying that it should make a single large cache based on the available RAM. That is 1.5 GB for a 2 GB system. I don't think that there will be more physical memory free then this in normal circumstances. Then it should load the contents of this cache files partially based on free available RAM based on the priority of the cache. High priority cache contents first.

Your point No. 2.
You are right there are programs that checks RAM periodically and do nothing, (Except doing what they are supposed to do, that is to inform the user about RAM status through alerts etc.). I also didn't ask EB developers to use any of these programs it was just to show that it is possible to get RAM details from the system in real time. If EB developers can make a program like EB which works in real time feeding data to the system from where the system is not expecting it, I think they are smart enough to be able to implement free RAM checking. Secondly, when I boot my 2 GB system why will my system fill up the entire RAM. I just cannot understand that point. My loaded XP systems fills up just 800 MB and Windows 7 Ultimate RC fills up just 1050 MB. So I fail to understand why my system will fill it up completely. However if the system do fill up the RAM completely then what is the point of using RAM cache I think than Flash Cache would be a better option.

Thanks,
Rajiv

Posted 2 years ago #
mradr
Member

KK, i'll try and break it down for you all best I can...

pro-logic:
"Currently" EB can't just start taking data out to make it smaller. Why you may ask? EB had made a "drive" or a spical file to put its data into. This file is always "filled" even if data is not inside. The only way to make this file smaller (it can make it bigger with out having to change much) is to go in and delete and make a new one. This adds time for it to rebuild it back into ram.

Rajiv:
Now, I was thinking about it more... Eboostr could do this in steps.... Make the file read in steps so that you can strip or add the different proity levels as an add on to the main file, so that way you can make the file smaller or bigger at will. Downside to this is... unless it autoly saw how big the different level were... it would use more ram then the current way--I think.

Current way ... or as far as I know how it works...
[] = Main Folder or the user set size aka say 512
^size of the block^ = The sub folders in that file

[^140^,^40^,^300^,^32^] = 512

The new way... or as far as I know how it could work... useing the same marks...
[140],[40],[300],[32] = 512

This shows how it could be broken down into their own file but still inside the limit given to EB by the user. The frist being the highest prop and the last being the rest or the lowest prop. Then when Eboostr gets the waring from a set vaule in ram (aka why your ram moniters will work here) and can start striping the lower props just leaving the higher level ones or when the page system is being used cause of ram being filled to fast (or aka my frist idea will work).

**Note: this is how it will have to work to get your ideas/thinking of it to work.

Rajiv:
Not saying they have to use a 3rd party either. Your just talking about start up, i'm talking about use. Aka, (with a 3GB system) your computer start up uses around 800MB, website add another 100, and you have 512 cach for EB (or around 1.5GB). Now, your friend wants to see a game, but you didn't close your websites out and your game takes about 1.5GBs, but some where in the game you had to load something, aka a map, this processes takes another 400 mb... will you know what... its out of memory and the error is thown that it is. During that map load processes it suck the last MB of memory left and the system didn't have time to know it was... unless you use the pagefile system.

Actully I do think USB is better for start up then ram is.... Cause you would have to take some time off the HDD during start up to even move that file back into ram. While if its on a USB, its all ready there ready to go during boot. Down side is, USB have a limit read while RAM is as fast as your system, so once you get that data into ram, it'll make up for that lost few sec during boot. MB at maxs only have 1-3 USB controllers, so your only looking at a speed rate of 30-90 mb, alot slower then ram is, but I have a feeling theres a "hot spot" for that read speed in witch it will be better to use a flash speed vs having to load things into ram then read from the ram during boot.

Posted 2 years ago #
Rajiv
Member

mradr, I have suggested a feature to the developers. Now if it could have been done without any modification of the internal working mechanism of EB it probably had been implemented till now. So I believe this feature will need some work at the developers end. I think they are the only one who can make us aware of the complexity of the work involved.

Secondly as per your e.g. a 3 GB system boots up it uses 800 MB of RAM. Now as per my suggestion EB should make a cache of 3096 MB - 800 MB - 256 MB = 2046 MB. (Total RAM - used by system on Boot - RAM that should be left free on purpose by EB = RAM available to EB for caching) now I surf website add another 100 to used RAM and EB should release 100 MB making cache size 1946 MB. Now, my friend wants to see a game, but I didn't close my websites out and my game takes about 1.5 GB, here EB should further release 1536 MB making the cache size 410 MB the some where in the game I had to load something, aka a map, this processes takes another 400 MB. then EB should release another 400 MB making the cache size just 10 MB. Now you see I got the benefit of caching when there was enough RAM and at the same time got enough RAM when I wanted it. If more RAM is required the system can still go out of memory even if there was no EB on my system.

Please note 256 MB of buffer is being used specifically to give EB some time to take action before RAM fills up.

I think the above makes my point clear.

Thanks,
Rajiv

Posted 2 years ago #
mradr
Member

mradr, I have suggested a feature to the developers. Now if it could have been done without any modification of the internal working mechanism of EB it probably had been implemented till now. So I believe this feature will need some work at the developers end. I think they are the only one who can make us aware of the complexity of the work involved.

I'm a programming in my off time, so I know the proccess it takes to add or take away from your program. I find it nicer if the user thats asking for something would also break it down to how it would work into making it better (or a real world way of doing that). I never said either that I knew everything how eboostr work, but I have a good educated guess on how it works and why the eboostr program works the way it works...

You still don't get it tho... Theres no time in between larg call request to fill the ram for Eboostr to move or take away from its cache sizes. While the small cache sizes don't fill the ram up during load, giving ebsootr time to take away aka your 256MB buffer. The game called for 1.5Gb, way more then your 256 buffer could handel in witch you would get the "Out of memeory" or OFM message. Thats why I said you must have a pagesystem setup so that EB can cache that and make its cache smaller to have it make room in the ram. (aka i'm using your idea and making it into a real world way of doing it...) Also remember... we're working with windows... not the other way around sadly...

Posted 2 years ago #
Rajiv
Member

mradr:
Firstly I never said or suggested turning off paging. Secondly I have already mentioned that if EB developers were able to make a programme that redirect calls to Cache device instead of HDD, cant they be able to hook/intercept calls for RAM allocation to the system.

Thanks,
Rajiv.

Posted 2 years ago #
chooky
Beta Veteran

Guys its pretty pointless arguing about theories of what eBoostr may or may not be able to made to do.

Posted 2 years ago #
mradr
Member

chooky wrote:
Guys its pretty pointless arguing about theories of what eBoostr may or may not be able to made to do.

No one was arguring as far as I know o.o? I was just talking and passing information along to help maybe get something down to the point were we could use it and where EB could understand...

If it sounds like I was arguring, I'm sorry, I wasn't trying to argu...

Rajiv wrote:
mradr:
Firstly I never said or suggested turning off paging. Secondly I have already mentioned that if EB developers were able to make a programme that redirect calls to Cache device instead of HDD, cant they be able to hook/intercept calls for RAM allocation to the system.

Thanks,
Rajiv.

Sorry if it sounds like i'm "doging" on you, I wasn't, I am just trying to figure it out myself too on how it will work.. in more detail anyways.

I know you didn't, but I know alot of people do when they hit the maxs size of ram, I did anyways and most of my friends, so I was just trying to cover both sides if we could of that problem. They can, so like if you don't have a page system all ready open by the OS, let eboostr do it, then see how much was paged and then lower the size of the cache file? That could work for both sides, then lower the count as needed that was in the ram all ready. I have a feeling you still think EB can do it auto magic like tho =/ It just can't know when a user will be opening and how much will be sent to the ram at any one time. Even thos ram scaners can't know, they only tell you whats in there right there and with a some lag (shuttering), how much "maybe" be going in there.

Posted 2 years ago #

RSS feed for this topic

Reply

You must log in to post.