The typical response if there is no credit for the work sent will just to be to turn off the computer. The loss of computing power will be enormous as only the fastest computers will be left. Not everyone has the cash to buy a new computer every 6 months, and the old ones are doing useful work.
The projects could only send out the exact number of required results, and then only send out replacements as needed. The expected savings in CPU time will be less than 25% as there are some WUs that are sent that never come back for one reason or another - and it could be as low as 0%. Neither of us has the information to accurately answer this, but we can put bounds on the savings. The project administrators do have this information.
I did say that I expected that the majority of users would prefer to save the CPU-time in lieu of the result being superfluous, but this is just sucking information out of my thumb. I don't know one way or the other.
I did say it could be implemented as a preference in the client. I realised that it would be inappropriate to enforce a policy that denies credit.
Anyhow, that is moot. I don't see that it is worthwhile, in light of the fact that the wasted CPU-time will tend to be less efficient CPU-time. I don't mean to lessen the role of slower computers, they serve to fill these redundant fourth positions, thereby increasing the efficiency of the fast hosts.
I agree that doing away with the fourth host per work unit is inappropriate.
In fact, let me state that more firmly. Any host that can submit a result before the deadline is valuable to the project. Whether they are K6-200's or Opterons, all are important and are making a contribution. Even if only one result is sent per week, it is valuable.
I wouldn't like it if anyone got the wrong idea from what I have said previously.
The main question hear is really how many of the 4th hosts would contact the server between the decision that enough results are received and the 4th host is finished crunching that WU. The next question would be: how can we make that number bigger? If the extra load on the servers because of this is minimal, i think it could be worth it, because i think we can find ways to make this number bigger. I think that the projects that most would benefit from this is SETI and LHC because of there long deadline.
Of the work saved hear, at the most 25% will be wasted at a later stage. Speed is something relative. It doesn't really matter how fast things are done, as long as it is done fast enough to be useful. If this host is the 4th host next time, it will prevent a faster host from being 4th.
Then you're really interested in a subject, there is no way to avoid it. You have to read the Manual.
Of the work saved here, at the most 25% will be wasted at a later stage
It can't possibly be as much as 25%, because the earliest the fourth host could be notified would be after the other 3 are done. Even if the hosts could be notified immediately (which of course they can't), the saving would probably be (thumb suck) 5% or less. Not all hosts would contact the server before they finished anyhow, so (to my mind) we are looking at a couple of percent at best.
If the hosts communicated with the server more frequently, it could save slightly more, but that would limit scalability.
So it really is not worthwhile to implement.
Also realise that the saving is proportional to (AllocatedHosts-RequiredResults)/AllocatedHosts. That fraction is 25% for Einstein, but for others it is probably far less.
I think you misunderstood me. If we can prevent that one WU is crunched unnecessary, that would mean that host have time to crunch one extra WU. If this extra WU is 1 of 3 actually crunched, then the extra WU is used 100%. if it is 1 of 4 then 25% of that extra WU is wasted.
Then you're really interested in a subject, there is no way to avoid it. You have to read the Manual.
I think you misunderstood me. If we can prevent that one WU is crunched unnecessary, that would mean that host have time to crunch one extra WU. If this extra WU is 1 of 3 actually crunched, then the extra WU is used 100%. if it is 1 of 4 then 25% of that extra WU is wasted.
My point was you can't save an entire WU from getting crunched, you can save on average about 20% of that final host's processing. I guessed that the fourth host would be about 80% complete on average when the third finished. 20% of 1/4 is 5%. That's where I got that.
A saving is a saving. The next WU has the same chance of a saving. On average, each work unit would experience the saving obviously, because we are talking on average. The slowest in the next 4 will have the same opportunity of a saving.
The work done on the 4th WU before we can stop it is wasted. The time left to completion is saved. It's this time i was referring to with this:
Quote:
Of the work saved here, at the most 25% will be wasted at a later stage
and nothing else.
Okay, I see what you are saying now, but I disagree. Work saved is work saved. If preempting the superfluous work saves two hours, those two hours are saved. The host will be ready to accept another WU 2 hours earlier. Of course the 2 hour saving is relative to the size of the project. Also one must realise, and I said this before, that those saved CPU-hours will tend to be less efficient CPU-hours, which is why I think the average saving will only be a couple of percent.
If I am still missing the point of what you are saying, please explain.
If you mean to say that the saved time will similarly get wasted in the future, I would respond that that is totally irrelevant. Saving time is better than not saving time. If it saves two hours per work unit, it saves them.
If you mean to say that the saving is not worth much, I agree. But really, unless more time gets wasted in the future, a saving is good. The time wasted in the future work units is no more with a saving than without, so it is irrelevant. In fact, there is potential for all WU's to save time.
RE: The typical response if
)
I did say that I expected that the majority of users would prefer to save the CPU-time in lieu of the result being superfluous, but this is just sucking information out of my thumb. I don't know one way or the other.
I did say it could be implemented as a preference in the client. I realised that it would be inappropriate to enforce a policy that denies credit.
Anyhow, that is moot. I don't see that it is worthwhile, in light of the fact that the wasted CPU-time will tend to be less efficient CPU-time. I don't mean to lessen the role of slower computers, they serve to fill these redundant fourth positions, thereby increasing the efficiency of the fast hosts.
I agree that doing away with the fourth host per work unit is inappropriate.
In fact, let me state that
)
In fact, let me state that more firmly. Any host that can submit a result before the deadline is valuable to the project. Whether they are K6-200's or Opterons, all are important and are making a contribution. Even if only one result is sent per week, it is valuable.
I wouldn't like it if anyone got the wrong idea from what I have said previously.
The main question hear is
)
The main question hear is really how many of the 4th hosts would contact the server between the decision that enough results are received and the 4th host is finished crunching that WU. The next question would be: how can we make that number bigger? If the extra load on the servers because of this is minimal, i think it could be worth it, because i think we can find ways to make this number bigger. I think that the projects that most would benefit from this is SETI and LHC because of there long deadline.
Of the work saved hear, at the most 25% will be wasted at a later stage. Speed is something relative. It doesn't really matter how fast things are done, as long as it is done fast enough to be useful. If this host is the 4th host next time, it will prevent a faster host from being 4th.
Then you're really interested in a subject, there is no way to avoid it. You have to read the Manual.
RE: Of the work saved here,
)
It can't possibly be as much as 25%, because the earliest the fourth host could be notified would be after the other 3 are done. Even if the hosts could be notified immediately (which of course they can't), the saving would probably be (thumb suck) 5% or less. Not all hosts would contact the server before they finished anyhow, so (to my mind) we are looking at a couple of percent at best.
If the hosts communicated with the server more frequently, it could save slightly more, but that would limit scalability.
So it really is not worthwhile to implement.
Also realise that the saving is proportional to (AllocatedHosts-RequiredResults)/AllocatedHosts. That fraction is 25% for Einstein, but for others it is probably far less.
RE: Also realise that the
)
Actually it's probably not proportional. The point is it's infeasible.
I think you misunderstood me.
)
I think you misunderstood me. If we can prevent that one WU is crunched unnecessary, that would mean that host have time to crunch one extra WU. If this extra WU is 1 of 3 actually crunched, then the extra WU is used 100%. if it is 1 of 4 then 25% of that extra WU is wasted.
Then you're really interested in a subject, there is no way to avoid it. You have to read the Manual.
RE: I think you
)
My point was you can't save an entire WU from getting crunched, you can save on average about 20% of that final host's processing. I guessed that the fourth host would be about 80% complete on average when the third finished. 20% of 1/4 is 5%. That's where I got that.
A saving is a saving. The next WU has the same chance of a saving. On average, each work unit would experience the saving obviously, because we are talking on average. The slowest in the next 4 will have the same opportunity of a saving.
The work done on the 4th WU
)
The work done on the 4th WU before we can stop it is wasted. The time left to completion is saved. It's this time i was referring to with this:
and nothing else.
Then you're really interested in a subject, there is no way to avoid it. You have to read the Manual.
RE: The work done on the
)
Okay, I see what you are saying now, but I disagree. Work saved is work saved. If preempting the superfluous work saves two hours, those two hours are saved. The host will be ready to accept another WU 2 hours earlier. Of course the 2 hour saving is relative to the size of the project. Also one must realise, and I said this before, that those saved CPU-hours will tend to be less efficient CPU-hours, which is why I think the average saving will only be a couple of percent.
If I am still missing the point of what you are saying, please explain.
If you mean to say that the
)
If you mean to say that the saved time will similarly get wasted in the future, I would respond that that is totally irrelevant. Saving time is better than not saving time. If it saves two hours per work unit, it saves them.
If you mean to say that the saving is not worth much, I agree. But really, unless more time gets wasted in the future, a saving is good. The time wasted in the future work units is no more with a saving than without, so it is irrelevant. In fact, there is potential for all WU's to save time.