Posts by William
|
1)
Message boards :
Number crunching :
Credit ReNewEd!
(Message 1796815)
Posted 17 Jun 2016 by  William
Post: 11 not counting overflows. |
|
2)
Message boards :
Number crunching :
OpenCL NV MultiBeam v8 SoG edition for Windows
(Message 1795013)
Posted 10 Jun 2016 by William
Post: Just got two bad work units with missing header information it looks like. Well I assumed that anybody who runs into an error that may be due to file damage does first check the integrity of the hard disc before taking it any further. |
|
3)
Message boards :
Number crunching :
OpenCL NV MultiBeam v8 SoG edition for Windows
(Message 1795005)
Posted 10 Jun 2016 by William
Post: well that was a dead end. Raistmer's last changes (before the extra lines for linux) exactly match Eric's and I've not had enough coffee to certify that Jason's internal switching matches that [@Jason rev. 3315 line 125 I assume you moved that into the temp variable at lines 227 ff. ?] So, unless it's reproducible - see Richard's comments on odd errors [or is that edd errors? ] |
|
4)
Message boards :
Number crunching :
OpenCL NV MultiBeam v8 SoG edition for Windows
(Message 1795001)
Posted 10 Jun 2016 by William
Post: If that is Raistmer's file he'll have build from https://setisvn.ssl.berkeley.edu/trac/browser/branches/sah_v7_opt/AKv8/client/seti_header.cpp at revision 3377 changes from Urs. you'd have to diff that against vanilla seti and Jason's. edit i.e. https://setisvn.ssl.berkeley.edu/trac/browser/branches/sah_v7_opt/Xbranch/client/seti_header.cpp and https://setisvn.ssl.berkeley.edu/trac/browser/seti_boinc/client/seti_header.cpp |
|
5)
Message boards :
Number crunching :
OpenCL NV MultiBeam v8 SoG edition for Windows
(Message 1794989)
Posted 10 Jun 2016 by William
Post: So does that mean that computer mangled the work units just when it grabbed them for processing? there's an MD5 check after DL isn't there? And/or a size check? |
|
6)
Message boards :
Cafe SETI :
Beet's give us a caption #64
(Message 1794716)
Posted 9 Jun 2016 by William
Post: Darwin Award competitor. |
|
7)
Message boards :
Number crunching :
CUDA Toolkit 8.0 Available for Developers
(Message 1794397)
Posted 8 Jun 2016 by William
Post: I think Richard is more worried about resource share, if a heterogenous app grabs devices BOINC has earmarked for other project's apps? but then the stub app needs to know what it has available and tell boinc what it might want. In effect, the app could say 'please give me as many GPU and CPU cores as possible' and boinc has to be able to reply 'ok you can have x CPU and y GPU cores' with an option for 'excuse me can you free up another core ' or ' have another'... That's quite a revamp of current scheduling... |
|
8)
Message boards :
Number crunching :
CUDA Toolkit 8.0 Available for Developers
(Message 1794394)
Posted 8 Jun 2016 by William
Post: I think Richard is more worried about resource share, if a heterogenous app grabs devices BOINC has earmarked for other project's apps? |
|
9)
Message boards :
Number crunching :
Some considerations regarding OpenCL MultiBeam app tuning from algorithm view
(Message 1793968)
Posted 6 Jun 2016 by William
Post: Here: http://lunatics.kwsn.info/index.php/topic,1808.msg60931.html#msg60931 I tried to explain some of peculiarities of VLAR task and options (in progress) of OpenCL MultiBeam app that could help to deal with them. made link clickable. |
|
10)
Message boards :
Number crunching :
vlar data and breakthrough listen
(Message 1793909)
Posted 6 Jun 2016 by William
Post: For the sake of DonS before his question gets buried in unrelated discussions: [and partially just rephrasing what Zalster posted] You can distinguish between Arecibo and breakthrough listen data [tasks] by the name of the tasks. If there's 'guppi' in the name, you are crunching breakthrough listen, if not you're looking at Arecibo data (what we've been doing for the past 17 years and still keep plodding through). Guppi stands for 'Greenbank Ultimate Pulsar Processing Instrument'. The Greenbank telescope does mainly close observations of suns that may have planets around them (therefore more likely to have aliens). Arecibo depends on what the researcher is looking at - we only piggyback. That data may be sweeping the sky. VLAR stands for 'very low angle range' Imagine a telescope pointing at a star for a night. as the star moves across the sky (or rather the earth moves...) the telescope needs to move with it. the difference between the position at the start and the end of the data makes the angle range (AR). Arecibo data can come in mid-AR (the bulk) with ARs in the region of 0.4 [if you look at a finished task e.g. this one you can see the AR printed near the top.] There are also VHAR - very high AR, 2 and above and VLAR with an AR below 0.12 [it's derived from the beam width these days so may differ for guppi]. As you can see in the task linked the AR for guppi is usually very very small - as I said they tend to point at a star, so you have minimal movement. I think that covered the questions. Now, to the discussion that ensued. When Greenbank data was first discussed by Eric, the assumption was, this would be very big tasks possibly lasting weeks if not months. When we finally got guppis it turned out they have been parceled into much the same size as we are used to from Arecibo. Now, VLAR on NV. Back in 2009 it was found that the signal search algorithms as NVidia ported them to CUDA aren't really suited for the data structure of VLARs. Basically it takes an disproportional amount of processing power. The GPUs we had back then didn't cope very well, for some people slowing down the display as to make the host totally unresponsive. As GPUs got bigger, the problem lessened. Still the complaints - and the ensuing workarounds [like automated task abort]- led to the project introducing checks on the AR, marking VLAR as such and not distributing them to NV GPUs. Now, the picture has shifted. Besides having much more powerful GPUs we also have OpenCL applications. And the SoG app is far better suited to VLARs then the current CUDA app. [AFAIK by processing some stuff on the CPU, but you'd have to ask the developer i.e. Raistmer] The downside of the OpenCL apps on NV is that they basically block a CPU core too. Whether or not you are prepared to sacrifice some CPU to better GPU is up to you. We are still waiting for better preferences on that issue, to better accommodate what and how people like to run. Since that is BOINC territory, it isn't exactly easy to achieve. So, guys and gals, if you have anything to add to enlighten DonS or more detail to provide, go ahead. If, however, you wish to discuss anything from the size of guppis to the suitability of apps please open a dedicated thread. This is a newbie question and he deserves a simple and precise answer not a technical discussion/argument he doesn't understand atm. |
|
11)
Message boards :
Number crunching :
1073741205 Error Code (Unknown Error)
(Message 1793151)
Posted 3 Jun 2016 by William
Post: Richard - first test passed OK. did you reproduce the error behaviour with the old build before you dropped in the new one? can't know if you've cured, if you don't have symptoms in the first place... [and just because you don't have symptoms any more, doesn't mean you've been cured...] |
|
12)
Message boards :
Number crunching :
OpenCL MB v8.12 issues thread attempt 2
(Message 1793103)
Posted 3 Jun 2016 by William
Post:
or on windows, just use the Lunatics installer. Doing you own app_info.xml is hardcore. The easier way is start out with installer and then get rid of the stuff that's only in there for the transition. And remember getting app_info.xml wrong is a very good way to wipe your cache. |
|
13)
Message boards :
Number crunching :
1073741205 Error Code (Unknown Error)
(Message 1792878)
Posted 2 Jun 2016 by William
Post: I like the tags https://github.com/BOINC/boinc/issues/1553 was awarded :) |
|
14)
Message boards :
Number crunching :
No credits for GPU work
(Message 1792825)
Posted 2 Jun 2016 by William
Post: App details says host crunched v8 on ATI. version 8.12, so must have done GPU work since 19th may. Some old tasks waiting on wingman, but nothing on board. The old question 'not asking or not getting'. Ubbe, we need more details on the problem. Please post the first 30 or so lines from the eventlog after a startup. if you know how to do it, enable the 'work_fetch_debug' log flag, do a manual update of the project and post the results. If not, don't worry, we'll check on that after we've eliminated other possibilities. In your preferences, do you allow the GPU to work while the computer is in use or not? edit: a possible source of the problem is win10 updating your video card driver to a version that has no OpenCL support. The startup messages will show that. We don't know your level of skill with either BOINC or computers in general. Please say if we need to provide greater detail on how to accomplish stuff. |
|
15)
Message boards :
Number crunching :
1073741205 Error Code (Unknown Error)
(Message 1792819)
Posted 2 Jun 2016 by William
Post: Anticipated timescale? About a decade... Ever the optimist. Some projects run server code from 2008... |
|
16)
Message boards :
Number crunching :
1073741205 Error Code (Unknown Error)
(Message 1792809)
Posted 2 Jun 2016 by William
Post: The trick is not the size of the rolling pin, the trick is to know how and where to deploy. What I don't quite understand is why we are suddenly seeing these errors. Those who experienced them, can you pinpoint when it started? And while we are there, can you check if we are looking at a problem when a task first starts, when it restarts or even something that happens to running tasks. Doing a controlled shutdown experiment and examining the entrails might help. What kind of shutdown was it anyway? |
|
17)
Message boards :
Number crunching :
I've Built a Couple OSX CUDA Apps...
(Message 1792155)
Posted 30 May 2016 by William
Post: sorry, NV for me is still synonymous with CUDA. I forget they can do OpenCL as well. |
|
18)
Message boards :
Number crunching :
I've Built a Couple OSX CUDA Apps...
(Message 1792137)
Posted 30 May 2016 by William
Post: From my POV the problem starts with having to get a driver... |
|
19)
Message boards :
Number crunching :
SETI/BOINC Milestones [ v2.0 ] - XXIX
(Message 1792076)
Posted 30 May 2016 by William
Post: Oh so quietly I clocked up 2k posts :) |
|
20)
Message boards :
Number crunching :
Average Credit Decreasing?
(Message 1792067)
Posted 30 May 2016 by William
Post: Question: I think you are asking the wrong question. IF RAC was really linear to science done, yes you could look at RAC (per project) to ask that question ('what's more effective') For E@H, with their fixed credits, that's indeed the case. Here, were RAC isn't a direct measurement of throughput, you get a less clear answer. Being a scientist, I'd just run the experiment ;) Probably the AMD will be better here as the NV cards aren't (currently) that good at processing the VLAR we are getting. But unless somebody can give you an approximate figure on your 7970, I'd just swap and see what I get. And remember RAC takes a looong time to stabilise going up. |
Next 20
©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.