It may come from md5s computations. GUI asks for them when a "refresh" occurred (triggered by a communication with a scheduler, asked by the user or automatically asked every 30 minutes after last one). Have you tried a tool like filemon to see which files are involved in these I/O?
Hi Doc, first of all great job with BoincStudio. Using filemon I found boinc.exe to be reading or writing to the client_state.xml file every 1 min or so.
Yes but it's a normal behaviour with some apps (in this case, write is triggered by some messages on task progress). So, other clients should act in the same way and for a client_state.xml of 1MB (with 1 cpu), you can expect ~1.5GB write I/O by day. Have you checked your I/O with standard boinc 5.4.9 core?
I got a little problem with BS and BS-BoincClient:
BS wants to download more WUs, because my quota is not jet reached and the cache is not filled:
08/06/2006 16:47: Requesting 147464 seconds of work on Einstein@Home for luemmel
08/06/2006 16:49: Requesting 148466 seconds of work on Einstein@Home for luemmel
08/06/2006 16:51: Requesting 149472 seconds of work on Einstein@Home for luemmel
08/06/2006 16:53: Requesting 153174 seconds of work on Einstein@Home for luemmel
08/06/2006 16:55: Requesting 155063 seconds of work on Einstein@Home for luemmel
08/06/2006 16:57: Requesting 155167 seconds of work on Einstein@Home for luemmel
08/06/2006 16:59: Requesting 155286 seconds of work on Einstein@Home for luemmel
08/06/2006 17:01: Requesting 156294 seconds of work on Einstein@Home for luemmel
08/06/2006 17:03: Refreshing luemmel: sched communication
08/06/2006 17:03: Requesting 156131 seconds of work on Einstein@Home for luemmel
This ONLY happens on my AMD dualcore. All other hosts are fine.
The cache is only filled to half the value that I want.
Another little problem: I think whenever (again only on the X2) a benchmark is done, BS is jumping back to 2 CPUs.
But still this is a very fine work, DocMaboul has done!
Especially the very little CPU consuption compared to BoincView.
Something that could be added (if it isn't already?), is an adjustment of the time interval the clients states are updated.
I got a little problem with BS and BS-BoincClient:
BS wants to download more WUs, because my quota is not jet reached and the cache is not filled:
08/06/2006 16:47: Requesting 147464 seconds of work on Einstein@Home for luemmel
08/06/2006 16:49: Requesting 148466 seconds of work on Einstein@Home for luemmel
08/06/2006 16:51: Requesting 149472 seconds of work on Einstein@Home for luemmel
08/06/2006 16:53: Requesting 153174 seconds of work on Einstein@Home for luemmel
08/06/2006 16:55: Requesting 155063 seconds of work on Einstein@Home for luemmel
08/06/2006 16:57: Requesting 155167 seconds of work on Einstein@Home for luemmel
08/06/2006 16:59: Requesting 155286 seconds of work on Einstein@Home for luemmel
08/06/2006 17:01: Requesting 156294 seconds of work on Einstein@Home for luemmel
08/06/2006 17:03: Refreshing luemmel: sched communication
08/06/2006 17:03: Requesting 156131 seconds of work on Einstein@Home for luemmel
This ONLY happens on my AMD dualcore. All other hosts are fine.
The cache is only filled to half the value that I want.
Another little problem: I think whenever (again only on the X2) a benchmark is done, BS is jumping back to 2 CPUs.
But still this is a very fine work, DocMaboul has done!
Especially the very little CPU consuption compared to BoincView.
Something that could be added (if it isn't already?), is an adjustment of the time interval the clients states are updated.
cu,
Michael
Project could not send you requested work if the project havn't enougth time to complete work units. In client_state.xml, verify on_frac, active_frac and cpu_efficiency. All values must to be close to 1. If not, your trouble is here.
BoincStudio is faking cpu number only on work request, not on results or bench reports. So, time to time, you could see the good number of cpu on project site.
I hope that this is a good thread to ask this question.
Would it be possible for BoincStudio to have a setting for number of CPU's to run a project on? For instance, on a dual/dual machine (two CPUs each with two cores), have a setting that allows only one instance of a project to run at a time, thus splitting cores between projects? For instance:
1 Instance of Leiden
2 Instances of Einstein
1 Instance of QMC
Or perhaps...
1 Instance of Leiden
1 Instance of Einstein
1 Instance of QMC
1 Instance of Rosetta
... and when any project runs out of work, switch that instance to the backup project until more work becomes available?
The benefit to this is that with careful selection of projects, one can choose those which "harmonize" in such a way as to maximize production by selecting a combination of those projects and instances that minimize conflicts for CPU and memory resources, for instance.
Example - two instances of E@H using optimized clients on a dual CPU system appears to be less efficient in terms of credit per hour than one instance of E@H and one instance of Rosetta. I ask because this is a capability I miss from the trux client, where it was possible to do this through manipulation of the "Priority Projects" parameter. If the number of "Priority Projects" was the same as the number of available CPUs (real, virtual, or cores), one project ran on each as long as work was available for all.
Thanks for considering - BoincStudio seems a very nice program, and this type of functionality would only make it better.
RE: RE: New version:
)
For current version, try this
Unknown BURP client md5:
)
Unknown BURP client md5: 044ffb12511d0ca441a2b3ca7f059865 for file projects/burp.boinc.dk/blender_4.34_windows_intelx86.exe
Adding 044ffb12511d0ca441a2b3ca7f059865 for file projects/burp.boinc.dk/blender_4.34_windows_intelx86.exe. Please report it.
me-[at]-rescam.org
RE: Unknown BURP client
)
Reported.
RE: RE: It may come from
)
Yes but it's a normal behaviour with some apps (in this case, write is triggered by some messages on task progress). So, other clients should act in the same way and for a client_state.xml of 1MB (with 1 cpu), you can expect ~1.5GB write I/O by day. Have you checked your I/O with standard boinc 5.4.9 core?
06/06/2006 17:18: Unknown
)
06/06/2006 17:18: Unknown QMC@HOME client md5: 956c62a331a666a7cea47a399a460ac1 for file projects/qah.uni-muenster.de/Amolqc-beta_5.06_windows_intelx86.exe
06/06/2006 17:18: Adding 956c62a331a666a7cea47a399a460ac1 for file projects/qah.uni-muenster.de/Amolqc-beta_5.06_windows_intelx86.exe. Please report it.
b88f51bf212e8d7407e515676600c
)
b88f51bf212e8d7407e515676600c3d0;setiathome_5.12_windows_intelx86.exe
d069c1b8209e9ef6c44683ded444e103;rosetta_5.16_windows_intelx86.exe
It seems to me that running
)
It seems to me that running only BOINC core (without Manager and BS) lower I/O disk intensive behaviour that we see.
c01fcfbcf463712cae02127a64b48614; malariacontrol_5.30_windows_intelx86
I got a little problem with
)
I got a little problem with BS and BS-BoincClient:
BS wants to download more WUs, because my quota is not jet reached and the cache is not filled:
08/06/2006 16:47: Requesting 147464 seconds of work on Einstein@Home for luemmel
08/06/2006 16:49: Requesting 148466 seconds of work on Einstein@Home for luemmel
08/06/2006 16:51: Requesting 149472 seconds of work on Einstein@Home for luemmel
08/06/2006 16:53: Requesting 153174 seconds of work on Einstein@Home for luemmel
08/06/2006 16:55: Requesting 155063 seconds of work on Einstein@Home for luemmel
08/06/2006 16:57: Requesting 155167 seconds of work on Einstein@Home for luemmel
08/06/2006 16:59: Requesting 155286 seconds of work on Einstein@Home for luemmel
08/06/2006 17:01: Requesting 156294 seconds of work on Einstein@Home for luemmel
08/06/2006 17:03: Refreshing luemmel: sched communication
08/06/2006 17:03: Requesting 156131 seconds of work on Einstein@Home for luemmel
This ONLY happens on my AMD dualcore. All other hosts are fine.
The cache is only filled to half the value that I want.
Another little problem: I think whenever (again only on the X2) a benchmark is done, BS is jumping back to 2 CPUs.
But still this is a very fine work, DocMaboul has done!
Especially the very little CPU consuption compared to BoincView.
Something that could be added (if it isn't already?), is an adjustment of the time interval the clients states are updated.
cu,
Michael
RE: I got a little problem
)
Project could not send you requested work if the project havn't enougth time to complete work units. In client_state.xml, verify on_frac, active_frac and cpu_efficiency. All values must to be close to 1. If not, your trouble is here.
BoincStudio is faking cpu number only on work request, not on results or bench reports. So, time to time, you could see the good number of cpu on project site.
I hope that this is a good
)
I hope that this is a good thread to ask this question.
Would it be possible for BoincStudio to have a setting for number of CPU's to run a project on? For instance, on a dual/dual machine (two CPUs each with two cores), have a setting that allows only one instance of a project to run at a time, thus splitting cores between projects? For instance:
1 Instance of Leiden
2 Instances of Einstein
1 Instance of QMC
Or perhaps...
1 Instance of Leiden
1 Instance of Einstein
1 Instance of QMC
1 Instance of Rosetta
... and when any project runs out of work, switch that instance to the backup project until more work becomes available?
The benefit to this is that with careful selection of projects, one can choose those which "harmonize" in such a way as to maximize production by selecting a combination of those projects and instances that minimize conflicts for CPU and memory resources, for instance.
Example - two instances of E@H using optimized clients on a dual CPU system appears to be less efficient in terms of credit per hour than one instance of E@H and one instance of Rosetta. I ask because this is a capability I miss from the trux client, where it was possible to do this through manipulation of the "Priority Projects" parameter. If the number of "Priority Projects" was the same as the number of available CPUs (real, virtual, or cores), one project ran on each as long as work was available for all.
Thanks for considering - BoincStudio seems a very nice program, and this type of functionality would only make it better.
.
