Posts by jason_gee

1) Message boards : Number crunching : Panic Mode On (104) Server Problems? (Message 1843004)
Posted 3 days ago by Profile jason_gee
Post:
The clue was when I used the word 'randomness'.
'Credit New' is now in charge of the scheduler.................LOL.


You're not just whistling Dixie Kittyman (though you may think you were). The estimate components of CreditNew have driven work issue since inception, and those prediction/estimate components are precisely where the design faults are.
2) Message boards : Number crunching : I've Built a Couple OSX CUDA Apps... (Message 1842609)
Posted 6 days ago by Profile jason_gee
Post:
Still a Race?

Otherwise the Linux version looks promising, still a large number of Inconclusives with the Mac version.


Quite probably (same time yet different lower period+score). That's across the unroll still. In between some family responsibilities, I've managed to work out a way to possibly retain the full speed code, allow some further optimisations, and produce the expected results. Will probably be end of the week before I can dig in properly, and I need to poke into updated code Petri sent me also.
3) Message boards : Number crunching : BOINC odd network traffic (Message 1842337)
Posted 7 days ago by Profile jason_gee
Post:
The Boinc Manager GUI is effectively an RPC (wiki link) client, and the Boinc client an RPC server. The GUI will be requesting a list of active tasks, remaining times etc, on a second by second basis. Depending on the number of tasks, whether or not you are showing 'All Tasks', and the version of Boinc manager you might be using, that traffic could be pretty variable. Personally I use Fred's BoincTasks instead, which lets me configure the update frequency on a host by host basis. Probably second by second updates IMO are excessive, though probably complaints would be heard if that was reduced.
4) Message boards : Number crunching : I've Built a Couple OSX CUDA Apps... (Message 1841414)
Posted 11 days ago by Profile jason_gee
Post:
Yeah, since v8 all known good applications converged a lot, the benching practices need refinement. Probably with some hand selected/tweaked tasks, to expose specific weaknesses. We lost our expert in that area (Joe), and no-one seems to know for sure what happened. Most likely It's time to transition to internal regression for most applications (like stock CPU has), but that takes a level of organisation resisted by the state of flux with all platforms at the moment.

Just tell the OS people to stop being 'Special Snowflakes', and concentrate on supporting developers instead of lining their pockets.
5) Message boards : Number crunching : CES 2017 -- AMD RYZEN CPU (Message 1841402)
Posted 11 days ago by Profile jason_gee
Post:
Yes, AMD fans have been burned before. They'll be wanting hard independent data before committing. My impression so far is that it may compete well with i5 and Skylake in general, but we'll see.
6) Message boards : Number crunching : Unable to get ATi GPU's to Crunch in Ubuntu (Message 1839721)
Posted 19 days ago by Profile jason_gee
Post:
try:
sudo apt-get update
sudo apt-get install build-essential

and try again [if it installs something]. Probably already installed, and not mentioned in the dependencies, but can't see any installer building kernel modules without it. There is probably other stuff missing if that package is missing, but at least would probably point to needing to setup for kernel module building in more detail. [The display mentions a log file with the probably correct order for installation... odd that it seems to just stop on Linux Headers...]
7) Message boards : Number crunching : Linux CUDA 'Special' App finally available, featuring Low CPU use (Message 1839540)
Posted 20 days ago by Profile jason_gee
Post:
Ugh, frustrating. Well we'll see. Probably if nothing happens between now and getting Windows working with the Radeon and 1050ti, then I'll rather umbilical in the 780 again for regression testing purposes (relatively easy, but ugly). If the 980 can be flashed to enable the boot screen I'd prefer that, since it'd drop 1 GPU I'm not really using for crunching, and avoid snaking cables in through the back. Failing that, the 680 can be more readily flashed apparently, and is currently sitting idle. Unfortunately alpha code would need some jiggering to work on 680, but then again that's going to have to happen eventually anyway.
8) Message boards : Number crunching : Linux CUDA 'Special' App finally available, featuring Low CPU use (Message 1839522)
Posted 20 days ago by Profile jason_gee
Post:
I have a list of issues, but none of the others prevent wider testing so much as present much rarer annoyances. I'll probably list those once I (or anyone else) resolves the pulsefinding issue, since that's priority. Later tonight, am going to attempt to bring the Mac Pro up on win10 (usb stick is prepared). That currently has el capitan, sierra, and Ubuntu 16.04 LTS. once same machine/device cross platform comparison is doable things get a bit easier. Fingers crossed for at least a sierra 1050ti driver sometime soon.
9) Message boards : Number crunching : Open Beta test: SoG for NVidia, Lunatics v0.45 - Beta6 (RC again) (Message 1839141)
Posted 22 days ago by Profile jason_gee
Post:
I've no idea who this Dr Grey is, but what I do know is that I would back Jason and Raistmer aganst his technical ability any day. Have a look at his team name.


I've got no qualms about anyone questioning my, raistmer's or the probably 30+ other people's work. It's been a long road and a long way to go. Only thing I take issue with is the fairly recent drives to abandon working hardware & applications in the name of progress. That's simply a deadend approach, because it discards the most time-proven parts for unknowns.
10) Message boards : Number crunching : Open Beta test: SoG for NVidia, Lunatics v0.45 - Beta6 (RC again) (Message 1839130)
Posted 22 days ago by Profile jason_gee
Post:
Adding: With v8, some certain subtle precision refinements became effective, designed to converge the dominant CPU and proper GPU applications cross platform, along with easing prior discrepancies that affected 64 bit CPU builds Vs x86 original. While the desired effect was achieved, yielding better than 5% inconclusive (i.e. resend) to pending ratios on the large scale, an unintended consequence was that 'rogue' machines and/or applications became more visible. That's not necessarily a bad thing by any means, just unexpected.
11) Message boards : Number crunching : Open Beta test: SoG for NVidia, Lunatics v0.45 - Beta6 (RC again) (Message 1839091)
Posted 22 days ago by Profile jason_gee
Post:

I cannot see the benefit to the project of catering for such low processing capability devices.

The only reason I keep it connected is because it makes me happy that way

You answered on your question.

Is it right to keep the database inflated just to enable folks to keep their pet devices warm? What is the real benefit here?

"Inflated database" it's quite relative term. As long as it works OK it's not "inflated". And as I already said, the influence of slow hosts on that perceived "inflation" over-estimated.
So yes, it is right to provide ability to help SETI on everything that can compute.

That's right spirit. And spirit much more valuable than revenue. Should be even in "free market" world :P


As soon as we adopt the intentions of the technology vendors at present, then more than 95% of our hardware compute capacity is immediately defunct. It would be nice if we could all have shiny new Kaby Lakes and GTX 1080s, but it's not realistically going to happen... especially when the gains represent poor return for the money. They need to do a lot better before we can say goodbye to stuff that works.
12) Message boards : Number crunching : Linux CUDA 'Special' App finally available, featuring Low CPU use (Message 1838843)
Posted 23 days ago by Profile jason_gee
Post:
Sure, but since our tasks are valid it's not a problem with this app here.

I think a problem exists with the apple darwin apps, I see those a lot in my inconclusives.

Don't forget that credit granting and ultimate validation is quite "forgiving". Task will be counted as valid even if some signal it reports isn't. Provided there are many other valid signals + invalid one in "best" area.
So, ultimate validation doesn't mean that all is OK.

Actually, we not in the stage to decide if app is OK or not. This stage already passed. Jason confirmed missing parts in Pulse signal reduction stages. So we know app is broken in that part.
Low invalids ratio just ensures that bug manifests itself in quite low number of cases. Actually it will show up only if there are few reportable Pulses in same PoT. Cause even one such pulse is rare event having 2 in same PoT and in such order that incorrect one will be reported - even more rare event.


A bit deeper digging verified a race on the power of 2 folds, which are running in parallel onto a single result set. So when a reportable pulse is detected in one fold, and higher score in the other, without synchronisation it's a coin toss as to which pulse is recorded (as observed).

The traditional (serial) algorithm treats the higher score as a refinement of the prior detection. Needs a bit more walkthrough, but probably i'll just separate the pulse results, and see if adding the reduction CPU side is too costly or not. My feeling is that they're rare enough to not have much noticeable performance impact, though if the increased bus consumption becomes a problem, then adding a GPU side reduction step shouldn't be a huge step.

Either way I'll probably end up undoing the (long time ago) nvidia coded triplets-first rearrangement along the way, restoring to CPU serial final order. The spikes, gaussians, and auto-correlations are somewhat paralleled already anyway, so the synch tap points for
these needed reductions are already there. Just probably need a bit of juggling and an intermediate store.
13) Message boards : Number crunching : Dumbfounded With Power Issues (Message 1838695)
Posted 23 days ago by Profile jason_gee
Post:
Does anyone have anything good/bad to say about a SUPERMICRO X9SRA Board? It seems to have everything I need.

Seems to support i7 3820, non-ECC UDIMM (have 16GB) should be able to use 3 PCIe slots.

It seems the i7 3820 only supports PCIe x16 2.0 Does that really matter for anything but gaming?


Arguably wouldn't even matter for gaming.

There was a user here earlier in the year, that had some processor compatibility weirdness on a supermicro board, which apparently had firmware predating the processor release. On attempting an update, apparently that bricked it (for whatever reasons). Supposedly quite recoverable on his particular board, but definitely frustrating. So if going with a Supermicro board, I would be inclined to triple check the installed firmware has the necessary microcode for the CPU to be used beforehand. [Seems like a newish board, and earlier processor, so should be fine, though 2011 socket spans a wide time range so...]
14) Message boards : Number crunching : Help with Ubuntu 16.04 TLS & Headless GPU Computing (Message 1838387)
Posted 24 days ago by Profile jason_gee
Post:
Interestingly the application appears to see the radeon Cypress (still using the Open source driver), so guess some Boinc/scheduler limitation prevents me getting AMD marked tasks. Maybe will try under anon platform at some point just to see what happens (but not a priority).


Multibeam plan classes are set up so that only AMD cards running with Catalyst/fglrx match them. I think there is one Astropulse plan class that can match Mesa but Astropulse AMD app doesn't work with Mesa. It's been a while since I last looked at it but I think the app is using some AMD specific compiler switch that Mesa doesn't like. Multibeam app is probably using the same compiler switches so I would keep my expectations low even if you go anon platform way.


Seems reasonable. I wonder if an intel iGPU or NV build would work (tweaked build or otherwise). The same thing here as with Cuda is rubbing me the wrong way, which is the massive segmentation induced maintenance overhead, for what should be heading toward heterogeneous implementations. Well at least my FrankenMac experiment is starting to pay off, saying there are holes in both the Mac and Linux platforms. I'll be a little taken aback if when I put the last spare SSD in with Windows, both the Radeon and the 1050ti work. I suppose I shouldn't be all that surprised, with the gaming market driving things.
15) Message boards : Number crunching : CUDA issues? (Message 1838120)
Posted 26 days ago by Profile jason_gee
Post:
Open CL runs fine.


Yeah, probably you're in a similar boat to my Mac Pro then. the GTX 780 (I had in before) runs great with Cuda on el Capitan, but like a dog under Sierra, and the 1050ti I have in there now completely unsupported. Probably a lot will depend on nv's goals (whatever they might be). I would hope they might want to be ready should Apple decide to use their GPUs again, though I suspect probably lower on some priority list.
16) Message boards : Number crunching : CUDA issues? (Message 1838117)
Posted 26 days ago by Profile jason_gee
Post:
Still coming to grips with Sierra here myself, and those I guess would be TBar's builds. While not aware of specific issues with the baseline Cuda codebase per se, my impression for Sierra web drivers has been that the Cuda on 7xx (Kepler+Maxwell) support at the moment seems pretty 'tacked on' (and pascal support non existent, of course). That would be enough for me to recommend sticking with what works for you (presumably the OpenCL builds run fine?). My suspicion is that improved Cuda support may trickle down rather slowly, as Sierra 10xx series web drivers don't seem to exist yet.
17) Message boards : Number crunching : Help with Ubuntu 16.04 TLS & Headless GPU Computing (Message 1838073)
Posted 26 days ago by Profile jason_gee
Post:
next morning, and no amd/ati tasks, so I installed drivers for the 1050ti (making sure to use the --no-opengl-files option, so as not to break the desktop running on the Radeon). Lo' and behold, I receive nv openCL marked tasks straight away, which so far appear to be running as expected at defaults (will see when some finish). nvidia-smi confirms the process is running, and a temp rise on the device anyway.

Interestingly the application appears to see the radeon Cypress (still using the Open source driver), so guess some Boinc/scheduler limitation prevents me getting AMD marked tasks. Maybe will try under anon platform at some point just to see what happens (but not a priority).

As is, running the 1050ti for Compute & development, and the Radeon for display-only, is how I'd like to run anyway, So I'll probably stick on 16.04 LTS for now. At least until nv get something for the 1050ti on Sierra/el capitan, or I get around to dropping in the other spare SSD with Win10 on it.
18) Message boards : Number crunching : Help with Ubuntu 16.04 TLS & Headless GPU Computing (Message 1837994)
Posted 27 days ago by Profile jason_gee
Post:
Yeah pretty Interesting situation. If I am forced to go 14.04 (which is more familiar to me) I'll probably end up doing so, however looks like the 2009 Mac Pro EFI/firmware/devices and 14.04 aren't friends, while 16.04 picks everything up fine (even the wifi). Would need to do some more research, or switch distro altogether if it comes to it. Fortunately have managed to familiarise with rEFInd boot manager pretty quickly. (Why can't Grub be made more like that ....)

Either way, there seem to be interesting comments that AMD made all the information available to create the Open Source drivers. Not entirely sure what will happen when a GPU task finally hits. It could be messy, lol.
19) Message boards : Number crunching : Help with Ubuntu 16.04 TLS & Headless GPU Computing (Message 1837988)
Posted 27 days ago by Profile jason_gee
Post:
[A bit Later:] Looks promising so far, with:
Tue 27 Dec 2016 01:52:29 ACDT | | Starting BOINC client version 7.6.31 for x86_64-pc-linux-gnu
Tue 27 Dec 2016 01:52:29 ACDT | | log flags: file_xfer, sched_ops, task
Tue 27 Dec 2016 01:52:29 ACDT | | Libraries: libcurl/7.47.0 OpenSSL/1.0.2g zlib/1.2.8 libidn/1.32 librtmp/2.3
Tue 27 Dec 2016 01:52:29 ACDT | | Data directory: /var/lib/boinc-client
Tue 27 Dec 2016 01:52:29 ACDT | | OpenCL: AMD/ATI GPU 0: AMD CYPRESS (DRM 2.43.0 / 4.4.0-57-generic, LLVM 4.0.0) (driver version 13.1.0-devel - padoka PPA, device version OpenCL 1.1 Mesa 13.1.0-devel - padoka PPA, 1024MB, 1024MB available, 680 GFLOPS peak)
Tue 27 Dec 2016 01:52:29 ACDT | | Creating new client state file
Tue 27 Dec 2016 01:52:29 ACDT | | Host name: jason-MacPro-Ubuntu
Tue 27 Dec 2016 01:52:29 ACDT | | Processor: 16 GenuineIntel Intel(R) Xeon(R) CPU X5677 @ 3.47GHz [Family 6 Model 44 Stepping 2]
Tue 27 Dec 2016 01:52:29 ACDT | | Processor features: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 popcnt aes lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm ida arat
Tue 27 Dec 2016 01:52:29 ACDT | | OS: Linux: 4.4.0-57-generic
Tue 27 Dec 2016 01:52:29 ACDT | | Memory: 31.41 GB physical, 61.99 GB virtual
...
Tue 27 Dec 2016 01:57:17 ACDT | SETI@home | Requesting new tasks for CPU and AMD/ATI GPU
...

No tasks for GPU yet... have dialled down the CPUs to use, and will see if it gets any.
20) Message boards : Number crunching : Help with Ubuntu 16.04 TLS & Headless GPU Computing (Message 1837980)
Posted 27 days ago by Profile jason_gee
Post:
Not sure if related/useful, but I've been wrestling getting 16.04 LTS operational (with X) on my 2009 Mac Pro, on which the primary GPU is a Radeon HD5870.

[Edit:] info sourced from https://laanwj.github.io/2016/05/06/opencl-ubuntu1604.html

The path things led down for this particular setup let to first finding the propietary AMD drivers for this older gen aren't out for 16.04 yet, though there is apparently OpenCL support for this in the newest Open Source drivers. I've not loaded up Boinc on the Linux host yet, but did manage to get OpenCL responding via some gymnastics:
[Edit:]
I did (likely some unneeded redundancy installing old then a newer ppa):
~$ sudo apt-get install mesa-utils
~$ sudo apt-get update
~$ sudo apt-get install mesa-utils
~$ sudo apt-get install mesa-opencl-icd
~$ sudo add-apt-repository ppa:paulo-miguel-dias/mesa
~$ sudo apt-get update
~$ sudo apt-get install libclc-amdgcn mesa-opencl-icd
~$ sudo apt-get install opencl-headers


Then compiled a small program to list the openCL device, and I get this:
$ gcc devices.c -o hello -O2 /usr/lib/x86_64-linux-gnu/libOpenCL.so.1 
$ ls
devices.c  hello
$ ./hello 
1. Platform
  Profile: FULL_PROFILE
  Version: OpenCL 1.1 Mesa 13.1.0-devel - padoka PPA
  Name: Clover
  Vendor: Mesa
  Extensions: cl_khr_icd
1. Device: AMD CYPRESS (DRM 2.43.0 / 4.4.0-57-generic, LLVM 4.0.0)
 1.1 Hardware version: OpenCL 1.1 Mesa 13.1.0-devel - padoka PPA
 1.2 Software version: 13.1.0-devel - padoka PPA
 1.3 OpenCL C version: OpenCL C 1.1 
 1.4 Parallel compute units: 10


Pretty sure newest devices have AMD drivers somewhere, but in my case even basic opencl1.1 enumeration is enough, since I don't really intend to crunch on the HD5870, ... during Australian summer anyway. Will probably try get Boinc up and running, and see if it'll detect these drivers/platforms in the morning.


Next 20


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