It will be work units that didn't make the deadline(for one reason or other) being resent, shouldn't last for long

I thought a quick return was very important to the genetic algorithm.

Seems a bit daft to resend them when they've been stale for a week!

Al.

It's a redundancy check. Each workunit gets produced twice to make sure the results agree. If there is processor error or someone is using a modified app version that doesn't produce the same results, the workunit gets trashed.

---

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

It's a redundancy check. Each workunit gets produced twice to make sure the results agree. If there is processor error or someone is using a modified app version that doesn't produce the same results, the workunit gets trashed.

Why don’t you use the usual BOINC validation system for that, issuing two tasks per WU instead of a pair of single-task WUs? Too much work for the server?

---

It's a redundancy check. Each workunit gets produced twice to make sure the results agree. If there is processor error or someone is using a modified app version that doesn't produce the same results, the workunit gets trashed.

Why don’t you use the usual BOINC validation system for that, issuing two tasks per WU instead of a pair of single-task WUs? Too much work for the server?

I can't answer which is better for the project....but personally I like the current system of instant validation and no pendings :)

---

Why don’t you use the usual BOINC validation system for that, issuing two tasks per WU instead of a pair of single-task WUs? Too much work for the server?

I think that's a valid point. I too like instant credit, but I'd expect the load on the server could be slightly less by putting the two results in one work unit (half the number of work units to keep in the database?)

---

Join the #1 Aussie Alliance on MilkyWay!

One result for sure would be then number of WU's crunched in a day would be ~50% less since each WU has to be run twice. Personally it doesn't make a difference to the crunchers but I don't know if that makes a difference to the project managers.

---

CLICK TO HELP BUILD

One result for sure would be then number of WU's crunched in a day would be ~50% less since each WU has to be run twice. Personally it doesn't make a difference to the crunchers but I don't know if that makes a difference to the project managers.

I'm not positive which way it's done since I've only skimmed the Validator code to see how the credit is awarded. It very well could be done in pairs. I only know it's been modified but the only thing i saw changed was that the credit isn't variable, it's fixed.

---

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

One result for sure would be then number of WU's crunched in a day would be ~50% less since each WU has to be run twice. Personally it doesn't make a difference to the crunchers but I don't know if that makes a difference to the project managers.

I'm not positive which way it's done since I've only skimmed the Validator code to see how the credit is awarded. It very well could be done in pairs. I only know it's been modified but the only thing i saw changed was that the credit isn't variable, it's fixed.

Dave-What they are talking about is like this Einstein result where it takes 2 results to get a valid workunit and on this one I am waiting for my wingman to complete so it is pending for the redundancy check so you have half the amount of workunits out in progress.Look at any mw task and there is only 1 result.

Another drawback for the user is you will get the message of work committed to other platforms so the user runs out of work more often and then net result being it doesn't help the server load all that much.

---

It's a redundancy check. Each workunit gets produced twice to make sure the results agree. If there is processor error or someone is using a modified app version that doesn't produce the same results, the workunit gets trashed.

But that's at odds with the "20 workunit limit" sticky: http://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=250

To quote (selectively) from Travis:

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

So resending a workunit a week later is pointless. What if it doesn't agree with the first validated result? How does the genetically spawned 'tree' get pruned of erroneous parameters; By then it will be tens/hundreds of generations evolved away from the first result.

Not looking to start an argument, just curious :)

Al.

It's a redundancy check. Each workunit gets produced twice to make sure the results agree. If there is processor error or someone is using a modified app version that doesn't produce the same results, the workunit gets trashed.

But that's at odds with the "20 workunit limit" sticky: http://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=250

To quote (selectively) from Travis:

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

So resending a workunit a week later is pointless. What if it doesn't agree with the first validated result? How does the genetically spawned 'tree' get pruned of erroneous parameters; By then it will be tens/hundreds of generations evolved away from the first result.

Not looking to start an argument, just curious :)

Al.

we don't use any redudancy at all. there are enough different parameter sets out there that a single erronenous one that slips through the cracks really wont cause much of a problem at all.

---

It's a redundancy check. Each workunit gets produced twice to make sure the results agree. If there is processor error or someone is using a modified app version that doesn't produce the same results, the workunit gets trashed.

But that's at odds with the "20 workunit limit" sticky: http://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=250

To quote (selectively) from Travis:

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

So resending a workunit a week later is pointless. What if it doesn't agree with the first validated result? How does the genetically spawned 'tree' get pruned of erroneous parameters; By then it will be tens/hundreds of generations evolved away from the first result.

Not looking to start an argument, just curious :)

Al.

we don't use any redudancy at all. there are enough different parameter sets out there that a single erronenous one that slips through the cracks really wont cause much of a problem at all.

There ya go. Sorry for my misinformation.

---

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