The deadline needs to be fixed on Einstein@Home. I have Einstein@Home running on an old Pentium II computer that I only run for a few hours a day except on weekends, when I run it all day. However, if I go anywhere on the weekend, I leave the computer off, and it doesn't have time to meet the deadline. I think this problem should be fixed.
Copyright © 2024 Einstein@Home. All rights reserved.
Deadline Problem
)
Crunching this way doen't make sense due to the size of the WU's, Increasing the deadline neither since most modern putters finish it in only 9 hours; as WU's are only sent to 3 to 4 machines people have to wait very long to get results validated, also for the E@H folks not intresting.
Day's for this type of machine are gone, I am afraid of.
John,
> Day's for this type of
)
> Day's for this type of machine are gone, I am afraid.
Thats a bit of a snobby attitude. Many people - in fact even many companies (I work in IT) keep older computers around because they do the job. Should I upgrade my PII router to an itanium? The extra speed isnt going to make my packets flow any faster. Should I spend money upgrading the spare machine that I dont use any more, but which sits around for general internet access by friends and guests?
Companies dont like changing things that work because as anyone in IT should know, whenever there is a problem, the first question is "What changed?". Indeed most decent problem management systems are integrated into the change management system... but I digress.
Even on faster machines I am missing deadlines. I have detached a PIII already because it couldnt make the deadline while sharing 50/50 with S@H (despite the math indicating that it should). Im considering detaching an AMD2500+ too (runs 4 projects) for the same reasons - its not making the E@H deadline at times.
The deadline is simply too short. The best proof of this is that it is shorter than the 10 days of the user configurable "max connect" setting. Also many supposedly informed people suggest setting this to 0.1 days for Einstein, which is ridiculous and defeats the purpose (to cache work to cater for project downtime), It is a global parameter so setting it for one project sets it for all.
Add to this that boinc seems to be slightly generous in the amount of work that it queues and you have a real problem.
We dont need instant gratification. I can wait weeks or months if need be for credit to be awarded (as long as it is awarded and my efforts are not for nothing). The projects should remember that if it wasnt for we volunteers, that they would be waiting for hundreds of years for their results. Whats a few more days or weeks?
Yes. Increasing the deadline
)
Yes.
Increasing the deadline by 7 days would allow my PII and in use laptop to get back to crunching E@H.
Truth be told, these machines may better serve SETI and Predictor.
> The deadline needs to be
)
> The deadline needs to be fixed on Einstein@Home. I have Einstein@Home running
> on an old Pentium II computer that I only run for a few hours a day except on
> weekends, when I run it all day. However, if I go anywhere on the weekend, I
> leave the computer off, and it doesn't have time to meet the deadline. I
> think this problem should be fixed.
There is nothing "wrong" with the deadline with Einsten@Home or Predictor@Home; even though both use 7 days. The models take a certain amount of processing to complete. If your computer cannot complete them within this window, then it is not the fault of the project or the deadline.
Just because you have a hammer in your hand does not mean that the object in your other hand is a nail. Your computer is slow compared to today's machines. As you stated, there is nothing wrong with it. However, your attempt to use this machine inappropriately is misapplied. However strong your desire to support Einstein@Home this machine with the constraints of operating time is just not the right tool for this job.
Projects with work that takes less time to complete is a far more appropriate
place to use this resource.
> Crunching this way doen't
)
> Crunching this way doen't make sense due to the size of the WU's, Increasing
> the deadline neither since most modern putters finish it in only 9 hours; as
> WU's are only sent to 3 to 4 machines people have to wait very long to get
> results validated, also for the E@H folks not intresting.
> Day's for this type of machine are gone, I am afraid of.
>
I have to agree with Todd Wright on this one... What you are saying is fine for those who only have the one project running on each PC. I have two machines, one, an Athlon 1900+ running 24/7 with 4 projects (S@H, LHC, CPDN & E@H), the other an Athlon64 FX53 (2400+) running most of the day, every day, also running 4 projects (S@H, PP@H, LHC & E@H).
Whilst the 64 can keep up, the 1900+ is pushing it's deadlines most of the time. Usually it just about makes it, but if there is a power cut for example, it fails to make the deadline. There have been two of these said power cuts in the last week and I have already lost credit for three late WUs as a result. If I can't get the current one finished by tonight, I'll be adding another one to this list. Read here if you don't believe me!
Also when thinking about deadlines you need to think about those who connect infrequently and cache up WUs to upload all the results at once. With deadlines as they are, this feature of BOINC can't be used when other projects are running.
As for Paul's comment that PIIs are too slow, I agree, but often universities and businesses re-use these beasts in "Junker Farms" which are set going on exactly this sort of research. We are thinking of setting up one of these after the local computer club moves. The fastest machine to go on this will probably be a PII 450 down to maybe Pent. 200s/486DX4s. Basically our Linux servers and a few of the better machines that we'd otherwise scrap. IE anything lower than 300MHz.
Deadlines NEED to be longer if you want to encourage more users to the project. All those who solely do this for high credit rankings should be thinking about those of us who do it for the science and have a bit of patience when waiting for their credit to rack up. If S@H is capable of giving people longer to do the work, why can't Einstein???
> I have to agree with Todd
)
> I have to agree with Todd Wright on this one... What you are saying is fine
> for those who only have the one project running on each PC. I have two
> machines, one, an Athlon 1900+ running 24/7 with 4 projects (S@H, LHC, CPDN
> & E@H), the other an Athlon64 FX53 (2400+) running most of the day, every
> day, also running 4 projects (S@H, PP@H, LHC & E@H).
>
(Sometimes) life is all about making choices, so I made the choice to run only E@H on my machine and do as many WU's as possible not for the points, just for the project.
I also have a cluster of older hardware that just cant't be run because of limitations in the boinc code for clustering at the moment, that's a bit the way it is.
>
> Deadlines NEED to be longer if you want to encourage more users to the
> project. All those who solely do this for high credit rankings should be
> thinking about those of us who do it for the science and have a bit of
> patience when waiting for their credit to rack up. If S@H is capable of giving
> people longer to do the work, why can't Einstein???
>
>
As I understood from previous threads, the project relies on quick feedback for the data models to evaluate, so it is not only a matter of points.
If possible, the creation of smaller WU's could be a solution for the slower machines, but I'm not in a position to evaluate this.
Maybe a project developer could comment on this ?
John,
Smaller WUs is another way to
)
Smaller WUs is another way to go, yeah... Twice the number half the size I would guess would be the first step. See if this eases deadline problems, as long as they don't shorten the deadlines further!
I just can't bear losing credit for WUs that would have completed in time had it not been for the power failures. Einstein just needs some sort of leeway for these eventualities. A lot of the time an extension of just 2 or 3 days would give me comfort zone enough that I could get the WU back before the expiration date.
The problem with the P2 could
)
The problem with the P2 could be resolved by leaving it turned on more often.
However the problem with Einstein is real. The problem isn't the deadline, however, but the rsc_fpops_est value for each WU. It doesn't reflect, using current code, the actual ammount of time a WU will take to crunch on a given host.
By way of comparison, try checking a simple math equation.
On any one of your hosts that is doing multiple projects...
1. Write down the estimated completion time of any Einstein WU.
2. Write down the actual average completion time.
(you can look on the web on your "Your Account -> My computers -> [some host] -> Results" link. These are listed in seconds, so convert to hour:minute)
3. Divide the estimated by the actual.
4. Now do steps 1 to 3 for any other project.
What numbers do you come up with? (List your CPU, Mhz Speed, Hyperthread etc.)
Posts on this subject are
)
Posts on this subject are bound to grow as summer approaches ... heat will force many to reduce their crunching hours. Fewer hours -> more deadlines missed.
> Whilst the 64 can keep up,
)
> Whilst the 64 can keep up, the 1900+ is pushing it's deadlines most of the
> time. Usually it just about makes it, but if there is a power cut for example,
> it fails to make the deadline. There have been two of these said power cuts in
> the last week and I have already lost credit for three late WUs as a result.
I'm wondering if you might need to do some tinkering with your resource share. My Athlon 850 is running Einstein, ProteinPredictor, SETI, Pirates (occasionally), and a pre-alpha project. It has no problems returning results for all projects on time.