thanks everyone for your imput, it was very helpful.

---

CLICK TO HELP BUILD

What ever happened to some of the ideas about changing this to help everyone....such as the per cpu method...which was supposed to be tried after the server upgrade weeks ago?

---

i figured i'd sticky this post because it's something that comes up pretty often.

the reason we can't have more than 20 WUs at a time (and even this is too many) has been discussed on here many times. it's even in the known issues section. what we're doing is dynamically updating a genetic search based on the results you guys return. if we feed out more than 20 workunits (even this is too many) by the time you finish crunching them, the population has moved so far away from where those points were generated that the work you've done on them is basically useless. ideally i'd really like to have the number somewhere around 5-10.

when we update the server code, you should be able to download new workunits as soon as you finish with your previous ones. if you're just complaining about wanting more WUs out there in the case when the server crashes... i don't think theres anything we can do about that as the workunits need to be dynamically generated as new ones come in.

that being said, we definitely are trying to increase the time per workunit. the model will be updated, and we'll be doing it across multiple streams of stars - you just need to be patient with us here. this is science in progress and Nate is working on how exactly to do that. also, i'm working on incorporating doing a line search into a workunit (which should increase the computation time by a factor of 10-50) or more) -- but that's maybe a week or two away because that'll take a bit of bug fixing. i'm hoping to have that in the next version of the application.

Excellent explanation. And I love the cartoon too... Much safer project SSETL vs SETI! LOL

---

It would be fine to have 5-10 wu's at a time when the time is extended by say 5-10 times. They would run 55-100 min on mine then.

Minimum needs to me 8. 8-way boxes are just too common any more.

Send me one w/ mobo. I'll replace a couple of my Q6600 'basket crunchers'!

;-)

Isn't there a way to go into one of the boinc files to change the LTD? It seems to me I read that in a thread a long time ago at SETI.

Yes, go to the Client state file, open with Notepad, search for 'long', change and save.

This must be done with the Boinc client closed imho.

Or see link in my sig... the older non Web version has a "clear" option.

Well Travis opposes distributing any more than 20 workunits at a time to any machine because theres always a chance that the machine might not return those results. And say if your 72 core machine had a power outage for 5 days. You would have a great portion of the workload, and nothing would get returned, therefore taking our search patterns in a completely different direction. I think increasing the maximum a computer can do in a day is better because then you can keep requesting work and it will continually be given to you. Its essentially the same except this time you have to keep asking for work instead of being given a large portion of it at a particular time.

---

Dave Przybylo
MilkyWay@home Developer
Department of Computer Science
Rensselaer Polytechnic Institute

Well Travis opposes distributing any more than 20 workunits at a time to any machine because theres always a chance that the machine might not return those results. And say if your 72 core machine had a power outage for 5 days. You would have a great portion of the workload, and nothing would get returned, therefore taking our search patterns in a completely different direction. I think increasing the maximum a computer can do in a day is better because then you can keep requesting work and it will continually be given to you. Its essentially the same except this time you have to keep asking for work instead of being given a large portion of it at a particular time.

Thanks for the answer Dave :) At least I understand now why other methods weren't tried.

---

Well Travis opposes distributing any more than 20 workunits at a time to any machine because theres always a chance that the machine might not return those results. And say if your 72 core machine had a power outage for 5 days. You would have a great portion of the workload, and nothing would get returned, therefore taking our search patterns in a completely different direction. I think increasing the maximum a computer can do in a day is better because then you can keep requesting work and it will continually be given to you. Its essentially the same except this time you have to keep asking for work instead of being given a large portion of it at a particular time.

Actually, results not being returned doesn't really matter too much. The only real problem we have is figuring out how to put a per-core limit on the WUs as opposed to a per-machine limit. Hopefully we can get this worked out soon.

---

Isn't there a way to go into one of the boinc files to change the LTD? It seems to me I read that in a thread a long time ago at SETI.

Yes, go to the Client state file, open with Notepad, search for 'long', change and save.

This must be done with the Boinc client closed imho.

Or see link in my sig... the older non Web version has a "clear" option.

sorry got sidetracked and edit time expired... think there are some new or coming soon built in boinc options to clear debt but this is still around...

http://skipsjunk.net/info/boincdv.html

The only real problem we have is figuring out how to put a per-core limit on the WUs as opposed to a per-machine limit. Hopefully we can get this worked out soon.

Hm, why don't you try to ask the guys from LHC how they have this worked out?
Actually one gets 10 WUs per core over there...

---

Member of BOINC@Heidelberg and ATA!

My BOINCstats

The only real problem we have is figuring out how to put a per-core limit on the WUs as opposed to a per-machine limit. Hopefully we can get this worked out soon.

Hm, why don't you try to ask the guys from LHC how they have this worked out?
Actually one gets 10 WUs per core over there...

Per core... BOINC Studio was great with that.

---

me@rescam.org

Well Travis opposes distributing any more than 20 workunits at a time to any machine because theres always a chance that the machine might not return those results. And say if your 72 core machine had a power outage for 5 days. You would have a great portion of the workload, and nothing would get returned, therefore taking our search patterns in a completely different direction. I think increasing the maximum a computer can do in a day is better because then you can keep requesting work and it will continually be given to you. Its essentially the same except this time you have to keep asking for work instead of being given a large portion of it at a particular time.

Actually, results not being returned doesn't really matter too much. The only real problem we have is figuring out how to put a per-core limit on the WUs as opposed to a per-machine limit. Hopefully we can get this worked out soon.

What about shrinking the deadline a bit. BOINC can be very casual about reporting work if the deadline is a long ways away. Somewhat tighter deadlines seem to be what the project needs. If you really generate the next round from the current round, I would suggest something like 25 or 26 hours. This gives at least some intermittently connected users to do some work. If you connect by hand and typically do it when you get home from work or some such, 24 hours exactly is a pain as you have to report just a few minutes earlier each day.

---

BOINC WIKI

What about shrinking the deadline a bit. BOINC can be very casual about reporting work if the deadline is a long ways away. Somewhat tighter deadlines seem to be what the project needs. If you really generate the next round from the current round, I would suggest something like 25 or 26 hours. This gives at least some intermittently connected users to do some work. If you connect by hand and typically do it when you get home from work or some such, 24 hours exactly is a pain as you have to report just a few minutes earlier each day.

I for one would be forced to detatch from the project as I cannot guarantee that my machine connects every 24 hours as in general it does not. Any project that absolutely requires such short deadlines is not suited for BOINC.

Edit: Manually tinkering with a project on a daily basis was fine when POEM was our POTM and I could tinker with the project to make sure I only had long WUs (POEM had a 7/core limit) even though it had reasonable deadlines. But requiring it on a permanent basis due to short deadlines is simply a poor design.

What about shrinking the deadline a bit. BOINC can be very casual about reporting work if the deadline is a long ways away. Somewhat tighter deadlines seem to be what the project needs. If you really generate the next round from the current round, I would suggest something like 25 or 26 hours. This gives at least some intermittently connected users to do some work. If you connect by hand and typically do it when you get home from work or some such, 24 hours exactly is a pain as you have to report just a few minutes earlier each day.

I for one would be forced to detatch from the project as I cannot guarantee that my machine connects every 24 hours as in general it does not. Any project that absolutely requires such short deadlines is not suited for BOINC.

Edit: Manually tinkering with a project on a daily basis was fine when POEM was our POTM and I could tinker with the project to make sure I only had long WUs (POEM had a 7/core limit) even though it had reasonable deadlines. But requiring it on a permanent basis due to short deadlines is simply a poor design.

In recent memory I have not been a very staunch defender of project decisions. But, there are cases where short deadlines are needed for the project to accomplish its goals. The fact that these deadlines conflict with your needs as a participant is unfortunate and not necessarily a bad design choice.

It just means that you, like all participants, has to decide if the project's parameters meets your capabilities. There are a half a dozen projects that I wish I could contribute to ... but I cannot because they don't have a version for OS-X ... and that cuts most of my processing power right out. And so, I have to suffer ...

If you do not have "always on" Internet, then this may not be a project that is suitable for your systems. At the moment, I have been toying with this project and a couple of others on my Mac Pro and with my Cable modem always on ... well, I am constantly seeing large shifts in work and fast turn-around on the tasks issued ... well, there is this one CPDN task that JUST WON'T FINSIH ... 1,000 hours to go ... :)

As John has mentioned there is the one minor issue with BOINC's design that can also cause problems ...

But, I don't suppose any of this is going to make you feel better about the deadlines ...

And projects with short deadlines, participants with fast machines and always on Internet are ideally suited for BOINC ... were they not having a minor issue with the system I would still be blowing through tasks for this project ...

---

I think the project's needs should be first, but also try to include most people's computers. I think 24 hours is a tad short, I would say 48-72 is better. Allows for a couple days/over a weekend to get connected again.

If it is possible to do such a thing as to have coding that will give 20 for a single/dual core is good, but give quads and up a per core amount. Bringing the limit down to say 10/core is not much work (at current run time) for single cores.

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

Well, the last tasks I got have a deadline on the 17th ...

Um, where is the 24 hour deadline?

---

Well, the last tasks I got have a deadline on the 17th ...

Um, where is the 24 hour deadline?

It's just a discussion still.?.

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

Well, the last tasks I got have a deadline on the 17th ...

Um, where is the 24 hour deadline?

It's just a discussion still.?.

Just a note: I have never heard Travis say that 5 days is a problem or that he would like to shorten that parameter...rather...it has been a participants discussion only at trying to improve search parameters :)

---

Just a note: I have never heard Travis say that 5 days is a problem or that he would like to shorten that parameter...rather...it has been a participants discussion only at trying to improve search parameters :)

Ah, I see ...

during the day I tend to be watching the 4 computers and force updates to keep my completed pool empty ... of course I waste 2-8 hours each 24 and they can build up then ... though usually not as much as you would think with a buffer of 0.2 ...

---

Just a note: I have never heard Travis say that 5 days is a problem or that he would like to shorten that parameter...rather...it has been a participants discussion only at trying to improve search parameters :)

Ah, I see ...

during the day I tend to be watching the 4 computers and force updates to keep my completed pool empty ... of course I waste 2-8 hours each 24 and they can build up then ... though usually not as much as you would think with a buffer of 0.2 ...

Yea Paul,as you know ;),Boinc allows a project a lot of options to acheive an "optimized" soloution between project and participants to make it the most efficient possible....there has been a lot of discussion of how to acheive that here and you are just late to the discussion and would need to spend hours reading to get up to speed :=) Imho The credit you receive was reached by concensus of the participants at the time and not by the project. A truly revoloutionary way to step towards solving Boinc parity and project disharmony.

---