This subject is coming up constantly now, with the inevitable comparison to SETI. The piece that is missing from most people's mind in regards to SETI's deadlines...
I am not sure, that I am understanding correct, what do You say...
At 1st - my mind is OK. :) Not OK are my hosts, attached to Einstein@home (a part of them). Some time ago they started "Sizif's job"...
And comparison is not inevitable to SETI, take a look to deadline politics in CPDN, as I wrote...
Today I need to decide, which my hosts can stay here and which - not (are to slow or not permanently online).
I hope, project chiefs (or managers) will help me to make this decision... :) How to help me? Simple answer me to this question, please... Can we hope, that time limits for crunching Einstein@home WU's can (or will) be raised in the future?
I hope, project chiefs (or managers) will help me to make this decision... :) How to help me? Simple answer me to this question, please... Can we hope, that time limits for crunching Einstein@home WU's can (or will) be raised in the future?
As you point out languages issues can make it difficult to convey humor and subtle detail accurately. So apologies for any confusion Brian and I may have caused for you here.
However, you are certainly correct in saying that as time has passed, EAH has become a more demanding project to run for part time crunching and older hosts.
Both Brian and I have argued the case for extending the deadlines in general, or implementing a variable deadline system of some sort (like SAH does). In defense of the project, they are aware of the issue, but like most other projects there have been other more pressing concerns to deal with.
You know, the old "So much to do, so little time (and cash)..." scenario. ;-)
The project team could change the 221 policy to zap a result even if it had been started... ;)
@metalius - this is an inside joke, I'm not serious.
How do You think, I understood your joke or not? Answer is not!!! :) For example, "the 221 policy to zap.." says me... totally nothing. :)
And don't forget - not all the people in the world are "English speaking", a lot of people (like me) never studied English at school.
This was some kind of joke too. :) Good luck!
I knew Alinator would get what I was talking about, but I had to safeguard against you knowing what I was talking about and thinking that I was serious.
At any rate, I think he has explained it. I wasn't thinking about explaining it completely, as I wasn't really serious anyway and I had company that had just shown up at the door, so I had to go...
As far as PIII capability goes; I have a 550 MHz Katmai (which is down with a bad hard drive currently). However, my personal database for it shows it had been running S5R3 tasks in about 90,000 seconds each on average so far. This means I would only have to run the machine roughly 6430 seconds per day to meet the deadline if EAH were the only project I ran on it. I'm not sure why your PIII would need 100 hours (roughly 5 times more than mine) to run an EAH task at this point in S5R3, since any later Socket 370 PIII should be able to make the deadline under the uptime constraints you mentioned with ease right now.
Could be a bad RDCF or a low benchmark. With the computer being hidden, we also cannot see his OS and application being used (the old 4.02 Linux app was slow).
Also, we know that there are at least two projects on the system, as comparisons are drawn to SETI. Thus one also has to take into account the resource allocation shares.
You apparently have a better knack of talking about this stuff than I do, so if he has questions, I defer to you to answer if you'd like... I have to try to concentrate on my Java classwork for the next couple of days...
I find this whole thing ridiculous. First off comparing SETI to Einstein is not comparing anything. They are different projects owned by different entities. They do not have to follow anyone else's rules.
Next, the project asks you to help, if you feel you can help under THEIR guidelines, not under yours. This project has some deadlines it wants to meet and it may not be able to extend your deadlines to meet their deadlines.
I have worked in many situations where there are certain time-lines, etc. that need to be watched. The project is doing the settings for what they believe they need to keep the project on schedule.
So the simple answer is, if you can not follow what the project requests, then find a new project. There are plenty of us that can and do get the results in plenty of time.
I am not sure, that I am understanding correct, what do You say...
Part of that is probably due to my not wanting to explain the entire design of the work-fetch, deadlines, estimates, and cpu scheduler processes that are built into BOINC. To really talk about what you're trying to talk about, you have to at least have a basic understanding of a few things. Our native language barrier is only going to cause the explanation process to be slower than if we were both able to communicate at the same level in either your native language or in mine.
Quote:
And comparison is not inevitable to SETI, take a look to deadline politics in CPDN, as I wrote...
CPDN also has a completely different reporting / credit structure with timesteps and trickles, etc... The Einstein application would have to be reengineered to work similarly.
Finally, I said "inevitable" because you're the 5th or 6th person I've seen raising this same complaint, and all of the complaints have compared how SETI does this, or SETI does that.
Quote:
I hope, project chiefs (or managers) will help me to make this decision... :) How to help me? Simple answer me to this question, please... Can we hope, that time limits for crunching Einstein@home WU's can (or will) be raised in the future?
The "simple answer" for you right now is if you are running another BOINC project on the same machine with Einstein, you can go to your BOINC preferences and increase the resource allocation for Einstein to give more time to the Einstein task. If this is not something you wish to do, then for right now the situation is not going to change. That said, I am trying to see if I can convince the project team here to temporarily increase deadlines by a week because of what I mentioned before about the application optimization being missing from all platforms except Intel Mac OS X. However, they are not going to increase out to several months like SETI or CPDN... As Alinator mentioned, deadlines are set by project goals. SETI does not have an actual immediate goal. The results there are just being stored. There is no post-processing being done. Here, the results are being stored AND there is post-processing of the results that we have submitted. As such, Einstein is well within their rights to ask that tasks be completed sooner than SETI does.
Sorry I cannot give you an answer that I think you want to hear...
So the simple answer is, if you can not follow what the project requests, then find a new project. There are plenty of us that can and do get the results in plenty of time.
That's not a fair thing to say, especially when I know that there's a language barrier and a knowledge gap going on. I don't have the time to walk through an explainer on how BOINC works, but perhaps some of the rest of you do. What they need to understand is the impact of RDCF and Resource Allocation upon the behavior of the cpu-scheduler...and the difference between a "short" deadline and a "tight" deadline. They also need to understand that, as Ned Ludd says, "EDF is your friend", and understand that if EDF engages, they have overestimated their system's capability to do all the requested work without running into deadline problems. They also need to understand that deadlines are set with project goals in mind, how CPDN has a different reporting structure from other BOINC projects, etc, etc, etc...
All of this will take some time to explain, time which I don't currently have...
Thanks... Narrowing down at BOINCstats, we see that the Pentium III-S system is split apparently 55/45 with SETI and Einstein. If they reversed the resource allocations to 45/55, it may help with Einstein. 50/50 may work as well, since the miss was so minor.
[Edit] The miss on the workunit posted was for the Mobile Pentium M 1.8, which was apparently a new attach. Thus, what I said originally may be true, the RDCF may be > 1.
[/Edit]
@ metalius: I went back and looked at the workunit that you were intially upset over, and I can understand why you are upset, but you missed the deadline by about 3 hours, and as Alinator mentioned, since you were the 3rd result for that workunit, you had to get the result in by your deadline time in order to get credit. Increasing your resource allocation up a few percent for Einstein should greatly help make sure that your system is able to meet the deadlines as they are now.
Finally, SSE optimization for the Windows application will cause this issue to completely go away for you at your current resource allocations, but optimization isn't coming in the next couple of weeks. Hopefully I can convince the project to extend deadlines out to 18 or 21 days again for a little while, which would also help you and people like you who are just on the edge of being able to make the current deadlines.
As far as PIII capability goes; I have a 550 MHz Katmai (which is down with a bad hard drive currently). However, my personal database for it shows it had been running S5R3 tasks in about 90,000 seconds each on average so far....
Then it must be a Katmai on Super-Steroids :).
Sorry but that figure of 90,000 seconds is impossible for a Katmai 550MHz
Here are some approximate but realistic average figures for PIII hosts:-
1. Katmai 500MHz - ~300Ksecs or ~83hrs
2. Katmai 600MHZ - ~250Ksecs or ~70hrs
3. Coppermine 866MHz - ~150Ksecs or ~42hrs
4. Coppermine 1GHz - ~140Ksecs or ~39hrs
4. Tualatin 1.4GHz - ~95Ksecs or ~26hrs
I agree that 100 hours is a bit too slow for an average PIII. It's even too slow for a PIII 450 which is the slowest PIII there is. An average PIII (either of the two coppermines in the list above) is quite suitable for EAH work as long as the box can get about 5 hours per day of actual EAH crunching.
To get back to the OP's original question. I would say there is little liklihood of an increase in the 14 day deadline any time soon. That's simply based on previous statements that people like Bernd have made. All participants should factor this in when assessing if a particular host is suited to this project or not. If you have a low end PIII you would like to use by all means go ahead and use it as long as you understand that it would need to have about 25% of "wall clock" hours in order to just meet the deadline. If you have a low end coppermine processor, do yourself a favour and upgrade it to a 1GHz chip which is a five minute job at minimal cost these days.
RE: This subject is coming
)
I am not sure, that I am understanding correct, what do You say...
At 1st - my mind is OK. :) Not OK are my hosts, attached to Einstein@home (a part of them). Some time ago they started "Sizif's job"...
And comparison is not inevitable to SETI, take a look to deadline politics in CPDN, as I wrote...
Today I need to decide, which my hosts can stay here and which - not (are to slow or not permanently online).
I hope, project chiefs (or managers) will help me to make this decision... :) How to help me? Simple answer me to this question, please...
Can we hope, that time limits for crunching Einstein@home WU's can (or will) be raised in the future?
RE: I hope, project
)
As you point out languages issues can make it difficult to convey humor and subtle detail accurately. So apologies for any confusion Brian and I may have caused for you here.
However, you are certainly correct in saying that as time has passed, EAH has become a more demanding project to run for part time crunching and older hosts.
Both Brian and I have argued the case for extending the deadlines in general, or implementing a variable deadline system of some sort (like SAH does). In defense of the project, they are aware of the issue, but like most other projects there have been other more pressing concerns to deal with.
You know, the old "So much to do, so little time (and cash)..." scenario. ;-)
Alinator
RE: 2 Brian
)
I knew Alinator would get what I was talking about, but I had to safeguard against you knowing what I was talking about and thinking that I was serious.
At any rate, I think he has explained it. I wasn't thinking about explaining it completely, as I wasn't really serious anyway and I had company that had just shown up at the door, so I had to go...
RE: As far as PIII
)
Could be a bad RDCF or a low benchmark. With the computer being hidden, we also cannot see his OS and application being used (the old 4.02 Linux app was slow).
Also, we know that there are at least two projects on the system, as comparisons are drawn to SETI. Thus one also has to take into account the resource allocation shares.
You apparently have a better knack of talking about this stuff than I do, so if he has questions, I defer to you to answer if you'd like... I have to try to concentrate on my Java classwork for the next couple of days...
I find this whole thing
)
I find this whole thing ridiculous. First off comparing SETI to Einstein is not comparing anything. They are different projects owned by different entities. They do not have to follow anyone else's rules.
Next, the project asks you to help, if you feel you can help under THEIR guidelines, not under yours. This project has some deadlines it wants to meet and it may not be able to extend your deadlines to meet their deadlines.
I have worked in many situations where there are certain time-lines, etc. that need to be watched. The project is doing the settings for what they believe they need to keep the project on schedule.
So the simple answer is, if you can not follow what the project requests, then find a new project. There are plenty of us that can and do get the results in plenty of time.
RE: I am not sure, that I
)
Part of that is probably due to my not wanting to explain the entire design of the work-fetch, deadlines, estimates, and cpu scheduler processes that are built into BOINC. To really talk about what you're trying to talk about, you have to at least have a basic understanding of a few things. Our native language barrier is only going to cause the explanation process to be slower than if we were both able to communicate at the same level in either your native language or in mine.
CPDN also has a completely different reporting / credit structure with timesteps and trickles, etc... The Einstein application would have to be reengineered to work similarly.
Finally, I said "inevitable" because you're the 5th or 6th person I've seen raising this same complaint, and all of the complaints have compared how SETI does this, or SETI does that.
The "simple answer" for you right now is if you are running another BOINC project on the same machine with Einstein, you can go to your BOINC preferences and increase the resource allocation for Einstein to give more time to the Einstein task. If this is not something you wish to do, then for right now the situation is not going to change. That said, I am trying to see if I can convince the project team here to temporarily increase deadlines by a week because of what I mentioned before about the application optimization being missing from all platforms except Intel Mac OS X. However, they are not going to increase out to several months like SETI or CPDN... As Alinator mentioned, deadlines are set by project goals. SETI does not have an actual immediate goal. The results there are just being stored. There is no post-processing being done. Here, the results are being stored AND there is post-processing of the results that we have submitted. As such, Einstein is well within their rights to ask that tasks be completed sooner than SETI does.
Sorry I cannot give you an answer that I think you want to hear...
RE: With the computer being
)
hosts list (@LHC) / host list 2 (@Seti). :-)
Projects: CPDN, Einstein, LHC, Seti.
RE: So the simple answer
)
That's not a fair thing to say, especially when I know that there's a language barrier and a knowledge gap going on. I don't have the time to walk through an explainer on how BOINC works, but perhaps some of the rest of you do. What they need to understand is the impact of RDCF and Resource Allocation upon the behavior of the cpu-scheduler...and the difference between a "short" deadline and a "tight" deadline. They also need to understand that, as Ned Ludd says, "EDF is your friend", and understand that if EDF engages, they have overestimated their system's capability to do all the requested work without running into deadline problems. They also need to understand that deadlines are set with project goals in mind, how CPDN has a different reporting structure from other BOINC projects, etc, etc, etc...
All of this will take some time to explain, time which I don't currently have...
RE: RE: With the computer
)
Thanks... Narrowing down at BOINCstats, we see that the Pentium III-S system is split apparently 55/45 with SETI and Einstein. If they reversed the resource allocations to 45/55, it may help with Einstein. 50/50 may work as well, since the miss was so minor.
[Edit] The miss on the workunit posted was for the Mobile Pentium M 1.8, which was apparently a new attach. Thus, what I said originally may be true, the RDCF may be > 1.
[/Edit]
@ metalius: I went back and looked at the workunit that you were intially upset over, and I can understand why you are upset, but you missed the deadline by about 3 hours, and as Alinator mentioned, since you were the 3rd result for that workunit, you had to get the result in by your deadline time in order to get credit. Increasing your resource allocation up a few percent for Einstein should greatly help make sure that your system is able to meet the deadlines as they are now.
Finally, SSE optimization for the Windows application will cause this issue to completely go away for you at your current resource allocations, but optimization isn't coming in the next couple of weeks. Hopefully I can convince the project to extend deadlines out to 18 or 21 days again for a little while, which would also help you and people like you who are just on the edge of being able to make the current deadlines.
RE: As far as PIII
)
Then it must be a Katmai on Super-Steroids :).
Sorry but that figure of 90,000 seconds is impossible for a Katmai 550MHz
Here are some approximate but realistic average figures for PIII hosts:-
1. Katmai 500MHz - ~300Ksecs or ~83hrs
2. Katmai 600MHZ - ~250Ksecs or ~70hrs
3. Coppermine 866MHz - ~150Ksecs or ~42hrs
4. Coppermine 1GHz - ~140Ksecs or ~39hrs
4. Tualatin 1.4GHz - ~95Ksecs or ~26hrs
I agree that 100 hours is a bit too slow for an average PIII. It's even too slow for a PIII 450 which is the slowest PIII there is. An average PIII (either of the two coppermines in the list above) is quite suitable for EAH work as long as the box can get about 5 hours per day of actual EAH crunching.
To get back to the OP's original question. I would say there is little liklihood of an increase in the 14 day deadline any time soon. That's simply based on previous statements that people like Bernd have made. All participants should factor this in when assessing if a particular host is suited to this project or not. If you have a low end PIII you would like to use by all means go ahead and use it as long as you understand that it would need to have about 25% of "wall clock" hours in order to just meet the deadline. If you have a low end coppermine processor, do yourself a favour and upgrade it to a 1GHz chip which is a five minute job at minimal cost these days.
Cheers,
Gary.