Every time I run into this kind of discussion (be it here, SAH, ...) I wonder why people tend to be so much worried about one project being down for a day.
If I were nasty, I would now say: if project managers can't run their servers, they don't deserve my CPU time.
Not that I'd decrease the resource share for that particular project (I set it according to my personal feelings about usefulnes of that project) but if the project doesn't use it fully that's fine with me. If SAH is down, E@H will get more :)
> Howdy!
>
> Every time I run into this kind of discussion (be it here, SAH, ...) I wonder
> why people tend to be so much worried about one project being down for a day.
>
> If I were nasty, I would now say: if project managers can't run their servers,
> they don't deserve my CPU time.
> Not that I'd decrease the resource share for that particular project (I set it
> according to my personal feelings about usefulnes of that project) but if the
> project doesn't use it fully that's fine with me. If SAH is down, E@H will get
> more :)
>
I am not worried about any particulay project being down for a day or a couple of months. I am annoyed by a system that does not do a very good job of doing multi project scheduling. If one project is down BOINC should automatically do work from some other project. The problem is that the way that it works right now, some machines are limited to one project because of one constraint or another. These machines should automatically serialize which project gets work now rather than getting one WU from each and making ALL of the work late, or not getting work from any projects at all to protect the work from being late or requiring a large amount of handholding to keep the machine in work.
> I am not worried about any particulay project being down for a day or a couple
> of months. I am annoyed by a system that does not do a very good job of doing
> multi project scheduling. If one project is down BOINC should automatically
> do work from some other project. The problem is that the way that it works
> right now, some machines are limited to one project because of one constraint
> or another. These machines should automatically serialize which project gets
> work now rather than getting one WU from each and making ALL of the work late,
> or not getting work from any projects at all to protect the work from being
> late or requiring a large amount of handholding to keep the machine in work.
I am just annoyed that there does not seem to be any sense of urgency about the odd issues gooing on with regard to multiple projects.
4.19 sometimes will run 3 projects on a 2 CPU machine, my macintosh is doing that right now as we speak.
Scheduling as you have stated.
Queuing by "days" rather than by finer granularity. I would like to have minimal queues, but based on WU per project (one from each project for each CPU), as it stands now, with projects bouncing up and down, using a short queue could mean running dry on multi-cpu systems, with longer queues, like my reasonable 2 days, means that I rarely completed an Einstein@Home WU.
Even more annoying is spending 10 hours processing work to have it reset to zero, this screws up my accounting for average processing times ... and it is a FAQ topic too! :(
I better quit before I get annoyed (or more annoyed).
>
> 4.19 sometimes will run 3 projects on a 2 CPU machine, my macintosh is doing
> that right now as we speak.
>
Hey, I'm glad you mentioned that. I wrote to Groundkeeper Software Support, who wrote Deep Thought that I've been using as a GUI. I thought it was their fault that I was sometimes running 3 projects on 2 CPU's.
They wrote back that they thought this was BOINC.
Apparantly they're right. You don't use Deep thought, Paul, do you?
Sometimes I'm running Einstein and Seti. That's OK, isn't it?
Gravity - its not just a good idea, its the Law!
North
I'll be testing gravity over the Sonora desert in Eloy Arizona in the beginning of April! Almost time for me to fly!!!!!
> Hey, I'm glad you mentioned that. I wrote to Groundkeeper Software Support,
> who wrote Deep Thought that I've been using as a GUI. I thought it was their
> fault that I was sometimes running 3 projects on 2 CPU's.
>
> They wrote back that they thought this was BOINC.
>
> Apparantly they're right. You don't use Deep thought, Paul, do you?
Actually, I am using it now on the Macintosh. I use BOINC View on a PC to look at the "farm" as a whole, but I like the Deep Thought program better than my "kluge", I mean, it worked, but it had its flaws. But before I reccommend something I like to have some faith that it works. Something about a reputation. But, at this time, I can say that though I am not sure about a couple things it does seem to work pretty well.
As far as the multi-process with the one "extra", I saw it with my CLI version, so, yes, I think it is the BOINC Daemon.
> Sometimes I'm running Einstein and Seti. That's OK, isn't it?
Well, I run all 5 current projects, so, you have to make your own decisions. Though, like one of my favorite people (John McLeod the 23rd ... sorry John ... :)) I am somewhat disappointed with the current state of the BOINC world.
I mean, with LHC@Home, indications are that it is their science application that can't seem to tell time (this is not for absolute certain, but of the 5 active projects their's is the only one that is zeroing out the run time; and no, it is not about credit, it is about did I just waste 10 hours of time because if they cannot do something that simple I should still have faith that the complex part of the program works?).
Einstein@Home and SETI@Home are having performance problems with the database. This is insane.
[edit - add]
I mean, 2 day queue, even though for 5 projects, is too large? John is absolutely correct that there are serious weaknesses in the implementation of the multi-project work scheduling
What I believe part of the problem with Einstein is could be the benchmark calculations they are using. I have a 2 day cache on my machines running up to 4 projects at a time on each with Boinc. They all seem to be pretty accurate in time to completion )within -+ 2% except for Einstein which is aprrox 25-35% off on all 4 of my hosts. If Einstein says it will take 8 hours to crunch a unit it takes 12 hours ,if Einstein says 7 hours it takes 10. Thus another factor adding into 1 week completion times causes a 2 day cache to push the envelope of the 7 day report time. If something can be done about this Bruce,I beleive a lot of the complaints of deadlines might be alleviated :) I like to keep a 3day+ cache due to projects that run out of work and Einstein is preventing me from doing that:(
> What I believe part of the problem with Einstein is could be the benchmark
> calculations they are using. I have a 2 day cache on my machines running up to
> 4 projects at a time on each with Boinc. They all seem to be pretty accurate
> in time to completion )within -+ 2% except for Einstein which is aprrox 25-35%
> off on all 4 of my hosts. If Einstein says it will take 8 hours to crunch a
> unit it takes 12 hours ,if Einstein says 7 hours it takes 10. Thus another
> factor adding into 1 week completion times causes a 2 day cache to push the
> envelope of the 7 day report time. If something can be done about this Bruce,I
> beleive a lot of the complaints of deadlines might be alleviated :) I like to
> keep a 3day+ cache due to projects that run out of work and Einstein is
> preventing me from doing that:(
I'm running three projects, and as we know, SETI is down at the moment.
When only one project was up, I ran my cache at 4 or 5 days.
Now that I've got three, setting the cache at about 1/2 day seems to work very well. BOINC (I'm on client 4.20) seems to adjust the request based on resource share and my turnaround time, and while the cache is staying pretty empty, there is always something waiting to be crunched -- and I'm never even close to deadlines.
> What I believe part of the problem with Einstein is could be the benchmark
> calculations they are using. I have a 2 day cache on my machines running up to
> 4 projects at a time on each with Boinc. They all seem to be pretty accurate
> in time to completion )within -+ 2% except for Einstein which is aprrox 25-35%
> off on all 4 of my hosts. If Einstein says it will take 8 hours to crunch a
> unit it takes 12 hours ,if Einstein says 7 hours it takes 10. Thus another
> factor adding into 1 week completion times causes a 2 day cache to push the
> envelope of the 7 day report time. If something can be done about this Bruce,I
> beleive a lot of the complaints of deadlines might be alleviated :) I like to
> keep a 3day+ cache due to projects that run out of work and Einstein is
> preventing me from doing that:(
>
I wonder if it would be possible (and useful) to have a "project crunch time correction factor" available to each computer on each account?
In looking at my average times for Seti and Einstein, I came up with the following table:
est. actual new
Seti AMD 1 0.80 18996 15197 15197 (0.80 * 18996)
Seti AMD 2 0.77 18895 14549 14549
Seti Intel 0.46 23299 10718 10718
Einstein AMD 1 1.11 27211 30204 30204
Einstein AMD 2 1.10 27065 29772 29772
Einstein Intel 1.20 33360 40032 40032
If I were able to assign the number in column 3 to each computer and project, then when the project calculates WU's to send, that number is used to scale the "estimated completion time" to a more realistic value.
It appears that a scale factor between 0 and 2 (1 being the default -- nothing changes) would suffice (and limiting this number would be a good idea.)
Also, I realize that future WU's may or will change, so it would be up to the individual to update their correction factor(s). Also hardware and software changes would be a factor for updating the number.
Or, simply leave the number at 1 and things would remain the same.
Anyway, just thinking about ways to get better estimated times without introducing cheating.
> I'm running three projects, and as we know, SETI is down at the moment.
>
> When only one project was up, I ran my cache at 4 or 5 days.
>
> Now that I've got three, setting the cache at about 1/2 day seems to work very
> well. BOINC (I'm on client 4.20) seems to adjust the request based on
> resource share and my turnaround time, and while the cache is staying pretty
> empty, there is always something waiting to be crunched -- and I'm never even
> close to deadlines.
>
Yep, I agree, 0.5 day works well. Most people with deadline problems just have their caches too large.
>
> Yep, I agree, 0.5 day works well. Most people with deadline problems just
> have their caches too large.
>
Maybe it works for you Cochise but for many of us 1-3 days may be required and Einstein makes it difficult under the public release of Boinc 4.19. In fact upon further review I said ALL other projects I'm in report accurate run times to my Benchmarks...welll Predictor actually Overstates my run times by 20-30% which is PREFERRED when other projects are accurate. Einstein project developers (Bruce I guess) need to be aware of possibly why they are getting so many reporting late and this thread is getting many responses and help adjust this PLEASE :)
Howdy! Every time I run
)
Howdy!
Every time I run into this kind of discussion (be it here, SAH, ...) I wonder why people tend to be so much worried about one project being down for a day.
If I were nasty, I would now say: if project managers can't run their servers, they don't deserve my CPU time.
Not that I'd decrease the resource share for that particular project (I set it according to my personal feelings about usefulnes of that project) but if the project doesn't use it fully that's fine with me. If SAH is down, E@H will get more :)
Metod ...
> Howdy! > > Every time I
)
> Howdy!
>
> Every time I run into this kind of discussion (be it here, SAH, ...) I wonder
> why people tend to be so much worried about one project being down for a day.
>
> If I were nasty, I would now say: if project managers can't run their servers,
> they don't deserve my CPU time.
> Not that I'd decrease the resource share for that particular project (I set it
> according to my personal feelings about usefulnes of that project) but if the
> project doesn't use it fully that's fine with me. If SAH is down, E@H will get
> more :)
>
I am not worried about any particulay project being down for a day or a couple of months. I am annoyed by a system that does not do a very good job of doing multi project scheduling. If one project is down BOINC should automatically do work from some other project. The problem is that the way that it works right now, some machines are limited to one project because of one constraint or another. These machines should automatically serialize which project gets work now rather than getting one WU from each and making ALL of the work late, or not getting work from any projects at all to protect the work from being late or requiring a large amount of handholding to keep the machine in work.
BOINC WIKI
> I am not worried about any
)
> I am not worried about any particulay project being down for a day or a couple
> of months. I am annoyed by a system that does not do a very good job of doing
> multi project scheduling. If one project is down BOINC should automatically
> do work from some other project. The problem is that the way that it works
> right now, some machines are limited to one project because of one constraint
> or another. These machines should automatically serialize which project gets
> work now rather than getting one WU from each and making ALL of the work late,
> or not getting work from any projects at all to protect the work from being
> late or requiring a large amount of handholding to keep the machine in work.
I am just annoyed that there does not seem to be any sense of urgency about the odd issues gooing on with regard to multiple projects.
4.19 sometimes will run 3 projects on a 2 CPU machine, my macintosh is doing that right now as we speak.
Scheduling as you have stated.
Queuing by "days" rather than by finer granularity. I would like to have minimal queues, but based on WU per project (one from each project for each CPU), as it stands now, with projects bouncing up and down, using a short queue could mean running dry on multi-cpu systems, with longer queues, like my reasonable 2 days, means that I rarely completed an Einstein@Home WU.
Even more annoying is spending 10 hours processing work to have it reset to zero, this screws up my accounting for average processing times ... and it is a FAQ topic too! :(
I better quit before I get annoyed (or more annoyed).
> > 4.19 sometimes will run
)
>
> 4.19 sometimes will run 3 projects on a 2 CPU machine, my macintosh is doing
> that right now as we speak.
>
Hey, I'm glad you mentioned that. I wrote to Groundkeeper Software Support, who wrote Deep Thought that I've been using as a GUI. I thought it was their fault that I was sometimes running 3 projects on 2 CPU's.
They wrote back that they thought this was BOINC.
Apparantly they're right. You don't use Deep thought, Paul, do you?
Sometimes I'm running Einstein and Seti. That's OK, isn't it?
Gravity - its not just a good idea, its the Law!
North
I'll be testing gravity over the Sonora desert in Eloy Arizona in the beginning of April! Almost time for me to fly!!!!!
[img]http://www.boincstats.com/stats/banner.php? cpid=418c9a98efef17b0f7b6237ff6826201[/img]
> Hey, I'm glad you mentioned
)
> Hey, I'm glad you mentioned that. I wrote to Groundkeeper Software Support,
> who wrote Deep Thought that I've been using as a GUI. I thought it was their
> fault that I was sometimes running 3 projects on 2 CPU's.
>
> They wrote back that they thought this was BOINC.
>
> Apparantly they're right. You don't use Deep thought, Paul, do you?
Actually, I am using it now on the Macintosh. I use BOINC View on a PC to look at the "farm" as a whole, but I like the Deep Thought program better than my "kluge", I mean, it worked, but it had its flaws. But before I reccommend something I like to have some faith that it works. Something about a reputation. But, at this time, I can say that though I am not sure about a couple things it does seem to work pretty well.
As far as the multi-process with the one "extra", I saw it with my CLI version, so, yes, I think it is the BOINC Daemon.
> Sometimes I'm running Einstein and Seti. That's OK, isn't it?
Well, I run all 5 current projects, so, you have to make your own decisions. Though, like one of my favorite people (John McLeod the 23rd ... sorry John ... :)) I am somewhat disappointed with the current state of the BOINC world.
I mean, with LHC@Home, indications are that it is their science application that can't seem to tell time (this is not for absolute certain, but of the 5 active projects their's is the only one that is zeroing out the run time; and no, it is not about credit, it is about did I just waste 10 hours of time because if they cannot do something that simple I should still have faith that the complex part of the program works?).
Einstein@Home and SETI@Home are having performance problems with the database. This is insane.
[edit - add]
I mean, 2 day queue, even though for 5 projects, is too large? John is absolutely correct that there are serious weaknesses in the implementation of the multi-project work scheduling
What I believe part of the
)
What I believe part of the problem with Einstein is could be the benchmark calculations they are using. I have a 2 day cache on my machines running up to 4 projects at a time on each with Boinc. They all seem to be pretty accurate in time to completion )within -+ 2% except for Einstein which is aprrox 25-35% off on all 4 of my hosts. If Einstein says it will take 8 hours to crunch a unit it takes 12 hours ,if Einstein says 7 hours it takes 10. Thus another factor adding into 1 week completion times causes a 2 day cache to push the envelope of the 7 day report time. If something can be done about this Bruce,I beleive a lot of the complaints of deadlines might be alleviated :) I like to keep a 3day+ cache due to projects that run out of work and Einstein is preventing me from doing that:(
> What I believe part of the
)
> What I believe part of the problem with Einstein is could be the benchmark
> calculations they are using. I have a 2 day cache on my machines running up to
> 4 projects at a time on each with Boinc. They all seem to be pretty accurate
> in time to completion )within -+ 2% except for Einstein which is aprrox 25-35%
> off on all 4 of my hosts. If Einstein says it will take 8 hours to crunch a
> unit it takes 12 hours ,if Einstein says 7 hours it takes 10. Thus another
> factor adding into 1 week completion times causes a 2 day cache to push the
> envelope of the 7 day report time. If something can be done about this Bruce,I
> beleive a lot of the complaints of deadlines might be alleviated :) I like to
> keep a 3day+ cache due to projects that run out of work and Einstein is
> preventing me from doing that:(
I'm running three projects, and as we know, SETI is down at the moment.
When only one project was up, I ran my cache at 4 or 5 days.
Now that I've got three, setting the cache at about 1/2 day seems to work very well. BOINC (I'm on client 4.20) seems to adjust the request based on resource share and my turnaround time, and while the cache is staying pretty empty, there is always something waiting to be crunched -- and I'm never even close to deadlines.
> What I believe part of the
)
> What I believe part of the problem with Einstein is could be the benchmark
> calculations they are using. I have a 2 day cache on my machines running up to
> 4 projects at a time on each with Boinc. They all seem to be pretty accurate
> in time to completion )within -+ 2% except for Einstein which is aprrox 25-35%
> off on all 4 of my hosts. If Einstein says it will take 8 hours to crunch a
> unit it takes 12 hours ,if Einstein says 7 hours it takes 10. Thus another
> factor adding into 1 week completion times causes a 2 day cache to push the
> envelope of the 7 day report time. If something can be done about this Bruce,I
> beleive a lot of the complaints of deadlines might be alleviated :) I like to
> keep a 3day+ cache due to projects that run out of work and Einstein is
> preventing me from doing that:(
>
I wonder if it would be possible (and useful) to have a "project crunch time correction factor" available to each computer on each account?
In looking at my average times for Seti and Einstein, I came up with the following table:
est. actual new
Seti AMD 1 0.80 18996 15197 15197 (0.80 * 18996)
Seti AMD 2 0.77 18895 14549 14549
Seti Intel 0.46 23299 10718 10718
Einstein AMD 1 1.11 27211 30204 30204
Einstein AMD 2 1.10 27065 29772 29772
Einstein Intel 1.20 33360 40032 40032
If I were able to assign the number in column 3 to each computer and project, then when the project calculates WU's to send, that number is used to scale the "estimated completion time" to a more realistic value.
It appears that a scale factor between 0 and 2 (1 being the default -- nothing changes) would suffice (and limiting this number would be a good idea.)
Also, I realize that future WU's may or will change, so it would be up to the individual to update their correction factor(s). Also hardware and software changes would be a factor for updating the number.
Or, simply leave the number at 1 and things would remain the same.
Anyway, just thinking about ways to get better estimated times without introducing cheating.
> I'm running three projects,
)
> I'm running three projects, and as we know, SETI is down at the moment.
>
> When only one project was up, I ran my cache at 4 or 5 days.
>
> Now that I've got three, setting the cache at about 1/2 day seems to work very
> well. BOINC (I'm on client 4.20) seems to adjust the request based on
> resource share and my turnaround time, and while the cache is staying pretty
> empty, there is always something waiting to be crunched -- and I'm never even
> close to deadlines.
>
Yep, I agree, 0.5 day works well. Most people with deadline problems just have their caches too large.
> > Yep, I agree, 0.5 day
)
>
> Yep, I agree, 0.5 day works well. Most people with deadline problems just
> have their caches too large.
>
Maybe it works for you Cochise but for many of us 1-3 days may be required and Einstein makes it difficult under the public release of Boinc 4.19. In fact upon further review I said ALL other projects I'm in report accurate run times to my Benchmarks...welll Predictor actually Overstates my run times by 20-30% which is PREFERRED when other projects are accurate. Einstein project developers (Bruce I guess) need to be aware of possibly why they are getting so many reporting late and this thread is getting many responses and help adjust this PLEASE :)