Message boards : Number crunching : Please increase the deadline
Author | Message |
---|---|
Hi guys, | |
ID: 22337 | Rating: 0 | rate: / Reply Quote | |
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 | |
ID: 22338 | Rating: 0 | rate: / Reply Quote | |
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). | |
ID: 22342 | Rating: 0 | rate: / Reply Quote | |
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. | |
ID: 22344 | Rating: 0 | rate: / Reply Quote | |
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 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) | |
ID: 22346 | Rating: 0 | rate: / Reply Quote | |
Thanks for the reply, guys :) | |
ID: 22350 | Rating: 0 | rate: / Reply Quote | |
When its not a no name PSU then it will be no problem. This card does not take that much. About 150W | |
ID: 22359 | Rating: 0 | rate: / Reply Quote | |
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. | |
ID: 22360 | Rating: 0 | rate: / Reply Quote | |
Thanks for the reply, skgiven :) | |
ID: 22369 | Rating: 0 | rate: / Reply Quote | |
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. | |
ID: 22372 | Rating: 0 | rate: / Reply Quote | |
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. | |
ID: 22373 | Rating: 0 | rate: / Reply Quote | |
My cache setting is set to 0 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 | |
ID: 22389 | Rating: 0 | rate: / Reply Quote | |
Some news... | |
ID: 22391 | Rating: 0 | rate: / Reply Quote | |
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? | |
ID: 22398 | Rating: 0 | rate: / Reply Quote | |
Hey Dagorath | |
ID: 22399 | Rating: 0 | rate: / Reply Quote | |
Hey Dagorath 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. | |
ID: 22400 | Rating: 0 | rate: / Reply Quote | |
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 | |
ID: 22402 | Rating: 0 | rate: / Reply Quote | |
Message boards : Number crunching : Please increase the deadline