Performance hit every 25 seconds.
csimon
Acadiana Icrontian
Ok ...I'm just noticing this but perhaps it's been happening all along.
I notice that while folding my performace meter drops from 100% to 0% about every 25 seconds or so. Can anyone else verify this is or isn't happening to them?
If it isn't does anyone have any suggestions as to what may be causing this?
using FAH4Console.exe -forcesse and core_78 v1.55
wtf?
I notice that while folding my performace meter drops from 100% to 0% about every 25 seconds or so. Can anyone else verify this is or isn't happening to them?
If it isn't does anyone have any suggestions as to what may be causing this?
using FAH4Console.exe -forcesse and core_78 v1.55
wtf?
0
Comments
Thats also why you run a genome in the background which I realized I didnt set up after I got my NF7.
That is absolutely correct, the drop intervals are due to checkpoint writes.
Here is my client.cfg:
[settings]
username=csimon
team=93
asknet=no
machineid=1
local=22
[http]
active=no
host=localhost
port=8080
usereg=no
[clienttype]
type=1
[core]
checkpoint=15
If I set my checkpoint to checkpoint=0 will that supress the function?
nevermind ...no matter what I set it to it still does it.
wait ... huh? care to elaborate on this?
I just looked at my client and it's behaving the exact same way. lsevald brought this up along time ago when Gro's were fairly new but I cannot remember if the intervals were this short or if the intervals were strictly between checkpoints which would be a matter of minutes not seconds.
This would be a good topic to post at the community forum as I am now very interested in why this is happening.
You are finishing a frame every 25 seconds are you?:)
I'm fairly certain that my system did not do this before I switched from core v.1.5.4 to 1.5.5. Anyone else that is experiencing this, which core version are you using? If the concensus seems to be v1.5.5, then I think I might go back to v.1.5.4 just to double check.
username=mmonnin
team=93
asknet=no
machineid=1
local=371
[http]
active=no
host=localhost
port=8080
usereg=no
usepasswd=yes
[clienttype]
type=1
[core]
priority=96
cpuusage=100
disableassembly=no
ignoredeadlines=no
This is running at low priority since there is a genome in the background at idle.
[settings]
username=csimon
team=93
asknet=no
machineid=1
local=28
[http]
active=no
host=localhost
port=8080
usereg=no
[clienttype]
type=1
[core]
checkpoint=30
I'm left to assume that with the new client 4.0 that if [core] settings are set to anything but default then they are set in client.cfg. I manually added cpuusage=100 and it made no difference.
maybe it is the core? or core + v4client
re-enter team #93, userid=t1rhino,
cpuusage=100
I have v1.55 core.
If you play with this, you will have to disassemble the client and the core and build in a workspace in RAM to store a percentage worth of work in-- essentially you will be losing up to one percent every time the client or core hangs this way. they did this simply so the client would not have to backtrack if, say, windows crashed instead of someone doing an orderly shutdown before rebooting windows and widnows not hanging. The new core has never backtracked more than 1 percent on anything I have let it run, and same for tinkers, except there it now is never mere than one frame-- so most of this is in the client, though the core does not exit. Client would have to be rewritten, and Guha at Folding did most if not all the work on current core and client, or co-ordinated that. Talk to guha, best way to find out if you have a hyper stable box.
One reason I think this is so, is I get pattern that is part of a percent of very tiny time drop like you do out of my F@Hs here, and it does not relate to the checkpoint= numbers, as it is tiny short time, and the checkpoint in client.cfg on both clients(linux and Windows, same release versions but appropriate for the O\S as to client) is 15 MIN cycles. Most folks like less to lose work not saved than to take 4% of time to write and not have to recalc if box dies or locks and and becasue they have other than perfectly stable boxes. In theory if you wanted the client to grab much more RAM, you could put the accumulation into RAM for 1-5% of work instead of 1-500 FRAMES of work (depenmding on size of Wu, the new biggest ones run 500 steps per prercent and I do not know if those are using one FRAME per step or not), but I think you might have fun rewriting what would be needed to get your client to go always-on all the time without giving it a priority that would override normal use of computer. My computer graphical client is set to run CPU 100%, and except for write chunk to HD and then set up for next portion of work in RAM, it does. But, with new client and core, have enver lost 15 min of work.... Even by trying....
John.
John.