News:

NOTICE: This forum is mostly an archive, though new posts are allowed. Registration may require manual admin activation. After registering visit https://bitsum.com/contact/ to request account activation.

Main Menu

Version 8 Beta Progress (v7.9 beta)

Started by chris635, March 04, 2015, 08:25:05 PM

Previous topic - Next topic

Jeremy Collake

The BF4 issue would be non-critical at best. I can deduce what is likely occurring with reasonable certainty, and don't consider it a real concern (other than user perception).

The only other possibility of a PID ever appearing to change would be if the GUI (Process Lasso in this case), somehow had a delayed reaction to a new instance of that process.

Otherwise, it's relaunching itself, or another Gaming Mode process, and causing Gaming Mode to toggle off/on during the same iteration. This will be low priority, just for business/time sake.

I am not sure about SmartTrim never operating when 'No Limits' is specified. There may be additional variables at work there. Still analyzing it.
Software Engineer. Bitsum LLC.

edkiefer

Quote from: Jeremy Collake on March 15, 2015, 02:44:54 PM
The BF4 issue would be non-critical at best. I can deduce what is likely occurring with reasonable certainty, and don't consider it a real concern (other than user perception).

The only other possibility of a PID ever appearing to change would be if the GUI (Process Lasso in this case), somehow had a delayed reaction to a new instance of that process.

Otherwise, it's relaunching itself, or another Gaming Mode process, and causing Gaming Mode to toggle off/on during the same iteration. This will be low priority, just for business/time sake.

I am not sure about SmartTrim never operating when 'No Limits' is specified. There may be additional variables at work there. Still analyzing it.
As i mentioned in my last 2 posts after further looking at it while PL is running and not it happens and you can see from log where parent is .There a lot going on when MP games run now a days .
IMO nothing wrong on PL side and only thing I don't like is power profile being switch so fast for no real reason, other than PL thinks its new processes .

I let you decide on this, only thing I can come up with is adding slight delay of few sec on power plans .
from my logs it does it in a sec to few seconds .
Bitsum QA Engineer

Jeremy Collake

Ah, yes, I miss some things in my skimming. I apologize.

You're right, though there won't be a work-around of any kind for this edge case, at least not by 8.0.
Software Engineer. Bitsum LLC.

chris635

On my main rig smart trim is working again with letting it decide with no limits. The only thing changed was my monitoring program for temperatures etc. I'll check my lap top soon.
Chris

Jeremy Collake

Quote from: chris635 on March 15, 2015, 04:49:16 PM
On my main rig smart trim is working again with letting it decide with no limits. The only thing changed was my monitoring program for temperatures etc. I'll check my lap top soon.

I added a new clause that I hoped might help, but wasn't sure. Still evaluating. This is the 'get it done' stage. Next is the 'make sure it's all 100%' stage.
Software Engineer. Bitsum LLC.

chris635

It is working on the little lap top now too!  ;)
Chris

Jeremy Collake

Must have 'hit it', but I will not know for certain until I evaluate later to determine the precise cause.

So much time in 'doing it right', but, trust me, lots more is expended when things are done wrong!
Software Engineer. Bitsum LLC.

Hotrod

Quote from: chris635 on March 15, 2015, 01:17:49 PM
If I open it in notepad it is spaced all over the place. If I open it with excel, it's a little difficult to read.

Try notepad++  it allows you to keep multiple project open at once, autosaves, and can be formatted to color code your coding for easier visual examination. It's been a long time since I modded mine but I believe it can be done with a simple csv file available for free download or you can write your own custom job.  :)

chris635

Smart trim, letting it decide with no limit seems to be working well!  ;)
Chris

Jeremy Collake

Quote from: chris635 on March 16, 2015, 12:49:28 PM
Smart trim, letting it decide with no limit seems to be working well!  ;)

Great to hear ;).

I am working hard to get this on out the door. Then, as always, we can make improvements from there. That's how I do things, and why I recommend Lifetime licenses.
Software Engineer. Bitsum LLC.

chris635

we'll it's a good thing I'm a lifetimer.
Chris

Jeremy Collake

Quote from: chris635 on March 16, 2015, 12:54:02 PM
we'll it's a good thing I'm a lifetimer.

Amen ;). Most people do buy lifetime licenses, if they buy anything at all (the hardest part).

It amazes me to see the risks some people take to avoid paying. Potential malware infections from 'keygens', etc.. and for a product so liberally licensed. Oh well.

Unfortunately for Bitsum, I don't get the recurring revenue most software companies get from their loyal user bases. I'm working on a way to solve that, but loyal lifetime users are always welcome to use the Donate link at the bottom of my signature. This is not a suggestion to you, Chris, it's totally separate ;).
Software Engineer. Bitsum LLC.

chris635

Quote from: Jeremy Collake on March 16, 2015, 12:57:19 PM

Unfortunately for Bitsum, I don't get the recurring revenue most software companies get from their loyal user bases. I'm working on a way to solve that.

well that sucks, I'll gladly do what I can, hopefully soon (3 kids eat up everything...LOL!). There is you and one other guy that I want to help a little more than just buying their products.
Chris

Jeremy Collake

Quote from: chris635 on March 16, 2015, 01:05:38 PM
well that sucks, I'll gladly do what I can, hopefully soon (3 kids eat up everything...LOL!). There is you and one other guy that I want to help a little more than just buying their products.

That's noble of you, but, if there is one thing the world has taught me -- it's this: You (me), and you alone, have the capacity to earn. Begging, donations, or just doing all the good will in the world will *never* pay your rent. Thus, I try to strike a reasonable compromise, while at the same time *producing*.
Software Engineer. Bitsum LLC.

chris635

Quote from: Jeremy Collake on March 16, 2015, 01:21:18 PM
That's noble of you, but, if there is one thing the world has taught me -- it's this: You (me), and you alone, have the capacity to earn. Begging, donations, or just doing all the good will in the world will *never* pay your rent. Thus, I try to strike a reasonable compromise, while at the same time *producing*.

Amen to that!
Chris

edkiefer

Is the ram load limit values suppose to be working now ?

Cause I am still seeing trim being done with 75% global and per process .I even manually raised global to 95% in ini file and still is trimming processes .
I am going by PL ram load values in graph and bottom of GUI window (my ram is generally around 25-30% max , unless I am running game or photo-editing app) .
Bitsum QA Engineer

Jeremy Collake

I'll know more in final testing here. I'll discover then if any problems remain.

I've set a tentative release date of the 21st.
Software Engineer. Bitsum LLC.

edkiefer

Quote from: Jeremy Collake on March 17, 2015, 11:47:44 AM
I'll know more in final testing here. I'll discover then if any problems remain.

I've set a tentative release date of the 21st.
Ok, that is fine , i am just testing it, don't mean to be pain or anything .
Just trying to make sure it working as it should .

one comment on your changelog ,can you put a * or something to only last change, so we know what has been changed from previous beta .
Bitsum QA Engineer

Jeremy Collake

I had intended to be doing that, but -  of course - the problem arises where a user may come from beta x,y, or z.

However, I try to keep them in chronological order (for now).

It could be recently broken even, I'll know more as I engage in dev today.
Software Engineer. Bitsum LLC.

Jeremy Collake

I found the likely cause. The dialog box wasn't saving those changes, for one. We'll make sure it's working by final, and I appreciate your continued testing more than I could express!

Also, it did break in the last beta version because the config would get wiped out. Clearly that was not a good stopping point.
Software Engineer. Bitsum LLC.

Jeremy Collake

I think v7.9.8.3 beta will have everything functioning right again. The config error caused the min RAM % to be wiped out, hence it appearing to not work in the last version.

All part of code halfway done. Part of the process. Having early beta testing helps though, makes sure I don't forget anything!

Building now 7.9.8.3. If timestamping servers hold up, will be just about 15 minutes.
Software Engineer. Bitsum LLC.

edkiefer

sounds good , FWIW : I was editing the ini smarttrim values manually, just in case UI wasn't working .I notice 75%+ on slider wasn't saving to ini in one of last few beta's .
Bitsum QA Engineer

Jeremy Collake

New version released. Sorry for this mistake in last night's beta, which apparently only you noticed ;). (I wish). But people know it's a beta.. but we're getting there so quickly now.

Software Engineer. Bitsum LLC.

edkiefer

The UI now is saving properly (7.9.8.3beta)   :)

the new function "MinimumProcessWorkingSetInMb=256"   This is a per-process value I assume ?
Bitsum QA Engineer

Jeremy Collake

Right. Per-process working set.

The second slider is set with a maximum value of the amount of RAM installed, if you wondered.
Software Engineer. Bitsum LLC.

edkiefer

Ok, I see .
Well 95% min load with default 256mb per-process has trimmed 7 times with 0 process trimmed  :)

I need more time to see if trigger is correct at lower values were it should trim .
Bitsum QA Engineer

Jeremy Collake

It should be right now, absent any config related mishaps from prior betas. But still, I need to review it again as I now move to the last area of v8.0 before release.
Software Engineer. Bitsum LLC.

edkiefer

ok, It did just trim Palemoon with 95%/256mb setting .
Palemoon runs around 750-1gig memory load and system load is around 30% .

So not sure that should of trimmed .

I'll play some with settings .
Bitsum QA Engineer

chris635

Guys, it will probably be Friday before I can test some more on my end. Work has gotten really busy for me.
Chris

Jeremy Collake

Quote from: edkiefer on March 17, 2015, 04:27:48 PM
ok, It did just trim Palemoon with 95%/256mb setting .
Palemoon runs around 750-1gig memory load and system load is around 30% .

The confusion may be whether the two settings are an AND or an OR.

Does it take both to match, or just one?

This is something I'll make clear soon.
Software Engineer. Bitsum LLC.

edkiefer

Quote from: Jeremy Collake on March 18, 2015, 10:28:28 AM
The confusion may be whether the two settings are an AND or an OR.

Does it take both to match, or just one?

This is something I'll make clear soon.
yes, The per process values seems to working ok .
I had it set to just under 1 gig and my browser only got trimmed when it went past it ,so like (13trims)4hrs of 0trim and then 1 trim once past .

Now I think the ram load global% should if right work if many smaller app add up to past threshold% .
I have to test this part , not sure how easy it will be .
Bitsum QA Engineer

Jeremy Collake

Quote from: chris635 on March 17, 2015, 08:01:36 PM
Guys, it will probably be Friday before I can test some more on my end. Work has gotten really busy for me.

Well then, you're fired! ;)

Just kidding, always wanted to say that. You don't need to explain anything to us. Disappear for weeks at a time if you choose, we all know how life is.
Software Engineer. Bitsum LLC.

edkiefer

Quote from: edkiefer on March 18, 2015, 11:03:15 AM
yes, The per process values seems to working ok .
I had it set to just under 1 gig and my browser only got trimmed when it went past it ,so like (13trims)4hrs of 0trim and then 1 trim once past .

Now I think the ram load global% should if right work if many smaller app add up to past threshold% .
I have to test this part , not sure how easy it will be .
Ok, might have to check the load% one .
I just had it set to 39% and per-process to almost 1 gig ,with bunch of processes but none greater than 750mb , ram load was 43% but it didn't trim .


Edit2, Did second test with lower minload to 38% and ram load of 46% used but still no trim so I think that needs to be looked at but of course depends on how it's coded  .
Bitsum QA Engineer

Jeremy Collake

I should make a debug build available to this core group of hard core beta testers, so we can log and analyze the debug output if necessary, and add a few extra code sanity checks. I'll try to do that tomorrow.

That debug output will tell you exactly what Lasso is doing.
Software Engineer. Bitsum LLC.

edkiefer

That would be good , right now it looks like per-processes x MB function ,doesn't matter as to what the load value is .
I had browser set to trigger and minload ram was way above my overall system usage and it still trimmed once browser went over per-processes MB value .

Knowing if both functions or either or need to be trigger before any trimming   would be good (whats the triggers ).
Bitsum QA Engineer

Jeremy Collake

Quote from: edkiefer on March 18, 2015, 01:14:03 PM
That would be good , right now it looks like per-processes x MB function ,doesn't matter as to what the load value is .
I had browser set to trigger and minload ram was way above my overall system usage and it still trimmed once browser went over per-processes MB value .

Right. They are independent of each other, but I'm considering whether I desire such or not. Should they be tied together? Opinions?
Software Engineer. Bitsum LLC.

edkiefer

Quote from: Jeremy Collake on March 18, 2015, 01:15:45 PM
Right. They are independent of each other, but I'm considering whether I desire such or not. Should they be tied together? Opinions?
I edited my above post , but yes, I am trying to figure which would be more flexible , having them tied (need both true) or each independent .
my first thought is leave separate .
If you have both connected then hardly not will be trimmed if you set per-process to a certain value , so I think use "or" statement .
Bitsum QA Engineer

chris635

Quote from: Jeremy Collake on March 18, 2015, 11:17:58 AM
Well then, you're fired! ;)

Just kidding, always wanted to say that. You don't need to explain anything to us. Disappear for weeks at a time if you choose, we all know how life is.

;D Don't fire me yet...please sir!
   
    Got some time here. So far trim seems to be working great. Manually entering numbers, using the slider and using arrow keys to move numbers up and down work just fine. Working set is triming good. I'll test on my end for greater than 25% ram usage tonight.

Chris
Chris

chris635

I'm testing the old gimped lap top now.
Chris

edkiefer

Quote from: chris635 on March 18, 2015, 04:55:33 PM
;D Don't fire me yet...please sir!
   
    Got some time here. So far trim seems to be working great. Manually entering numbers, using the slider and using arrow keys to move numbers up and down work just fine. Working set is triming good. I'll test on my end for greater than 25% ram usage tonight.

Chris
The top slider min_ram% is not working for me, the bottom per-process xMb does work here .
Bitsum QA Engineer

chris635

Quote from: edkiefer on March 18, 2015, 05:27:20 PM
The top slider min_ram% is not working for me, the bottom per-process xMb does work here .

hey ed,

    I checked again, and the ram% slider moves up and down adjusting the percentage numbers and stays to where I assign it. Is the the issue?
Chris

edkiefer

Quote from: chris635 on March 18, 2015, 05:41:14 PM
hey ed,

    I checked again, and the ram% slider moves up and down adjusting the percentage numbers and stays to where I assign it. Is the the issue?
No, I don't mean that way, both sliders work and save proper values in ini file .

What I mean is how trim works by changing the sliders .
here try this put bottom slider to 25mb , set top slider to way over your ram load, like 75%  (in this case I still get a trim ).

Now set top slider to 20% (much lower than ram load) and set bottom per=process to higher than any process (2000mb) and see what you get in each case .In this case I get no trim .
So in these examples I don't think top slider is working right , but bottom works no matter what top slider is .

Now like we were saying, there 2 ways for it to be coded , either independently for each slider or need both sliders to be true before trim works .
Jeremy says it should be independently .
Bitsum QA Engineer

chris635

I'm checking now. As I understand it, even if "ram load" hasn't hit a certain percentage, the working set for each process can easily go above 25 mb, so if the working set is set very low, it will still trim all process over 25 mb. Right now I have 10 process over 25 mb working set ( a couple over 100 mb, firefox being one) and it should trim those. Minimum ram load percent should clean everything when ram load period reaches that percentile (which it shouldn't as I have the minimum ram load set to 75% to test)
Chris

chris635

Quote from: edkiefer on March 18, 2015, 05:52:38 PM
No, I don't mean that way, both sliders work and save proper values in ini file .

What I mean is how trim works by changing the sliders .
here try this put bottom slider to 25mb , set top slider to way over your ram load, like 75%  (in this case I still get a trim ).

Now set top slider to 20% (much lower than ram load) and set bottom per=process to higher than any process (2000mb) and see what you get in each case .In this case I get no trim .
So in these examples I don't think top slider is working right , but bottom works no matter what top slider is .

Now like we were saying, there 2 ways for it to be coded , either independently for each slider or need both sliders to be true before trim works .
Jeremy says it should be independently .

It works this way. I will raise bottom slider now and lower top slider as far as it goes and see.
Chris

Jeremy Collake

#144
Yea, it's a logic design issue. Do both values have to match before a trim, or only one. I'm going with both for future versions.
Software Engineer. Bitsum LLC.

Jeremy Collake

But note that clicking 'Trim Now' will cause it to ignore the RAM Load minimum ... because you are telling it to Trim Now.
Software Engineer. Bitsum LLC.

edkiefer

Quote from: Jeremy Collake on March 18, 2015, 07:08:51 PM
Yea, it's a logic design issue. Do both values have to match before a trim, or only one. I'm going with both for future versions.
Ok, so both sliders will have to have true or pass for anything to trim .(need to have min ram load below ram usage and per=process needs to use more than the set MB value before trim trims anything )
Bitsum QA Engineer

chris635

Quote from: edkiefer on March 18, 2015, 05:52:38 PM
No, I don't mean that way, both sliders work and save proper values in ini file .

What I mean is how trim works by changing the sliders .
here try this put bottom slider to 25mb , set top slider to way over your ram load, like 75%  (in this case I still get a trim ).

Now set top slider to 20% (much lower than ram load) and set bottom per=process to higher than any process (2000mb) and see what you get in each case .In this case I get no trim .
So in these examples I don't think top slider is working right , but bottom works no matter what top slider is .

Now like we were saying, there 2 ways for it to be coded , either independently for each slider or need both sliders to be true before trim works .
Jeremy says it should be independently .

okay I see now. As you can see, my ram load was over 10% and it did not trim.
Chris

edkiefer

Quote from: chris635 on March 18, 2015, 07:24:16 PM
okay I see now. As you can see, my ram load was over 10% and it did not trim.
right, that is what I meant .

Anyway Jeremy going to alter it so should be fine then .
Bitsum QA Engineer

chris635

Quote from: edkiefer on March 18, 2015, 07:26:01 PM
right, that is what I meant .

Anyway Jeremy going to alter it so should be fine then .

Okay! I hope this push's people to really learn and take advantage of process lasso's power.
Chris