Unless a newbie visits the Manager Options >> Computing Preferences page, Saves it to use Local Preferences, the preferences set globally on all projects is 10 days of cache. That is what is set up when a person first attaches to a project as a newbie would do installing BOINC for the first time. Those are the BOINC defaults.
...
Thanks for the info.
But when I set the prefs (or when they are automatically set) to 0.01 all I get is one or two WUs, regardless of the rig.
Why or how is this?
Because 0.01 days equates to about 14 minutes as Stephen mentioned. That is the typical time for a task to complete. So the client is only asking for the replacement task to replace the one currently crunching.
If you have outages in your network that doesn't allow you to continually turn in work and receive replacement you can bump your daily work request to 0.1 days or around there to get around 30 tasks in your cache.
That really is the only reason to hold more work in your cache is when you don't have an constant internet connection. Or you are advised in Notices that the project has a planned maintenance outage, then you can request more work to tide you over till the project is back online. But remember to reduce your request later when the project is back and you are back to returning/requesting work on a one for one basis.
Does it help to set up a RAMdisk dedicated to BOINC?
Thanks again
(PS ~ I am trying to piece together the process for setting up a signature graphic .... searching for 'signature' does not bring me to a single page with all the steps ....)
No not really. The only people that have entertained that thought are the ones worried about the constant writing to disks that some projects and some applications do and are worried they are wearing out their new SSD or whatever.
In reality even the worst applications would only use up 1/10 of the TDW specifications in a year. The ones over at WCG come to mind.
Plus with a RAMDISK, if you lose power, all your work and BOINC states are lost. The amount of time BOINC does drive access is very minimal compared to the cpu and gpu crunching time.
(PS ~ I am trying to piece together the process for setting up a signature graphic .... searching for 'signature' does not bring me to a single page with all the steps ....)
The signature graphic on your Account >> Preferences >> Community pages is best done by NOT using the menu image or link icons. Best to input directly using BBCode formatting.
Also the signature graphics that I and many other have is culled from the stats aggregation sites where they produce the stats link formatting for you. You normally just cut and paste into the projects Community page signature section.
Some projects also have issues using https links for graphics and the workaround is simply replacing https with http.
This is true. I was just surprised by a petitioner request on one of my projects for more work by changing limits and the admin responded he would look into it this weekend.
But the issue here is with BOINC and with DA basically washing his hands of any further BOINC development, all we can hope for is Vitalli to pick up the burden. Which he has for the most part being the author of the latest Android and security commits. DA is just a button pusher now for merges submitted.
. . But is the work allocation governed solely by BOINC or can the project ops set their own limits? If they can surely they could set the max allocation to 5+5 regardless of the higher requests available within BOINC. That is the only change I believe would be needed to eliminate a large number of the needless resends.
Does it help to set up a RAMdisk dedicated to BOINC?
Thanks again
. . If you are running BOINC from an SSD there would be very little or no benefit from using a RamDisk so you are better off leaving all your system RAM for BOINC apps to use. If not then I will mention that smaller SSD drives such as 60GB or 120GB are rather cheap these days and would be plenty for BOINC and several projects. I added 60GB SSDs on my earlier systems and 120GB on the later units. It is much cheaper than adding system RAM.
Because 0.01 days equates to about 14 minutes as Stephen mentioned. That is the typical time for a task to complete. So the client is only asking for the replacement task to replace the one currently crunching.
If you have outages in your network that doesn't allow you to continually turn in work and receive replacement you can bump your daily work request to 0.1 days or around there to get around 30 tasks in your cache.
That really is the only reason to hold more work in your cache is when you don't have an constant internet connection. Or you are advised in Notices that the project has a planned maintenance outage, then you can request more work to tide you over till the project is back online. But remember to reduce your request later when the project is back and you are back to returning/requesting work on a one for one basis.
. . Also a very important part of the settings that Keith recommended, 0.01+0.0 or 0.1+0.0, is the 0.0 because it indicates the function of prompt reporting and work fetch.
Stephen
P.S. I am not that concerned if a host has 50 or even 100 tasks cached, as long at the rig can complete them and return a result WELL before deadline. But if everyone got behind a max of 0.99+0.0 then no task would need to wait more than a day for validation. However I completely agree with the settings that Keith has advocated. (Apart from the fact I already use the same :) )
This is true. I was just surprised by a petitioner request on one of my projects for more work by changing limits and the admin responded he would look into it this weekend.
But the issue here is with BOINC and with DA basically washing his hands of any further BOINC development, all we can hope for is Vitalli to pick up the burden. Which he has for the most part being the author of the latest Android and security commits. DA is just a button pusher now for merges submitted.
. . But is the work allocation governed solely by BOINC or can the project ops set their own limits? If they can surely they could set the max allocation to 5+5 regardless of the higher requests available within BOINC. That is the only change I believe would be needed to eliminate a large number of the needless resends.
Stephen
I would have to go back in and walk the work_fetch.cpp code in the user client and the scheduler code in the server client to see if the server admins have that control.
You are correct that if that is in the server code then project admins could certainly limit the amount work that a host can hold in its cache.
We just had a bump in the amount of work a host can hold at Universe this afternoon. But that is set outside of the default BOINC server client code configuration I think. If a project relies on the default BOINC server configuration files, then it inherits the default ten day limit without modification.
The key datapoint a person can use and adjust for is the average turnaround time of the host in the Details page of each host. You should strive to keep that figure right at 1 day or less by adjusting your cache levels.
The key datapoint a person can use and adjust for is the average turnaround time of the host in the Details page of each host. You should strive to keep that figure right at 1 day or less by adjusting your cache levels.
. . That comment sent me to my rig details pages. Each of them is right where it is supposed to be, they are all just a smidgen higher than my work fetch settings. Work fetch is 0.1, att is 0.12, the slow rig fetch is 0.33 and att is 0.35. So the system works :) And that is the reason I recommended a max of 0.99 (or maybe 0.98) to allow for that slippage.
I would have to go back in and walk the work_fetch.cpp code in the user client and the scheduler code in the server client to see if the server admins have that control.
Some Projects do send you tons of work even with a zero resource share, NFS and Latin squares comes to mind off the top of my head. They don't do it right away but after a few requests for tasks they will send hundreds of tasks for a quad cpu with a zero resource share. I think they are abusing the 'pre-fetch' settings to do it but am not sure as I can't read the code anymore.
I was a C++ guy who was forced to learn by doing it all by hand but once newer languages came along I walked away and let others learn, it was mostly just a hobby for me anyway keep the local Boy Scout and Professional Orgs sites going. I did have a paying gig but it was part-time and they had much better people than me doing it full-time so I volunteered to follow the clicks looking for dead ends and they loved that, me too as I could do it from home and still get paid.
Unless a newbie visits the Manager Options >> Computing Preferences page, Saves it to use Local Preferences, the preferences set globally on all projects is 10 days of cache. That is what is set up when a person first attaches to a project as a newbie would do installing BOINC for the first time. Those are the BOINC defaults.
...
Thanks for the info.
But when I set the prefs (or when they are automatically set) to 0.01 all I get is one or two WUs, regardless of the rig.
Why or how is this?
Because 0.01 days equates to about 14 minutes as Stephen mentioned. That is the typical time for a task to complete. So the client is only asking for the replacement task to replace the one currently crunching.
If you have outages in your network that doesn't allow you to continually turn in work and receive replacement you can bump your daily work request to 0.1 days or around there to get around 30 tasks in your cache.
That really is the only reason to hold more work in your cache is when you don't have an constant internet connection. Or you are advised in Notices that the project has a planned maintenance outage, then you can request more work to tide you over till the project is back online. But remember to reduce your request later when the project is back and you are back to returning/requesting work on a one for one basis.
@ Keith:
Thanks again, but what I was trying to point out, is that if a Newbie first contacts BOINC and doesn't "mess" around with the prefs, both prefs are set per default to 0.01 days of work. This gives me (maybe for others different), at the start of it all, ALWAYS ONE WU or max. two.
So, this is what I was trying to say or rather point out to the two previous posters -- so a Newbie shouldn't be having problems (i.e. overloaded cache).
You start with the default prefs and work your way up (0.02, 0.03, 0.04 etc.), till things balance out.
That is what I do/did.
Or am I missing out on something -- perhaps basics?
San-Fernando-Valley
)
Because 0.01 days equates to about 14 minutes as Stephen mentioned. That is the typical time for a task to complete. So the client is only asking for the replacement task to replace the one currently crunching.
If you have outages in your network that doesn't allow you to continually turn in work and receive replacement you can bump your daily work request to 0.1 days or around there to get around 30 tasks in your cache.
That really is the only reason to hold more work in your cache is when you don't have an constant internet connection. Or you are advised in Notices that the project has a planned maintenance outage, then you can request more work to tide you over till the project is back online. But remember to reduce your request later when the project is back and you are back to returning/requesting work on a one for one basis.
Tomahawk4196
)
No not really. The only people that have entertained that thought are the ones worried about the constant writing to disks that some projects and some applications do and are worried they are wearing out their new SSD or whatever.
In reality even the worst applications would only use up 1/10 of the TDW specifications in a year. The ones over at WCG come to mind.
Plus with a RAMDISK, if you lose power, all your work and BOINC states are lost. The amount of time BOINC does drive access is very minimal compared to the cpu and gpu crunching time.
Quote:(PS ~ I am trying to
)
The signature graphic on your Account >> Preferences >> Community pages is best done by NOT using the menu image or link icons. Best to input directly using BBCode formatting.
Also the signature graphics that I and many other have is culled from the stats aggregation sites where they produce the stats link formatting for you. You normally just cut and paste into the projects Community page signature section.
Some projects also have issues using https links for graphics and the workaround is simply replacing https with http.
Keith Myers wrote: This is
)
. . But is the work allocation governed solely by BOINC or can the project ops set their own limits? If they can surely they could set the max allocation to 5+5 regardless of the higher requests available within BOINC. That is the only change I believe would be needed to eliminate a large number of the needless resends.
Stephen
Tomahawk4196
)
. . If you are running BOINC from an SSD there would be very little or no benefit from using a RamDisk so you are better off leaving all your system RAM for BOINC apps to use. If not then I will mention that smaller SSD drives such as 60GB or 120GB are rather cheap these days and would be plenty for BOINC and several projects. I added 60GB SSDs on my earlier systems and 120GB on the later units. It is much cheaper than adding system RAM.
Stephen
Keith Myers wrote:Because
)
. . Also a very important part of the settings that Keith recommended, 0.01+0.0 or 0.1+0.0, is the 0.0 because it indicates the function of prompt reporting and work fetch.
Stephen
P.S. I am not that concerned if a host has 50 or even 100 tasks cached, as long at the rig can complete them and return a result WELL before deadline. But if everyone got behind a max of 0.99+0.0 then no task would need to wait more than a day for validation. However I completely agree with the settings that Keith has advocated. (Apart from the fact I already use the same :) )
Stephen "Heretic
)
I would have to go back in and walk the work_fetch.cpp code in the user client and the scheduler code in the server client to see if the server admins have that control.
You are correct that if that is in the server code then project admins could certainly limit the amount work that a host can hold in its cache.
We just had a bump in the amount of work a host can hold at Universe this afternoon. But that is set outside of the default BOINC server client code configuration I think. If a project relies on the default BOINC server configuration files, then it inherits the default ten day limit without modification.
The key datapoint a person can use and adjust for is the average turnaround time of the host in the Details page of each host. You should strive to keep that figure right at 1 day or less by adjusting your cache levels.
Keith Myers wrote: The key
)
. . That comment sent me to my rig details pages. Each of them is right where it is supposed to be, they are all just a smidgen higher than my work fetch settings. Work fetch is 0.1, att is 0.12, the slow rig fetch is 0.33 and att is 0.35. So the system works :) And that is the reason I recommended a max of 0.99 (or maybe 0.98) to allow for that slippage.
Stephen
Keith Myers wrote: I
)
Some Projects do send you tons of work even with a zero resource share, NFS and Latin squares comes to mind off the top of my head. They don't do it right away but after a few requests for tasks they will send hundreds of tasks for a quad cpu with a zero resource share. I think they are abusing the 'pre-fetch' settings to do it but am not sure as I can't read the code anymore.
I was a C++ guy who was forced to learn by doing it all by hand but once newer languages came along I walked away and let others learn, it was mostly just a hobby for me anyway keep the local Boy Scout and Professional Orgs sites going. I did have a paying gig but it was part-time and they had much better people than me doing it full-time so I volunteered to follow the clicks looking for dead ends and they loved that, me too as I could do it from home and still get paid.
Keith Myers
)
@ Keith:
Thanks again, but what I was trying to point out, is that if a Newbie first contacts BOINC and doesn't "mess" around with the prefs, both prefs are set per default to 0.01 days of work. This gives me (maybe for others different), at the start of it all, ALWAYS ONE WU or max. two.
So, this is what I was trying to say or rather point out to the two previous posters -- so a Newbie shouldn't be having problems (i.e. overloaded cache).
You start with the default prefs and work your way up (0.02, 0.03, 0.04 etc.), till things balance out.
That is what I do/did.
Or am I missing out on something -- perhaps basics?
Have a nice Sunday ...