CPU <-> GPU rebranding

[Raistmer]

I have no idea why VLARKILL occurred even after a reschedule. I think Raistmer can answer this one better then me. However i noticed a couple of vlarrkils on my account also while using the tool, but nearly not as much as it used to be (before that complete series went down the drain).

In Rick's case it seems he sent some of true VLARs back to GPU when used "75%" distribution. Can this mode of operation leave VLARs on GPU?

[Marius]

I have no idea why VLARKILL occurred even after a reschedule. I think Raistmer can answer this one better then me. However i noticed a couple of vlarrkils on my account also while using the tool, but nearly not as much as it used to be (before that complete series went down the drain).

In Rick's case it seems he sent some of true VLARs back to GPU when used "75%" distribution. Can this mode of operation leave VLARs on GPU?

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

[Raistmer]

Maybe. I never used flop estimates for this purpose cause execution path will based on numbers derived from AR. Science app doesn't know about estimations of its performance

[Purple Rabbit]

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.

[Morten]

Hi,

What about MB application 605? I only have 605 no 603s, so I receive "Error : There is no application defined for version 603".

Regards
Morten Ross

[Richard Haselgrove]

Hi,

What about MB application 605? I only have 605 no 603s, so I receive "Error : There is no application defined for version 603".

Regards
Morten Ross

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.

[Raistmer]

If you simple dublicate your 605 field, new downloaded tasks will still be branded as 605 and still no 603 wtasks will be available. You need to get rid from 605 completely by drying your current cache and changing 605 to 603.
[603 version num reserved for CPU app and 608 - for GPU CUDA app for now]

[Richard Haselgrove]

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.

[MarkJ]

I just downloaded it and installed on all my cuda machines, after first testing it on one of them. Seems I have VLAR/VHAR on all of them except one (it didn't have any MB work).

I did notice that the rebranded work units immediately went into "running, High Priority" mode. Seems their estimated time was 20+ hours. That estimate is dropping like a stone as it starts crunching them so it will work it out, but they will be finished by the time the TSI has come up (60 mins).

@ Marius, its a great little tool. Thank you. 

One question about the automatic mode and the default time of 4 hours. I assume it just sits there waiting for the 4 hours to be up and then does its scan/rebrand before going back to sleep. I don't need to get windows to schedule it?

Cheers,
MarkJ

[Morten]

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

[Richard Haselgrove]

I did notice that the rebranded work units immediately went into "running, High Priority" mode. Seems their estimated time was 20+ hours. That estimate is dropping like a stone as it starts crunching them so it will work it out, but they will be finished by the time the TSI has come up (60 mins).

If tasks are estimated at 20 hours, but finishing in less than 1 hour, you have a horribly out-of-kilter Duration Correction Factor. With no VLAR handler in place, I would have expected a sawtooth waveform with maybe a factor of 4x between peak and valley, but 20x? No wonder you were seeing preemptions and EDF on boinc_alpha.

I suggest a sanity-check on the FLOPs estimates in your app_info: once the after-effects of your CUDA/VLAR processing have worked their way out of your system, estimates for all SETI work (MB/CPU, MB/CUDA, and AP) should be accurate within a few %.

[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.

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

[Richard Haselgrove]

Good thinking!

Edit - during transitional periods, there may be more than one version number in there for any one plan_class - some old work downloaded and still scheduled to be crunched with an older version, and some new work with references to a new version. Best BOINC practice would be to scan the versions, and choose the highest available for the app/plan/platform.

[Marius]

One question about the automatic mode and the default time of 4 hours. I assume it just sits there waiting for the 4 hours to be up and then does its scan/rebrand before going back to sleep. I don't need to get windows to schedule it?

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

[Marius]

Good thinking!

Edit - during transitional periods, there may be more than one version number in there for any one plan_class - some old work downloaded and still scheduled to be crunched with an older version, and some new work with references to a new version. Best BOINC practice would be to scan the versions, and choose the highest available for the app/plan/platform.

Excellent idea!

The "old" units would have been already rescheduled anywhay so very little chance on V*AR in the old cuda application.

Greetings,
Marius