Seti@Home optimized science apps and information
Optimized Seti@Home apps => Windows => Topic started by: perryjay on 11 Dec 2009, 12:33:06 pm
-
Will this be added to the installer app-info anytime soon or could someone show me what I would have to add in? I'm really good at messing up my app-info when I try to do it myself! :-)
-
Will this be added to the installer app-info anytime soon or could someone show me what I would have to add in? I'm really good at messing up my app-info when I try to do it myself! :-)
Hi there. No app_info mods required. Just drop the new DLLs over the old ones in the setiathome project folder. A revised installer will likely eventually use 2.3 as baseline install, but other improvements to applications are in progress, so updating that isn't a priority at the moment, since the current version works as baseline, for advanced users to optionally tweak.
The 2.3DLLs offer a high degree of improved performance over 2.2 ones. If, however, you aren't entirely aware or confident with the possible ramifications of switching the DLLs out (pushing things harder), or what you were doing and why, I'd normally probably advise against it ... Since you've come here to enquire about the right way to go about things, I'd say give it a go (swapping the DLLs in which is actually easy), If you break it you own both parts ;).
-
Jason,
Would you happen to know whether the v6.09 application (presumably the one installed at Beta on 13 August) actually contains any code updates of any significance, or is this just a fudge to allow automatic distribution of the 2.3 DLLs to hosts with adequate drivers/BOINC versions?
If there's no significant application change (even bug-fixes), as I suspect, we can safely say that it makes no difference at all to people already using optimised applications - who are already able to drop in the 2.3 DLLs if they are using a recent-enough driver.
-
Thanks guys. I had already swapped in the 2.3 DLLs in but was also thinking there might have been some extra changes in the 6.09 build. A case of you never know until you ask ;D
-
Jason,
Would you happen to know whether the v6.09 application (presumably the one installed at Beta on 13 August) actually contains any code updates of any significance, or is this just a fudge to allow automatic distribution of the 2.3 DLLs to hosts with adequate drivers/BOINC versions?
If there's no significant application change (even bug-fixes), as I suspect, we can safely say that it makes no difference at all to people already using optimised applications - who are already able to drop in the 2.3 DLLs if they are using a recent-enough driver.
A quick look a while back told me nothing of consequence, though I've been occupied lately with other things. Will need to chase up the Berkeley svn adresses again to look, when I get around to it.
Jason
[Later:] Listing observed changes in 6.09 checkin, which is a bulk one dated 18th August 2009, Joe's fixes to fllops counting date after that 26th August 09 :
- some addition of a preprocessor directive to anyalyzefuncs, to allow turning on/off locking affinity to a single core in build
- changed Cuda DLLs
- Some changes to logging output
- some removal of syncronisation in soem puslefind kernels ( I beleive we already did this, but will check)
So apparently no, AFAICT no specific changes to make 2.3 work, or make them work differently.
-
Does the Lunatics' Unified Installer v0.2 still work when a user already has Stock Seti 6.09 Wu's in his Cache?,
They'll be branded as 6.09, will the installer put in 6.09 entries in the app_info?
Claggy
-
The apps still 'work' since tasks are the same, though as noted task cache will need to be drained first, since stock app is marking work differently. I'm in the process of working things out for an updated installer. Probably it would help speed things along nicely if someone could test the following method going from stock 6.09 cuda plan class cuda23:
Before restarting Boinc:
- go in and edit the applicable '.aistub' files to include 6.09 entries and duplicate app version entries for the cuda23 plan class.
- if a 64 bit system, also change/add app version to have a paltform tag 'windows_intelx86' and another of the same version for 'windows_x86_64'
- run the aimerge command
Double check the resulting joined app info has:
- app version entries of both cuda and cuda23 plan class, in both 6.08 & 6.09 variants
- entries for both platform types, if on a x64 system
- 0n x64 That would amount to two plan classes X two versions X 2 platforms = 8 app version blocks
- On x86 That would amount to two plan classes X two versions = 4 app version blocks
- For the CPU app on x64 (6.03) put the duplicate app version bloxks also = 2 app version blocks, on x64
- AstroPulse same deal with x64 ( 2 app version blocks for 5.05, with different platform tags)
- Then start Boinc and see if any tasks are dumped.
I appreciate this would be a difficult migration process to acheive by hand, so will expedite getting my installer development back up and running ASAP (after a painful Win7 migration and loss of a hard drive, requiring retreival of much stuff from backups, ongoing process. ).
Jason
-
I warned a user on Seti yesterday that he might loose all his Cuda tasks as i didn't think the Installer would put 6.09 entries in the app_info,
he went ahead, and after he'd finally restarted Boinc, he did loose all this Cuda Wu's,
i haven't got the heart to tell him he should detach/reattach to free up all those Cuda wu that wont expire until 1st Feb '10,
then install the apps again. :(
Claggy
-
...
I appreciate this would be a difficult migration process to acheive by hand, so will expedite getting my installer development back up and running ASAP (after a painful Win7 migration and loss of a hard drive, requiring retreival of much stuff from backups, ongoing process. ).
Jason
Jason:
Sorry for the painful rebuild following your hard drive death. I've migrated to Win7 Pro x64 (bit painful from XP) without any untoward damage. As for your testing request, I'm unqualified I fear ("aimerge" huh?). But it's now a new decade so I'm wondering how you're doing with an updated installer that will include optimized 6.09 Cuda?
[BTW I use a small 0.25 day cache so for me its no problem to drain it down prior to running your installer].
-
...
I appreciate this would be a difficult migration process to acheive by hand, so will expedite getting my installer development back up and running ASAP (after a painful Win7 migration and loss of a hard drive, requiring retreival of much stuff from backups, ongoing process. ).
Jason
Jason:
Sorry for the painful rebuild following your hard drive death. I've migrated to Win7 Pro x64 (bit painful from XP) without any untoward damage. As for your testing request, I'm unqualified I fear ("aimerge" huh?). But it's now a new decade so I'm wondering how you're doing with an updated installer that will include optimized 6.09 Cuda?
[BTW I use a small 0.25 day cache so for me its no problem to drain it down prior to running your installer].
Applause, you have gotten through some things that most do not. There is a test of an new installer but it is not easy.
It will take some time to mature. It will be posted as it is ready.
Regards
-
v6.09 running well on my GTX275 + Win XP
-
In this message http://setiathome.berkeley.edu/forum_thread.php?id=54288&nowrap=true#992283
Near the bottom of this message is shown the app_info file that was created for this person by the v .35 installer. There are two sections labled for version 608. One is for plan_class cuda and the other is for plan_class cuda 23. Is the stated version 608 correct for both sections?
I thought version 609 equated to plan_class cuda 23 or am I wrong?
-
In this message http://setiathome.berkeley.edu/forum_thread.php?id=54288&nowrap=true#992283
Near the bottom of this message is shown the app_info file that was created for this person by the v .35 installer. There are two sections labled for version 608. One is for plan_class cuda and the other is for plan_class cuda 23. Is the stated version 608 correct for both sections?
I thought version 609 equated to plan_class cuda 23 or am I wrong?
As far at the SETI project itself is concerned, it really doesn't matter at all. Yes, if you run the stock applications, 608/cuda and 609/cuda23 is the way it'll turn out: but for people who use app_info, a show-stopper can be that Marius's ReScheduler application will only operate on tasks with a '608' version number. Until Marius can find the time to post an updated version, or let someone else have the source code to make the changes for him, they're stuck. Tagging everything with v608 is the lesser of two evils.
-
Thanks for the info Richard..............
-
In this message http://setiathome.berkeley.edu/forum_thread.php?id=54288&nowrap=true#992283
Near the bottom of this message is shown the app_info file that was created for this person by the v .35 installer. There are two sections labled for version 608. One is for plan_class cuda and the other is for plan_class cuda 23. Is the stated version 608 correct for both sections?
I thought version 609 equated to plan_class cuda 23 or am I wrong?
As far at the SETI project itself is concerned, it really doesn't matter at all. Yes, if you run the stock applications, 608/cuda and 609/cuda23 is the way it'll turn out: but for people who use app_info, a show-stopper can be that Marius's ReScheduler application will only operate on tasks with a '608' version number. Until Marius can find the time to post an updated version, or let someone else have the source code to make the changes for him, they're stuck. Tagging everything with v608 is the lesser of two evils.
Interesting and kind of new to me. The rescheduler parses only the client_state.xml and it searches for all workunit with plan_class items to know if a unit is for cpu or gpu. It does not expect the new plan_class "cuda23", so everything marked for plan_class cuda23 (609) will internally be seen as a standard cuda application (no matter what version_num is specified).
Since i no longer have a nvidia at home, does somebody have an example client_state.xml with multiple plan_classes so i can take a look and test? (please email me at marius66 at home dot nl)
Thanks in advance,
Marius
-
Attached is a grab of the the client state from my p4 (XP w/sp3). It is a bit 'unusual' (different again to the installer), since I experimented to find that installing both plan classes was needed for installer migration purposes, but left the version numbers on that machine at 6.09 (since it doesn't matter & I use experimental builds that don't require rescheduling)
Hope that helps, (Sorry can't get to my email right now...Can email later if you need)
Jason
[Later:] I guess you have it now from download count, removing to save space... Let me know if you need something different. I'll do my best to recreate any kindof scenario you might need.
[Even Later:] If you're having trouble locating a problem, After some thought I can walk through a scenario that *might* demonstrate one reasonably likely/common potential issue, that I could test our combined theories about how it *should* react on that same p4. I've come to think the newest installers & the client state I gave might be red herrings in this situation, since the app infos have been somewhat 'robustified' to minimise the potential for task loss. Stock 6.09 & Boinc without anonymous platform use, however, IIRC aren't likely to be so forgiving.
-
Hello Jason,
Thanks indeed ;) Its a neat example where the reschedule ignores the 609/cuda23 application. In this particulary situation there are only 603 and 609/cuda workunits so i was not able to test all. If you have a combination with 603, 608/cuda, 609/cuda and 609/cuda23 that would be very nice, the more difficult the better and even multiple projects are welcome to see if it can crack that..
I think that as long people don't use the slider to move units from the cpu to the gpu everything should be just fine AFAICS, VLAR's (and optional the VHAR's) will be moved to the cpu. The other way from cpu to gpu is kind of a problem because in this combination of 609/cuda and 609/cuda23 i don't know which cuda application is active and which one i may use (mayby i just need to remove the slider and stick with the basics of moving VLAR and VHAR to the cpu)
Is it btw also possible to have multiple 603 applications for the cpu?
Greetings,
Marius
-
...The other way from cpu to gpu is kind of a problem ...
hehehe, well you sussed out my example scenario ;D. The 6.03->6.09 problem is common, because some will attempt to install & run a shiny new cuda card (Very Excited! ;D) on a full cache, get 'project has no work' and immediately through impatience attempt to shift CPU work over, with no 6.08/cuda matching app/version/planclass on the host. So that's why I said 'not compatible with 6.09' which as you point out isn't strictly the complete truth, but something we need to look at.
Now the problems get multiplied a little with upcoming possible further plan classes and platforms/devices etc, and I feel recognition should be configurable for specific app/version/planclass, and the optimal rescheduing requirements may change with development in the near future. Aware that you have mentioned being quite busy elsewhere, Are you amenable to providing source so that we can maintain (giving you svn access as well) a codebase such that we can consider integration with the installer & better assist users while you're not about ?
Cheers, Jason
[Edit:] multiple 6.03 apps ? 'Naturally' fom the project at this time No, but Yes I've actually tried that myself by creating different plan classes. I did that to compare different apps under live conditions. Given that Boinc has been improved to schedule by resources, it is quite feasible to have, for example, mutithreeaded and single threaded variants. Really a particular application executable should be distinguished by application name, version number and plan class.
-
Hello Jason,
Thanks indeed ;) Its a neat example where the reschedule ignores the 609/cuda23 application. In this particulary situation there are only 603 and 609/cuda workunits so i was not able to test all. If you have a combination with 603, 608/cuda, 609/cuda and 609/cuda23 that would be very nice, the more difficult the better and even multiple projects are welcome to see if it can crack that..
I think that as long people don't use the slider to move units from the cpu to the gpu everything should be just fine AFAICS, VLAR's (and optional the VHAR's) will be moved to the cpu. The other way from cpu to gpu is kind of a problem because in this combination of 609/cuda and 609/cuda23 i don't know which cuda application is active and which one i may use (mayby i just need to remove the slider and stick with the basics of moving VLAR and VHAR to the cpu)
Is it btw also possible to have multiple 603 applications for the cpu?
Greetings,
Marius
Hi Marius - glad to see you're around again!
One observation on removing the slider. Occasionally we get VLAR storms where I end up with nothing but VLAR tasks (I think the big crunchers who are still running VLAR killer apps probably dont help this situation as the tasks have got to end up somewhere!). In this situation, I would prefer not to move all VLAR tasks to CPU and leave the GPU idle but take the hit on slow processing. I am probably in the monority on this but I would like the ability to rebrand VLARs back to the GPU if it goes idle. The norm for me is to set the slider to the 'normal' running ratio of tasks. (However I reaslise the difficulty of extracting the right cuda information to construct a plan_class when moving from CPU to GPU).
With the new Fermi cards (only just got a couple of GTX470s so still experimanting) I havent yet worked out how 'bad' the hit is. Also just to make things more complicated the consensus I have seen so far is to introduce a new plan_class of cuda_fermi.
I discovered in testing that Reschedule didnt work for cuda_fermi plan class but still use it to check the current ratio of tasks - unfortunately I stupidly hit the Run button by mistake but only lost a few tasks when I think it rebranded them back to GPU with the wrong plan_class entry and they errored out when it couldn't find the app.
John.
-
With the new Fermi cards (only just got a couple of GTX470s so still experimanting) I havent yet worked out how 'bad' the hit is. Also just to make things more complicated the consensus I have seen so far is to introduce a new plan_class of cuda_fermi.
I discovered in testing that Reschedule didnt work for cuda_fermi plan class but still use it to check the current ratio of tasks - unfortunately I stupidly hit the Run button by mistake but only lost a few tasks when I think it rebranded them back to GPU with the wrong plan_class entry and they errored out when it couldn't find the app.
Why i'm i not suprised, another variation in the plan_class definitions ;). Could you please email me a client_state.xml example at marius66 at home dot nl and i'll have a look at it.
plan_class=cuda (608)
plan_class=cuda23 (609)
plan_class=cudafermi (6???)
Thanks in advance,
Marius
-
It is not yet certain what the new plan class will be - it hasn't been installed yet. The definitive answer will become apparent on the applications page (http://setiathome.berkeley.edu/apps.php) in due course.
But I strongly suspect they will copy the Beta application plan (http://setiweb.ssl.berkeley.edu/beta/apps.php). That would make the plan_class
cuda_fermi
as Questor wrote, and the app_version 610: everything else is exactly analogous to the earlier plan_classes.
-
It is not yet certain what the new plan class will be - it hasn't been installed yet. The definitive answer will become apparent on the applications page (http://setiathome.berkeley.edu/apps.php) in due course.
But I strongly suspect they will copy the Beta application plan (http://setiweb.ssl.berkeley.edu/beta/apps.php). That would make the plan_class
cuda_fermi
as Questor wrote, and the app_version 610: everything else is exactly analogous to the earlier plan_classes.
Marius,
Apologies for not replying to your post - I have been away on holiday for a week.
I have now emailed you a copy of my fermi client state file. However, the machine is using an app_info.xml so is only picking up the app entries from there. However, the fermi app has now been released to live setiathome so if it helps I can temporarily remove the opt apps and get a clean client state file using stock apps if it will help. It might have to wait until the current issues with the seti site are resolved as getting the apps and new wus will probaly be an issue.
John.