Richard,
Any idea if this is going to have any effect on the rescheduler?

---

PROUD MEMBER OF Team Starfire World BOINC

Richard,
Any idea if this is going to have any effect on the rescheduler?

Not the same effect, I think. As far as I know, Marius does open every individual file and check the AR directly. There may be other side-effects, as Jason and I were discussing in 176 hours to completion??, but it's too early to draw conclusions on that.

If you read through the top half of this thread, you will see the process that Richard guided me through to get mine working..

MadMac I'm following instructions from message 1001523 using tool 1.7 from Lunatics (I couldn't see any other place to get it from)running it from C:\ProgramData\BOINC running windows7 ultimate 64bit. When I run ReSchedule tool I get the following log

Reschedule version 1.7
Time: 18-06-2010 09:06:43
CPU tasks: 0 (0 VLAR/VHAR)
GPU tasks: 0 (0 VLAR/VHAR)
No reschedule needed

Task 1635808649 was from tape 18no took 47 minutes where as task 1635814181 took 9.97 minutes was from tape 19no. Am I correct in saying that 1635808649 is a VLar or a VHar?

---

Others more qualified than me will have to answer that, but Im guessing so..

---

Others more qualified than me will have to answer that, but Im guessing so..

Thanks for your fast responce

---

Others more qualified than me will have to answer that, but Im guessing so..

Thanks for your fast responce

You might have better luck with version 1.9

You might have better luck with version 1.9

Thanks Richard. According to reschedule 1.9 no tasks need to be moved according to log

User testing for a reschedule
CPU tasks: 0 (0 VLAR, 0 VHAR)
GPU tasks: 0 (0 VLAR, 0 VHAR)
No reschedule needed

I'm not sure I agree with the log. I will let the tasks run slowly on my Gpu

---

This is the angle range for that work unit.. WU true angle range is : 0.012972. Task 1635808649 is definitely a VLAR.

---

PROUD MEMBER OF Team Starfire World BOINC

In that case I'm most surprised that ReSchedule 1.9 says that there are no VLars /VHar. Under settings I've set the paths as:

Boinc main path C:\Program Files\BOINC
Boinc data path C:\ProgramData\BOINC

I'm using win 7 ultimate. Tasks are taking round 1 hour 22 minutes. Not sure why but I can't move them to the cpu

---

Perhaps reschedule can't find them because they have the "wrong" plan_class (or whatever tag is appropriate).

Gruß,
Gundolf

---

Computer sind nicht alles im Leben. (Kleiner Scherz)

SETI@home classic workunits 3,758
SETI@home classic CPU time 66,520 hours

I got work for my Fermi today :)
Now running 2 WU's on a GTX470 (607 @ 751 Mhz and 1.000volt).
Didn't get the red "app_info" messages and I run the Lunatics apps :)

It's actually an Asus ENGTX470 but I use the MSI Afterburner software for overclocking and fan regulation.

It works perfectly with the Asus and its free for download on the MSI site :)

I got work for my Fermi today :)
Now running 2 WU's on a GTX470 (607 @ 751 Mhz and 1.000volt).
Didn't get the red "app_info" messages and I run the Lunatics apps :)

It's actually an Asus ENGTX470 but I use the MSI Afterburner software for overclocking and fan regulation.

It works perfectly with the Asus and its free for download on the MSI site :)

AFAIK lunatics does not have an app that works with Fermi without creating useless results. The only app working with Fermis is the stock 610 at the moment. You're trashing (erroneous overflow) every WU with that app. That was the main reason for the server side upgrade we're now suffering from.

Haven't you paid any attention to all the Fermi threads here lately? Especially post in this very thread clearly says to not use lunatics app for FERMI

Since you have your computer(s) hidden, there's no way to tell what happens to your WU's.

I strongly urge you to stop using the lunatics app for your Fermi, and step back to the stock 610 app.

I think I should have been more clear ;)

From what I read my app_info.xml is correct.
I use the Lunatics apps for the CPU only, Fermi is using the "standard" app.

<app_info>
<app>
<name>setiathome_enhanced</name>
</app>
<file_info>
<name>AK_v8b_win_x64_SSSE3x.exe</name>
<executable/>
</file_info>
<app_version>
<app_name>setiathome_enhanced</app_name>
<version_num>603</version_num>
<platform>windows_intelx86</platform>
<file_ref>
<file_name>AK_v8b_win_x64_SSSE3x.exe</file_name>
<main_program/>
</file_ref>
</app_version>
<app_version>
<app_name>setiathome_enhanced</app_name>
<version_num>603</version_num>
<platform>windows_x86_64</platform>
<file_ref>
<file_name>AK_v8b_win_x64_SSSE3x.exe</file_name>
<main_program/>
</file_ref>
</app_version>
<app>
<name>setiathome_enhanced</name>
</app>
<file_info>
<name>libfftw3f-3-1-1a_upx.dll</name>
<executable/>
</file_info>
<file_info>
<name>setiathome_6.10_windows_intelx86__cuda_fermi.exe</name>
<executable/>
</file_info>
<file_info>
<name>cudart32_30_14.dll</name>
<executable/>
</file_info>
<file_info>
<name>cufft32_30_14.dll</name>
<executable/>
</file_info>
<app_version>
<app_name>setiathome_enhanced</app_name>
<version_num>610</version_num>
<avg_ncpus>0.300000</avg_ncpus>
<max_ncpus>0.300000</max_ncpus>
<flops>57462450464</flops>
<plan_class>cuda_fermi</plan_class>
<file_ref>
<file_name>setiathome_6.10_windows_intelx86__cuda_fermi.exe</file_name>
<main_program/>
</file_ref>
<file_ref>
<file_name>cudart32_30_14.dll</file_name>
</file_ref>
<file_ref>
<file_name>cufft32_30_14.dll</file_name>
</file_ref>
<file_ref>
<file_name>libfftw3f-3-1-1a_upx.dll</file_name>
</file_ref>
<coproc>
<type>CUDA</type>
<count>0.5</count>
</coproc>
</app_version>
</app_info>

Your current setup is OK, when you told me the whole story :-)

:P Sorry :P

Perhaps reschedule can't find them because they have the "wrong" plan_class (or whatever tag is appropriate).

How can I tell if this info has been set/ set correctly?

---

Speedy, the rescheduler won't work with the fermi. It only recognizes 6.08 and 6.09 it cannot do the 6.10 Fermi plan_class.

---

PROUD MEMBER OF Team Starfire World BOINC

Ok thanks. I'm running them on my gpu they are taking about 1 hour 24 minutes each. I have another 2 after this 1 completes it's 18% done

So I'm correct in saying theres no way to send tasks from a GTX 470 Gpu to the Cpu?

---

Speedy, the rescheduler won't work with the fermi. It only recognizes 6.08 and 6.09 it cannot do the 6.10 Fermi plan_class.

My fermi machine had almost run out of tasks on GPU but had plenty of suitable CPU tasks so I did a bit of testing on this.

The rescheuled tool seems to work OK with all tasks as long as you are rebranding from GPU to CPU.

The problem occurs when you rebrand from CPU to GPU.

The issue seems to be more about the plan_class entry rather than version number.

608 tasks were plan_class cuda
609 tasks are plan_class cuda_23 (although some people have left 609 as cuda)
610 tasks are plan_class_fermi

Moving tasks from CPU to GPU, Reschedule has to add a plan_class entry for tasks as it does not exist for CPU tasks.

After taking a full backup and stopping network access I ran reschedule to move tasks from CPU to GPU and examined the client_state.xml file.

There are 3 relevant sections in the file - file_info, workunit and result. Result has a version number and plan_class, workunit has version number and file_info has neither.

All workunit entries that had been changed to GPU had a version number of 610 - correct.

All 'result' entries that had been changed to GPU had a plan class entry of >cuda< rather than >cuda_fermi<.
I did a "case sensitive" [there are 2 other entries which contain >CUDA< which should not change] search and replace using Notepad from >cuda< to >cuda_fermi<, restarted BOINC and all worked OK - no lost workunits because of missing apps.

I believe the same is true of 609 tasks also as >cuda_23< was adopted - so the same thing should apply but I havent actually tested this yet.

Anyone continuing to use >cuda< rather than >cuda_23< or >cuda_fermi< "should" find that reschedule works OK.

This does of course mean manual intervention in the use of Reschedule - not ideal but better than letting your GPU run dry.
i.e.
1. Stop BOINC (and include the running applications)
2. Run Reschedule to move tasks from CPU to GPU
3. Manually edit client_state file to change plan_class where necessary
4. Restart BOINC.

N.B. If you run Reschedule while BOINC is running, it will automatically restart BOINC before you have a chance to edit the file and all incorrect tasks will be dropped.

I have only tested this on one machine so caution should be used if your are attempting this - especially with the shortage of new tasks at present (you dont want to lose any precious tasks!) and definitely take a backup before doing this so that all files can be restored to before Rescheduling until you are confident that all is working OK.


John.

---

GPU Users Group

Can I please have a example of what could need to be changed client state file?

---

Speedy, the rescheduler won't work with the fermi. It only recognizes 6.08 and 6.09 it cannot do the 6.10 Fermi plan_class.

If you would all just read a bit more of the thread - specifically, to my conversation with MadMaC on 16 June.

Questor (just now) is absolutely right, and has confirmed what we found then: ReScheduler puts the correct <version_num> into the file, but the wrong <plan_class>.

Manually changing every <plan_class> to <cuda fermi> obviously works, but the alternative is to change your app_info file so that BOINC knows how to handle the reschuled tasks. We got into a slight muddle with x64 applications last time, so here'e a slightly different suggestion.

Open your app_info.xml file for editing. (Usual rules - plain text only, Notepad in ANSI mode is fine). Locate the <app_version> ... </app_version> containing your Fermi application.

Duplicate the entire section (copy and paste), including the two bracketing tags <app_version> and </app_version>. In one copy, change the <plan_class> from cuda_fermi to cuda: leave the other alone.

Repeat the above paragraph if you have any more app_version sections containing the Fermi application. Save your changes.

And that's it. Rescheduler should work automatically again.

Thanks Richard. I'm going to leave client state file alone as I'm scard I'm going to crash my tasks. Thanks all the same

---