Posts by aaronh

1) Message boards : Number crunching : Linux AP_V6 Question (Message 1211652)
Posted 29 Mar 2012 by Profile aaronh
Post:
I believe, as a rule, SSSE3 implies PNI/SSE3, as it's Supplemental
2) Message boards : Number crunching : Finally! GPU wars 2012 - GTX 650 Ti reviews (Message 1208848)
Posted 22 Mar 2012 by Profile aaronh
Post:
Shhh... don't tell that to my little ION GPU! It doesn't support double-precision but crunches Seti beautifully!:D


True, we don't need DP over here, but it might mean a re-shuffling of priorities for some apps that do utilise DP.
3) Message boards : Number crunching : Finally! GPU wars 2012 - GTX 650 Ti reviews (Message 1208841)
Posted 22 Mar 2012 by Profile aaronh
Post:
Here's a review of what's important to us: Compute performance. Looks like double-precision has gotten *no* love:

http://www.brightsideofnews.com/news/2012/3/22/nvidia-gtx-680-reviewed-a-new-hope.aspx?pageid=4

Edit: also, newegg appears to be out of stock already.
4) Message boards : Number crunching : Kepler ... the good news ... (Message 1205523)
Posted 13 Mar 2012 by Profile aaronh
Post:
And please bear in mind, that until somebody has a Kepler running here, we won't know if any of the apps are compatible...


*looks at the big tax refund check that finally came in*
5) Message boards : Number crunching : Nvidia 295.73 Driver (Message 1199011)
Posted 23 Feb 2012 by Profile aaronh
Post:
My Experience of these drivers is the same as 295.51, Once the DVI connected Monitor goes to sleep, the Cuda device becomes unavailable


This seems to be a non-issue for me on Linux (nvidia version 295.20), but it doesn't even need X to be running in order to use CUDA, so that might help...

strike this: Whoops, I'm using HDMI, not DVI. No idea about DVI on Linux!

Nope, I have DVI after all. I keep mixing up the two interfaces.
6) Message boards : Number crunching : Ubuntu 11.10 new NVIDIA problem (Message 1198063)
Posted 21 Feb 2012 by Profile aaronh
Post:
What is the min driver for the x41g Linux app?


The minimum Linux driver for a Cuda 3.2 application is (from the README included with the x41g app):
* CUDA 3.2 Video Driver (260.19.26 or higher)
7) Message boards : Number crunching : Floppy Shredding (Message 1196120)
Posted 16 Feb 2012 by Profile aaronh
Post:
I feel old: when I read the phrase "old hardware," I just assumed these would be 5 1/4" drives. Yeah yeah, I know there are older :P

There are no floppy drives in this video, but there is a scanner-bass, and a dot-matrix drum-kit. Be patient though, as it takes the ZX Spectrum a minute to load...

Big Ideas (Don't Get Any)
8) Message boards : Number crunching : Software developer needs testers for multi-GPU users (Message 1190246)
Posted 31 Jan 2012 by Profile aaronh
Post:
It would be terrific if Windows-only things (like this) were identified as such.
So folks like me would not get excited about 'something new to me'
only to discover .... not applicable.


I know what you mean, and sometimes I take the extra step of trying it under wine just so I can mock-complain that it doesn't work for me.

All things considered, I was impressed by how well it ran under wine. (quite well) I've come to expect total failure from these sorts of utilities when put in that situation.

One thing I noticed, though: In all the network information, it lacked any information regarding IPv6. Feature request?
9) Message boards : Number crunching : PCI to PCIE Adaptor and Other Interesting Gizmos (Message 1187048)
Posted 21 Jan 2012 by Profile aaronh
Post:
There does exist a PCI Express lane splitter, but I can only find one that splits x4 -> 4 x1 lanes.
http://www.amfeltec.com/products/x4pcie-splitter4.php
10) Message boards : Number crunching : Linux x64 Cuda Multibeam (x41g) (Message 1185537)
Posted 15 Jan 2012 by Profile aaronh
Post:
Aaron, I don't know if you're seeing it too, but I get lots of warnings for unused variables, code that doesn't do anything, and pointers converted to smaller integers.


Yes, I've seen those. At the time, I was holding off with an "If it ain't broke, don't fix it" view. Slowly, they've been getting fixed.
11) Message boards : Number crunching : Linux x64 Cuda Multibeam (x41g) (Message 1185143)
Posted 14 Jan 2012 by Profile aaronh
Post:
My initial post was just sort of a 'hint' at the one compiling the code to consider building it on a not so recent linux distro...

I got that point clearly, as you can see with my discussions with ivan.

As I stated to him, I checked major distributions for what I thought would be reasonable compatibility (mostly using the charts at distrowatch). Obviously, I was mistaken.

SuSe 11.2 reached its end-of-life in May 2011. Should it still be supported? The question I think becomes, at what point, where do you draw the line? Compatiblity with *how old* of a distribution is desired/needed?
12) Message boards : Number crunching : Newbie Linux GPU, No work units? (Message 1185048)
Posted 13 Jan 2012 by Profile aaronh
Post:
Is there likely to be a 32-bit Linux CUDA app released once v7 is out?

I was told that 32-bit linux build never worked, and as all my CUDA systems are 64-bit, I haven't looked into the reasons why this is so.

--- several hours later ---
Well I'm stumped. I've tried a few things. It doesn't work... at all. It's definitely something to think about.
13) Message boards : Number crunching : No cuda work!! (Message 1184754)
Posted 12 Jan 2012 by Profile aaronh
Post:
ya and if you use an optimised apps installer, make sure you check the checkbox about you want cuda crunching :) (which i saw doesnt come by default)

(There is no installer for linux...)
14) Message boards : Number crunching : Linux x64 Cuda Multibeam (x41g) (Message 1183449)
Posted 7 Jan 2012 by Profile aaronh
Post:
Note all this, despite my brain-fades earlier, was with CUDA 4.0. I tried 4.1 on the SLC5 machine, but its libraries were too old. Next, I'll install 4.1 on the SLC6 machine, and see if there are any code adjustments needed. For 4.0, none were.

It was actually found that CUDA 4.0 was slower for most (all?) scenarios, and although things were fixed to work with 4.0, we stayed with using 3.2.

However, 4.1rc2 might be showing promise, with that new fandangled llvm compiler...
15) Message boards : Number crunching : i7 Hyperthreading + GPU + Most Efficient Seti Workload (Message 1182684)
Posted 4 Jan 2012 by Profile aaronh
Post:
Just shut down the GPU crunchers when you are running Second Life.

Or shut down Second Life when you're not using it? :)
16) Message boards : Number crunching : i7 Hyperthreading + GPU + Most Efficient Seti Workload (Message 1182683)
Posted 4 Jan 2012 by Profile aaronh
Post:
OK, update time: Running 2 instances of x41G is now failing - running out of VRAM when running Second Life. (Generated a whole bag of Compilation errors). I've gone back to just a single CUDA instance and am seeing that my free VRAM memory is around 340mb. So its no wonder that a second instance is generating errors (300MB + 100MB of 'dynamic expansion'.

I've done multiple test runs and x41g only uses 243MB of VRAM per instance (so two would need 486MB). There is no "dynamic expansion" of x41g. It might also be possible that SecondLife is competing for other resources: Not all of your tasks are claiming a lack of memory. Some say "all CUDA-capable devices are busy or unavailable." which leads me to believe that something else has claimed the GPU.

Im wondering if a more ram optimised client is possible - or conversely a client that fully utilises the processing ability of the card - even with a slight memory increase would probably be preferable.

The client is more memory bandwidth-bound than compute-bound, although this has been improved upon with the Lunatics code. This is one of the reasons why running multiple clients works on Fermis: It gives the GPU something to compute while the other client is doing memory transfers.
17) Message boards : Number crunching : i7 Hyperthreading + GPU + Most Efficient Seti Workload (Message 1182336)
Posted 2 Jan 2012 by Profile aaronh
Post:
I have also, as of today, upgraded to the latest x41g GPU app for linux 64 bit. Initial impressions of it are that processing times have improved from 10% to 30%.

So for now, until I have some stability in running times I am going to run 4 CPU tasks (one for each core) and 2 GPU tasks.


I was looking at some of your x41g results, I see almost all of them are reporting low available VRAM. Is something else using it up? You should have plenty of free room to play on your card, which claims it has 1.5g VRAM. (You should be able to easily run 2 x41g tasks in less than half of that)

The good news is that the excellent work by Jason G. has prevented most of those from becoming errors: due to the boinc_temporary_exit mechanism, the task just retries instead of dying.

Depending on what you do with the machine normally, you might actually be using more VRAM than you'd think you were. I find that X and Firefox abuse VRAM: I only have 36MB used when X starts, but my normal workload ends up around 150MB, with just gnome2 and firefox running.

I would like to verify that the app is correctly detecting the free VRAM on your card: Could you please provide the memory usage as reported by nvidia-smi, both without S@H running, and when it's running normally?
18) Message boards : Number crunching : Linux x64 Cuda Multibeam (x41g) (Message 1182331)
Posted 2 Jan 2012 by Profile aaronh
Post:
B*gger! When I worked up enough courage to try the GTX 460 in the Supermicro, it turned out Scientific Linux CERN 5 is too out-of-date to run the programme:
[eesridr:setiathome.berkeley.edu] > ldd setiathome_x41g_x86_64-pc-linux-gnu_cuda32 
./setiathome_x41g_x86_64-pc-linux-gnu_cuda32: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by ./setiathome_x41g_x86_64-pc-linux-gnu_cuda32)
./setiathome_x41g_x86_64-pc-linux-gnu_cuda32: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by ./setiathome_x41g_x86_64-pc-linux-gnu_cuda32)
./setiathome_x41g_x86_64-pc-linux-gnu_cuda32: /lib64/libc.so.6: version `GLIBC_2.11' not found (required by ./setiathome_x41g_x86_64-pc-linux-gnu_cuda32)


I thought I had checked that my build-system would provide binaries that would work on the many recent releases of major distributions (Ubuntu, Fedora, SuSe). I confess, there were a few distros that I had not checked versions against. (However, it appears it should work against the 6.x series of Scientific Linux)

From the README.txt:
Recent Linux distribution providing:
* linux kernel 2.6.15 or later
* libc6 (>= 2.11)
* libgcc1 (>= 4.1.1)
* libstdc++6 (>= 4.4.0)

For most of the distros I checked, this means anything released since 2009... it's now 2011.. 2012 I mean! Since we're dealing with a minimum CUDA driver that was released in Dec 2010 (260.19.26), I assumed my bases were covered.

I will definitely keep this in mind for future builds. I can eliminate the libstdc++/GLIBCXX issues by using an older gcc, or statically linking. However to fix the libc6 dependency, I would need to set up a new build environment... not happening this week.
19) Message boards : Cafe SETI : Mystery Photo Game 27 (Message 1181652)
Posted 30 Dec 2011 by Profile aaronh
Post:
Nova Scotia?
20) Message boards : Number crunching : Linux x64 Cuda Multibeam (x41g) (Message 1181525)
Posted 30 Dec 2011 by Profile aaronh
Post:
Terror Australis: I'm seeing a lot of inconclusives for your GTS250. Re-running a few of the tasks locally on my GTX460, my results agree with your wing-mate, not you.

I'm going to keep watch, because it's possible that it might just be your card, and not the application. (At this time, ivan has no inconclusives, with a similar card.)


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.