hi all,
running seti@classic for more than a year.
"Migrated" like much other, about 1 month ago to seti@boinc.
seti@boinc can be nice. as u know, due several
outtages on side berkeley, it was not possible to keep the
demand on WUs high enough to me.
I did what I did, when a member of the farm was "idle", I turned
back to seti@classic. And returned and back and returend...
Like some of you thinking.
In the BOINC dokumentation is written, it could not be possible tu run both client together..
That was one of the first thing I tested, I'am a believer, but not all the time.
What happens when seti@classic and the boinc-client with the seti@boinc project are running on the same cpu (without ht)?
Seti@classic "receives" more cpu cycles as seti@boinc, seti@boinc is working but makes nearly no progress.
On Seti@classic I use the 3.03 CL version.
This week was a hard time for boinc cruncher, nearly no wu where available.
the tool
since the beginning of the migration I'm using a small tool.
The function of the tool is
-mesure the cpu usage. if the cpu usage is going below a defined value, then the tools startes what you wants.
if the seti@boinc client is running, the cpu usage is "high".
if the seti@boinc has nothing to do, the usage falls down.
then this tool startes the seti@classic client, the tools waites a defined period
an put afterwords the stop_after_send.txt in the seti@classic directory. You know it, the presence of this file is stopping the seti@classic
client after uploading a completed wu.
If the boinc clinet got a wu, now he would begin (cpu usage high)
if there is still nothing to do, stop_after_send.txt will be deleted and seti classic will be restarted and the it begins.
This week, it was a nice to look to the clients, they where "switching" themself from seti@boinc and seti@classic and back.
sorry for lot writting, wanted to share the idea in detail.
it works under 32bit m$. all parameters are written into a .ini easy to adapt
I tested/optimized until it was doing what it should.
Now It's a helpful tool for me
I'm not shure if there is an common interest to such a tool
If some one in the community is interested to test it, it would be a pleasure to share it (ofcourse for free).
hardcopies as attachements.
-first pic, normal status
-2nd pic tool mesured a load cpu load and repeat the mesurement every 8000 milisec. If the cpu usage has to fall below 10 % this for 15 loops, after starting seti 1 the waites 25000 milisec until putting the stop_after_send.txt in the seti 1 directory
sorry my english is not perfect.
afraid or interested?
friendly
ric
the ini file:
todo=setiathome-3.03.i386-winnt-cmdline.exe -proxy 1.10.1.120:5517
Wpos.top=1740
Wpos.left=1320
text1.text=8000
text2.text=25000
text3.text=15
text4.text=10
You can put what else you want inthis line, behind the =
even a shutdown, a other exe or cmd or..
running seti@classic for more than a year.
"Migrated" like much other, about 1 month ago to seti@boinc.
seti@boinc can be nice. as u know, due several
outtages on side berkeley, it was not possible to keep the
demand on WUs high enough to me.
I did what I did, when a member of the farm was "idle", I turned
back to seti@classic. And returned and back and returend...
Like some of you thinking.
In the BOINC dokumentation is written, it could not be possible tu run both client together..
That was one of the first thing I tested, I'am a believer, but not all the time.
What happens when seti@classic and the boinc-client with the seti@boinc project are running on the same cpu (without ht)?
Seti@classic "receives" more cpu cycles as seti@boinc, seti@boinc is working but makes nearly no progress.
On Seti@classic I use the 3.03 CL version.
This week was a hard time for boinc cruncher, nearly no wu where available.
the tool
since the beginning of the migration I'm using a small tool.
The function of the tool is
-mesure the cpu usage. if the cpu usage is going below a defined value, then the tools startes what you wants.
if the seti@boinc client is running, the cpu usage is "high".
if the seti@boinc has nothing to do, the usage falls down.
then this tool startes the seti@classic client, the tools waites a defined period
an put afterwords the stop_after_send.txt in the seti@classic directory. You know it, the presence of this file is stopping the seti@classic
client after uploading a completed wu.
If the boinc clinet got a wu, now he would begin (cpu usage high)
if there is still nothing to do, stop_after_send.txt will be deleted and seti classic will be restarted and the it begins.
This week, it was a nice to look to the clients, they where "switching" themself from seti@boinc and seti@classic and back.
sorry for lot writting, wanted to share the idea in detail.
it works under 32bit m$. all parameters are written into a .ini easy to adapt
I tested/optimized until it was doing what it should.
Now It's a helpful tool for me
I'm not shure if there is an common interest to such a tool
If some one in the community is interested to test it, it would be a pleasure to share it (ofcourse for free).
hardcopies as attachements.
-first pic, normal status
-2nd pic tool mesured a load cpu load and repeat the mesurement every 8000 milisec. If the cpu usage has to fall below 10 % this for 15 loops, after starting seti 1 the waites 25000 milisec until putting the stop_after_send.txt in the seti 1 directory
sorry my english is not perfect.
afraid or interested?
friendly
ric
the ini file:
todo=setiathome-3.03.i386-winnt-cmdline.exe -proxy 1.10.1.120:5517
Wpos.top=1740
Wpos.left=1320
text1.text=8000
text2.text=25000
text3.text=15
text4.text=10
You can put what else you want inthis line, behind the =
even a shutdown, a other exe or cmd or..
