That's a little unfair since the scheduler can't know whether or not you intend to run future tasks of this type. Whilst there are quorums outstanding that require this data, the files wont be deleted, since there may be an opportunity to send you more of the same. Once there are no tasks remaining for a particular set, the client will be advised to delete the data. Premature deletion restricts the scheduler's choice of suitable hosts to use for further tasks (locality scheduling).
it's not unfair, it's how it is/was. i have a handful of systems that run Einstein as a backup project from time to time (whenever GPUGRID is out of work). all systems run Einstein with the same relative frequency and timeline. one system was retaining ~2.5GB while the others only had a few hundred MB. so obviously something was hung up on the one system to cause it to hold on to so much. resetting the project resolved it and the retained data when out of work stayed low.
Gary Roberts wrote:
Resetting is fine if the volunteer has finished running these GW CPU tasks.
*snip excess circumlocution*
which is exactly why i said "when all tasks are completed and reported and no tasks on the system"
and the OP mentioned that he had run the project for a LONG time with the 5GB limit in place without issue. so he could be in the same situation of just retaining too much old data. but if he's content with the simple limit change, then that's fine too.
I tend to use .... to indicate deleted material in a quote. If you wish to deliver an insult, it probably should be outside the quote so as not to create a wrong impression about who said what.
Ian&Steve C. wrote:
which is exactly why i said "when all tasks are completed and reported and no tasks on the system" ....
So Einstein is a backup project for you that gets called when needed. I would like others that don't have your experience to understand the consequences of throwing away a bunch of apps and data which could be called upon at a moment's notice.
If the main project can't supply, Einstein could be used without a new download penalty. Even if primary tasks have finished, a new request could easily get some resend tasks for the previous data. Saves those resends possibly being sent to a host that didn't already have the data.
For users running the project permanently, keeping the older data provides the scheduler with a wider choice for allocating resends. This becomes increasingly important as time goes by.
I should thank you for the insult though, since it might get casual readers who skipped the previous discussion to go back and see what the fuss was about. If that happens, all the better.
You were never the intended audience for the "circumlocution", which would have been abundantly clear to you. You were promoting a 'quick fix' solution that potentially wastes bandwidth. I chose to present the reasons why there were hidden consequences.
Your avatar suggests you may have some affiliation or connection with, or perhaps a more general interest in NASA. I happen to regard NASA as one of the most important US government funded organisations that exists and that it should be well resourced and supported. When such entities have to cope with continual budget restrictions over the years, they have to learn to do more with less. It can't have been easy for them.
Einstein@Home also needs to do more with less. On a daily basis, we see indications of a project that is under pressure - eg. the uploads problem last weekend. If a casual user can appreciate the benefit from putting up with a few temporary GBs of disk space to save some unnecessary bandwidth wastage, it would be worth the effort of properly explaining all the pros and cons.
So I'll continue with my "circumlocution" in the hope that some may take the time to consider the impact of the various choices that they come across.
i can say with certainty that having to re-download the files that might actually be needed while cleaning up ones that aren't, 1. is better overall for someone who is trying to constrain BOINC to never use X amount of disk space, and 2. isnt going to make or break things for the client or the server. the project isnt paying for internet access based on usage. and the project issues referenced aren't due to bandwidth limits. similarly very few people these days are paying for internet based on data use, and any person who would be paying for internet access based on data use isnt going to be running a BOINC project with tons of data moving back and forth. you're exaggerating the impact of a handful of people resetting the project to clean up old files. IF THEY WANT TO.
but you seem to be painting contradicting pictures here. on one hand you make it seem like a client wont be able to process certain tasks without the old files (which implies that you wont download them again), but then on the other hand we have this dystopian world where the project servers are suffering if they have to send you the same old files again. but if the former is true, then the latter wont happen. which is it?
go ahead and reset the project if one wants, it wont hurt anything and it wont affect your ability to crunch for this project. if the project wants to send you some of those old WUs again, you'll just download the files again, no harm done.
but that wasn't even my first suggestion anyway, I actually was on board with the OP checking his compute preferences and increasing that BOINC disk allotment value, which is the quick fix the OP implemented here.
sure, maybe the project has to do more with less, but that almost always means less personnel and more automation, not internet bandwidth.
Gary Roberts wrote:That's a
)
it's not unfair, it's how it is/was. i have a handful of systems that run Einstein as a backup project from time to time (whenever GPUGRID is out of work). all systems run Einstein with the same relative frequency and timeline. one system was retaining ~2.5GB while the others only had a few hundred MB. so obviously something was hung up on the one system to cause it to hold on to so much. resetting the project resolved it and the retained data when out of work stayed low.
which is exactly why i said "when all tasks are completed and reported and no tasks on the system"
and the OP mentioned that he had run the project for a LONG time with the 5GB limit in place without issue. so he could be in the same situation of just retaining too much old data. but if he's content with the simple limit change, then that's fine too.
_________________________________________________________________________
I tend to use .... to
)
I tend to use .... to indicate deleted material in a quote. If you wish to deliver an insult, it probably should be outside the quote so as not to create a wrong impression about who said what.
So Einstein is a backup project for you that gets called when needed. I would like others that don't have your experience to understand the consequences of throwing away a bunch of apps and data which could be called upon at a moment's notice.
If the main project can't supply, Einstein could be used without a new download penalty. Even if primary tasks have finished, a new request could easily get some resend tasks for the previous data. Saves those resends possibly being sent to a host that didn't already have the data.
For users running the project permanently, keeping the older data provides the scheduler with a wider choice for allocating resends. This becomes increasingly important as time goes by.
I should thank you for the insult though, since it might get casual readers who skipped the previous discussion to go back and see what the fuss was about. If that happens, all the better.
You were never the intended audience for the "circumlocution", which would have been abundantly clear to you. You were promoting a 'quick fix' solution that potentially wastes bandwidth. I chose to present the reasons why there were hidden consequences.
Your avatar suggests you may have some affiliation or connection with, or perhaps a more general interest in NASA. I happen to regard NASA as one of the most important US government funded organisations that exists and that it should be well resourced and supported. When such entities have to cope with continual budget restrictions over the years, they have to learn to do more with less. It can't have been easy for them.
Einstein@Home also needs to do more with less. On a daily basis, we see indications of a project that is under pressure - eg. the uploads problem last weekend. If a casual user can appreciate the benefit from putting up with a few temporary GBs of disk space to save some unnecessary bandwidth wastage, it would be worth the effort of properly explaining all the pros and cons.
So I'll continue with my "circumlocution" in the hope that some may take the time to consider the impact of the various choices that they come across.
Cheers,
Gary.
i can say with certainty that
)
i can say with certainty that having to re-download the files that might actually be needed while cleaning up ones that aren't, 1. is better overall for someone who is trying to constrain BOINC to never use X amount of disk space, and 2. isnt going to make or break things for the client or the server. the project isnt paying for internet access based on usage. and the project issues referenced aren't due to bandwidth limits. similarly very few people these days are paying for internet based on data use, and any person who would be paying for internet access based on data use isnt going to be running a BOINC project with tons of data moving back and forth. you're exaggerating the impact of a handful of people resetting the project to clean up old files. IF THEY WANT TO.
but you seem to be painting contradicting pictures here. on one hand you make it seem like a client wont be able to process certain tasks without the old files (which implies that you wont download them again), but then on the other hand we have this dystopian world where the project servers are suffering if they have to send you the same old files again. but if the former is true, then the latter wont happen. which is it?
go ahead and reset the project if one wants, it wont hurt anything and it wont affect your ability to crunch for this project. if the project wants to send you some of those old WUs again, you'll just download the files again, no harm done.
but that wasn't even my first suggestion anyway, I actually was on board with the OP checking his compute preferences and increasing that BOINC disk allotment value, which is the quick fix the OP implemented here.
sure, maybe the project has to do more with less, but that almost always means less personnel and more automation, not internet bandwidth.
_________________________________________________________________________
Thank you everyone who
)
Thank you everyone who replied.
I ended up setting the disk reservation to 15 Gb, which should be enough for a while unless the program needs lots more.
And the explanations as to what the program is doing were most enlightening.
Thanks again.