Programs that are loaded but not actually doing anything will be swapped out to virtual RAM if the physical memory is needed for an active process. As long as you have enough virtual memory you shouldn't notice anything significant.
You often see people giving the reason for slow execution speed as "other (perhaps rogue) processes stealing your cpu cycles". As an example let's assume an EAH result normally takes 10K cpu seconds on your machine. Suddenly you notice that the latest results are now taking 14K cpu seconds. Would you interpret this as a sign that other processes are consuming a significant proportion of your available cpu cycles? If you do then you would be wrong :). Many people seem to fall for this. It's not the cpu time that would change under these circumstances but rather the wall clock time - something that isn't easily visible without a bit of work on your part. You would need to record from your messages tab, the actual wall clock starting and finishing times for every time any crunching was done on a particular result and see how this total elapsed time compared with the reported cpu time.
Fortunately, BOINC does this hard work for you and reports (on each computer's page on the website) the actual cpu efficiency which is the ratio of cpu time to wall clock time. Alinator has asked you a couple of times already to have a look at this value but you don't seem to have noticed since you haven't reported the figure :). Please have a look and let us know.
Agreed, there's a big difference between have a result which took more wall time to complete and when all of a sudden your CPU time for equivalent work goes up or is significantly more than for similar machines.
Unfortunately, the latter case can be a lot more difficult than the former to troubleshoot.
You often see people giving the reason for slow execution speed as "other (perhaps rogue) processes stealing your cpu cycles". As an example let's assume an EAH result normally takes 10K cpu seconds on your machine. Suddenly you notice that the latest results are now taking 14K cpu seconds. Would you interpret this as a sign that other processes are consuming a significant proportion of your available cpu cycles? If you do then you would be wrong :). Many people seem to fall for this. It's not the cpu time that would change under these circumstances but rather the wall clock time - something that isn't easily visible without a bit of work on your part.
Granted that folks are often wrong in saying that--but they are not _always_ wrong.
Running Hyperthreaded on a Gallatin processor (Northwood relative with an added 2M L3 cache), I've noted on reproducible experiments that the process running on the "other" virtual CPU can appreciably raise or lower the reported CPU time for running a benchmark or a BOINC result. I've seen effects both way up to at least 20%, if memory serves.
That much is repeated careful observation, and I'll stand by it (by the way the reported bonus efficiency a year or so ago of running the then current SETI and Einstein science aps on the two virtual CPUs of a typical hyperthreaded P4 was one excellent and widely observed example of such an effect).
Reasons why is more a matter of informed inference and uninformed speculation. The intent of the timer-reporting is to attribute each clock cycle to _one_ of the two currently active processes. But inside the machine, both are often doing something (in fact, that is the whole point of the exercise). So some reporting bag-squeezing can come into play, if the "wrong" process is charged time for a cycle, it pushes the time up for one and down for the other. Anti-efficiency is also sometimes apparent (one of Akos Fete's Einstein code revisions suddenly poisoned HT utility to a remarkable degree). Probably this is due to interlocks required to preserve state integrity giving the effect of more time lost to switching overhead than is gained by extra parallel resource use.
Less malevolently, the ability of the hardware usefully to share its resources (in effect, really to make useful progress in parallel on work required by both processes) clearly varies a lot with the code. Hence real work productivity can go up _and_ reported time go down when a good pairing is active.
I'm not saying that any of this applies in the case of Jeff's situation. Just nit-picking the sweeping dismissal of such effects by a post from Gary Roberts.
I take back what I said before about 900 in a day. It is really still only 300-400 because the climate project added an extra 500 as it does not update everyday. It seems even with turning everything off aside from the essentials still doesn't do the trick. I am going to install that program that was mentioned and see if there is something else eating up the cpu time.
I am confused now. Where would I find this? Is this info in the Boinc client itself or on the Boinc stats page? I have looked in both locations and cannot find it...
If you look at your account here at Einstein and then klick on the line
"Computers on this account". Next klick on the Computer ID you want to se
and the info is there.
I thought maybe this is what you wanted to see, but thought I had posted this information earlier, the site to see it anyway, maybe you guys couldn't access the link...
Ok here is the info only for Einstein.
Total Credit 2,421.45
Recent average credit 104.21
CPU type GenuineIntel
Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz [x86 Family 6 Model 15 Stepping 2] [fpu tsc pae nx sse sse2 mmx]
Number of CPUs 2
Operating System Microsoft Windows XP
Professional Edition, Service Pack 2, (05.01.2600.00)
Memory 2047.11 MB
Cache 976.56 KB
Swap space 2719 MB
Total disk space 117.19 GB
Free Disk Space 108.03 GB
Measured floating point speed 1590.76 million ops/sec
Measured integer speed 3286.61 million ops/sec
Average upload rate 4.43 KB/sec
Average download rate 380.76 KB/sec
Average turnaround time 0.55 days
Maximum daily WU quota per CPU 72/day
Results 24
Number of times client has contacted server 512
Last time contacted server 24 Mar 2007 15:22:48 UTC
% of time BOINC client is running 88.8714 %
While BOINC running, % of time work is allowed 88.7853 %
Average CPU efficiency 0.951668
Result duration correction factor 0.362694
So how can I fix this
)
So how can I fix this issue?
RE: Programs that are
)
Agreed, there's a big difference between have a result which took more wall time to complete and when all of a sudden your CPU time for equivalent work goes up or is significantly more than for similar machines.
Unfortunately, the latter case can be a lot more difficult than the former to troubleshoot.
Alinator
RE: You often see people
)
Granted that folks are often wrong in saying that--but they are not _always_ wrong.
Running Hyperthreaded on a Gallatin processor (Northwood relative with an added 2M L3 cache), I've noted on reproducible experiments that the process running on the "other" virtual CPU can appreciably raise or lower the reported CPU time for running a benchmark or a BOINC result. I've seen effects both way up to at least 20%, if memory serves.
That much is repeated careful observation, and I'll stand by it (by the way the reported bonus efficiency a year or so ago of running the then current SETI and Einstein science aps on the two virtual CPUs of a typical hyperthreaded P4 was one excellent and widely observed example of such an effect).
Reasons why is more a matter of informed inference and uninformed speculation. The intent of the timer-reporting is to attribute each clock cycle to _one_ of the two currently active processes. But inside the machine, both are often doing something (in fact, that is the whole point of the exercise). So some reporting bag-squeezing can come into play, if the "wrong" process is charged time for a cycle, it pushes the time up for one and down for the other. Anti-efficiency is also sometimes apparent (one of Akos Fete's Einstein code revisions suddenly poisoned HT utility to a remarkable degree). Probably this is due to interlocks required to preserve state integrity giving the effect of more time lost to switching overhead than is gained by extra parallel resource use.
Less malevolently, the ability of the hardware usefully to share its resources (in effect, really to make useful progress in parallel on work required by both processes) clearly varies a lot with the code. Hence real work productivity can go up _and_ reported time go down when a good pairing is active.
I'm not saying that any of this applies in the case of Jeff's situation. Just nit-picking the sweeping dismissal of such effects by a post from Gary Roberts.
I take back what I said
)
I take back what I said before about 900 in a day. It is really still only 300-400 because the climate project added an extra 500 as it does not update everyday. It seems even with turning everything off aside from the essentials still doesn't do the trick. I am going to install that program that was mentioned and see if there is something else eating up the cpu time.
You never did tell us what
)
You never did tell us what BOINC is reporting for the performance metrics. They're one of those host items the project only displays to the owner.
Alinator
Hmmm, where can I find that
)
Hmmm, where can I find that info?
On the Computer Summary page
)
On the Computer Summary page at the bottom just above the Location selection drop down.
Alinator
I am confused now. Where
)
I am confused now. Where would I find this? Is this info in the Boinc client itself or on the Boinc stats page? I have looked in both locations and cannot find it...
Hi Jeff If you look at
)
Hi Jeff
If you look at your account here at Einstein and then klick on the line
"Computers on this account". Next klick on the Computer ID you want to se
and the info is there.
Anders n
Hi thanks, I thought maybe
)
Hi thanks,
I thought maybe this is what you wanted to see, but thought I had posted this information earlier, the site to see it anyway, maybe you guys couldn't access the link...
Ok here is the info only for Einstein.
Total Credit 2,421.45
Recent average credit 104.21
CPU type GenuineIntel
Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz [x86 Family 6 Model 15 Stepping 2] [fpu tsc pae nx sse sse2 mmx]
Number of CPUs 2
Operating System Microsoft Windows XP
Professional Edition, Service Pack 2, (05.01.2600.00)
Memory 2047.11 MB
Cache 976.56 KB
Swap space 2719 MB
Total disk space 117.19 GB
Free Disk Space 108.03 GB
Measured floating point speed 1590.76 million ops/sec
Measured integer speed 3286.61 million ops/sec
Average upload rate 4.43 KB/sec
Average download rate 380.76 KB/sec
Average turnaround time 0.55 days
Maximum daily WU quota per CPU 72/day
Results 24
Number of times client has contacted server 512
Last time contacted server 24 Mar 2007 15:22:48 UTC
% of time BOINC client is running 88.8714 %
While BOINC running, % of time work is allowed 88.7853 %
Average CPU efficiency 0.951668
Result duration correction factor 0.362694