Don't need AP for that - provided you have the new app's and associated files already present, as you do, you can simply change the version numbers in client_state.
I don't recommend that you do this unless you really know what you're doing (as Gary does), but...
Compare the blocks for your v1.25 and v1.28 tasks, paying particular attention to , , and . If they match, a simple replace from 125 to 128 will do the trick.
You need to replace that string in both the and sections for cached tasks, but avoid changing it in the description - you can't do a complete global replace. It's probably best to report completed tasks first, and avoid 'rebranding' (as we call it at SETI) tasks in progress. Following Gary's lead, by suspending v1.25 tasks first and starting the v1.28 tasks, would ensure that.
Is not possible to do just a clever renaming of the executables? (finishing first the WUs that already started to avoid the "rebranding" thing)
I guess this wont work if BOINC (or the project) does some kind of "validation" of the apps files... (or if the project expects something different in the results files depending of the apps)
I'm very tempted to set up AP to run the remaining 1.25 tasks with the new app but it's getting late here and I need to go home. Maybe in the morning if I get really keen ...
I had a similar temptation so I just wait until running tasks have finished and then reset the project. After resetting boinc resent all remain tasks with 1.28 version marks.
I hoped you backed up all the p2030.20110117.*.bin4 data files before you reset the project, and restored them afterwards? That saves one heck of a lot of download bandwidth, both at your end and for the project - and it gets your crunching restarted a lot quicker.
Is not possible to do just a clever renaming of the executables? (finishing first the WUs that already started to avoid the "rebranding" thing)
I guess this wont work if BOINC (or the project) does some kind of "validation" of the apps files... (or if the project expects something different in the results files depending of the apps)
You'd also have to copy/replace the file sizes and digital signature blocks before BOINC would accept them, and do the same for the db.dev.win.* and dbhs.dev.win.* files which are also different.
Another way might be to re-version the current 125 block to something unused like 99, and replace it with a duplicate of the 128 renumbered 125. That would keep all the older files and signatures in place, but process 125 'branded' work with the files from 128.
I have been playing around with the new NVIDIA drivers for Windows alongside the new BRP4 1.28 application. Beta driver 306.02 appears to be giving a 5-6% performance improvement with the new app over previous drivers that I tried. I am seeing this improvement via a Fermi card.
... you can simply change the version numbers in client_state.
Richard, thanks very much for that. I don't follow Seti at all and I've never tried 'rebranding' tasks before so I wasn't sure if there were any complications with doing something like this. In this case around 40 tasks have now been successfully rebranded and things seem to be chugging along just fine.
Last night my computer started running each 1.28 WU for 2-3s; stopping with 0% progress and then moving to the next. After running all of them, it started a Collazt WU (a 0% share/backup project for me) which began to run normally. Restarting boinc didn't help; but everything returned to normal after I rebooted.
Occasionally we have a few data files which contain garbage or "semi-garbage", so that the app finds less candidates in the data than the validator thinks is healthy. We try to kill those units from time to time, but we are kind of conservative, trying to not kill anything unless we are really really sure it's one of the "hopeless" batches.
This particular thing seems to be a marginal case, because it has one unit that (probably erroneously) found a candidate and thus passed initial validation. That kept it from qualifying for being flagged as "hopeless".
Good work with the new version.
My HD 7970 is utilized up to 70% or so with just one task running (significantly higher than before).
I hope to see over 90% utilization with future releases. :)
This report is a little vague.
I've got an Imac with a Radeeon HD 6770M running Lion 10.7.4
I've had to turn off GPU processing because I noticed that playing flash video (you tube) while doing openCL processing had a tendency to hang the GPU.
The machine hangs hard (mouse pointer still moves but everything else is locked up) and has to be powered off.
Its not completely reproducable. It tends to happen after video has been playing for a couple of minutes. But has happened multiple times.
I assume its the openCL that causing it since it only started happening once the opencl work unit appeared. And its stopped since I unsubscribed from the openCL workunits. But its not a huge sample set.
Anyone else noticed issues?
Yes, same here for iMac with Radeon 6770 / 512MB running Mountain Lion, the machine hangs when using Flash (hard reboot is needed) but knowing Flash and its bugs it's no surprise for me. I am crunching with GPU while computer is used because there's no lag for regular work. When I intend to use Flash I usually click on BM "Snooze GPU". I also keep 1 CPU for GPU instructions only - out of 4 CPUs only 3 are utilized for CPU crunching. Machine has no issues if no Flash is used, so far I am very happy with the results.
RE: Don't need AP for that
)
Is not possible to do just a clever renaming of the executables? (finishing first the WUs that already started to avoid the "rebranding" thing)
I guess this wont work if BOINC (or the project) does some kind of "validation" of the apps files... (or if the project expects something different in the results files depending of the apps)
RE: RE: I'm very tempted
)
I hoped you backed up all the p2030.20110117.*.bin4 data files before you reset the project, and restored them afterwards? That saves one heck of a lot of download bandwidth, both at your end and for the project - and it gets your crunching restarted a lot quicker.
RE: Is not possible to do
)
You'd also have to copy/replace the file sizes and digital signature blocks before BOINC would accept them, and do the same for the db.dev.win.* and dbhs.dev.win.* files which are also different.
Another way might be to re-version the current 125 block to something unused like 99, and replace it with a duplicate of the 128 renumbered 125. That would keep all the older files and signatures in place, but process 125 'branded' work with the files from 128.
I have been playing around
)
I have been playing around with the new NVIDIA drivers for Windows alongside the new BRP4 1.28 application. Beta driver 306.02 appears to be giving a 5-6% performance improvement with the new app over previous drivers that I tried. I am seeing this improvement via a Fermi card.
RE: ... you can simply
)
Richard, thanks very much for that. I don't follow Seti at all and I've never tried 'rebranding' tasks before so I wasn't sure if there were any complications with doing something like this. In this case around 40 tasks have now been successfully rebranded and things seem to be chugging along just fine.
Once again, thanks for the information.
Cheers,
Gary.
Last night my computer
)
Last night my computer started running each 1.28 WU for 2-3s; stopping with 0% progress and then moving to the next. After running all of them, it started a Collazt WU (a 0% share/backup project for me) which began to run normally. Restarting boinc didn't help; but everything returned to normal after I rebooted.
Has anybody an idea what
)
Has anybody an idea what happened here?
http://einsteinathome.org/workunit/129801060
Hi! Thanks for reporting
)
Hi!
Thanks for reporting this.
Occasionally we have a few data files which contain garbage or "semi-garbage", so that the app finds less candidates in the data than the validator thinks is healthy. We try to kill those units from time to time, but we are kind of conservative, trying to not kill anything unless we are really really sure it's one of the "hopeless" batches.
This particular thing seems to be a marginal case, because it has one unit that (probably erroneously) found a candidate and thus passed initial validation. That kept it from qualifying for being flagged as "hopeless".
Cheers
HB
Good work with the new
)
Good work with the new version.
My HD 7970 is utilized up to 70% or so with just one task running (significantly higher than before).
I hope to see over 90% utilization with future releases. :)
RE: This report is a little
)
Yes, same here for iMac with Radeon 6770 / 512MB running Mountain Lion, the machine hangs when using Flash (hard reboot is needed) but knowing Flash and its bugs it's no surprise for me. I am crunching with GPU while computer is used because there's no lag for regular work. When I intend to use Flash I usually click on BM "Snooze GPU". I also keep 1 CPU for GPU instructions only - out of 4 CPUs only 3 are utilized for CPU crunching. Machine has no issues if no Flash is used, so far I am very happy with the results.