Message boards :
Number crunching :
No more guppi's=vlars on the gpu please
Message board moderation
Author | Message |
---|---|
zoom3+1=4 Send message Joined: 30 Nov 03 Posts: 65709 Credit: 55,293,173 RAC: 49 |
I just aborted every last cuda42 guppi and I will not run them on My gpu, I thought it was agreed that vlars would not be run on the gpu??? The T1 Trust, PRR T1 Class 4-4-4-4 #5550, 1 of America's First HST's |
Mark Stevenson Send message Joined: 8 Sep 11 Posts: 1736 Credit: 174,899,165 RAC: 91 |
They might run slower but don't cause any problems on my 750ti cards i just let whatever gets downloaded run . Has to be crunched sometime and don't bother me . So they take a bit more time but it's better than aborting them and looking like a total A-HOLE . MB VLAR's don't get run on Nvidia cards (they come from Arecebo) - The new lot come from Green Bank , it's a new scorce of data for the project . Things change it's called life . I would rather move forward than stagnate !! Life is what you make of it :-) When i'm good i'm very good , but when i'm bad i'm shi#eloads better ;-) In't I " buttercups " p.m.s.l at authoritie !!;-) |
Mr. Kevvy Send message Joined: 15 May 99 Posts: 3776 Credit: 1,114,826,392 RAC: 3,319 |
The problem is this isn't just "RAC-obsession". VLARs were kept off the NVidia GPUs for a long time because they can cause the machine to stutter or hang or the work unit to crash. ie my wife's machine starting generating piles of errors as every time she watched any sort of streaming video ie YouTube or Facebook the VLAR work unit in progress would crash. Even if the volunteer chooses not to accept them, their machine(s) will still get them on their CPUs where they will run just fine and cause no issues (for some, even faster than non-VLARs) rather than 2.5x or more slower, at least while there are some non-VLARs. (I keep reading that they are going away, but I haven't seen any indication when. The indication from the team was that it was going to remain about half and half.) If the more efficient GPUs stick to the non-VLAR work, this frees up more CPUs out there for the VLARs (even on my own machine I see this with the GPUs choking on a stack of GUPPIs while the CPUs have all the regular non-VLAR MB work they should be getting. Random scheduling is inefficient.) It's possible that the net result of allowing them on NVidia GPUs is hardly any improvement in compute capacity, just an increase in grief and people leaving the project... yes, some have over it. I'm still puzzled that the code to keep the GUPPIs away was already in place and worked just fine for months(?), but apparently when it was put back on Beta with a setting in the project prefs. to allow or deny them, the result was no GPU work at all. Something must have not been done the same, because the code was already in place and working. I hope it is retried, so this issue can finally be put to rest. |
Mike Send message Joined: 17 Feb 01 Posts: 34253 Credit: 79,922,639 RAC: 80 |
In my point of view time has changed and the apps are better than 3 years ago. I`m aware of lots of NV hosts running VLARs just fine. For those having stuttering or heavy screen lags are 3 options. Use OpenCL app which can be tuned to almost no lags. Like Jason mentioned in the other thread use the boinc option dont crunch while computer is in use. Third option is to use exclusive app option in cc_config.xml. If you only get lags whilst streaming or watching video just exclude this kind of apps. I`m testing different app params atm. So hopefully i can add some params to the read.me for the next installer before final release if Richard is O.K. with it. With each crime and every kindness we birth our future. |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14649 Credit: 200,643,578 RAC: 874 |
So hopefully i can add some params to the read.me for the next installer before final release if Richard is O.K. with it. No problems with that. With any luck, I'll do another slice of installer work this afternoon and tomorrow (but must shop first). My main irritation with guppi_VLAR on GPUs is how slowly they run - and in general, the anti-lag tuning options come at the expense of runtime or CPU availability. I'd prefer to see VLARs sent preferentially to CPUs, because that way we actually get through the recordings quicker and find whatever there is to be found. Looking at the CPU-only cruncher beside me, 10 of the 18 tasks currently scheduled are non-VLAR. At the moment, I am running guppi VLAR on GPU. If the option arrives to disallow that, I'll be in something of a dilemma - to switch or not to switch - unless I can compensate by upping the proportion of VLARs on CPU as well. |
Al Send message Joined: 3 Apr 99 Posts: 1682 Credit: 477,343,364 RAC: 482 |
Richard, to pretty much confirm what you said, on my 48 core machine, 25 of 48 are vlars, basically half of them. |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
Then re-read my last group mail and maybe you could devise another answer than "something bigger needed". |
Mr. Kevvy Send message Joined: 15 May 99 Posts: 3776 Credit: 1,114,826,392 RAC: 3,319 |
If the option arrives to disallow that, I'll be in something of a dilemma - to switch or not to switch. Having initiated the fundraiser for the receiver, I'd probably be the last person one would expect to throw the switch, but I might. That decision comes not from credit or technical issues, but from the observation plan All 43 stars within 5 parsecs, at 1-15 GHz. First-ever complete SETI survey within 5 parsecs. Sensitive to “Earth-leakage†levels of radio transmission. The bill of sale on this new data was that it would be focusing on the habitable planets discovered by the Kepler mission. I don't see that anywhere in the BL list. My reasoning behind wanting it is that, unfortunately and I am hoping temporarily, we only have a sample size of one. We know that life can form and evolve to intelligence on a planet large enough to have a magnetic field in the >273K <373K "goldilocks zone" in a system with a "good jupiter" around a class G2V star. As we know nothing about other possibilities, this is what we should be looking at. If the response is that because we don't know what else is out there then we are limiting our chances of discovery, then we must stick to doing random searches a la Arecibo as we have until now; anything else is making a decision as to what we expect to find thus limiting the possibilities. The furthest Kepler object is 8K Ly away, and there are six hundred million stars within 5K Ly. There's just too much to look at without narrowing it down to the best possibilities of what we currently know in order to maximize our odds (which is why we got interested in GBT in the first place, right?) There isn't much chance of life around an "exotic" because it fried any planets around it on its way to becoming "exotic" so this is designed to look for deliberate beacons (is it?), but as we don't know what logic alien intelligence follows, we may as well look anywhere... they may decide to put beacons around habitable planets, because that is where we should be looking, except unfortunately they're from a Jupiter-sized world with oceans of liquid that to us would be gas, so we don't bother looking there because it isn't habitable to us and miss it by doing targeted searches. I hope to be proven wrong. And I would still probably add a multi-CPU Xeon box or two to the mix to work on the GUPPIs. |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14649 Credit: 200,643,578 RAC: 874 |
Then re-read my last group mail and maybe you could devise another answer than "something bigger needed". Perhaps you could remind me by re-publishing the relevant part of your last group email here, where everyone can participate in the discussion? I think it was sent 22 May. |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
Then re-read my last group mail and maybe you could devise another answer than "something bigger needed". With easy. Especially it was these forums suggestion came from. so, posting here or there but prohibiting Eric response will lead absolutely nowhere! While we working on VLAR computation speedup on GPU there are few things that could help both project performance and healthness. |
zoom3+1=4 Send message Joined: 30 Nov 03 Posts: 65709 Credit: 55,293,173 RAC: 49 |
I just wanted what the thread title says, nothing more, please. Guppi's/vlar's on the cpu, not on the gpu. Thanks. The T1 Trust, PRR T1 Class 4-4-4-4 #5550, 1 of America's First HST's |
Bernie Vine Send message Joined: 26 May 99 Posts: 9954 Credit: 103,452,613 RAC: 328 |
I just wanted what the thread title says, nothing more, please. Yes but I, and I suspect others are fine with them so there has to be a way to "select" them or not. I personally do not want a blanket ban. |
Zalster Send message Joined: 27 May 99 Posts: 5517 Credit: 528,817,460 RAC: 242 |
I'm with Bernie, I have no problem with the GUPPIs So an option it better choice. |
zoom3+1=4 Send message Joined: 30 Nov 03 Posts: 65709 Credit: 55,293,173 RAC: 49 |
I just wanted what the thread title says, nothing more, please. I am ok with a switch Bernie. The T1 Trust, PRR T1 Class 4-4-4-4 #5550, 1 of America's First HST's |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14649 Credit: 200,643,578 RAC: 874 |
And what did Eric reply? (if you remember, there was a glitch with the distribution system and I didn't get any 'reply all'). I think I can post this small segment of an email I received from Eric on another matter: The main effect of Breakthrough on SETI@home has been to pull personnel away. Matt, for example, is 95% Breakthrough and 5% SETI@home these days. (not least, because Matt himself said much the same thing in Technical News, around the same time.) The problem is finding someone qualified to modify the code in a BOINC scheduler, with enough time to devote to the issues. |
Brent Norman Send message Joined: 1 Dec 99 Posts: 2786 Credit: 685,657,289 RAC: 835 |
Remember you can always use the SETI Preferences to set computer locations, Default, Home, Work, School. You can use those locations to set one computer to use CPU only, CPU + GPU, or GPU only ... and other computers to do something else. |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
And what did Eric reply? (if you remember, there was a glitch with the distribution system and I didn't get any 'reply all'). Eric replied nothing. Maybe he read your reply and decided to obstain?... |
rob smith Send message Joined: 7 Mar 03 Posts: 22158 Credit: 416,307,556 RAC: 380 |
I'm firmly in the "If they are sent to my crunchers I'll let them crunch" camp. I would rather one of mine didn't get so many guppi, but it does, so it carries on crunching. Bob Smith Member of Seti PIPPS (Pluto is a Planet Protest Society) Somewhere in the (un)known Universe? |
HAL9000 Send message Joined: 11 Sep 99 Posts: 6534 Credit: 196,805,888 RAC: 57 |
I'm firmly in the "If they are sent to my crunchers I'll let them crunch" camp. I would rather one of mine didn't get so many guppi, but it does, so it carries on crunching. Indeed. The original reason for not sending VLARs to GPUs was that, at the time, they could cause a host to lockup or crash. I don't see the argument that they run less efficiently on GPUs now as valid. If we are going that route we might as well disallow NV GPUs from downloading AP tasks. Since they are less efficient than Radeon GPUs at processing the tasks. Having options from the project to tailor which apps and what kind of work run on specific hardware would be nice. Something similar to what Collatz or PrimeGrid have would probably be ideal, but require a lot of work. Out of curiosity do we know how iGPUs handle these tasks? SETI@home classic workunits: 93,865 CPU time: 863,447 hours Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[ |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
Similarly to AMD most probably. |
©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.