[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.

Well, *I* am not complaining ... other than I can't report work and get more ... :)

---

I don't know if there are any statistics on how often computers connect to BOINC (let alone this project) so for me this is more of a theoretical discussion.

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.

Note that I'm not saying this is a bad decision per se, but that a project with such short deadlines is just not suitable for BOINC in general. Even if you are connected to the net permanently, you essentially have to run the project exclusively. At some point the project becomes a standalone client. If you absolutely positively need those results that quickly, maybe, just maybe, distributed computing is the wrong way to go.

It just means that you, like all participants, has to decide if the project's parameters meets your capabilities.

Like I said, I would have to detatch. How many others would have to detatch? Is the shorter duration of WUs really worth this loss of crunching power?

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 ...

Not having an OS-X version is a programming limitation, not a design choice, so it's not really relevant.

If you do not have "always on" Internet, then this may not be a project that is suitable for your systems.

Why not? This discussion has been around for a long time on other projects (or at least on LHC as I'm sure you've seen). I've yet to see a good argument. This is not the only project that uses existing WUs to generate new ones and they work fine without having very short deadlines.

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 ... :)

I crunched for CPDN in the past but my older computers apparently were not stable enough and could never finish a WU so I stopped out of frustration. I believe my newest systems could crunch it now without a problem but this is jsut the opposite extreme. :)

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 ...

The problem I have is that there are no VISTA x64 drivers for my wireless access devices. The only way I can get my main machine to connect is to tether it through my blackberry. It's a royal pain so I only do it when I have a lot of work to report (and when there is so much the system starts getting sluggish). Trust me, I would like to be able to be "always on" but I can't. It's particularly frustrating for me since this is my team's POTM and of course as this is my old school I'd like to support this project more than I can currently.

In any case I completely disagree with you about short deadline projects being ideally suited for BOINC for reasons I stated above. Without the problems you're referring to, you wouldn't be going through WUs any faster than now no matter how short the deadlines were. Instead, I would rather see the length of WUs increased. That's a much better goal in my opinion.

P.S. I was able to return work. :D

Well, we can agree to disagree.

But, I think that with always on Internet and short deadlines that the project is still ideal for BOINC ... just not for you... which colors you assessment, just as assuridly as my always on (well, unless they break it) Internet allows me flexibility you do not have.

When I first got into DC the simpler CPDN models took nearly two calendar years to complete and I don't think that they actually got very many complete models ... so I concentrated on SaH ... but when BOINC came out I started to use them as a backup for when SaH was down ...

Besides, I think it is something that needs to be done ... too many skeptics out there and the models do need to be improved and the only way to do that is to run the darn things and see what shakes out ...

Just as here ...

But, the short deadline is not in place, my work today is not due till the 19th ... though much of it will be back by the end of the day I am sure (if not all of it).

---

Well, we can agree to disagree.

But, I think that with always on Internet and short deadlines that the project is still ideal for BOINC ... just not for you... which colors you assessment, just as assuridly as my always on (well, unless they break it) Internet allows me flexibility you do not have.

When I first got into DC the simpler CPDN models took nearly two calendar years to complete and I don't think that they actually got very many complete models ... so I concentrated on SaH ... but when BOINC came out I started to use them as a backup for when SaH was down ...

Besides, I think it is something that needs to be done ... too many skeptics out there and the models do need to be improved and the only way to do that is to run the darn things and see what shakes out ...

Just as here ...

But, the short deadline is not in place, my work today is not due till the 19th ... though much of it will be back by the end of the day I am sure (if not all of it).

It should be possible to have tasks with a 5 minute deadline (as long as the download and crunch times are substantially less than that) if the tasks are time critical. I am not suggesting that deadlines this short are needed here (especially not since the crunch time seems to exceed 10 minutes on many machines). BOINC should be able to handle this, even if not all computers connections can.

There are going to be projects that are just not suitable for a given computer setup. CPDN doesn't run on my Pentium Pro 200 Mhz Dual because of RAM and HD limitations. If this project tightens its deadlines to be < 14 hours, 6 of my machines will not be suitable because the deadlines are < the connect interval. It is a call the project needs to make. There is a tradeoff. If the deadlines are too long, many of the returned results are useless. If the deadlines are too short, some machines will have to drop out.

Some projects (S@H for example) do not have to make this trade off. The only reason that they care about deadlines at all is to keep the size of the data stored on their disks as small as possible.

---

BOINC WIKI

Last night I implemented and submitted a modification to the client that I believe may be useful for projects like this. It seems as if a project or work unit/result defined maximum wait between completion/upload and report of the task may be a good idea. This would allow projects like this to get the report more quidkly than the current fixed maximum wait of 24 hours.

It is still true that BOINC does not work hard to meet loose deadlines. With a deadline of 5 days, you can expect that some work will be returned as late as minutes before the deadline. That is just the way that BOINC works.

---

BOINC WIKI

Until I saw this thread, it had not sunk in that Milkyway is using the reported results to generate the next work to be sent out.

I run off-line, and make a connection to the internet no more often than twice a day. Meaning no matter how fast my computer, nor how short your deadlines, the very SOONEST that I can submit a result is 12 hours after downloading the WU. [If higher-priority work from other projects supersedes Milkyway work, it'll be 24 hours.]

Should I stop participating in Milkyway ?
.

Until I saw this thread, it had not sunk in that Milkyway is using the reported results to generate the next work to be sent out.

I run off-line, and make a connection to the internet no more often than twice a day. Meaning no matter how fast my computer, nor how short your deadlines, the very SOONEST that I can submit a result is 12 hours after downloading the WU. [If higher-priority work from other projects supersedes Milkyway work, it'll be 24 hours.]

Should I stop participating in Milkyway ?
.

No-The project team has stated all results returned before the deadline are valuable-keep on trucking dude :)

---

I think the 20 wu limit is ok.

Its only that the re-connect is timed to 20 min after each connect, which will cause my big puter to go idle....

http://milkyway.cs.rpi.edu/milkyway/show_host_detail.php?hostid=15565

16 cores... 12 min per wu..--> 8 min idle / 20 min

Just a note since the Admin posted that he didn't expect more than 8 core machines here! ;-)

sysfried

PS: yeah, I do understand the boinc principle, and I do have other projects attached, so i don't really run idle!

I think the 20 wu limit is ok.

Its only that the re-connect is timed to 20 min after each connect, which will cause my big puter to go idle....

http://milkyway.cs.rpi.edu/milkyway/show_host_detail.php?hostid=15565

16 cores... 12 min per wu..--> 8 min idle / 20 min

Just a note since the Admin posted that he didn't expect more than 8 core machines here! ;-)

sysfried

sysfried, my quad goes idle too if I let it download "the full" 20 work units. I got around that by setting a very small cache (0.02 days). Boinc then downloads only a few work units, and doesn't defer communication. When 2 or 3 WU are finished, it just downloads new ones. As long as there are WU available from the server, this scheme works fine.

---

BOINC.BE: For Belgians who love the smell of glowing red cpu's in the morning
Tutta55's Lair

sysfried, my quad goes idle too if I let it download "the full" 20 work units. I got around that by setting a very small cache (0.02 days). Boinc then downloads only a few work units, and doesn't defer communication. When 2 or 3 WU are finished, it just downloads new ones. As long as there are WU available from the server, this scheme works fine.

I could have thougth of that! Darn. But hey, thanks for the heads up. I'll fix it tomorrow.. btw, wrong host id: here's the right one: 15945

Sysfried

sysfried, my quad goes idle too if I let it download "the full" 20 work units. I got around that by setting a very small cache (0.02 days). Boinc then downloads only a few work units, and doesn't defer communication. When 2 or 3 WU are finished, it just downloads new ones. As long as there are WU available from the server, this scheme works fine.

I could have thougth of that! Darn. But hey, thanks for the heads up. I'll fix it tomorrow.. btw, wrong host id: here's the right one: 15945

Sysfried

Hmmmmmmmmmmmmmmmmm... Can anyone think of a downside to this? I can.

Voltron

sysfried, my quad goes idle too if I let it download "the full" 20 work units. I got around that by setting a very small cache (0.02 days). Boinc then downloads only a few work units, and doesn't defer communication. When 2 or 3 WU are finished, it just downloads new ones. As long as there are WU available from the server, this scheme works fine.

I could have thougth of that! Darn. But hey, thanks for the heads up. I'll fix it tomorrow.. btw, wrong host id: here's the right one: 15945

Sysfried

Hmmmmmmmmmmmmmmmmm... Can anyone think of a downside to this? I can.

Voltron

Please tell us, because I can't. As long as the server supplies work, this scheme works fine. When the server does run out of work, usually something is seriously wrong and it takes several hours to fix. 20 WU in cache or just 5 or 6 doesn't make much difference then.

---

BOINC.BE: For Belgians who love the smell of glowing red cpu's in the morning
Tutta55's Lair

sysfried, my quad goes idle too if I let it download "the full" 20 work units. I got around that by setting a very small cache (0.02 days). Boinc then downloads only a few work units, and doesn't defer communication. When 2 or 3 WU are finished, it just downloads new ones. As long as there are WU available from the server, this scheme works fine.

I could have thougth of that! Darn. But hey, thanks for the heads up. I'll fix it tomorrow.. btw, wrong host id: here's the right one: 15945

Sysfried

Hmmmmmmmmmmmmmmmmm... Can anyone think of a downside to this? I can.

Voltron

Please tell us, because I can't. As long as the server supplies work, this scheme works fine. When the server does run out of work, usually something is seriously wrong and it takes several hours to fix. 20 WU in cache or just 5 or 6 doesn't make much difference then.

The key concept is "server share" what works for one may very well overload the server if too many quads get on this bus. Think son.

Voltron

The problem with connecting that often is load on the server. There are something like 9,000 active hosts at the moment (according to BOINCStats). If every one of them connects to the server every 5 minutes, that's a lot of connections to the database, file system etc.

BTW, 0.02 days is approx.half an hour, which is more than the 20 minute back-off. To only get 4 work units, a fast quad running 64 bit Linux would need to have their "connect every" set to something like 2 - 3 minutes (0.0014 - 0.002 days). That's a lot of connections for a single host. Now multiply that by the (unknown to me) number of quads (and better) attached to the project...

So I don't think the key is to connect more often but to wait for "x" WU per core (or longer work units), which AFAIK Travis is working on.

I'd say 10 per core and a backoff of 15 minutes would be the way to go, but only if it suits the project. Of course, this would leave the project open to clients asking for more work than they can handle, by faking the number of cores/CPUs with a certain program I won't mention (and don't use)

---

Join the #1 Aussie Alliance on MilkyWay!

The key concept is "server share" what works for one may very well overload the server if too many quads get on this bus. Think son.

Voltron

Son? :p Ok dad, I see the point you want to make ;)

---

BOINC.BE: For Belgians who love the smell of glowing red cpu's in the morning
Tutta55's Lair

The key concept is "server share" what works for one may very well overload the server if too many quads get on this bus. Think son.

Voltron

Son? :p Ok dad, I see the point you want to make ;)

Hmmmmm 1st crash in weeks overnight .....hmmmm.....Guy I don't know where 'dad' is but down here in Texas and sw US thats just the way we talk(watch some old westerns) :)

---

The key concept is "server share" what works for one may very well overload the server if too many quads get on this bus. Think son.

Voltron

Son? :p Ok dad, I see the point you want to make ;)

Hmmmmm 1st crash in weeks overnight .....hmmmm.....Guy I don't know where 'dad' is but down here in Texas and sw US thats just the way we talk(watch some old westerns) :)

I didn't take offense. I just thought it funny being addressed as son.

And I do appreciate Voltron's (and Yoda's) reply. I hadn't thought of that.

---

BOINC.BE: For Belgians who love the smell of glowing red cpu's in the morning
Tutta55's Lair

by faking the number of cores/CPUs with a certain program I won't mention (and don't use)

<-- uses it without speaking a word of French. :P But no matter what it's set to it won't DL more work than the limit set in your prefs. So if you're set at 0.1 days work that's all you'll get at any one time.

---

me@rescam.org

by faking the number of cores/CPUs with a certain program I won't mention (and don't use)

<-- uses it without speaking a word of French. :P But no matter what it's set to it won't DL more work than the limit set in your prefs. So if you're set at 0.1 days work that's all you'll get at any one time.

As I understand it, if you had a machine reporting in as 16 cores (of which many are faked) and asking for 0.1 day worth of work, you'd get up to 0.1 days work for each cors, including the fake ones.

All I am saying is that if we go to a "per core" arrangement, some people might abuse the arrangement using such tools.

I'd really like to get a bigger cache too but it's not what the project admins want (or there would not be a 20 WU limit). See the very first post in this thread...

---

Join the #1 Aussie Alliance on MilkyWay!

FYI:
My win boxe (real dual core) does get 20.
My Linux boxes, all true SMP boxes are lucky to get one or two WU's per request.

Is there any cure for this?