Forum > GPU crunching
GPU/CPU performance dependence from AR value
Richard Haselgrove:
Just for fun, I adapted Fred's script to re-brand VHAR as well as VLAR - as it happens, the strict 'V' cases are easy to handle, at both LAR and HAR. The ones in the middle are more difficult to pick out.
The first one I tried, BOINC (as expected) immediately fetched more work to re-fill the gaps in the CUDA queue caused by the re-branding. I got mostly VLAR. So I re-branded that, and BOINC replaced it - with VHAR. So I re-branded that, and .... you get the picture. Note that I am doing this under controlled, observed conditions on machines with plenty of horsepower and spare capacity I can 'borrow' from other projects. Even so, I'm going to have to keep an eye on VHAR deadlines for the next few days. If I was working on a SETI-only box with a huge cache setting, I could have got myself into serious bother.
--- Quote from: Raistmer on 18 Apr 2009, 06:39:56 am ---
That is, no such action should be taken for 10 day cache at all. And better is such rebranding will occur on regular basis pertty often but by pretty small chunks to not to deceive BOINC work amount estimate too much each time.
--- End quote ---
Difficult one. I can see your point about moving in small steps, but the objective you're trying to achieve is to shave a few seconds off crunch times. In order to re-brand tasks, you have to shut down and restart the BOINC core client: and that's one of the most inefficient operations around. What I'm doing (except when experimenting) is waiting until the last possible moment before one of the target ARs reaches the head of the CUDA queue, and then doing the whole lot in one big batch. That gives me the longest possible uninterrupted run before the next batch needs doing. This approach would only work for VLAR with v6.6.20, because VHAR run immediately on arrival: I'm running v6.6.23, so I can use it for VHAR as well.
Josef W. Segur:
--- Quote from: Richard Haselgrove on 19 Apr 2009, 08:36:16 am ---...
In order to re-brand tasks, you have to shut down and restart the BOINC core client: and that's one of the most inefficient operations around.
...
--- End quote ---
Perhaps using a rewriting proxy to rebrand in the Scheduler reply would be a better approach. I think perhaps the Proxomitron might be able to handle that.
Joe
Raistmer:
well, script could be written on perl. If that proxy supports external program calls maybe yes, such proxy will be best way to go.
For now I mean "small step: is 1-2 days cache, not 10 days one to avoid deadline misses but big enough to compensate BOINC shutdown/restart.
Raistmer:
--- Quote from: Richard Haselgrove on 19 Apr 2009, 08:36:16 am ---The first one I tried, BOINC (as expected) immediately fetched more work to re-fill the gaps in the CUDA queue caused by the re-branding. I got mostly VLAR. So I re-branded that, and BOINC replaced it - with VHAR. So I re-branded that, and .... you get the picture.
--- End quote ---
Not nessesary to rebrand all tasks. Some limit can be setted up. In short, in boundaries of deadline such script would improve performance. That is, our goal will write such script and ensure that its work will not lead to deadline misses (for more or less conscious user, even app_info can be devastating weapon in hands of "no-clue" user...)
Raistmer:
<result>
<name>27dc08ab.16638.387984.5.8.30_0</name>
<final_cpu_time>0.000000</final_cpu_time>
<final_elapsed_time>0.000000</final_elapsed_time>
<exit_status>0</exit_status>
<state>1</state>
<platform>windows_intelx86</platform>
<version_num>608</version_num>
<plan_class>cuda</plan_class>
<wu_name>27dc08ab.16638.387984.5.8.30</wu_name>
<report_deadline>1240759087.000000</report_deadline>
<file_ref>
<file_name>27dc08ab.16638.387984.5.8.30_0_0</file_name>
<open_name>result.sah</open_name>
</file_ref>
</result>
Do I understand right that only yellow lines should be changed for CPU<->GPU rebranding ?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version