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

BTW. Why the opt. crew published an opt._CUDA_app with VLARkill if this is so dangerous for the science?

Is there really nobody (script in the background) which look to this 5 error results/per WU?


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

---

I am also curious about the rescheduler. I haven't made any changes to how often my computer writes to disc and was wondering if I lose time everytime I have to restart boinc? If so how much and is there a setting I should change?

---

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

Sorry, I have waited and waited...

I have stated many things here and other places.

Cherry Picking requires a "user" to spend a LOT of Time "Picking and Choosing" what Workunits to run and which to ABORT (normally what you want to keep, is VHAR's which is the Sweet Spot for Credit). Then with all the recorded information being processed, there is no way to just get only VHAR's.

VLAR Kill removes VLAR's from the GPU and keeps everything else. It not really "cherry picking in the truest sense of the defintion. It does cause more work for the Seti Servers and a bit more bandwidth. It is not a show stopper.

Reschedule puts VLAR's on the CPU where they can be more effective (and can put VHAR's on the GPU). To an extent as you "crunch everything" it the best of both worlds. WE know there are cautions, as Lunatics did not write the code and owner has not been seen for a while. Use with Caution.

It all boils down to how much Science a User wants to do, and how many other things they want to spend/waste time trying to make go RAC higher.

Simple statement RAC is a Very Fickle thing. It goes up and down for NO Apparent Reason! In Seti as a function of Angle Ranges that get split from whichever recorded image. Then you have "delays" as seen in the AVE Result Return Turnaround time in the Server Status. Pending Credits go up and down... To find a true RAC you have to run the machine for a Year and then Average everything.

So people have to decide what works for them. Some may cause a bit more work for the Seti Servers... Well that has been happening for a while and the Admins have not objected.

I also know that in the Developement Forums at Lunatics they are still trying to solve the VLAR Puzzle. They and Alpha Testers there have spent countless hours Programming and in OFFLINE Tests tyring to resolve the issue. There is still hope.

"WE" have to remember that Job #1 is to find ET in the "Best" fashion that "WE" can find. Some things require more effort than others. Beyond that, you can waste a lot of time "trying" whatever you like. Failure in that case does not belong to Seti, it becomes the "user" that had to learn which ever lesson.

So while I do not care for VLAR Kill, I feel that in the short term it works for those that have to have something. But then I could say that you are not completing everything that Seti gives you to work on.

It is all MOOT...

Lets find ET!

Regards

---

Please consider a Donation to the Seti Project.

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

Well, that just shows how much those users care for the project, if they leave, it's all a number game to them, and nothing more.
I only Reschedule once a day, Mark (for clarity sake) Reschedules twice a day. It only takes a few minutes of your time... I wouldn't call that "babysitting". = Not a valid point.
Babysitting implies you are constantly watching and monitoring something.

How about making an Auto-reschedule tool that reschedules automagically at a user-specified time? That may help some...

---

- Luke.

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

I know people are going to take exception to this, but if they're doing damage, then their loss is a benefit.

I also don't understand "babysit" in this context.

What do you really need to do, stop BOINC and run a script?

Windows and *nix both have perfectly servicable schedulers. The scheduler in the OS can run a batch file or shell script that stops BOINC, reschedules the work, and restarts BOINC.

---

Well, that just shows how much those users care for the project, if they leave, it's all a number game to them, and nothing more.

That's not entirely true. I happen to care about the science done at SETI. I also care about the science done at GPUGRID, and the science done at Milkyway.

If SETI has WUs that waste my GPU resources, then that hurts the amount of science I'm able to perform for all three projects. I care about that.

I may very well decide that the VLAR problem is not worth the impact it has on the total science done, and drop SETI until such a time as they correct the problem. In my opinion, this almost, but not quite, falls under the category of a "poorly behaved application" that causes undesired effects on either the computer, other projects, or users of the computer.

Generally speaking, I drop projects that have poorly behaved applications until either the app's behavior is fixed or a suitable work-around is developed.

VLARkill seems like a reasonable workaround, although hardly perfect. As far as I know it seems to be acceptable to the people running SETI too. If it's not -- I'll be happy to take my nvidia-shaped marbles and play elsewhere.

---

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

You People are getting entirely "Too Serious" about something that is being worked on... Where and how, most of you do not know nor can you see it. Eric is on Lunatics, Joe has put many things into Seti Code that makes things better. Raistmer is a Volunteer Developer. There is MORE! You know many of the names here that make your life easier. Some are just not obvious right now.

Over the months more things will go into Seti Beta and then arrive here... Testing is a long and involved process.

The Science is getting done (with few exceptions)

GIVE IT a Break!

Regards

---

Please consider a Donation to the Seti Project.

Im going to throw my 2 cents in also. If vlarkill is so bad, then why does Seti allow it? Untill we start hearing from the guys that run Seti, then its not a problem.
I run 3 computers an old P4 running opt apps. a mac running stock that knows it cant run AP or GPU . And my i7 with a gpu running op apps.
My computer skills stink. If an app. cant do it it with out my input then it wont get done. And there are many like me in seti land. So yes i run vlarkill untill the next generation of unified installer or Seti itself says ok no more vlarkill. I will stay with Seti no matter what though.

---

[/quote]

Old James

If vlarkill is so bad, then why does Seti allow it?

... because it is very difficult for them to disallow.

BOINC has the "anonymous platform" specifically to give the user the ability to run their own applications -- either compiled from "reviewed" source, or from third parties.

There is no mechanism to override that.

But what I don't quite get.

There is this fairly slick rescheduler app. that stops BOINC, goes through the queues and "rebrands" CPU as GPU and GPU as CPU based on angle-range.

It seems to me that, running in "auto" mode, the GPU app. would never get a VLAR to kill.

So, why isn't that more widely used?

---

Luke said - How about making an Auto-reschedule tool that reschedules automagically at a user-specified time? That may help some...

ReScheduler can do that now. It's the "Auto mode"(sic) some folks have mentioned briefly.

The problem is in the time between reschedule events, occasionally a VLAR workunit sneaks in and gets into the clutches of the GPU before it can be "rebranded" for the CPU. A VLAR on my 8800 GTS is a possible GPU lock-up or restart situation, so I run the VLARkill opt-app, too. I don't have any solid numbers, but maybe 2 or 3 workunits get sent back per month (maybe the opt-app should have been named "VLARDeny" rather than VLARkill) out of the approx 3,000/mo my pc crunches.

Martin
edited...

There is this fairly slick rescheduler app. that stops BOINC, goes through the queues and "rebrands" CPU as GPU and GPU as CPU based on angle-range.

It seems to me that, running in "auto" mode, the GPU app. would never get a VLAR to kill.

So, why isn't that more widely used?

Some people run Seti on their GPUs only, not on their CPUs, so rebranding won't work for everybody.

---

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?

Ghosts are not an error....at least not on the part of a user's rig.
Any error has been due to problems at the server end.

I do get a few errors now and again on my rigs, but with a RAC of over 100K, there are bound to be a few here and there. I am sure the percentage is lower than most.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

How about making an Auto-reschedule tool that reschedules automagically at a user-specified time? That may help some...

Actually....the rescheduler DOES have an automagic option that can be turned on and set to run every so many hours.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

And a final comment....

The vlarkill app DOES cherry pick.

The definition of a cherry picker is one who picks and chooses what WU's they want to run and what WU's they want to abort based on whether they earn more or less credit/hour on their rigs.

And that is exactly what the vlarkill app does.

Having said that.........

The Lunatics folks have done wonderful things for this project, and continue to do so every day. The optimization of Cuda crunching is no exception. They are right now working on a way to get around the vlar problem. And I have little doubt that they will one day succeed.

Until then, my solution is to take the time and effort to utilize the resched tool to shunt vlar work which is not wanted on the GPU to be processed by the CPU instead of allowing the vlarkill app to abort it. This does save server bandwidth by not forcing resends. And it keeps my conscience clear because I know that I am processing any and all work that the Seti servers send me.

If Eric thought that the vlarkill induced resends were causing enough of a problem to be an issue, I think he may have indicated so by now.

So my previous statements were based on my 'Seti religion', and my dislike of cherry picking of any sort.
I do realize that those using the vlarkill app are doing it to maximize their GPU production, and this has boosted Seti processing by a large amount....and that is a good thing. They are not doing it to be deceitful or to cheat the system, as some early 'cherry pickers' were doing.

Hopefully, the Lunatics folks will find that magic solution that will keep all the GPU's happy, and fanatics like me too...

Kill or not, keep 'em crunching folks.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

Ideal solution - The CUDA app gets re-written so that VLAR work units get processed in a sensible time. There must be reason that they get bogged down?

Work around - Reprogram the scheduler to only alocate VLAR to CPUs. Or fall back to CPU once the system sees it has a VLAR workunit.

Next best, Use a reschedule app to move VLARs to CPU and some shorties to GPU to even things out. No negative effect on the project, users RAC is improved.

Last resort - use VLAR kill.

The current default system is not working correctly as the user should not notice that BOINC is running in the background. If the bogged down Cuda app makes the users DVD playback stutter, then it's not working correctly.

Fair comment?

Ian

Ideal solution - The CUDA app gets re-written so that VLAR work units get processed in a sensible time. There must be reason that they get bogged down?

Work around - Reprogram the scheduler to only alocate VLAR to CPUs. Or fall back to CPU once the system sees it has a VLAR workunit.

Next best, Use a reschedule app to move VLARs to CPU and some shorties to GPU to even things out. No negative effect on the project, users RAC is improved.

Last resort - use VLAR kill.

The current default system is not working correctly as the user should not notice that BOINC is running in the background. If the bogged down Cuda app makes the users DVD playback stutter, then it's not working correctly.

Fair comment?

Ian

First of all......I don't think we are ever gonna see optimum options in the way the Seti scheduler works.......it needs to handle sooooooooooo many different situations that it cannot possibly be programmed to handle them all.

Second......as in my previous post.....Lunatics is actively working on a Cuda solution that can effectively process vlar without the time penalty it currently suffers from.

Third......yes, the resched tool solves most of the current problems.

Fourth......yes...you have made some fair, if redundant comments.

You understand the situation perfectly.

Meow.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

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

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

It has been brought up ;-)

See this message.

Gruß,
Gundolf

Luke.....

I think that most valid comments have been made in this thread.

You are the thread owner.....what do you say to locking it at this point?

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster