Using Arch's wiki for setting up boinc. https://wiki.archlinux.org/title/BOINC
I was able to get up and running in about 2 hours from beginning to end.
After the first few tasks cleared out running under the old app. I swapped in this custom one.
I am on a EVGA 3080Ti FTW and my task run times went from about ~320 seconds. Down to ~230 seconds.
Seems like a serious boost in productivity. If I'm going to expend all this electricity on running the tasks. Might as well take the time and effort to get the most bang for the buck out of it.
Currently running the latest special app, and haven't noticed any issues until recently. My computer will go through the available work in under an hour, and then is forced to wait until the next update.
Wed 22 Nov 2023 08:51:10 PM PST | Einstein@Home | To get more Einstein@Home work, finish current work, stop BOINC, remove app_info.xml file, and restart.
Wed 22 Nov 2023 08:51:10 PM PST | Einstein@Home | Project requested delay of 14400 seconds
I have the settings in BOINC to hold 3 days of work, with an additional 3 days of work. Einstein@Home is the only GPU project that I am currently running.
Followed the log file instructions of removing the app_info.xml file, and restarting. Reload the special app, and still get this issue. Found this issue discussed way back in 2009 or earlier, and tried their suggestion of resetting the project.
It's the additional days of work setting that is getting you into trouble.
Set that to zero or 0.25 days of additional work and update.
Nobody understands the purpose of that setting and use it incorrectly. It is telling the scheduler to await your return in 3 days when you have a internet connection again.
It was designed to be used back in the dialup days when you may not have constant internet connections.
If you want more work, add it to your cache size. Just don't ask for too much that you can't finish before deadline.
Einstein has very stable servers and a constant supply of work. You could set your cache size to 1 task and it will just keep sending you another task for every one you return with no interruption.
Thank you for the fast response. I set the additional days to zero and let it run all day. I tried manually updating a few times too, but still get the back off request for 14400 seconds, and Einstein would only send me a few new work units.
I currently have 9 E@H work units. Once I run through these, the computer idles until the 14400 seconds runs out, and an auto update is requested again.
When I ran the regular application, I didn't get this back off request, and I consistently had enough work to keep my GPUs working constantly.
Thank you for the fast response. I set the additional days to zero and let it run all day. I tried manually updating a few times too, but still get the back off request for 14400 seconds, and Einstein would only send me a few new work units.
I currently have 9 E@H work units. Once I run through these, the computer idles until the 14400 seconds runs out, and an auto update is requested again.
When I ran the regular application, I didn't get this back off request, and I consistently had enough work to keep my GPUs working constantly.
Thank you again for the help.
do you have einstein set to a resource share of 0?
Hello. Thank you for the help. Looked at the client_state.xml file, and was already set to zero. Looked at every instance of "rsc_backoff_interval" inside the xml file, and for every project, the backoff value was already set to zero as well.
Have you made any changes or additions to the app_info.xml file? would you mind posting what your file contains now?
but I have a feeling that this is some kind of weird interaction between the use of app_info and Einstein project servers. A team mate had this problem recently, and seems to have solved it by tweaking the resource share from 0 to 10. and I’m pretty sure I’ve seen this before too on my system, and solved it by simply removing the app_info and putting it back again. But I’m not having this problem at all right now.
Thanks for this I converted
)
Thanks for this
I converted my desktop machine to Manjaro Linux.
Using Arch's wiki for setting up boinc. https://wiki.archlinux.org/title/BOINC
I was able to get up and running in about 2 hours from beginning to end.
After the first few tasks cleared out running under the old app. I swapped in this custom one.
I am on a EVGA 3080Ti FTW and my task run times went from about ~320 seconds. Down to ~230 seconds.
Seems like a serious boost in productivity. If I'm going to expend all this electricity on running the tasks. Might as well take the time and effort to get the most bang for the buck out of it.
+1
)
+1
A Proud member of the O.F.A. (Old Farts Association). Be well, do good work, and keep in touch.® (Garrison Keillor)
Hello. Currently running
)
Hello.
Currently running the latest special app, and haven't noticed any issues until recently. My computer will go through the available work in under an hour, and then is forced to wait until the next update.
Wed 22 Nov 2023 08:51:10 PM PST | Einstein@Home | To get more Einstein@Home work, finish current work, stop BOINC, remove app_info.xml file, and restart.
Wed 22 Nov 2023 08:51:10 PM PST | Einstein@Home | Project requested delay of 14400 seconds
I have the settings in BOINC to hold 3 days of work, with an additional 3 days of work. Einstein@Home is the only GPU project that I am currently running.
Followed the log file instructions of removing the app_info.xml file, and restarting. Reload the special app, and still get this issue. Found this issue discussed way back in 2009 or earlier, and tried their suggestion of resetting the project.
Seeing if anyone has any suggestions please.
Thank you in advance.
It's the additional days of
)
It's the additional days of work setting that is getting you into trouble.
Set that to zero or 0.25 days of additional work and update.
Nobody understands the purpose of that setting and use it incorrectly. It is telling the scheduler to await your return in 3 days when you have a internet connection again.
It was designed to be used back in the dialup days when you may not have constant internet connections.
If you want more work, add it to your cache size. Just don't ask for too much that you can't finish before deadline.
Einstein has very stable servers and a constant supply of work. You could set your cache size to 1 task and it will just keep sending you another task for every one you return with no interruption.
Thank you for the fast
)
Thank you for the fast response. I set the additional days to zero and let it run all day. I tried manually updating a few times too, but still get the back off request for 14400 seconds, and Einstein would only send me a few new work units.
I currently have 9 E@H work units. Once I run through these, the computer idles until the 14400 seconds runs out, and an auto update is requested again.
When I ran the regular application, I didn't get this back off request, and I consistently had enough work to keep my GPUs working constantly.
Thank you again for the help.
Well you can remove the
)
Well you can remove the backoff time if you are willing to edit the client_state.xml file.
The backoff value is listed there and you can simply set it to zero and save the file and restart BOINC.
It will look like this in the Einstein project section.
<rsc_backoff_interval>
<name>NVIDIA</name>
<value>0.000000</value>
</rsc_backoff_interval>
Or AMD or Intel depending on your brand. Just set the 14400 seconds value to zero.
Someone537833 wrote: Thank
)
do you have einstein set to a resource share of 0?
_________________________________________________________________________
Hello. Thank you for the
)
Hello. Thank you for the help. Looked at the client_state.xml file, and was already set to zero. Looked at every instance of "rsc_backoff_interval" inside the xml file, and for every project, the backoff value was already set to zero as well.
<rsc_backoff_interval>
<name>NVIDIA</name>
<value>0.000000</value>
</rsc_backoff_interval>
Hello. All my projects are
)
Hello. All my projects are set to 100, including E@H.
Have you made any changes or
)
Have you made any changes or additions to the app_info.xml file? would you mind posting what your file contains now?
but I have a feeling that this is some kind of weird interaction between the use of app_info and Einstein project servers. A team mate had this problem recently, and seems to have solved it by tweaking the resource share from 0 to 10. and I’m pretty sure I’ve seen this before too on my system, and solved it by simply removing the app_info and putting it back again. But I’m not having this problem at all right now.
_________________________________________________________________________