If a PC have additional a GPU for crunching, the owner can choose to use the VLARkill mod or the ReScheduler.

What's about the RAC?

If a PC use the VLARkill mod, the RAC is like a CPU only PC.

But, if a PC use the ReScheduler - the RAC will be the same?


Continuously 24/7 and the 'result turnaround time' (with well SETI@home servers) will be all the time the same.
AFAIK, the RAC is stable after ~ one month.


Haa.. if an owner use the ReScheduler, the 'result turnaround time' will vary. (If VLARs to the CPU, and normal & VHARs to GPU)

So 'this' RAC will be 'useless' for to compare with other PCs.

Correct?


____________
[Optimized project applications, for to increase your PC performance (double RAC)!][Overview of abbreviations, which are used often in forum and their meaning.]

---

I use Rescheduler when I need to, but don't put it on your desktop, since the icon is horrible...

I'm more than happy to spend a few hours designing a new one...

---

- Luke.

You saw my question?

I guess - you misunderstood..

Or you would like to say (it's a way of to say) : 'I don't care about.' ?

Sure - this isn't a big prob with the RAC. But an interesting topic for the credit hunter out there.


____________
[Optimized project applications, for to increase your PC performance (double RAC)!][Overview of abbreviations, which are used often in forum and their meaning.]

---

You saw my question?

I guess - you misunderstood..

Or you would like to say (it's a way of to say) : 'I don't care about.' ?

Sure - this isn't a big prob with the RAC. But an interesting topic for the credit hunter out there.


____________
[Optimized project applications, for to increase your PC performance (double RAC)!][Overview of abbreviations, which are used often in forum and their meaning.]

Oh, I do care... but I wouldn't be able to answer it, since I don't have much knowledge on the topic.

I just made a side comment.

---

- Luke.

Not sure of what you meant but I use the rescheduler as this is about getting all the units sent to me done in time and not causing too much grief to my wingmen. RAC is important but doing the work more so. Hopefully someday Seti will figure out how to not make us have to even worry about it.

---

Official Abuser of Boinc Buttons...
And no good credit hound!

I just made a side comment.

For remembrance.

---

me@rescam.org

Sutaru, some could say using optimized clients could be cheating to gain a higher RAC.

---

Sutaru, some could say using optimized clients could be cheating to gain a higher RAC.

I wouldn't consider using rescheduler or the lunatics opti apps 'cheating'. Since they don't harm the science of the project.

What I do really frown upon is cherry-picking WU's that crunch well on your components. That goes beyond necessary, and the gain is minimal, and you waste precious S@H bandwidth and time. Plus it affects the science, so while someone out there may gain RAC, overall, the project loses time.

I think some rules are needed to prohibit cherry-picking.

---

- Luke.

Sutaru, some could say using optimized clients could be cheating to gain a higher RAC.

I wouldn't consider using rescheduler or the lunatics opti apps 'cheating'. Since they don't harm the science of the project.

What I do really frown upon is cherry-picking WU's that crunch well on your components. That goes beyond necessary, and the gain is minimal, and you waste precious S@H bandwidth and time. Plus it affects the science, so while someone out there may gain RAC, overall, the project loses time.

I think some rules are needed to prohibit cherry-picking.

I agree with you there, it is about the science first then RAC...

---

Official Abuser of Boinc Buttons...
And no good credit hound!

If a PC have additional a GPU for crunching, the owner can choose to use the VLARkill mod or the ReScheduler.

What's about the RAC?

If a PC use the VLARkill mod, the RAC is like a CPU only PC.

But, if a PC use the ReScheduler - the RAC will be the same?


Continuously 24/7 and the 'result turnaround time' (with well SETI@home servers) will be all the time the same.
AFAIK, the RAC is stable after ~ one month.

Haa.. if an owner use the ReScheduler, the 'result turnaround time' will vary. (If VLARs to the CPU, and normal & VHARs to GPU)

So 'this' RAC will be 'useless' for to compare with other PCs.

Correct?


____________
[Optimized project applications, for to increase your PC performance (double RAC)!][Overview of abbreviations, which are used often in forum and their meaning.]

I could see VLARkill mode as cheating as it does "cherry pick". It is really like looking at the tasks and aborting ones that have a high estimated completion time.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

I could see VLARkill mode as cheating as it does "cherry pick". It is really like looking at the tasks and aborting ones that have a high estimated completion time.

Correct me if I'm wrong, but doesn't VLARkill kill jobs that run inefficiently on the GPU app, but not under the stock app? If that's correct, then VLARkill is making more efficient use of the available GPU resources, which increases the amount of science done for SETI overall, not just on that one computer.

Isn't that a good thing?

If, on the other hand, these low AR tasks also exhibit the same level of slowdown with the stock CPU app, then yeah, it doesn't make sense.

---

Want to find one of the largest known primes? Try PrimeGrid. Or help cure disease at WCG.

VLARKill makes more efficient use of a GPU's resources at the expense of the project's bandwidth which tends to be saturated from time to time. I'm not speaking for or against the idea, but it does seem quite primitive in it's handling of a problem.

---

Sorry, I used maybe not well words.

I didn't meant really cheating, I 'highlighted' it with '.

I use the VLARkill mod, because I don't want to make this ReScheduler handwork.


The question which was in my mind, but maybe didn't used well english (which isn't my mother language)..
How accurate is the RAC of a PC which use the ReScheduler?

This RAC will be the same like a not ReScheduler RAC?


Non Rescheduler:
24/7, well SETI@home servers, everytime the same WU cache settings.
~ same 'result turnaround time'.
RAC after ~ one month stable.

Used Rescheduler:
24/7, well SETI@home servers, everytime the same WU cache settings.
~ same 'result turnaround time'? I don't think so.
RAC stable? Accurate?


3 day setting for both PCs:
I DL WU, after 3 days calculated and reported.

I DL CUDA VLAR WU, Rescheduler -> send to CPU, there are lot of VLARs collected, the WU will be calculated not in 3, the well result will be send after 5 days.
Or much earlier, if no VLAR for CPU collected.

You could follow me?
It's because of the continuously 'result turnaround time' for to calculate a well RAC.
This is impotant for a stable well RAC. No?

So how inaccurate could be a RAC of a PC which use a ReScheduler?


____________
[Optimized project applications, for to increase your PC performance (double RAC)!][Overview of abbreviations, which are used often in forum and their meaning.]

---

I renamed the title of this thread from:

RAC 'cheating' with ReScheduler ?

to:

RAC inaccurate with ReScheduler ?


____________
[Optimized project applications, for to increase your PC performance (double RAC)!][Overview of abbreviations, which are used often in forum and their meaning.]

---

I could see VLARkill mode as cheating as it does "cherry pick". It is really like looking at the tasks and aborting ones that have a high estimated completion time.

Correct me if I'm wrong, but doesn't VLARkill kill jobs that run inefficiently on the GPU app, but not under the stock app? If that's correct, then VLARkill is making more efficient use of the available GPU resources, which increases the amount of science done for SETI overall, not just on that one computer.

Isn't that a good thing?

If, on the other hand, these low AR tasks also exhibit the same level of slowdown with the stock CPU app, then yeah, it doesn't make sense.

So the work doesn't get done when it was assigned. Making for more work on the projects back end. Which could actually cause problems. If the task was went to several hosts that VLARkill'd it then the work never got done. As after a certain number of errors a task is no longer sent out. Who knows if that one contained a signal they were looking for.

I don't see why the task can't just be reassigned to the CPU if the GPU can't process it.

It is berkeleys project & they will run it how they like. If they decide it's a problem then they might not allow the VLARkill version of the app.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

I renamed the title of this thread from:

RAC 'cheating' with ReScheduler ?

to:

RAC inaccurate with ReScheduler ?


____________
[Optimized project applications, for to increase your PC performance (double RAC)!][Overview of abbreviations, which are used often in forum and their meaning.]

I don't think RAC gets effected to much. It's knows the CUDA overclaims credit, but that seems to get corrected. I don't know if it gets correct if two cuda do the same task.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

Ahh.. BTW..

Not only VLARs to CPU (and the other stay there for what they're DLed), I can set the ReScheduler to send only VLARs to CPU.
This would mean, all the nomal & VHAR WUs of CPU will be send to the GPU.


____________
[Optimized project applications, for to increase your PC performance (double RAC)!][Overview of abbreviations, which are used often in forum and their meaning.]

---

Ahh.. BTW..

Not only VLARs to CPU (and the other stay there for what they're DLed), I can set the ReScheduler to send only VLARs to CPU.
This would mean, all the nomal & VHAR WUs of CPU will be send to the GPU.

That makes sense, then you have all work being downloaded being sent to the "resource" that can handle it most effeciently. Keeping the CPU(s) and the GPU(s) working to the best of their ability. That would provide the most stable Maximum RAC.

Then by setting a moderate Cache you get the best turnaround time.

Regards

---

Please consider a Donation to the Seti Project.

[...]
So the work doesn't get done when it was assigned. Making for more work on the projects back end. Which could actually cause problems. If the task was went to several hosts that VLARkill'd it then the work never got done. As after a certain number of errors a task is no longer sent out. Who knows if that one contained a signal they were looking for.
[...]

AFAIK, but I could be wrong, if 5 or 6 error results are reported the WU won't be send out again (for the moment).
One of the SETI@home crew look which kind of error and if it's all VLARkill error's the WU will be saved and send out fresh again.

Maybe one which know it very well could (dis-)confirm.


____________
[Optimized project applications, for to increase your PC performance (double RAC)!][Overview of abbreviations, which are used often in forum and their meaning.]

---

I would support the banishment of the use of VLARkill. So what if a task runs inefficiently on your GPU? Live with it. I gratefully crunch the work I am allocated.

That's just pathetic, nitpicky behaviour, that gives you a minimal RAC increase at the expense of the projects precious bandwidth and money.

If the RAC is more important to someone than the science, it just shows how much they care for the project.

As for the opposing view that it is overall good for the project, well, all the tasks get crunched eventually, so there is no actual gain for the science as I see it, and even if there is, it is hugely outweighed by the overall loss.

Ban VLARkill!.

---

- Luke.