Message boards :
Number crunching :
Cherry-picking + Mass VLARkill usage.
Message board moderation
Previous · 1 · 2 · 3
Author | Message |
---|---|
Sutaru Tsureku Send message Joined: 6 Apr 07 Posts: 7105 Credit: 147,663,825 RAC: 5 |
[...] 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.] |
hiamps Send message Joined: 23 May 99 Posts: 4292 Credit: 72,971,319 RAC: 0 |
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! |
Pappa Send message Joined: 9 Jan 00 Posts: 2562 Credit: 12,301,681 RAC: 0 |
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. |
Luke Send message Joined: 31 Dec 06 Posts: 2546 Credit: 817,560 RAC: 0 |
One problem with VLar Kill that has not been brought up. 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. |
1mp0£173 Send message Joined: 3 Apr 99 Posts: 8423 Credit: 356,897 RAC: 0 |
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. |
Michael Goetz Send message Joined: 14 May 99 Posts: 56 Credit: 622,268 RAC: 0 |
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. |
Pappa Send message Joined: 9 Jan 00 Posts: 2562 Credit: 12,301,681 RAC: 0 |
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. |
James Sotherden Send message Joined: 16 May 99 Posts: 10436 Credit: 110,373,059 RAC: 54 |
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 |
1mp0£173 Send message Joined: 3 Apr 99 Posts: 8423 Credit: 356,897 RAC: 0 |
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? |
Lint trap Send message Joined: 30 May 03 Posts: 871 Credit: 28,092,319 RAC: 0 |
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... |
Wembley Send message Joined: 16 Sep 09 Posts: 429 Credit: 1,844,293 RAC: 0 |
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. Some people run Seti on their GPUs only, not on their CPUs, so rebranding won't work for everybody. |
kittyman Send message Joined: 9 Jul 00 Posts: 51469 Credit: 1,018,363,574 RAC: 1,004 |
Luke, 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 |
kittyman Send message Joined: 9 Jul 00 Posts: 51469 Credit: 1,018,363,574 RAC: 1,004 |
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 |
kittyman Send message Joined: 9 Jul 00 Posts: 51469 Credit: 1,018,363,574 RAC: 1,004 |
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 |
Ianab Send message Joined: 11 Jun 08 Posts: 732 Credit: 20,635,586 RAC: 5 |
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 |
kittyman Send message Joined: 9 Jul 00 Posts: 51469 Credit: 1,018,363,574 RAC: 1,004 |
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? 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 |
Gundolf Jahn Send message Joined: 19 Sep 00 Posts: 3184 Credit: 446,358 RAC: 0 |
One problem with VLar Kill that has not been brought up. It has been brought up ;-) See this message. Gruß, Gundolf |
kittyman Send message Joined: 9 Jul 00 Posts: 51469 Credit: 1,018,363,574 RAC: 1,004 |
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 |
©2024 University of California
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.