I don't know how much load this would place on the schedulers and other servers, but with the current lack of new tasks, and the high number of lost tasks, could early resends be created.

I would suggest resending tasks older than 10 or 14 days after they are first sent, when one or both of the replies have not been received.

I am aware that the original task would have to be kept until the deadline had passed, but in many cases this will just time out.

I know this will occasionally result in unnecessary duplication of tasks, but we used to have a replication of 3 or 4, so there would not be much waste.

Comments and suggestions please.

[edit] changed quorum to replication

By my opinion, it's a GOOD idea.
Francesco

---

I don't know how much load this would place on the schedulers and other servers, but with the current lack of new tasks, and the high number of lost tasks, could early resends be created.

I would suggest resending tasks older than 10 or 14 days after they are first sent, when one or both of the replies have not been received.

I am aware that the original task would have to be kept until the deadline had passed, but in many cases this will just time out.

I know this will occasionally result in unnecessary duplication of tasks, but we used to have a replication of 3 or 4, so there would not be much waste.

Comments and suggestions please.

[edit] changed quorum to replication

"Out of work" is caused by a number of different things.

A common one is related to angle range: some process slowly, and some are "shorties."

If there is a more than 10:1 ratio between "fast" and "slow" work, and the work creation rate is constant, it seems like we can consistently "outrun" the splitters if there is a run of shorties.

I'm not sure what the limiting factor is, but if it's the feeder or the database, the odds are that reissues wouldn't be any better than new work.

---

There is another reason:

If SETI started releasing "make work" work units to artificially keep us busy, that is volunteer CPU cycles that would not be available for other projects.

It'd make those who crunch only SETI happier, but not for the multi-project crunchers.

If you really want to stay busy, the answer is to find another project that is mildly interesting, and give them a 5% or 10% resource share.

---

I am running 5 projects with equal share (plus LHC) and I am never out of work. Recently, after upgrading my BOINC to 6.6.36 on Linux, Einstein and only Einstein insists that I will not finish in time (false). I then suspend all other projects and get Einstein work. One must beat the machine with brain.
Tullio

---

I am running 5 projects with equal share (plus LHC) and I am never out of work. Recently, after upgrading my BOINC to 6.6.36 on Linux, Einstein and only Einstein insists that I will not finish in time (false). I then suspend all other projects and get Einstein work. One must beat the machine with brain.
Tullio

Tullio,

Have you tried just letting it run? I think you might be surprised.

-- Ned

---

I am still getting SETI work (MB).To Ned: yes, I've let it run but it has the same behavior.

---

ewver since i went to 6.6.36 on my mac milkyways says the same thing wont finish in time. Sop i just set aseti at NNT and when the cahe gets low enough i get milkyway tasks again.

---

[/quote]

Old James

I am still getting SETI work (MB).To Ned: yes, I've let it run but it has the same behavior.

I suspect the "won't finish in time" is caused by the other work already in the cache, and at some point BOINC will let the cache for other projects run down.

... and at that point, it'll fetch the "won't finish" project.

It may take a while for that to happen, however -- as in more than a week.

---

I am still getting SETI work (MB).To Ned: yes, I've let it run but it has the same behavior.

I suspect the "won't finish in time" is caused by the other work already in the cache, and at some point BOINC will let the cache for other projects run down.

... and at that point, it'll fetch the "won't finish" project.

It may take a while for that to happen, however -- as in more than a week.

It is caused by a bug in 6.6.36 that caused a value for estimated delay that was much too large.

---

BOINC WIKI

I am still getting SETI work (MB).To Ned: yes, I've let it run but it has the same behavior.

I suspect the "won't finish in time" is caused by the other work already in the cache, and at some point BOINC will let the cache for other projects run down.

... and at that point, it'll fetch the "won't finish" project.

It may take a while for that to happen, however -- as in more than a week.

It is caused by a bug in 6.6.36 that caused a value for estimated delay that was much too large.

Ah, I'm not running anything that old.

---

I've got a 6.10.2 BOINC client and can easily install it. But is it reliable on Linux?
Tullio

---

I've got a 6.10.2 BOINC client and can easily install it. But is it reliable on Linux?
Tullio

It goes crash during detection of some GPUs.

If you are going to run Alpha test versions, you should really join the BOINC Alpha test email list.

---

BOINC WIKI

I don't know how much load this would place on the schedulers and other servers, but with the current lack of new tasks, and the high number of lost tasks, could early resends be created.

I would suggest resending tasks older than 10 or 14 days after they are first sent, when one or both of the replies have not been received.

I am aware that the original task would have to be kept until the deadline had passed, but in many cases this will just time out.

I know this will occasionally result in unnecessary duplication of tasks, but we used to have a replication of 3 or 4, so there would not be much waste.

Comments and suggestions please.

[edit] changed quorum to replication

Adding a new feature like that to BOINC isn't easy, though of course it's technically feasible. To a certain extent it would mean hosts which are actually slow machines would be doing redundant processing every time the project runs short of work. Presumably fast hosts with large caches will be turning around work faster during such episodes, so would not be affected much.

From the subject, I initially thought you were referring to the <resend_lost_results> project option. I'm hoping that mork might be able to support that mode, and when the project doesn't have much work the "no jobs available" reply to many hosts may be reducing database load anyhow. Certainly resending those ghosted WUs would make sense when possible.

                                                                  Joe

I don't know how much load this would place on the schedulers and other servers, but with the current lack of new tasks, and the high number of lost tasks, could early resends be created.

I would suggest resending tasks older than 10 or 14 days after they are first sent, when one or both of the replies have not been received.

I am aware that the original task would have to be kept until the deadline had passed, but in many cases this will just time out.

I know this will occasionally result in unnecessary duplication of tasks, but we used to have a replication of 3 or 4, so there would not be much waste.

Comments and suggestions please.

[edit] changed quorum to replication

Adding a new feature like that to BOINC isn't easy, though of course it's technically feasible. To a certain extent it would mean hosts which are actually slow machines would be doing redundant processing every time the project runs short of work. Presumably fast hosts with large caches will be turning around work faster during such episodes, so would not be affected much.

From the subject, I initially thought you were referring to the <resend_lost_results> project option. I'm hoping that mork might be able to support that mode, and when the project doesn't have much work the "no jobs available" reply to many hosts may be reducing database load anyhow. Certainly resending those ghosted WUs would make sense when possible.

                                                                  Joe

Unfortunately, this runs into other projects that have work available. Part of the point of BOINC is for the client to pick up work from other projects when a project is out of work. Since there more than 50 active projects, everyone should be able to find some other projects that strike their fancy.

---

BOINC WIKI

If you really want to stay busy, the answer is to find another project that is mildly interesting, and give them a 5% or 10% resource share.

I try to setup other people's machines with their
PRIMARY Project @ 100%
Backup Project @ 10%
All else empty Project @ 1%

They never run out of work. And people seem to become interested in other projects as well.

---

SETI@home since 1999
"Set it, and Forget it!"

If you really want to stay busy, the answer is to find another project that is mildly interesting, and give them a 5% or 10% resource share.

I try to setup other people's machines with their
PRIMARY Project @ 100%
Backup Project @ 10%
All else empty Project @ 1%

They never run out of work. And people seem to become interested in other projects as well.

In my opinion, you can give a project too low a resource share.

The "all else, empty project" is going to get 80 hours a year, and on the rare occasions that it gets work, it'll go straight to "high priority."

---

It's not the only bug in 6.6.36 for linux. This version is apparently incompatible with ubuntu 9.04 version. I run boinc 6.4.5 version again and it's running.

I haven't any deadline problems because seti don't download tasks for my computer.

Around one year ago, I crunshed astropulse taskes with success and now I don't have astropulse taskes whereas my computer is highly efficient.

I actually crunsh another projects.

---

just a poet

It seems to work on my SuSE Linux 10.3. It just downloaded an Einstein unit. All SETI units and QMC units are regularly downloaded after the preceding one has finished. But I must start the BOINC client and then the BOINC manager. The manager won't start the client.
Tullio

---