Message boards :
Number crunching :
i7 Hyperthreading + GPU + Most Efficient Seti Workload
Message board moderation
Previous · 1 · 2 · 3 · 4 · 5 · Next
Author | Message |
---|---|
Josef W. Segur Send message Joined: 30 Oct 99 Posts: 4504 Credit: 1,414,761 RAC: 0 |
On Linux: The core client looks for the runtime library and if that's found uses it to get device properties. The code is in boinc/client/coproc_detect.cpp and of course you'd need to look at the version applicable to the particular version of the BOINC core client in use. Joe |
ML1 Send message Joined: 25 Nov 01 Posts: 20084 Credit: 7,508,002 RAC: 20 |
On Linux: Thanks for that. I'll check that out. Happy fast crunchin', Martin See new freedom: Mageia Linux Take a look for yourself: Linux Format The Future is what We all make IT (GPLv3) |
ausymark Send message Joined: 9 Aug 99 Posts: 95 Credit: 10,175,128 RAC: 0 |
Update Finally got the system crunching as before. Thanks to sunu over at the lunatics site and those here in the seti@home group. See the other thread about this issue/fix here: http://setiathome.berkeley.edu/forum_thread.php?id=65695 So now i can get back to the experiment. Just hoping now that getting hold of work units wont be an issue like it has over the last week and a bit. Cheers Mark |
ausymark Send message Joined: 9 Aug 99 Posts: 95 Credit: 10,175,128 RAC: 0 |
Update: With the PC now moved over to Ubuntu 11.10, optimised biniaries in place, overclocked reliably at 46x on my Asus Z68V-Pro motherboard, and with 4 days of solid work units being fed to it - the system is once again approaching the 10,000 RAC mark. Hopefully within the next week it should flatten out somewhere around the 13,000 RAC mark running on 3 Seti CPU processes and 2 Seti GPU processes. Fingers crossed no other major hiccups occur. Cheers Mark |
Blake Bonkofsky Send message Joined: 29 Dec 99 Posts: 617 Credit: 46,383,149 RAC: 0 |
I seriously hope you are planning for more than 13k RAC from a 580 and a 2600k. My i3-550 and a single GTX460 does about 22k with consistent workflow. |
Gabriel Siegel Send message Joined: 2 Apr 00 Posts: 10 Credit: 1,430,196 RAC: 0 |
This could be a power supply issue. I had a similar issue with my old PSU. It would crash when the GPU was loaded heavily (Crysis 2 :-)) My old PSU was a 1000W one, but still it could not take the load (piece of junk honestly). I have two GeForce GTX 580's though, so of course my machine is power hungry. Now I have a better brand 1000W PSU with no issues at all... |
ausymark Send message Joined: 9 Aug 99 Posts: 95 Credit: 10,175,128 RAC: 0 |
Latest Update: This has been very interesting to say the least. Firstly to Blake, the computer system is not running 24/7, its usual duty cycle is between 12 and 16 hours. However I am generally consistent as to start and finish times on any particular day. I have watched as the RAC climbed to 18.500, however it has since fallen and is fluctuating around the 16K to 16.5K mark. I will monitor the progress again over the next two weeks to see if there is any change - my guess is that its a work unit/RAC variation that may once again see the average RAC end up around the 17K mark. Also the rebooting problem was RAM related, now resolved. On a Team note, I will be hitting the lead position within the team/group I am within the next 48 hours. I am now crunching the same number of RAC credits in a fortnight that once took me 10 Years to achieve ..... amazing CPU/GPU improvements in that time! Anyway, let the experiment roll on. Cheers Mark |
ausymark Send message Joined: 9 Aug 99 Posts: 95 Credit: 10,175,128 RAC: 0 |
Further notes Several things have occurred over the last 4 weeks. A drop of Astropulse work units (Replaced by normal CPU work units), and scarcity of GPU work units, both of which have dramatically affected throughput. Dropping from a high of 18K credits down to just below 10K credits. Also my computer running time will shortly change from 14 hours a day back to an average of around 6 hours a day. Naturally that's going to affect the throughput again. 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. Why this configuration? In the past its been suggested that for CPU tasks that one more task is run than the number of cores available so that the cores are maxed out all the time. However as I am also running the GPU seti client the CPU must still feed data to the GPU, so I don't wish to constrain that aspect. So with hyperthreading enabled any CPU slack should be used for GPU data feeding - thats the theory anyway. So it will take awhile until we get back to some form of stable credit throughput - and if not achieved I will probably stay at the current configuration as it seems to work the best from brief testing. Hopefully I will have a new update within 4 weeks. Until then - Happy New Year! |
aaronh Send message Joined: 27 Oct 99 Posts: 169 Credit: 1,442,686 RAC: 0 |
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%. 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? |
ausymark Send message Joined: 9 Aug 99 Posts: 95 Credit: 10,175,128 RAC: 0 |
Hi aaronhaviland Found the issue with that. I had previously worked out with the old CUDA client that with OS it was using 650mb of VRAM, which left a good 800Mb for games etc. (Primarily Second Life). However with the change to the new CUDA client I also changed to the updated Second Life Viewer - both of which have higher memory requirements. I have also noticed that the new X41G code will use up to 200Mb more VRAM above the 600Mb I am allowing for - so consequently the possible active amount being used with operating system can potentially be as much as 950+ Mb! When using Second Life, which in the past I had configured to use 500Mb of VRAM, things would run fine - however now we are hitting VRAM limits. I have reduced it down to just 400Mb of VRAM and the free VRAM seems to float between 260Mb free to as little as 40Mb. Note: I am also assuming the nVidia 580 is underutilized running just 1 CUDA task and that it can run 2 CUDA tasks in almost the same amount of time that it can run 1 CUDA task. (This assumes nothing fundamental has changed between the older CUDA client and the newer x41G CUDA client.) I will monitor the situation to see how it goes. Cheers Mark |
Dave Send message Joined: 29 Mar 02 Posts: 778 Credit: 25,001,396 RAC: 0 |
My thoughts are with that duty cycle you will get better overall life via keeping the machine on. Every time you turn your machine on it shortens its life. maybe power it down to eco power scheme when you're not using via a desktop shortcut or something. Or auto overnight. |
ausymark Send message Joined: 9 Aug 99 Posts: 95 Credit: 10,175,128 RAC: 0 |
Hi Dave Sorry, Im not leaving my PC run 24/7 due to the environmental impacts that has and the extra cost of electricity. I also don't agree with your logic. All computer parts have a Mean Time Before Failure (MTBF) rating. Running those parts when I don't require the computer means that MTBF "dead line" comes up sooner. Yes I am aware of cool down/heatup issues with shutting the thing down but I have purchased good quality parts when I built the rig so it should be able to handle it. Also, as a side point - having it run 24/7 increases the probability of a power spike (even with a surge protector) - and that is more deadly to any powering up/down of the system. And yes, I fully realise that with the system running it would be churning through somewhere between 20K and 35K RAC's. Anyway, thats my 2c worth :) Cheers :) |
ausymark Send message Joined: 9 Aug 99 Posts: 95 Credit: 10,175,128 RAC: 0 |
HI aaronhaviland 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 will monitor this configuration and see how it goes. 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. Anyway the experiment continues ;) Cheers Mark |
Wembley Send message Joined: 16 Sep 09 Posts: 429 Credit: 1,844,293 RAC: 0 |
Just shut down the GPU crunchers when you are running Second Life. |
aaronh Send message Joined: 27 Oct 99 Posts: 169 Credit: 1,442,686 RAC: 0 |
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. |
aaronh Send message Joined: 27 Oct 99 Posts: 169 Credit: 1,442,686 RAC: 0 |
Just shut down the GPU crunchers when you are running Second Life. Or shut down Second Life when you're not using it? :) |
ausymark Send message Joined: 9 Aug 99 Posts: 95 Credit: 10,175,128 RAC: 0 |
OK have done some more testing. Seems as though Second Life is competing with the x41G CUDA clients that is causing the VRAM usage expansion in a way that the previous CUDA clients did not. I may temporarily go back to the previous version to see if it does the same thing. Cheers Mark |
ausymark Send message Joined: 9 Aug 99 Posts: 95 Credit: 10,175,128 RAC: 0 |
Update OK, seems as though the previous CUDA client was also being 'starved' for VRAM when Second Life was running - however seemed to be handing it better. Previous experience indicates that I would get around 10 computational errors per week in this configuration, whereas the x41g allows 30+ computational errors to slip through - which I am guessing is VRAM issue. So for the moment I am going to run with the old CUDA client as overall I wil get better throughput. Will wait for an update to the Second Life viewer to see if its VRAM memory configuration setting actually works like it once did. Cheers Mark |
ausymark Send message Joined: 9 Aug 99 Posts: 95 Credit: 10,175,128 RAC: 0 |
Update OK, going back to the older CUDA client seems to crash Second Life more so I've switched back to the x41g client. I have raised a bug issue with the Second Life viewer team and will see what gets resolved from that end. Cheers Mark |
HAL9000 Send message Joined: 11 Sep 99 Posts: 6534 Credit: 196,805,888 RAC: 57 |
Update I prefer the phoenix viewer myself. Perhaps it, or one of the other 3rd party viewers, doesn't have this issue? SETI@home classic workunits: 93,865 CPU time: 863,447 hours Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[ |
©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.