I still wish they would make a version that turns in completed units after a minute. That is what makes your RAC bounce all the time. Knocked off 1st page not because of lower RAC but because I sleep and nothing gets turned in all night. PLEASE COME BACK CRUNCH3R

---

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

I still wish they would make a version that turns in completed units after a minute. That is what makes your RAC bounce all the time. Knocked off 1st page not because of lower RAC but because I sleep and nothing gets turned in all night. PLEASE COME BACK CRUNCH3R

There's a setting in your config file that will do this.

In the file cc_config.xml, add this line:

<report_results_immediately>1</report_results_immediately>

into the <options> section of the config file.

Then either restart boinc or tell boinc to read the config file (in the "advanced menu".)

Note that this option is bad for projects like SETI since it causes there to me more communications with the project, resulting in more load on the server.

Conversely, however, this setting is good for other projects, such as GPUGRID, which benefit from not having that 24 hour delay in getting results returned because their new work is based upon returned results, unlike SETI.

So, turning this setting on hurts some projects but helps others.

Either way, it has a negligible effect on your RAC.

It's a shame this can't be set on a project by project basis.

---

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

I think hiamps was taking a sabbatical from the boards last time we went round this circle, so here's a reprise.

The major downside to reporting results immediately at SETI is the network bandwidth it consumes.

Every time BOINC contacts Berkeley, it transmits a file called 'sched_request_setiathome.berkeley.edu.xml'. You can always see the most recent one in your BOINC Data folder (at the root, not in the seti project folder). Have a look at the size of it, and consider the implications of sending that much data every couple of minutes or so (a dual-GPU machine might easily do that during a VHAR 'shorty' event).

I think hiamps was taking a sabbatical from the boards last time we went round this circle, so here's a reprise.

The major downside to reporting results immediately at SETI is the network bandwidth it consumes.

Every time BOINC contacts Berkeley, it transmits a file called 'sched_request_setiathome.berkeley.edu.xml'. You can always see the most recent one in your BOINC Data folder (at the root, not in the seti project folder). Have a look at the size of it, and consider the implications of sending that much data every couple of minutes or so (a dual-GPU machine might easily do that during a VHAR 'shorty' event).

So how about an option to turn in every hour? The only other option is for me to "Abuse my Boinc buttons" when I am home. Now I will have to watch out for Ned....

---

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

I think hiamps was taking a sabbatical from the boards last time we went round this circle, so here's a reprise.

The major downside to reporting results immediately at SETI is the network bandwidth it consumes.

Every time BOINC contacts Berkeley, it transmits a file called 'sched_request_setiathome.berkeley.edu.xml'. You can always see the most recent one in your BOINC Data folder (at the root, not in the seti project folder). Have a look at the size of it, and consider the implications of sending that much data every couple of minutes or so (a dual-GPU machine might easily do that during a VHAR 'shorty' event).

So how about an option to turn in every hour? The only other option is for me to "Abuse my Boinc buttons" when I am home. Now I will have to watch out for Ned....

Remind me - have you set up a proper flop-balanced working app_info, along the lines of MarkJ's app_info for AP503, AP505, MB603 and MB608? (Don't just blindly copy the figures in that thread - much water, and many CUDA v2.3 DLLs, have flowed under the bridge since July). But if you do that, and get it well-matched to your own hardware, most times BOINC will feel the need for another task in its cache pretty much every time it finishes an old one. Coupled with an automatic rescheduler or script, you can achieve most of what you want: my current list, with ten tasks ready to report across three CUDA-enabled hosts, is pretty typical - and no abused buttons in sight!

I think hiamps was taking a sabbatical from the boards last time we went round this circle, so here's a reprise.

The major downside to reporting results immediately at SETI is the network bandwidth it consumes.

Every time BOINC contacts Berkeley, it transmits a file called 'sched_request_setiathome.berkeley.edu.xml'. You can always see the most recent one in your BOINC Data folder (at the root, not in the seti project folder). Have a look at the size of it, and consider the implications of sending that much data every couple of minutes or so (a dual-GPU machine might easily do that during a VHAR 'shorty' event).

So how about an option to turn in every hour? The only other option is for me to "Abuse my Boinc buttons" when I am home. Now I will have to watch out for Ned....

Remind me - have you set up a proper flop-balanced working app_info, along the lines of MarkJ's app_info for AP503, AP505, MB603 and MB608? (Don't just blindly copy the figures in that thread - much water, and many CUDA v2.3 DLLs, have flowed under the bridge since July). But if you do that, and get it well-matched to your own hardware, most times BOINC will feel the need for another task in its cache pretty much every time it finishes an old one. Coupled with an automatic rescheduler or script, you can achieve most of what you want: my current list, with ten tasks ready to report across three CUDA-enabled hosts, is pretty typical - and no abused buttons in sight!

I will tell you anything you need to know if you can make it work for my machine. I can build them but suck at understanding programing of any sort. I noticed there are lots of examples but none seem to be Generic for all to use...

---

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

Note that this option is bad for projects like SETI since it causes there to me more communications with the project, resulting in more load on the server.

It's bad for any project. It's just that some projects are better able to tolerate the extra load (the ratio of server capacity to user count is more favorable).

If you really must force BOINC to connect more often:

\progra~1\boinc\boinccmd --project http://setiathome.berkeley.edu/ update

Put that in a .CMD file and give it to the windows scheduler.

... but try to keep it to a dull roar, okay hiamps? :-)

---

I will tell you anything you need to know if you can make it work for my machine. I can build them but suck at understanding programing of any sort. I noticed there are lots of examples but none seem to be Generic for all to use...

But that has nothing to do with programming. It's just tweaking one value in your cc_config.xml (<flops>) and observing the effect of it on the bouncing of your DCF (or better, the lack thereof).

Gruß,
Gundolf

This whole topic is just annoying.

Luke, from other threads, I see that you're overclocking you system. Don't you know that this can increase the possibility that the results you send back won't match a non-OC'd system, or any other system? And that would cause more work to be sent out that would not be required had you not overclocked your system? So why do you do it? Based on your argument, OC'd systems should be banned, too.

I have the vlarkill app installed on my 2 systems that have CUDA cards in them. I don't normally have it abort since I also use the rescheduler tool, but occasionally a vlar sneaks up on my system and gets killed. Still uses less bandwidth than me installing an opt app incorrectly and trashing the cache or doing an upgrade of Boinc that does the same thing somehow.

As Careface has said, there's a difference between cherry picking and vlarkill, but even if you don't believe that, there was a bit of an outcry a while back about cherry picking and that practice wasn't banned, so I just can't see vlarkill being banned, either.

-Dave

@Dave...
I don't agree with you there.
The point is, VLARkill has a probability of 1 to kill or send back uncompleted/corrupt WU's
Overclocking however, has a much less than 1 probability of returning flawed WU's, even less if you make sure it is stable via Prime95 or say another program like OCCT.

Perhaps I should change the title to "Cherrypicking + Mass VLARkill Usage..."

---

- Luke.

This whole topic is just annoying.

Luke, from other threads, I see that you're overclocking you system. Don't you know that this can increase the possibility that the results you send back won't match a non-OC'd system, or any other system? And that would cause more work to be sent out that would not be required had you not overclocked your system? So why do you do it? Based on your argument, OC'd systems should be banned, too.

I have the vlarkill app installed on my 2 systems that have CUDA cards in them. I don't normally have it abort since I also use the rescheduler tool, but occasionally a vlar sneaks up on my system and gets killed. Still uses less bandwidth than me installing an opt app incorrectly and trashing the cache or doing an upgrade of Boinc that does the same thing somehow.

As Careface has said, there's a difference between cherry picking and vlarkill, but even if you don't believe that, there was a bit of an outcry a while back about cherry picking and that practice wasn't banned, so I just can't see vlarkill being banned, either.

-Dave

@Dave...
I don't agree with you there.
The point is, VLARkill has a probability of 1 to kill or send back uncompleted/corrupt WU's
Overclocking however, has a much less than 1 probability of returning flawed WU's, even less if you make sure it is stable via Prime95 or say another program like OCCT.

Perhaps I should change the title to "Cherrypicking + Mass VLARkill Usage..."

You're still not doing the math right.
Vlarkill = probability of 1 to kill VLAR task/frequency of VLAR in cache available to kill
OC = possible corruption of ANY task

So, which is more likely? Doesn't matter, because your argument for banning vlarkill is that it produces re-sends, so any practice that would/could produce re-sends at above the ambient level (even a normal CPU w/stock apps can produce a bad result every now and then) should be banned.

-Dave

---

This whole topic is just annoying.

Luke, from other threads, I see that you're overclocking you system. Don't you know that this can increase the possibility that the results you send back won't match a non-OC'd system, or any other system? And that would cause more work to be sent out that would not be required had you not overclocked your system? So why do you do it? Based on your argument, OC'd systems should be banned, too.

I have the vlarkill app installed on my 2 systems that have CUDA cards in them. I don't normally have it abort since I also use the rescheduler tool, but occasionally a vlar sneaks up on my system and gets killed. Still uses less bandwidth than me installing an opt app incorrectly and trashing the cache or doing an upgrade of Boinc that does the same thing somehow.

As Careface has said, there's a difference between cherry picking and vlarkill, but even if you don't believe that, there was a bit of an outcry a while back about cherry picking and that practice wasn't banned, so I just can't see vlarkill being banned, either.

-Dave

@Dave...
I don't agree with you there.
The point is, VLARkill has a probability of 1 to kill or send back uncompleted/corrupt WU's
Overclocking however, has a much less than 1 probability of returning flawed WU's, even less if you make sure it is stable via Prime95 or say another program like OCCT.

Perhaps I should change the title to "Cherrypicking + Mass VLARkill Usage..."

You're still not doing the math right.
Vlarkill = probability of 1 to kill VLAR task/frequency of VLAR in cache available to kill
OC = possible corruption of ANY task

So, which is more likely? Doesn't matter, because your argument for banning vlarkill is that it produces re-sends, so any practice that would/could produce re-sends at above the ambient level (even a normal CPU w/stock apps can produce a bad result every now and then) should be banned.

-Dave

Do you overclock your systems? By the looks of your rigs, you do.
VLARkill still has a larger overall probability of killing a task.

Anyone that overclocks their systems should know to test it thoroughly before running any critical program on it. Most people will test their systems strenuously 24 hours or longer to make sure it's stable, Prime95 may not be as harsh as S@H, but I'll tell you, OCCT's LINPACK benchmark is definitely harder, and most overclockers will check with more than one program.
And even if you pass the most strenuous benchmarks, and somehow, you still have errors, and then you choose to crunch S@H, eventually, through one program or another, your going to get an error or a BSOD.
Overclocking errors are finite. Because most overclockers know what they are doing, and when a BSOD arrives, they will take the appropriate method to fix it.

Anyway, this isn't a discussion to ban overclocking. If you would like to start a new thread about it, please do.

I have never had a single error through my i7 rig. And I'm pretty damn sure Mark's rigs have only ever had a minimal amount of errors, if any, relative to how many tasks he crunches.

---

- Luke.

Do you overclock your systems? By the looks of your rigs, you do.
VLARkill still has a larger overall probability of killing a task.

Anyone that overclocks their systems should know to test it thoroughly before running any critical program on it. Most people will test their systems strenuously 24 hours or longer to make sure it's stable, Prime95 may not be as harsh as S@H, but I'll tell you, OCCT's LINPACK benchmark is definitely harder, and most overclockers will check with more than one program.
And even if you pass the most strenuous benchmarks, and somehow, you still have errors, and then you choose to crunch S@H, eventually, through one program or another, your going to get an error or a BSOD.
Overclocking errors are finite. Because most overclockers know what they are doing, and when a BSOD arrives, they will take the appropriate method to fix it.

Anyway, this isn't a discussion to ban overclocking. If you would like to start a new thread about it, please do.

I have never had a single error through my i7 rig. And I'm pretty damn sure Mark's rigs have only ever had a minimal amount of errors, if any, relative to how many tasks he crunches.

You're missing the point.

What's the basis of saying vlarkill should be banned?

Unless I'm also missing the point, you are basing this on the argument that vlarkill creates unnecessary re-sends.

I don't think either one should be banned, but what my argument is getting at is that you can't really argue to ban a practice because of X (and here, X would be "creating unnecessary re-sends) but then say that some other practice that results in X is OK. And I'm not saying that YOU specifically are creating errors with OC-ing, but people DO create errors with it, just like some people create re-sends with the vlarkill app, but not everyone does.

Anyway, I guess I've said enough for now.

-Dave

---

Luke,
Speaking as a one time ghost on Mark's machine, does that count as an error? It does result in a resend. I'm pretty sure I wasn't the only one sitting waiting for them to time out either. With the amount of WUs he has on his machine it's next to impossible for him to even know they are ghosts.

Would it be possible to build in a button in the BOINC manager to report suspected ghost tasks?

---

PROUD MEMBER OF Team Starfire World BOINC

Do you overclock your systems? By the looks of your rigs, you do.
VLARkill still has a larger overall probability of killing a task.

Anyone that overclocks their systems should know to test it thoroughly before running any critical program on it. Most people will test their systems strenuously 24 hours or longer to make sure it's stable, Prime95 may not be as harsh as S@H, but I'll tell you, OCCT's LINPACK benchmark is definitely harder, and most overclockers will check with more than one program.
And even if you pass the most strenuous benchmarks, and somehow, you still have errors, and then you choose to crunch S@H, eventually, through one program or another, your going to get an error or a BSOD.
Overclocking errors are finite. Because most overclockers know what they are doing, and when a BSOD arrives, they will take the appropriate method to fix it.

Anyway, this isn't a discussion to ban overclocking. If you would like to start a new thread about it, please do.

I have never had a single error through my i7 rig. And I'm pretty damn sure Mark's rigs have only ever had a minimal amount of errors, if any, relative to how many tasks he crunches.

You're missing the point.

What's the basis of saying vlarkill should be banned?

Unless I'm also missing the point, you are basing this on the argument that vlarkill creates unnecessary re-sends.

I don't think either one should be banned, but what my argument is getting at is that you can't really argue to ban a practice because of X (and here, X would be "creating unnecessary re-sends) but then say that some other practice that results in X is OK. And I'm not saying that YOU specifically are creating errors with OC-ing, but people DO create errors with it, just like some people create re-sends with the vlarkill app, but not everyone does.

Anyway, I guess I've said enough for now.

-Dave

All I am asking for is for people to use common sense and use rescheduler instead of VLARkill, crunch the work they're given, and in effect, stop wasting server bandwidth, time, and money, by re-sending perfectly good work via VLARkill, all at the expense of a minimal RAC gain. That's all I'm asking for.

My counter-argument metaphor:
In New Zealand, we have banned nuclear power (say this as VLARkill), because of the pollution and danger factors, does that mean we should have to ban solar plants (Overclocking) and hydropower (optimized apps), because they also cause pollution on a lower scale as well? No.

All I'm asking for is common sense and a little bit less "I'm going to squeeze every inkling from my RAC, even if it has negative consequences".

I hope you understand (and me to you).

---

- Luke.

Luke,
Speaking as a one time ghost on Mark's machine, does that count as an error? It does result in a resend. I'm pretty sure I wasn't the only one sitting waiting for them to time out either. With the amount of WUs he has on his machine it's next to impossible for him to even know they are ghosts.

Would it be possible to build in a button in the BOINC manager to report suspected ghost tasks?

I can't comment on this... because I don't know enough about the whole 'ghost' topic, and I don't want to be misleading.

As to to the button in BOINC... I think it has to with something tasks getting lost in between, the ghost tasks won't appear on your machine, but they will still show up as "In Progress" here on the S@H website.
The button would probably have to be on the S@H website in the task list.

---

- Luke.

Ok, one more comment from me. As I said earlier, I run both the VLARKill and the rescheduler. Since I started using the rescheduler I have killed one VLAR that got on my machine and was killed before I had a chance to reschedule after the last outage. The VLARs are really hard on my machine and I get a BSOD every time my GPU tries to run one. With the VLARKill as a backup to the rescheduler I don't have BSODs anymore but I still get to do most of the work sent to me. It is only on very rare occasions I need the killer.

---

PROUD MEMBER OF Team Starfire World BOINC

Good evening,

I offered the power of my GC to support the project beside the power of my CPU and want to do as much work (No. of WUs) as long as I allow my PC to run for the project.

The project decided to send WUs to my GC, which do not run effective as other WUs do, that´s why I decided to kill this kind of WU to support the project in a better way because my GC is able the run other WUs more effective and faster.

If you do not want me to kill a VLAR-WU, you should enable me to choose in the project settings what kind of WU I want to crunch or you should send VLAR-WUs to CPU-Users only (6.03).

---

Am Ende ist nur Verwirrung

All I am asking for is for people to use common sense and use rescheduler instead of VLARkill, crunch the work they're given, and in effect, stop wasting server bandwidth, time, and money, by re-sending perfectly good work via VLARkill, all at the expense of a minimal RAC gain. That's all I'm asking for.

That's fine, and I completely support that attitude.
I was responding to the fourth line from the bottom of your post that started this thread, though.

My counter-argument metaphor:
In New Zealand, we have banned nuclear power (say this as VLARkill), because of the pollution and danger factors, does that mean we should have to ban solar plants (Overclocking) and hydropower (optimized apps), because they also cause pollution on a lower scale as well? No.

Actually, that comparison doesn't quite work, because you say nuclear has "pollution and danger" but the others just have "pollution", so they're not equivalent in adverse effects. But I'll let it go...

All I'm asking for is common sense and a little bit less "I'm going to squeeze every inkling from my RAC, even if it has negative consequences".

I hope you understand (and me to you).

Like I said, if that's all you're asking for, I'm completely in agreement. That just wasn't what I originally got from what you were saying. Maybe I read it wrong, wouldn't be the first time.

-Dave

---

One problem with VLar Kill that has not been brought up.

5 aborts for a WU and the WU is never processed.

Cherry picking may get extremely hard on the daily quota. There is discussion about lowering the recovery rate dramatically - just to prevent cherry picking.

---

BOINC WIKI

One problem with VLar Kill that has not been brought up.

5 aborts for a WU and the WU is never processed.

Cherry picking may get extremely hard on the daily quota. There is discussion about lowering the recovery rate dramatically - just to prevent cherry picking.

And you will see lot of people leave the project (which don't want to babysit (ReSchedule) their PCs).

Because they don't want to waste their electricity bill for to crunch VLAR WUs on their GPUs.


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

---