Points are based upon time the application is running, which is not necessarily the same as CPU time, and your overall score - processor, memory etc. If your results returned is going up significantly that would indicate more processor time available to the agent. I would expect your run time to stay the same. If your points received are down then it may be that when the agent is returning work to the server something else is takikng the CPU and reducing your score; but this doesn't tie in with getting more results.

A conundrum

The reason you are confused is because you are trying to make a statistical correlation that doesn't exist. You can't compare points per result. Every WU takes a different amount of time to compute (for both HPF and FAAH). 1 WU may take 2 hours, the next 10. If you completed 5 2hr. WUs and 1 10hr. WU, you should be awarded roughly the same amount of points (assuming your device score is relatively stable).

Your best bet is to compare points per hour, but even that can be erroneous because benchmark scores can vary (even greatly). However, on average, points per hour is probably your best yardstick.

Regarding ICQ preventing shutdown, assuming you indeed are getting a little more throughput from your machine, it won't be much because under normal conditoin, the grid app will get between 95% - 99% of the CPU anyway. So, at best you'd get just a litte more throughput, but it would be almost undetectable because of other variants. If you are getting significantly more throughput it's because you normally have something running that is taking up a noticable amount of CPU time, be it AV software, games, spy/adware, a CPU intensive flash/java plugin in a web browser, etc. When Windows shuts down, it closes all other apps, so it's possible that you are getting more throughput because this task has been shut down.

Of course I read the whole thread. As I'll restate - the number of results is meaningless since the amount of time each takes is variable. Some take just a few hours and others will take many hours (or even a couple of days). Neither project has workunits that take a predictable amount of time.

What you want to check is points/hour. Points is the most consistent way of checking your throughput.

Getting huffy, aren't we? For the first time, Wayndal gave us the figures for Processor Utilization that I asked for days ago. Next thing is to check on his returned results using the Device ID.

We'll just work down the check list until we understand what is going on.

mycrofth

I have looked up results for the device in question. The last couple of days it looks like it has been working ok. However there are periods of time where for some days the agent is reporting that the application had crashed. This seemed to happen roughly once an hour. This is most likely because when a crashed result is returned, the agent is told to hold off for an hour. After that time period, it got another work unit and crashed. The most recent date for a lot of such crashes was 1-16-06. Such crashes would count as results, but generate few points.

So, the question is why is it crashing? The culprits that come to mind are:

1. VM overcommitment. If the sum of all applications consume more than the maximum virtual memory the system is configured for, the most recent application trying to get more memory crashes. There might be just too much going on in the machine or there might be some application with a memory leak. One can check this with the task manager. If it is simple overcimmitment, then increaseing the total VM max should fix it. If it is a memory leak, increasing the max will only delay the problem.

2. There might be some firewall software or other software trying to protect from stack overflows or other such things. Any of these kinds of packages might cause the agent grief by prohibiting it from proceeding. For example, the Windows DEP protection causes problems for the agent as does the McAfee overflow protection. There may be others.

3. It could be some sort of intermittent hardware problem. Memory, the CPU, disk drivers etc can be tested with various tools to see if they catch the problem. Sometimes the problem is too subtle for the test tools to catch.

4. Permissions to write to the World Community Grid install directory or its sub-directories might be lost or revoked, which would cause the agent to crash.

5. I am not familiar with the ICQ tool, but it might have the ability to cause the agent to crash for some reason. Perhaps it is killing the thread running the project before telling the UD program that the system is shutting down. Thus, UD thinks the program crashed rather than thinking it is a normal system shutdown. This is just a wild guess.

At any rate, the last days after 1-16, the agent on this device looks like it has been running ok.