I really think 7 days is way too short for Einstein@Home. I would really suggest doubling that, at the least, to 14 days. Consider:
-10% of 168 hours is 16.8 hours - which according to your figures is enough for two E@H WUs on a modern machine running E@H exclusively.
-Subtract the fact that most users will run SETI@Home at the same priority level - now E@H gets 5% of those 168 hours, or 8.4 hours, and can finish out a single WU without going overtime.
-Now consider that many users will run even more projects - now E@H can't finish in time.
-And many users do not have the latest and greatest machines, making the problem worse.
I understand that E@H is still in its testing phase, and therefore the scientists in charge want a quicker turnaround of the WUs they send out, so they can make sure the whole system is working correctly. But definitely extend the time limit once E@H is "fully" public. Which imposes more delay - a resent WU with a 7-day time limit, or a completed WU with a 14-day time limit?
Bah! I think 7 days is more than adequate for the project. If it means a little more intelligent resource allocation on the part of some users, then so be it. There's no reason at all why you can't E@H exclusively on 1 machine and S@H on another. Granted, some folks are limited to a single machine, which might mean a little more planning on their part. But at no point has anyone put a gun to your head and demanded that you run the E@H project - if you don't like the time parameters of when the WUs must be completed, then hey, simple solution - DON'T RUN IT!!
"Chance is irrelevant. We will succeed."
- Seven of Nine
If it's possible, the WUs themselves should be split according to need and availibility of processing power. Each WU sent out should be doled out so that the end user's CPU will be able to complete the WU as per their cache setting. That way we can predict the worst-case turnaround.
Let's say that a user has a one-day cache for each project: That's six days' worth of work. Assuming that each project gives every user a custom-tailored WU to match their processing power (a lofty assumption, I know), then we can definitely expect turnaround to take no longer than a week.
Users aren't stupid - If you've got a slow machine, you're not going join all of the BOINC projects. But if the WUs are portioned according to the host's abilities and cache, then the deadlines can be reduced without causing too much trouble.
> For whats it's worth Pro Predictor is at a 7 day Deadline also. Personally I
> think all the Projects should adopt the 7 Day Deadline & stick with it. It
> might alleviate some of the complaining about delays in getting credit.
Hmm, I thought credit complaints would be a low priority.
The biggest problem is that BOINC daemon will download too much work from too many projects. Sign up for two or three projects on a slow machine, and you discover that everything is returned late. If you don't sign up for several projects there is the distinct probability that you will be out of work at some time and your computer will be completely idle. The fix has to include information about all of the work on the host, the long term debt and the resource shares.
I have a couple of machines that for whatever reason take about 70 to 100 hours for a single Einstein WU. BOINC should be automatically restricting these to one project at a time. My cache is 0.1 days.
100 hours for a single WU!? That's amazingly slow. If it is that slow, I would think that YOU would know to sign up for only ONE project on those machines. Assign the reallly slow machines to ONE project, set their cache for .1 days and I doubt you would have any problems.
Eeek!! that sounded a bit aggressive and I didn't mean to give that impression so I hope your not offended, just trying to be helpful.
I really think 7 days is way
)
I really think 7 days is way too short for Einstein@Home. I would really suggest doubling that, at the least, to 14 days. Consider:
-10% of 168 hours is 16.8 hours - which according to your figures is enough for two E@H WUs on a modern machine running E@H exclusively.
-Subtract the fact that most users will run SETI@Home at the same priority level - now E@H gets 5% of those 168 hours, or 8.4 hours, and can finish out a single WU without going overtime.
-Now consider that many users will run even more projects - now E@H can't finish in time.
-And many users do not have the latest and greatest machines, making the problem worse.
I understand that E@H is still in its testing phase, and therefore the scientists in charge want a quicker turnaround of the WUs they send out, so they can make sure the whole system is working correctly. But definitely extend the time limit once E@H is "fully" public. Which imposes more delay - a resent WU with a 7-day time limit, or a completed WU with a 14-day time limit?
Bah! I think 7 days is more
)
Bah! I think 7 days is more than adequate for the project. If it means a little more intelligent resource allocation on the part of some users, then so be it. There's no reason at all why you can't E@H exclusively on 1 machine and S@H on another. Granted, some folks are limited to a single machine, which might mean a little more planning on their part. But at no point has anyone put a gun to your head and demanded that you run the E@H project - if you don't like the time parameters of when the WUs must be completed, then hey, simple solution - DON'T RUN IT!!
"Chance is irrelevant. We will succeed."
- Seven of Nine
That's not encouragement to
)
That's not encouragement to crunch for Einstein.
If it's possible, the WUs themselves should be split according to need and availibility of processing power. Each WU sent out should be doled out so that the end user's CPU will be able to complete the WU as per their cache setting. That way we can predict the worst-case turnaround.
Let's say that a user has a one-day cache for each project: That's six days' worth of work. Assuming that each project gives every user a custom-tailored WU to match their processing power (a lofty assumption, I know), then we can definitely expect turnaround to take no longer than a week.
Users aren't stupid - If you've got a slow machine, you're not going join all of the BOINC projects. But if the WUs are portioned according to the host's abilities and cache, then the deadlines can be reduced without causing too much trouble.
2¢
Hello guys, I'm running 4
)
Hello guys,
I'm running 4 or more projects on my clients, regardless of the power of the machine.
My slower boxes are 600 - 800 MHz, they never missed a deadline of any project !
My cache setting is set to 0.5 days.
My oldest and slowest machine is a 166 MHz box; it is running ALL projects except CPDN. Even this machine finishes WU's before the deadline is over !
So, if you want to participate und don't have a modern box, this should not really be a problem.
Supporting BOINC, a great concept !
My 200 MHz machine which
)
My 200 MHz machine which returned WU's within 70 hours (it was doing E@H 100%) hasn't gotten a WU in quite a while now.... :-(
Now that E@H has been
)
Now that E@H has been launched to the public, will the reporting date be extended to 2 weeks?
> My 200 MHz machine which
)
> My 200 MHz machine which returned WU's within 70 hours (it was doing E@H 100%)
> hasn't gotten a WU in quite a while now.... :-(
This is because we increased the memory requirements to 70 MB, and your machine has 64 MB. It has nothing to do with the deadlines!
Dont' the messages in the BOINC GUI tell you that no work is arriving because you don't have enough memory?
The next app version should use less memory, so in a little while this machine should again be able to run E@H.
Bruce
Director, Einstein@Home
> For whats it's worth Pro
)
> For whats it's worth Pro Predictor is at a 7 day Deadline also. Personally I
> think all the Projects should adopt the 7 Day Deadline & stick with it. It
> might alleviate some of the complaining about delays in getting credit.
Hmm, I thought credit complaints would be a low priority.
The biggest problem is that
)
The biggest problem is that BOINC daemon will download too much work from too many projects. Sign up for two or three projects on a slow machine, and you discover that everything is returned late. If you don't sign up for several projects there is the distinct probability that you will be out of work at some time and your computer will be completely idle. The fix has to include information about all of the work on the host, the long term debt and the resource shares.
I have a couple of machines that for whatever reason take about 70 to 100 hours for a single Einstein WU. BOINC should be automatically restricting these to one project at a time. My cache is 0.1 days.
BOINC WIKI
100 hours for a single WU!?
)
100 hours for a single WU!? That's amazingly slow. If it is that slow, I would think that YOU would know to sign up for only ONE project on those machines. Assign the reallly slow machines to ONE project, set their cache for .1 days and I doubt you would have any problems.
Eeek!! that sounded a bit aggressive and I didn't mean to give that impression so I hope your not offended, just trying to be helpful.