I think this is only possible if Rick has checked the option "Use True Angle Rate" (basicly the tool is then using Eric and Richard's detection of vlar/vhar)
Rsc_fpops_est = 80360000000000.000000 is a vlar
Rsc_fpops_est = 23780000000000.000000 is a vhar

Instead of your detection algorithm (which i assume is also used when doing the vlarkill):
true_angle_range < 0.13 = vlar
true_angle_range > 1.127 = vhar

Greetings,
Marius

Thanks guys. I typically run the reschedule with VLAR/VHAR to CPU. Being an engineer who can't keep his hands off of things  , I then unchecked the box and ran the 75% to GPU. I think I could have tried "true angle" as well.

I tend to play with things to see how they work. I was just a bit surprised when some of the "bad" ones actually ran OK how ever I got them back to the GPU. Of course there was a lot of carnage too 

By the way I had about 60 tasks and when I rescheduled using "VLAR/VHAR to CPU" all but 2 went to the CPU. After playing I got about 35 on the GPU. I wasn't paying attention, but I think maybe 10 or 15 ran with the rest dying the horrible death.

Look at the SETI applications page. There is no current MB application 605: there will, briefly, have been a CUDA app with that number, while they were ironing out the initial major bugs, but that app has long since passed into history.

If you are seeing v6.05 on your host, then at some point you must have installed an app_info.xml file with a 605 version number reference. I suggest you go and review the work you did then, and reassure yourself that whatever application you installed to handle that 605 reference is still an appropriate one that you want to use. Assuming that it is, duplicate your 605 section and change one of the copies to have a 603 version number: ReScheduled tasks should work then.

This is one reason why it's a good idea to stick with the project's version numbering, even when installing third party applications. It makes absolutely no difference at all to the validity of the results, but non-standard numbering can have unexpected side-effects later on, as here.

But if he uses Marius's "ReSchedule" tool to create 603 tasks, then a double-version app_info will run them. It would have the interesting, and possibly useful, side-effect of allowing him to distinguish between rebranded tasks (v6.03) and native MB/CPU downloads (v6.05). It would, however, destroy any chance of using Marius's tool to rebrand downloaded CPU tasks back to CUDA.

@ Morten,

One thing I didn't cover in my previous post: do make absolutely sure that your '605' reference doesn't point to a CUDA app! The whole point of rebranding is to point the tasks to a CPU handler. Your description "MB application" could refer to either CPU or CUDA.

@ Marius,

How are the CPU and CUDA versions defined in your application? Are they hard-coded version numbers, or are they data picked up from the .ini file? It would be better, in the long run, to use configuration data to establish the version numbers, to allow for future Berkeley releases and special cases like Morten's.

I was referring to CPU 605s, and based on app_info, some of which had both 603 and 605, and boinc started to pick up on the 605s recently. I thus assumed that 603s were about to expire and removed 603s from app_info. I have now reverted back to 603 and removed reference to 605s in my countless different app_infos, sigh.

Morten

At the moment they have been hardcoded (just 2 references), but it isn't a lot of work making them configurable.

I think its even better to just figure out the right applications from the client_state.xml. Take a look at the /client_state/app_version/. Filter those on app_name=setiathome_enhanced, if i'm right (not really sure) there are alway's two applications for setiathome_enhanced with one marked with a plan_class=cuda (at the moment 603 and 608/cuda).

I need the platform info from the application section anywhay as i need to brand the platform as well (as Glennaxl asked a while back), picking up the version numbers would just be a perfect way to get the tool working for future versions of MB.



Greetings,
Marius

Yes, its just a idle background application waiting for the 4 hours timeout (or whatever hours you have configured it to run). It does all the work itself without the need for the standard windows scheduler (or other complicated stuff).

However if you want it to work from within batch files or via windows scheduler use the commandline  "Reschedule.exe /Autorun <percentage>". It will start, do its thing and exit immediately.

Greetings,
Marius