Advanced search

Message boards : Number crunching : Please increase the deadline

Author Message
Profile microchip
Avatar
Send message
Joined: 4 Sep 11
Posts: 110
Credit: 326,102,587
RAC: 0
Level
Asp
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 22337 - Posted: 22 Oct 2011 | 17:14:21 UTC

Hi guys,

I'd really love to crunch for you but I'm the owner of a not-so-fast GPU (GT 440) and even though I've only selected the short WUs in my preferences, the reporting deadline is just not enough for me. Maybe extend it with 2 more days and I'll be happy. I also GPU crunch on other projects (PrimeGrid, M@H, E@H, etc) and after a few "experiments" trying to crunch for GPUGRID, I see I barely can report in time...

And I don't want to hear "buy a faster card" as my budget doesn't allow it. Is there really a reason for such short deadlines?

Profile microchip
Avatar
Send message
Joined: 4 Sep 11
Posts: 110
Credit: 326,102,587
RAC: 0
Level
Asp
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 22338 - Posted: 22 Oct 2011 | 17:57:41 UTC
Last modified: 22 Oct 2011 | 17:58:18 UTC

To follow up a bit on it, could this be my problem for WUs taking so long? The GT 440 has 96 cuda cores, while the GPUGRID seems to think it only has 16, if I'm interpreting this correctly

# There is 1 device supporting CUDA
# Device 0: "GeForce GT 440"
# Clock rate: 1.64 GHz
# Total amount of global memory: 1073283072 bytes
# Number of multiprocessors: 2
# Number of cores: 16

ahj
Avatar
Send message
Joined: 25 Sep 10
Posts: 10
Credit: 31,143,381
RAC: 0
Level
Val
Scientific publications
watwatwatwatwatwatwatwat
Message 22342 - Posted: 23 Oct 2011 | 0:59:30 UTC

GPUGRID needs short deadlines because new work units are generated from the results of the previously completed work units. The faster work units are completed, the quicker the GPUGRID team can investigate the target research, whether it be protein simulation/drug binding etc. If your budget doesn't allow for anything greater than a GT440, then unfortunately GPUGRID really isnt't the project for you (unless the devs have something planned for the future).

If you don't have any loyalty to the BOINC framework, you should really try folding@home, where the GT440 gets very respectable numbers for the $ and watt.

Regards

Dagorath
Send message
Joined: 16 Mar 11
Posts: 509
Credit: 179,005,236
RAC: 0
Level
Ile
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 22344 - Posted: 23 Oct 2011 | 2:14:08 UTC - in response to Message 22338.

To follow up a bit on it, could this be my problem for WUs taking so long? The GT 440 has 96 cuda cores, while the GPUGRID seems to think it only has 16, if I'm interpreting this correctly


I think what's happening is that the GPUgrid application can use only 16 of the 96 cores due to the GT 440's architecture or compute capability. You can probably find other projects that have apps that can use all of your 96 cores.

Profile Retvari Zoltan
Avatar
Send message
Joined: 20 Jan 09
Posts: 2343
Credit: 16,201,255,749
RAC: 698
Level
Trp
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 22346 - Posted: 23 Oct 2011 | 3:19:41 UTC - in response to Message 22344.

To follow up a bit on it, could this be my problem for WUs taking so long? The GT 440 has 96 cuda cores, while the GPUGRID seems to think it only has 16, if I'm interpreting this correctly


I think what's happening is that the GPUgrid application can use only 16 of the 96 cores due to the GT 440's architecture or compute capability. You can probably find other projects that have apps that can use all of your 96 cores.


GPUGrid can use only the 2/3 of the cuda cores of CC2.1 cards (in your case 64), regardless of this reporting bug (the number of cores always equals 8 times the number of multiprocessors, regardless of the real ratio, which is 48 for CC2.1 cards, and 32 for CC2.0 cards)

Profile microchip
Avatar
Send message
Joined: 4 Sep 11
Posts: 110
Credit: 326,102,587
RAC: 0
Level
Asp
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 22350 - Posted: 23 Oct 2011 | 10:10:18 UTC

Thanks for the reply, guys :)

I'm currently eyeing a GTX 560 from ASUS. Though I only have a 450W power supply in my cruncher. Not sure if that'll be enough for it...

Profile dskagcommunity
Avatar
Send message
Joined: 28 Apr 11
Posts: 456
Credit: 817,865,789
RAC: 0
Level
Glu
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 22359 - Posted: 24 Oct 2011 | 15:20:24 UTC
Last modified: 24 Oct 2011 | 15:21:13 UTC

When its not a no name PSU then it will be no problem. This card does not take that much. About 150W
____________
DSKAG Austria Research Team: http://www.research.dskag.at



Profile skgiven
Volunteer moderator
Volunteer tester
Avatar
Send message
Joined: 23 Apr 09
Posts: 3968
Credit: 1,995,359,260
RAC: 0
Level
His
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 22360 - Posted: 24 Oct 2011 | 16:29:10 UTC - in response to Message 22359.
Last modified: 24 Oct 2011 | 16:34:09 UTC

Guys, if you look at the run times for microchip's tasks you will see that the card could finish ~2.6tasks per days. You would also see the tasks were started and stopped many times.

From microchip's project list, you can see he crunches for about 5 or 6 other GPU projects, and if you go to them you can see microchip does this on the same system. So the problem is running more than one GPU project; the projects aliquot of time, compounded by the 'switch between applications' setting and cache levels means the tasks are stopped and started repeatedly.

Newcomers with similar systems should use recommended settings, such as keep a low cache, don't crunch on multiple GPU projects with entry level GPU's, report tasks immediately, and set 'switch between applications' to a high number (Use 900minutes, as this is longer than the time that system would take to complete a normal length GPUGrid task).

microchip, although it's not the fastest it's far from useless, and a GT 440 (96 cuda core version) has a 45W TDP. Even the 144cuda core versions only has a 69W TDP.

If you want to upgrade some time, then get a CC2.0 GPU and a good PSU. Until then configure your system to crunch here.

Profile microchip
Avatar
Send message
Joined: 4 Sep 11
Posts: 110
Credit: 326,102,587
RAC: 0
Level
Asp
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 22369 - Posted: 26 Oct 2011 | 16:14:17 UTC

Thanks for the reply, skgiven :)

Yes, I also crunch on the GPU for 3 other projects (Einstein, Milkyway and PrimeGrid) so with GPUGRID in it, I have 4 projects on the GPU. My cache setting is set to 0 so it should report results immediately. I haven't touched the "switch between applications" option so it is currently set at 60 minutes. I'll increase it as suggested

Profile Retvari Zoltan
Avatar
Send message
Joined: 20 Jan 09
Posts: 2343
Credit: 16,201,255,749
RAC: 698
Level
Trp
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 22372 - Posted: 26 Oct 2011 | 21:17:49 UTC - in response to Message 22369.

My cache setting is set to 0 so it should report results immediately

It will download new task only when the current one finished. Uploading finished tasks is not the same as reporting them. Reporting results takes place once per day by default, so you might miss a bonus at GPUGrid, if you finish a task just in 24h (or 48h), but don't report it immediately.
You should make a cc_config.xml simple text file (if you don't have one already) to the working directory of BOINC, and paste the following lines in it:
<cc_config>
<options>
<report_results_immediately>1</report_results_immediately>
</options>
</cc_config>
Then save it, and restart BOINC manager.

Dagorath
Send message
Joined: 16 Mar 11
Posts: 509
Credit: 179,005,236
RAC: 0
Level
Ile
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 22373 - Posted: 26 Oct 2011 | 21:49:58 UTC - in response to Message 22369.

My cache setting is set to 0


Create the cc_config.xml as Retvari suggested.

Also, your statement that your cache is 0 isn't absolutely clear so I offer the following suggestion just to make sure. The cache is governed by 2 settings. The "Connect about every__days" should be 0 and the "Additional work buffer__ days" should be very small, I use 0.1.

Profile microchip
Avatar
Send message
Joined: 4 Sep 11
Posts: 110
Credit: 326,102,587
RAC: 0
Level
Asp
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 22389 - Posted: 27 Oct 2011 | 13:28:39 UTC - in response to Message 22373.

My cache setting is set to 0


Create the cc_config.xml as Retvari suggested.

Also, your statement that your cache is 0 isn't absolutely clear so I offer the following suggestion just to make sure. The cache is governed by 2 settings. The "Connect about every__days" should be 0 and the "Additional work buffer__ days" should be very small, I use 0.1.


both of these are set to 0 here and I already have the cc_config.xml file with the setting to report immediately. I made that file 5 days ago, but even when I didn't have it, BOINC reported them immediately after finishing with crunching. This is for version 6.12.34. While I was on version 6.10.58, it did not report them immediately so something changed in 6.12.34

Profile microchip
Avatar
Send message
Joined: 4 Sep 11
Posts: 110
Credit: 326,102,587
RAC: 0
Level
Asp
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 22391 - Posted: 27 Oct 2011 | 18:02:29 UTC

Some news...

My last WU took 34 hours to compute on the GT 440. I barely made it and was actually 5 minutes over the deadline (which was set at 19:45 CEST) and I reported at 19:50. Luckily I did get the credit. I've no idea why I got it as I was full 5 minutes late in reporting. Still nice to have it, though :)

Dagorath
Send message
Joined: 16 Mar 11
Posts: 509
Credit: 179,005,236
RAC: 0
Level
Ile
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 22398 - Posted: 28 Oct 2011 | 6:59:01 UTC - in response to Message 22391.
Last modified: 28 Oct 2011 | 7:02:22 UTC

The stderr output for that 34 hour task shows you're not using swan_sync=0 and the task seems to have restarted repeatedly. Did it get preempted repeatedly by other projects or did it run uninterrupted? If you set the "switch between tasks every..." to 900, the task should run 15 hours without being preempted, unless you have other tasks that go to high priority mode. Any high priority tasks?

Put "export SWAN_SYNC=0" in your .bashrc file so it initializes SWAN_SYNC every time you boot and then run that command in a terminal to initialize it for the current session. Then exit BOINC client and restart it to restart the task with SWAN_SYNC=0. Some say it makes no difference, others claim it does.

You allow BOINC to use all 6 of your cores. So then you have 6 CPU tasks running plus the GPU task, right? Try allotting BOINC only 5 cores so that 1 core is free to service the GPU. To do that set "On multiprocessor systems use at most..." to 83%. That might decrease your run times too.

Profile microchip
Avatar
Send message
Joined: 4 Sep 11
Posts: 110
Credit: 326,102,587
RAC: 0
Level
Asp
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 22399 - Posted: 28 Oct 2011 | 10:00:39 UTC
Last modified: 28 Oct 2011 | 10:06:56 UTC

Hey Dagorath

Yes, I have SWAN_SYNC=0 in my bashrc, but I haven't rebooted yet so I shall initialize it now and restart boinc. About freeing one CPU core, I don't think that'll make a difference as the Linux scheduler switches tasks dynamically between different cores - it doesn't lock a task to a single core for the whole time. I also set the "switch between applications" to 10 hours instead of 15. And no, there were no high-priority tasks running on the GPU

Richard Haselgrove
Send message
Joined: 11 Jul 09
Posts: 1576
Credit: 5,806,236,851
RAC: 9,763,519
Level
Tyr
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 22400 - Posted: 28 Oct 2011 | 10:10:47 UTC - in response to Message 22399.

Hey Dagorath

Yes, I have SWAN_SYNC=0 in my bashrc, but I haven't rebooted yet so I shall initialize it now and restart boinc. About freeing one CPU core, I don't think that'll make a difference as the Linux scheduler switches tasks dynamically between different cores - it doesn't lock a task to a single core for the whole time. I also set the "switch between applications" to 10 hours instead of 15.

I think all modern OS kernels do that, to support all the other background multitasking that goes on.

"Free a core" is just a conventional shorthand for "reduce the CPU loading", to make it more responsive for servicing the sync tasks.

Profile skgiven
Volunteer moderator
Volunteer tester
Avatar
Send message
Joined: 23 Apr 09
Posts: 3968
Credit: 1,995,359,260
RAC: 0
Level
His
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 22402 - Posted: 28 Oct 2011 | 12:17:05 UTC - in response to Message 22398.
Last modified: 28 Oct 2011 | 12:19:06 UTC

Some say it makes no difference, others claim it does.

SWAN_SYNC makes a difference (improves performance) for Fermi cards on Linux:
SWAN_SYNC was specifically designed for Fermi cards and works better on the 6.14 app (used with Linux).
For the 6.15 app used with Windows with a Fermi, SWAN_SYNC still improves performance a little, but with just a small gain (on average) the expense of losing a CPU core/thread is not worth it for some, and might reduce system responsiveness (more noticeable on lesser cards).
____________
FAQ's

HOW TO:
- Opt out of Beta Tests
- Ask for Help

Post to thread

Message boards : Number crunching : Please increase the deadline

//