i7 Hyperthreading + GPU + Most Efficient Seti Workload


log in

Advanced search

Message boards : Number crunching : i7 Hyperthreading + GPU + Most Efficient Seti Workload

Previous · 1 · 2 · 3 · 4 · 5 · Next
Author Message
Josef W. Segur
Volunteer developer
Volunteer tester
Send message
Joined: 30 Oct 99
Posts: 4203
Credit: 1,030,288
RAC: 267
United States
Message 1159073 - Posted: 5 Oct 2011, 14:38:37 UTC - in response to Message 1158991.

On Linux:

Anyone know what the boinc-client actually looks for to determine if there are any GPUs that can be used?


Happy fast crunchin',
Martin

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

Profile ML1
Volunteer tester
Send message
Joined: 25 Nov 01
Posts: 8266
Credit: 4,071,441
RAC: 350
United Kingdom
Message 1159120 - Posted: 5 Oct 2011, 16:11:38 UTC - in response to Message 1159073.

On Linux:

Anyone know what the boinc-client actually looks for to determine if there are any GPUs that can be used?

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.


Thanks for that. I'll check that out.

Happy fast crunchin',
Martin

____________
See new freedom: Mageia4
Linux Voice See & try out your OS Freedom!
The Future is what We make IT (GPLv3)

Profile ausymark
Send message
Joined: 9 Aug 99
Posts: 68
Credit: 9,297,900
RAC: 2,900
Australia
Message 1159580 - Posted: 6 Oct 2011, 22:40:56 UTC - in response to Message 1158956.

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
____________

Profile ausymark
Send message
Joined: 9 Aug 99
Posts: 68
Credit: 9,297,900
RAC: 2,900
Australia
Message 1161377 - Posted: 12 Oct 2011, 5:43:31 UTC

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
Volunteer tester
Avatar
Send message
Joined: 29 Dec 99
Posts: 617
Credit: 46,332,781
RAC: 0
United States
Message 1161385 - Posted: 12 Oct 2011, 6:54:40 UTC - in response to Message 1161377.

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.
____________

Profile Gabriel Siegel
Send message
Joined: 2 Apr 00
Posts: 9
Credit: 824,778
RAC: 0
Denmark
Message 1162350 - Posted: 14 Oct 2011, 22:05:47 UTC - in response to Message 1154373.
Last modified: 14 Oct 2011, 22:08:30 UTC

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...
____________

Profile ausymark
Send message
Joined: 9 Aug 99
Posts: 68
Credit: 9,297,900
RAC: 2,900
Australia
Message 1174485 - Posted: 29 Nov 2011, 5:48:14 UTC

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
____________

Profile ausymark
Send message
Joined: 9 Aug 99
Posts: 68
Credit: 9,297,900
RAC: 2,900
Australia
Message 1181766 - Posted: 31 Dec 2011, 2:46:53 UTC - in response to Message 1174485.

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!
____________

Profile aaronh
Volunteer tester
Avatar
Send message
Joined: 27 Oct 99
Posts: 169
Credit: 1,412,472
RAC: 0
United States
Message 1182336 - Posted: 2 Jan 2012, 4:04:21 UTC - in response to Message 1181766.

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?

Profile ausymark
Send message
Joined: 9 Aug 99
Posts: 68
Credit: 9,297,900
RAC: 2,900
Australia
Message 1182372 - Posted: 2 Jan 2012, 10:39:58 UTC - in response to Message 1182336.

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
Avatar
Send message
Joined: 29 Mar 02
Posts: 774
Credit: 23,193,139
RAC: 0
United Kingdom
Message 1182488 - Posted: 2 Jan 2012, 22:14:45 UTC

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.

Profile ausymark
Send message
Joined: 9 Aug 99
Posts: 68
Credit: 9,297,900
RAC: 2,900
Australia
Message 1182491 - Posted: 2 Jan 2012, 22:43:41 UTC - in response to Message 1182488.

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 :)
____________

Profile ausymark
Send message
Joined: 9 Aug 99
Posts: 68
Credit: 9,297,900
RAC: 2,900
Australia
Message 1182547 - Posted: 3 Jan 2012, 6:15:31 UTC - in response to Message 1182336.

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
Volunteer tester
Avatar
Send message
Joined: 16 Sep 09
Posts: 415
Credit: 888,257
RAC: 0
United States
Message 1182548 - Posted: 3 Jan 2012, 6:35:42 UTC - in response to Message 1182547.

Just shut down the GPU crunchers when you are running Second Life.

____________


Donate with your searches and online buys:
http://www.goodsearch.com/toolbar/university-of-california-setihome

Profile aaronh
Volunteer tester
Avatar
Send message
Joined: 27 Oct 99
Posts: 169
Credit: 1,412,472
RAC: 0
United States
Message 1182683 - Posted: 4 Jan 2012, 1:36:15 UTC - in response to Message 1182547.

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.

Profile aaronh
Volunteer tester
Avatar
Send message
Joined: 27 Oct 99
Posts: 169
Credit: 1,412,472
RAC: 0
United States
Message 1182684 - Posted: 4 Jan 2012, 1:36:58 UTC - in response to Message 1182548.

Just shut down the GPU crunchers when you are running Second Life.

Or shut down Second Life when you're not using it? :)

Profile ausymark
Send message
Joined: 9 Aug 99
Posts: 68
Credit: 9,297,900
RAC: 2,900
Australia
Message 1182889 - Posted: 5 Jan 2012, 0:38:09 UTC - in response to Message 1182684.

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
____________

Profile ausymark
Send message
Joined: 9 Aug 99
Posts: 68
Credit: 9,297,900
RAC: 2,900
Australia
Message 1182935 - Posted: 5 Jan 2012, 7:53:30 UTC - in response to Message 1182889.

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
____________

Profile ausymark
Send message
Joined: 9 Aug 99
Posts: 68
Credit: 9,297,900
RAC: 2,900
Australia
Message 1183370 - Posted: 7 Jan 2012, 2:00:32 UTC - in response to Message 1182935.

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
____________

Profile HAL9000
Volunteer tester
Avatar
Send message
Joined: 11 Sep 99
Posts: 3859
Credit: 106,947,347
RAC: 97,121
United States
Message 1183440 - Posted: 7 Jan 2012, 7:06:43 UTC - in response to Message 1183370.

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


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 BP6/VP6 User Group today!

Previous · 1 · 2 · 3 · 4 · 5 · Next

Message boards : Number crunching : i7 Hyperthreading + GPU + Most Efficient Seti Workload

Copyright © 2014 University of California