Cherry-picking + Mass VLARkill usage.

Message boards : Number crunching : Cherry-picking + Mass VLARkill usage.
Message board moderation

To post messages, you must log in.

1 · 2 · 3 · Next

AuthorMessage
Luke
Volunteer developer
Avatar

Send message
Joined: 31 Dec 06
Posts: 2546
Credit: 817,560
RAC: 0
New Zealand
Message 961474 - Posted: 7 Jan 2010, 7:37:35 UTC
Last modified: 7 Jan 2010, 19:00:03 UTC

Okay, this topic has gotten big enough over in RAC inaccurate with Rescheduler?"

I'll start from the start shall I???

Say the team at S@H bring over an amount of data equal to 1000 WU's to crunch.

Without VLARkill & cherrypicking
Someone crunches the sum total of 2WUs.
What this means is overall, the amount of WU's left to crunch will slowly decrease.
Once there are no more WU's left, the team at S@H, go back and collect another bucket of 1000 WU's. and the process repeats. Simple.

This wastes no excess bandwidth, no excess time, no excess server processes, and no excess money. And it does not hold wingmen up.


With VLARkill & cherrypicking
With VLARkill (apparently according to Sutaru) Someone aborts the tasks they don't want, and as a result crunches 5 WU's more for a total of 7 WU's.
What this means is overall, the amount of WU's left to crunch will dcrease more rapidly.
Once there are no more WU's left, we may have to wait for S@H to bring in more WU's, since I do doubt they will bring in more WU's from Arecibo for the <1% of users who abuse the system. Plus the ALFA receiver is not always running, so there is a max as to how much data can be taken from the recorder.

This wastes excess bandwidth, excess time, excess server processes, and excess money. And it does hold wingmen up, all for a minimal gain in RAC.

Overall, we are left with a less productive project.

If one chooses to abuse the system and abort perfectly fine WU's, what does that say about their views on the project? It just makes them interesting in the credits.

No only is this selfish and inconsiderate, but I think it is disgraceful and should be banned.

EDIT: Compromise 1,
I still think it is disgraceful, and mass VLARkill usage should be banned & discouraged.


- Luke.
- Luke.
ID: 961474 · Report as offensive
kittyman Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 9 Jul 00
Posts: 51468
Credit: 1,018,363,574
RAC: 1,004
United States
Message 961475 - Posted: 7 Jan 2010, 7:45:01 UTC

Wonder if the Lunatics crew could modify the vlarkill app to, instead of killing the vlar WU's and sending them back to the mother ship, could automagically send them to the CPU instead?

Kinda like an automagic rescheduler....

Of course, this would not work for the few who do not run any CPU crunching at all, but just GPU....

Just a random thought tossed to the wind......and maybe Jason Gee........LOL.
"Freedom is just Chaos, with better lighting." Alan Dean Foster

ID: 961475 · Report as offensive
Luke
Volunteer developer
Avatar

Send message
Joined: 31 Dec 06
Posts: 2546
Credit: 817,560
RAC: 0
New Zealand
Message 961476 - Posted: 7 Jan 2010, 7:46:13 UTC

Mark said...
My 3 Cuda rigs are all running the vlarkill app......only because I have been too lazy to download the non-vlarkill version and modify my app-info file to run it since I last detached and reattached to Seti.

BUT....I check the rescheduler tool and run it when necessary to shift any vlar work from the GPU to the CPU. I do this once or twice a day, so I suspect you will find very few if any vlarkilled WUs from my Cuda rigs.

I know that many who run the vlarkill app are not so inclined to do the monitoring and use the rescheduler tool so kindly provided at Lunatics to achieve the same end that I do.
This does allow the app to 'cherry pick' and was the main reason I held off on engaging in Cuda crunching as long as I did.

Once the rescheduler tool was made available, as well as the non-vlarkill app, I could get involved with Cuda crunching without betraying my staunch distaste for anything involving cherry picking of work to maximize a cruncher's output.

I have expressed my absolute disdain for picking and choosing what to crunch based on it's 'profitability' many times in this forum....those who have been around for a while know that.

Sooooooooo.....
Until the Lunatics folks come up with a better solution....and they ARE working on it.....
I suggest that folks make use of the rescheduler tool to let their rigs process all the work that their rigs are allocated by the Seti servers.

Do not burden the servers further by allowing the vlarkill app to toss out what doesn't Cudaspeak well.

I could go along with banning the vlarkill app......

That would force users to either use the rescheduler to make sure their Cuda cards do not process vlar work, or accept the fact the if they do not, they will have to process some dogs. Just like everybody else.


Thanks Mark.
- Luke.
ID: 961476 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 961482 - Posted: 7 Jan 2010, 8:06:51 UTC - in response to Message 961475.  

Wonder if the Lunatics crew could modify the vlarkill app to, instead of killing the vlar WU's and sending them back to the mother ship, could automagically send them to the CPU instead?

Kinda like an automagic rescheduler....

Of course, this would not work for the few who do not run any CPU crunching at all, but just GPU....

Just a random thought tossed to the wind......and maybe Jason Gee........LOL.


Actually what I've been experimenting with, based on testing & recommendations by Joe and Raistmer, is a bit like that but perhaps somewhat simpler. It takes the 'hard parts' (pulsefinding in long datasets) from the GPU processing that happen to be dominant in VLAR, and arguably not extremely well thought out in current cuda multibeam implementations), and it processes those bits on CPU instead. Reasoning is that the rest of the processing is quite well done, and seems to perform quite efficiently ... so why not do those bits on GPU still ?

There are a few main things slowing progress with this experimentation down. My single main Pre-Alpha tester running AMD & lower end cards is not seeing the expected performance, and it seems has troubles with other projects conflicting somehow (dunno what's up with that).

Another factor is the lastest Driver performance, and SDK status from nVidia seems to have some issues, hopefully which will be worked out with time.

I've also had a hard drive self detsruct recently .. slowing things down, but gradually gettign the complex build environment back up to scratch.

One (fairly major) upshot to the experimentation, that has appeared so far, is stability. The difficult Power-Over Time arrays within which the difficult pulsefinding dominates, causing VLAR to actually crash the drivers & render the display unusable (for at least some of us), is largely solved by transferring the difficult pulsefinds... and as a conseqence, tasks that normally crash out with the stock CUDA app ... don't.

Jason

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.
ID: 961482 · Report as offensive
kittyman Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 9 Jul 00
Posts: 51468
Credit: 1,018,363,574
RAC: 1,004
United States
Message 961483 - Posted: 7 Jan 2010, 8:17:39 UTC - in response to Message 961482.  

Thank you for chiming in with the latest in Lunatics news......

I am sure some folks here do not get over to your site to check it out.
Even I am somewhat lax in doing so, given the lack of 'blockbuster' advances over the last months. Not that you are not trying, but it's a yeoman's task indeed.

The GPU/CPU phase shifting within the app is a very interesting approach.

If you really need any help in testing some things, I am at the point where I would be willing to give up some live time to help the cause.

PM me if you need help....

But you will have to handhold me, 'cuz it's been soooooo long since I beta tested for you folks. Too long.

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

ID: 961483 · Report as offensive
Profile Careface

Send message
Joined: 6 Jun 03
Posts: 128
Credit: 16,561,684
RAC: 0
New Zealand
Message 961484 - Posted: 7 Jan 2010, 8:21:10 UTC

Hmm. So this project's goal is to be less stressful for servers? Or is it to get work done? If its the later, then I don't see why VLARkill is an issue at all.. VLAR take an age on CUDA cards, and lowers overall output... Rather than seeing VLARkill as "I get more credit this way" why not think of it as without VLARkill "I get fewer credits"?

Yes, there is a kickback effect for the servers and they get some more strain with reissues and what not, but I think you'll find that those <1% who "abuse" the system (not sure how VLARkill is abusing the system when its simply making it more efficient in terms of science done) are going to be a major chunk of the overall crunching power of S@H.

You seem to assume that these "abusers" of the system are simply here for the credits - if we take this premise and follow it with your "lets ban VLARkill", then really the conclusion that will follow from that will be "fine, I'm shifting to a higher paying project" = losing more SETI power.

I guess my issue with your post is the term "abuse". I do not see VLARKill as anything but making the most of what hardware power I donate to SETI - I'm not here for credits at all - I'm here because I want to find out what's out there as fast as possible, because (lets be fair) the likelihood of us finding anything in my lifetime is somewhat minute.

My second issue is with grouping VLARkill and "cherrypickers" together. I believe there is a distinction. For a start, cherrypickers (i.e people who manually abort certain WU only taking in the most profitable in terms of credit [credit/hr] AR WU) are relying on the premise of "I only want to run these WU because they give the highest credit/hr", whereas VLARkillers (for lack of a better term) are simply about "I'm going to avoid these AR ranges [note: different from "I'm going to take only 0.4 AR WU"] because they run like crap and in the same time I can get much more science [note: I guess in this sense "science" refers to credits, which definitely hinders my point, but eh] done with other AR Ranges, not just 0.4 AR".

It really is a subtle distinction, but I believe it's present. I only run VLARkill because I simply don't use SETI on CPU and GPU at the same time due to my rig being a single core, and it makes watching videos nigh on impossible, and because I feel there is a valid and reasonable explanation as to why I do not run VLAR WU on my card.

It's not about the credits - it's about the science [in my view].

I do agree with you though that it sucks that the servers take a beating with people aborting 6bajillion WU due to the VLARkill app, but I think here the blame isn't to be placed on me. Why not do something like F@H does and only send specific WU to the GPU clients? Yes yes, money and all that jazz, valid point - but I don't imagine it would be a particularly hard/long thing to code, and the benefits of writing such a script would outweigh the negatives of the cost to write it. Essentially, why not make ReScheduler server side? Send CPU any kind of WU, send GPU non-VLAR/VHAR due to inefficiencies in code.. if there are no non-VLAR/VHAR work, then oh noes~ the GPU goes without work for a while until some do come in - alternatively, elect to run said VLAR/VHAR WU on the GPU until some others come in.

Sorry, I do see your point, but I simply don't agree with what has been proposed. Harm > benefits in this case, imo.
ID: 961484 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 961486 - Posted: 7 Jan 2010, 8:22:33 UTC - in response to Message 961483.  
Last modified: 7 Jan 2010, 8:23:17 UTC

@Mark: Will get beer then send a PM detailing stuff ;)
"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.
ID: 961486 · Report as offensive
kittyman Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 9 Jul 00
Posts: 51468
Credit: 1,018,363,574
RAC: 1,004
United States
Message 961487 - Posted: 7 Jan 2010, 8:30:16 UTC - in response to Message 961486.  
Last modified: 7 Jan 2010, 8:34:39 UTC

@Mark: Will get beer then send a PM detailing stuff ;)

Beer brings cheer, but whiskey is nifty....LOL.

I await your PM...just give me time to get back on the testing trail......

I have lost all track of the tools needed to do so. I am sure many have been updated numerous times since then. You know I used to keep up on it, but have not for a long time......so many things will have to be explained to me from scratch about now.

And I am sorry but I have to ask this one last time, because it has been running though my mind every few months for a long while now......

Does anybody know what happened to our beloved Chicken, now long gone?
I still sometimes think about and miss our old Simon....who started this all.

How many here and now remember what the 'Chicken apps' were...LOL.

PM me if you think this is not appropriate.

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

ID: 961487 · Report as offensive
Luke
Volunteer developer
Avatar

Send message
Joined: 31 Dec 06
Posts: 2546
Credit: 817,560
RAC: 0
New Zealand
Message 961488 - Posted: 7 Jan 2010, 8:38:22 UTC - in response to Message 961484.  
Last modified: 7 Jan 2010, 8:43:26 UTC

Replying instead of quoting Careface. Quite a long post you've put together...

I don't see any gain in science at all, since the notion that "we'll (as a project) get through more work quicker if we collectively run VLARkill" is flawed, when all the work (if we don't run VLARkill) will get crunched eventually anyway. The discerning factor here is that, Eric, Matt .et al, piggybacks a finite amount of tasks from Arecibo, they only get so much time on the telescope, and the ALFA receiver is not always switched on.

As for "I'm going to shift to a higher paying project" - the people that do this have flawed logic. Everyone here must remember that BOINC's (literally - Berkeley Open Infrastructure for Network Computing) original goal was in the name of science, all 'credits' were intended for was to show a users contribution to a project. However, this appears to have been warped to something like 'I've got more credits than you' in some instances. The 'credit' was also meant to be a BOINC wide standard, there should be no higher or lower paying project at all, but that's another topic that isn't suitable for discussion here.

It's a morality issue too, people are aborting perfectly good and non-corrupt (albeit slow) tasks to throw back to the server for others to crunch, and if everyone (although extremely unlikely) was to adopt VLARkill, these tasks would not get done at all. It's like a kid saying "I don't want this piece of cake, because it only has a single skittle on top!". Any parent would tell that kid the be grateful for what he has, or politely tell him/her off.

I respect your views Careface, I really do...
- Luke.
ID: 961488 · Report as offensive
Profile Careface

Send message
Joined: 6 Jun 03
Posts: 128
Credit: 16,561,684
RAC: 0
New Zealand
Message 961489 - Posted: 7 Jan 2010, 8:39:36 UTC - in response to Message 961487.  
Last modified: 7 Jan 2010, 8:53:54 UTC


How many here and now remember what the 'Chicken apps' were...LOL.


I do! I still have one of the 'old' V2.4 chicken apps hiding somewhere in my backups folder >_>;


I don't see any gain in science at all, since the notion that "we'll (as a project) get through more work quicker if we collectively run VLARkill" is flawed, when all the work (if we don't run VLARkill) will get crunched eventually anyway. The discerning factor here is that, Eric, Matt .et al, piggybacks a finite amount of tasks from Arecibo, they only get so much time on the telescope, and the ALFA receiver is not always switched on.


Hm, perhaps I was a little too vague - while I agree there is no overall gain in science done, there is a gain in science done per <unit of time>, which was pretty much what the VLARkill app was designed for. Eventually, yes, all WU will be crunched eventually, but that could have been said for SETI classic running unoptimised code on pentium 3s - it'd just take a hell of a lot longer, and that's the issue for me. I have no problem running VLAR WU if there's nothing else to crunch, but if there's a more efficient (in terms of science per hour, so to speak) route, I'm definitely going to take it.

Just like my crappy part time job at a supermarket - eventually, I sure as hell am going to get all of the stuff on the shelf, but if I can get it done quicker by whatever method, I'm going to do it and get the hell out of there as fast as possible :p

As for "I'm going to shift to a higher paying project" - the people that do this have flawed logic. Everyone here must remember that BOINC's (literally - Berkeley Open Infrastructure for Network Computing) original goal was in the name of science, all 'credits' were intended for was to show a users contribution to a project. However, this appears to have been warped to something like 'I've got more credits than you' in some instances. The 'credit' was also meant to be a BOINC wide standard, there should be no higher or lower paying project at all, but that's another topic that isn't suitable for discussion here.


I fully agree - which is why I'm not one of those higher-credit-project-shifters.. Heck, I'm not even one of those "hey, F@H is 'better' than SETI, I'll run that!" because I'm here because I'm more interested in this project :)


It's a morality issue too, people are aborting perfectly good and non-corrupt (albeit slow) tasks to throw back to the server for others to crunch, and if everyone (although extremely unlikely) was to adopt VLARkill, these tasks would not get done at all. It's like a kid saying "I don't want this piece of cake, because it only has skittle on top!". Any parent would tell that kid the be grateful for what he has, or politely tell him/her off.


For the sake of the argument I'll assume you're assuming everyone is running CUDA and everyone has VLARkill, which would make this true - and I would agree with you, it's a crappy situation. That's why I have no problem running VLAR in the case of there being nothing else to crunch. Generally speaking, I don't run other projects at all, because S@H is the only one I'm actually interested in, and.. yes, I guess strictly speaking that's me being selfish, but I guess I just don't want to be told what I am and am not allowed to contribute - much like the charities I donate to (Child Heart Foundation/Cancer Foundation etc), I don't want to be told what I'm allowed to have my money go towards - it's really about the overall goal, not just the immediate and mid-term stepping stones. (my opinion, of course :P)


I respect your views Careface, I really do...


And I, yours. Us Kiwi's gotta stick together, right? :p But on a serious note, if it really does become "rule" that VLARkill is banned, I'm not going to emorage and quit SETI - I just won't be overly happy about it.

Typical NZ thing, really. "She'll be right mate"
ID: 961489 · Report as offensive
Luke
Volunteer developer
Avatar

Send message
Joined: 31 Dec 06
Posts: 2546
Credit: 817,560
RAC: 0
New Zealand
Message 961492 - Posted: 7 Jan 2010, 8:45:32 UTC - in response to Message 961487.  

@Mark: Will get beer then send a PM detailing stuff ;)

Beer brings cheer, but whiskey is nifty....LOL.

I await your PM...just give me time to get back on the testing trail......

I have lost all track of the tools needed to do so. I am sure many have been updated numerous times since then. You know I used to keep up on it, but have not for a long time......so many things will have to be explained to me from scratch about now.

And I am sorry but I have to ask this one last time, because it has been running though my mind every few months for a long while now......

Does anybody know what happened to our beloved Chicken, now long gone?
I still sometimes think about and miss our old Simon....who started this all.

How many here and now remember what the 'Chicken apps' were...LOL.

PM me if you think this is not appropriate.

Mark


LOL - gotta' love the chicken apps... my first opti!
- Luke.
ID: 961492 · Report as offensive
kittyman Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 9 Jul 00
Posts: 51468
Credit: 1,018,363,574
RAC: 1,004
United States
Message 961498 - Posted: 7 Jan 2010, 9:06:57 UTC - in response to Message 961492.  



LOL - gotta' love the chicken apps... my first opti!

Me too.......but they no longer taste like chicken.....LOL.


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

ID: 961498 · Report as offensive
Profile Gundolf Jahn

Send message
Joined: 19 Sep 00
Posts: 3184
Credit: 446,358
RAC: 0
Germany
Message 961506 - Posted: 7 Jan 2010, 10:12:20 UTC - in response to Message 961474.  

With regard to the disadvantages of VLARkill I'd like to return to the following statement from Sutaru's thread:
HAL9000 wrote:
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.
Currently SETI is set to
max # of error/total/success tasks	5, 10, 5
(and there is no one doing that rejecting of work units by hand, Sutaru)

So, there is a non-zero probability (albeit very small) that a result is not computed - and that could contain the signal!

Gruß,
Gundolf
Computer sind nicht alles im Leben. (Kleiner Scherz)

SETI@home classic workunits 3,758
SETI@home classic CPU time 66,520 hours
ID: 961506 · Report as offensive
Profile HAL9000
Volunteer tester
Avatar

Send message
Joined: 11 Sep 99
Posts: 6534
Credit: 196,805,888
RAC: 57
United States
Message 961507 - Posted: 7 Jan 2010, 10:20:10 UTC - in response to Message 961506.  

With regard to the disadvantages of VLARkill I'd like to return to the following statement from Sutaru's thread:
HAL9000 wrote:
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.
Currently SETI is set to
max # of error/total/success tasks	5, 10, 5
(and there is no one doing that rejecting of work units by hand, Sutaru)

So, there is a non-zero probability (albeit very small) that a result is not computed - and that could contain the signal!

Gruß,
Gundolf

I also noted in that thread that the VLARkill app seems to be working the same as the stock app. However I am unsure if the result I was using as reference was autokilled.
SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[
ID: 961507 · Report as offensive
Profile hiamps
Volunteer tester
Avatar

Send message
Joined: 23 May 99
Posts: 4292
Credit: 72,971,319
RAC: 0
United States
Message 961512 - Posted: 7 Jan 2010, 12:22:52 UTC - in response to Message 961487.  

@Mark: Will get beer then send a PM detailing stuff ;)

Beer brings cheer, but whiskey is nifty....LOL.

I await your PM...just give me time to get back on the testing trail......

I have lost all track of the tools needed to do so. I am sure many have been updated numerous times since then. You know I used to keep up on it, but have not for a long time......so many things will have to be explained to me from scratch about now.

And I am sorry but I have to ask this one last time, because it has been running though my mind every few months for a long while now......

Does anybody know what happened to our beloved Chicken, now long gone?
I still sometimes think about and miss our old Simon....who started this all.

How many here and now remember what the 'Chicken apps' were...LOL.

PM me if you think this is not appropriate.

Mark

I often wonder if he is the hidden user I sometimes see on their boards. I miss Simon he helped me a lot and I still owe him....
Official Abuser of Boinc Buttons...
And no good credit hound!
ID: 961512 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 961513 - Posted: 7 Jan 2010, 12:24:04 UTC

OMG, all this was discussed many times.
Current CUDA implementation is unable to do VLAR effectively. Using GPU for VLAR is just a waste of crunching time and electricity.
Currently 2 re-sheduling methods available
1) Most preferable one:
By using Re-schedule app by Marius or by using re-schedule script by me or something alike. VLARs will be marked as CPU job instead of GPU one, no task reissues needed.
2) default way for lazy or unaware users - VLARkill build.
It has disadvantage of task re-issue by server but still gives much better performance than doing VLARs on GPU.

And to consider this as some negative and non-social activity is nonsense IMO ( @Luke specially :P )
ID: 961513 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 961514 - Posted: 7 Jan 2010, 12:29:59 UTC - in response to Message 961474.  


Overall, we are left with a less productive project.
- Luke.


It's just untrue as long as sending task into outer world will bring more performance than crunching it locally on server.
Project completely relies on performance of external hosts. VLARkill substantially
increase such host performance.
Last what I would say on this topic.
ID: 961514 · Report as offensive
Profile Gundolf Jahn

Send message
Joined: 19 Sep 00
Posts: 3184
Credit: 446,358
RAC: 0
Germany
Message 961537 - Posted: 7 Jan 2010, 14:37:28 UTC - in response to Message 961507.  

I also noted in that thread that the VLARkill app seems to be working the same as the stock app. However I am unsure if the result I was using as reference was autokilled.

Nope, that wasn't VLARkilled. It got "The number of results detected exceeds the storage space allocated". And it wasn't even VLAR at a true angle range of 2.404728.

Killed VLARs return a real error (with exit code -6, I think).

Gruß,
Gundolf
ID: 961537 · Report as offensive
Profile dnolan
Avatar

Send message
Joined: 30 Aug 01
Posts: 1228
Credit: 47,779,411
RAC: 32
United States
Message 961539 - Posted: 7 Jan 2010, 14:43:08 UTC

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
ID: 961539 · Report as offensive
Profile perryjay
Volunteer tester
Avatar

Send message
Joined: 20 Aug 02
Posts: 3377
Credit: 20,676,751
RAC: 0
United States
Message 961549 - Posted: 7 Jan 2010, 15:55:57 UTC

Ok, my turn. My little Celeron dual just isn't powerful enough to do as much work as I would like for SETI. When we first started to do work on GPUs I ran out and bought an 8500GT card. It was all I could afford at the time. It wasn't long before I noticed I had a problem, VLARs would cause the driver to crash and the WU would error out. Not only was this not getting any work done for the project, it was also running the risk of screwing up my machine.

When the VLARKiller came out I jumped on it and all was well with the world. WUs that I could not do were sent back in the hopes they would go to someone that could get them done. Then I saw the first version of the rescheduler but I knew nothing of this Perl that had to be used. I tried instead going to a little stronger 9500GT card but was still getting the driver crashes. Then I saw they had made the rescheduler easier to install and use. No more Perl. I jumped on it and have been getting more work done than ever before. Since I have been running rescheduler I have VLARkilled one WU. It snuck in with the refills I got after the last outage and started before I had a chance to check with the rescheduler.

This is not cherry picking, it is preservation of my machine. While the VLARs were trying to run I couldn't do anything else on my machine until the driver crashed and another good WU started. The combo of VLARkill and reschedule are the best things to happen for me since I first figured out how to use the Chicken opt apps way back when.


PROUD MEMBER OF Team Starfire World BOINC
ID: 961549 · Report as offensive
1 · 2 · 3 · Next

Message boards : Number crunching : Cherry-picking + Mass VLARkill usage.


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