To tell the truth I pay no attention to RAC at all... but I do think that suspending BOINC in the middle of the night when I am in bed is not going to help me have better running systems.
Back to the points I raised when I first posted about this is that my systems showed 14 suspensions all but 3 of them when I was no where near the system. There is no automated tasks set to run that I know of (indexing is off for example) and Virus scan was not scheduled to run during those days where I had log events. I also ran a test to see if AV would trigger it and in the 20-30 minutes I ran it manually (full scan) there were no suspensions. So, I have no idea why BOINC shut off my systems when I was not doing anything on them, and I have no knowledge of anything that might have triggered 14 events ... I will also note that the evens are pretty evenly scattered so that also indicates that it was not very likely that a long running process like AV scan was the cause which would have been more likely to have caused a number of events tightly clustered when it was running. Last point, though not previously raised. Historically I never saw BOINC CPU tasks causing lag on anything but the most weak systems when they were heavily over-loaded. Usually in those cases even suspension of BOINC did nothing to ease the lag... meaning that it mattered not if BOINC was running tasks or not. I used to run EverQuest though not the heaviest loading game in the universe, and never suspended BOINC and saw no ill effects. If and when I see lag now it is not from CPU side issues, it is from the GPU side and GPU side only. Both MW and Prime Grid applications have been reputed to cause these issues (I have personally seen it with PG on the MAC but, since I don't allow PG to run on the Mac now I don't know if they have fixed it or not) Since I have almost nothing I run on the windows systems I have I don't know how good or bad most other applications are on the GPUs though GPU Grid never seemed to cause me issues in the past ... On Feb 17, 2010, at 10:20 AM, Lynn W. Taylor wrote: > The people you have to test this are not your target audience, The > testars are self-selected volunteer computing zealots who would rather > have broken video playback (or stop BOINC manually) than a 5% drop in RAC. > > On 2/17/2010 10:05 AM, David Anderson wrote: >> >> Rom Walton wrote: >>> >>> It seems to me that it would be better to monitor this once a second and >>> then use a decaying average to prevent needlessly starting and stopping >>> processes for apps that jump around the user defined threshold. >> >> I'm not sure what you mean by "needless". >> If the load average is close to threshold, >> BOINC should stop until it's well below threshold. >> >> The current policy is: >> every 10 seconds, look at CPU usage over the last 10 sec. >> If it's greater than 25%, suspend BOINC; otherwise, resume BOINC. >> >> Suppose there's some activity that uses 100% of the CPU >> for 1 second, every 5 seconds. >> The current mechanism won't trigger. >> >> a) We could make it trigger by sampling every 1 sec. >> Then, on average, BOINC would suspend itself halfway >> through every spike. >> >> b) Or we could be more aggressive: sample every 1 sec, >> and if CPU load is above 25%, suspend BOINC for the next 10 sec. >> This would keep BOINC suspended indefinitely while >> that activity is going on. >> >> We need to do some experimentation with real apps >> (e.g. video playback, commercial-removing software) >> to decide whether to use a) or b), and what the parameters should be. >> Maybe what we should do is provide detailed controls via cc_config.xml, >> and let people experiment. >> >> -- David >> _______________________________________________ >> boinc_dev mailing list >> [email protected] >> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >> To unsubscribe, visit the above URL and >> (near bottom of page) enter your email address. >> > _______________________________________________ > boinc_dev mailing list > [email protected] > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > To unsubscribe, visit the above URL and > (near bottom of page) enter your email address. _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
