Seti@Home optimized science apps and information
Optimized Seti@Home apps => Windows => GPU crunching => Topic started by: Raistmer on 07 May 2009, 04:06:03 pm
-
Attached script will move VLAR and VHAR tasks to CPU and midrange tasks to GPU queues.
This increase host productivity.
With small modifications it can be used to move all (or almost all) MB tasks to GPU and vice-versa.
It should be run from BOINC data directory.
Don't forget to backup you BOINC data folder and disable BOINC network access on first script use.
[attachment deleted by admin]
-
Thanks for the script.
I have also noticed that it does not seem to be working when there are some other boinc projects besides seti@home... it's trying to find other project WUs in seti work directory and ofcourse it fails...
Could you please fix this, so it searches and try to fix only seti WUs. I guess it shouldn't be so complicated.
Thanks in advance.
-
Yes, it will try find SETI beta tasks in SETI project too.
-
Hello. I'd like to use this script but I have no idea as the how to (use a script in general). I found an explanation for ubuntu but i'm on XP. I found elsewhere than it doesn't work with more than 500 WU, is it true (I have more than a thousand currently) ?
Thanks
-
You need a perl interpreter for windows, like activeperl or some other windows distribution.
http://win32.perl.org/wiki/index.php?title=Main_Page
-
If you have >500 MB tasks in cache script will exit w/o modifying BOINC state.
It's some kind of foolproof. There are too many users now who trash whole 10-day cache with few thousands tasks with easy trying some new software/configurations w/o any care of properly backing up their BOINC installation.
Anyone who skilled enough can easely modify this limit. The rest of users should obey it.
-
OK, it is quite simple...but I have a problem :'(
I modified the limit, that was simple. I run it, and it doesn't work :
>perl -w CPU_GPU_rebrand_V2.pl
Number of CPU tasks before rescheduling:0
Number of GPU tasks before rescheduling:610
Illegal division by zero at CPU_GPU_rebrand_V2.pl line 50.
I studied the script, and the div/0 is logical with all the tasks considered as GPU. I don't understand why this is the case, however.
btw, thank you for your previous answers, I have learned something.
-
Attached script will move VLAR and VHAR tasks to CPU and midrange tasks to GPU queues.
...
Don't forget to backup you BOINC data folder and disable BOINC network access on first script use.
BTW, is it too hard to convert VisualBasic6-program into VBScript?
In the beginning I did rebranding 608->603 manually, but after increasing of VLAR-WUs quantity I made VB6-program and using it past days...
-
OK, it is quite simple...but I have a problem :'(
I modified the limit, that was simple. I run it, and it doesn't work :
>perl -w CPU_GPU_rebrand_V2.pl
Number of CPU tasks before rescheduling:0
Number of GPU tasks before rescheduling:610
Illegal division by zero at CPU_GPU_rebrand_V2.pl line 50.
I studied the script, and the div/0 is logical with all the tasks considered as GPU. I don't understand why this is the case, however.
btw, thank you for your previous answers, I have learned something.
I have exactly the same problem. :( Using Boinc 6.6.20, and having a Q9650 and GTX260.
Having a lot of CPU AP tasks, and probably no 603 CPU tasks, only 6.08 GPU ones (from which some of them are VLARs to be rebranded for sure).
-
Here replacement script.
[attachment deleted by admin]
-
Thanks, just used V3 script which rebranded 86 GPU to CPU units.
But I think I also came accross a serious bug. Before applying the script, I had a couple of AP WUs, some of them half-done, which now dissapeared... :(
-
Thanks, just used V3 script which rebranded 86 GPU to CPU units.
But I think I also came accross a serious bug. Before applying the script, I had a couple of AP WUs, some of them half-done, which now dissapeared... :(
Will look at this issue. For now you should restore from backup.
-
It seems OK for me (I don't participate in AP).
C:\Documents and Settings\All Users\Application Data\BOINC>CPU_GPU_rebrand_V3.pl
Number of CPU tasks before rescheduling:0
Number of GPU tasks before rescheduling:1882
Number of CPU tasks after rescheduling:508
Number of GPU tasks after rescheduling:1374
I'ill let it work in "no network mode" for tonight to confirm the success.
-
Thanks, just used V3 script which rebranded 86 GPU to CPU units.
But I think I also came accross a serious bug. Before applying the script, I had a couple of AP WUs, some of them half-done, which now dissapeared... :(
Try this one.
I have no AP tasks so can't check if it will work as intendedbut hope it will.
Backup before first use required as usual.
[attachment deleted by admin]
-
Not good, still kills ap wus in the second WHILE loop if i understand correctly.
I think the wu check should be based on the <app_name>seti... instead of !<name>ap,
because that would be compatible with any other project.
<result>
<name>ap_12mr09ad_B4_P0_00220_20090517_09656.wu_1</name>
<final_cpu_time>0.000000</final_cpu_time>
<final_elapsed_time>0.000000</final_elapsed_time>
<exit_status>0</exit_status>
<state>2</state>
<platform>windows_intelx86</platform>
<fpops_cumulative>588532400000000.000000</fpops_cumulative>
<wu_name>ap_12mr09ad_B4_P0_00220_20090517_09656.wu</wu_name>
<report_deadline>1245152434.000000</report_deadline>
<file_ref>
<file_name>ap_12mr09ad_B4_P0_00220_20090517_09656.wu_1_0</file_name>
<open_name>pulse.out</open_name>
</file_ref>
<version_num>608</version_num>
<plan_class>cuda</plan_class>
</result>
-
Raistmer, could you please check EPG suggestion and release a new version of the script?
Thanks in advance.
-
Try this one
[attachment deleted by admin]
-
Tested with Seti MB 603,608 AP503, Einstein@home wus; looks ok to me.
Thank you very much!
-
Tested with Seti MB 603,608 AP503, Einstein@home wus; looks ok to me.
Thank you very much!
Fine. I used your hint about app_name along with other changes.
-
Seems to be working OK now. Thanks a lot.
-
This is a great idea, i'm still filling my queue after getting a new computer (and boinc is still running low on gpu units as queue starts with cpu tasks :-\)
Anywhay, I created a little tool for rebranding the units, copy it to your data directory and run from there. No additional binaries are needed, there's no unit limit and you can choose the percentage it needs to rebrand.
Just in case things go wrong (and as Raistmer always tells us), this is beta, make sure you disable network acces, stop boinc and make a safety copy.
This tool is a lot slower then the perl script as it parses all the xml ;D
[attachment deleted by admin]
-
No additional binaries are needed, there's no unit limit and you can choose the percentage it needs to rebrand.
Did you preserve AR ranges in your tool? The primary aim of original script not just to move part of tasks from GPU to CPU and vice versa, but to put on GPU only those tasks that computed better on GPU and leave other (VLAR included) on CPU.
-
Did you preserve AR ranges in your tool? The primary aim of original script not just to move part of tasks from GPU to CPU and vice versa, but to put on GPU only those tasks that computed better on GPU and leave other (VLAR included) on CPU.
Yes VLAR (<0.13) and VHAR (>1.127) are forced on to the cpu no matter what the choosen percentage is. The rest of the units can be swapped. Its done almost exactly as in the perl script with some extra code to get the percentages right. If there are a lot of vlar/vhar units the percentages can be off though.
-
Excellent! :)
-
Just tried out Marius's reschedule app.
Seems to be working perfectly on my system.
Now all I would wish for was to make it accept simple cmdline parameters, so that I could run it in a bat-file.
It could look something like this:
net stop boinc
reschedule.exe 100 (the number tells the tool how much % to convert to CUDA)
net start boinc
Then I could schedule this bat-file to run once or twice a day, and have rebranding done automatically. Would be very nice.
-
No problem KarVi, i added a commandline param. When started you only see the process in the taskmanager as its a GUI application.
For pushing 75% of the units to the GPU use:
ReSchedule.exe /Autorun 75
Enjoy,
Marius
[attachment deleted by admin]
-
Cool, I've also set this up on one of my machines in scheduled tasks to run once every three hours, using a batch file that stops boinc service first, then restarts it. Seems to be working. Nice one ;D
-
every three hours
In my experience each time you stop boinc service you will loose a (big) part of the workunits in process (unless you only run GPU). I guess executing it once every 24 or 48 hours would be fine to deal with the vlar/vhar problems.
-
Thanks Marius for the swift developement of a new version.
Will set this up to run once every 24 hours, and see how things develop.
Thanks again, this will make things easier going ahead.
-
In my experience each time you stop boinc service you will loose a (big) part of the workunits in process (unless you only run GPU). I guess executing it once every 24 or 48 hours would be fine to deal with the vlar/vhar problems.
Then you have something wrong with your setup. I've lost about three or four tasks, in total, over several machines and several years. Unfortunately, most of them were CPDN tasks!
One set of problems was related to a failing hard disk (accepted for replacement under RMA) - BOINC apps couldn't read back their checkpoint files on restart.
Another cause is the <platform> tag which I erroneously put in early versions of the CUDA app_info.xml - if you still have that, it should come out.
I run a script which checks first to see how many VLAR tasks (and optionally VHAR tasks) are in the CUDA queue, and how close they are to the head of that queue. If nothing nasty is likely to happen in the near future, it doesn't bother with the stop/restart cycle - so I can run it as often as I like (every 6 hours seems plenty). Maybe you could think about something like that?
-
...
Another cause is the <platform> tag which I erroneously put in early versions of the CUDA app_info.xml - if you still have that, it should come out.
...
You can stop beating yourself up over that one. I didn't spot it either. Besides IMO boinc should ignore platform spec if using anon platform. Quirk or Bug, well I dunno, but at least ambiguous or poorly defined.
-
Then you have something wrong with your setup. I've lost about three or four tasks, in total, over several machines and several years.
Not data corruption or something ike that, what i was trying to say is that there is a high chance the unit will restart from zero (even while it was at 99%). So if i would restart boinc every hour all tasks would restart and nothing would ever finish (except for cuda)
I run a script which checks first to see how many VLAR tasks (and optionally VHAR tasks) are in the CUDA queue, and how close they are to the head of that queue. If nothing nasty is likely to happen in the near future, it doesn't bother with the stop/restart cycle - so I can run it as often as I like (every 6 hours seems plenty). Maybe you could think about something like that?
Now that is interesting, how do you determine the "index" of a unit in the queue? And how you determine you end up in the "danger zone". If that could be done automaticly that would be sweet.
Would this also work in combination with high priority?
Greetings,
Marius
-
Now that is interesting, how do you determine the "index" of a unit in the queue? And how you determine you end up in the "danger zone". If that could be done automaticly that would be sweet.
Background: the original script was developed by Fred Wellsby ('Fred W' on the SETI boards). He wrote the underlying rebranding code, in VB script, and I added the reporting and decision-making logic. Both variants were posted, with Fred's permission, in the closed 'development' section of these boards on 22 April - with the suggestion that Lunatics take on the further refinements to generalise it and make it robust. Since then, Fred's version has been downloaded six times, and my version nine times, but there have been no comments / critiques / enhancements posted. By anyone, including me.
Marius doesn't have access to the development area, so I'm re-attaching those raw, buggy, rough-and-ready files here in the public area. I recommend that people don't just download them blindly and run them 'as is'. They aren't ready, and I will NOT support individual users who get into a mess trying to use them for their own personal gain. You have been warned.
I would, however, be delighted to work with people who are trying to improve the scripts to the benefit of the community as a whole.
Now on to the specifics. The date of 22 April is significant. The previous night, there had been some fairly heated discussion on the SETI boards when some people realised for the first time that Raistmer's VLAR_kill mods worked by causing tasks to return an error code to the SETI servers, with implications for quota. So I got Fred's permission to pass on his code, in the hope that we could develop a "humane killer" for VLARs - we weren't trying for any greater optimisation or rebalancing than that [though I found it was easy to extend the concept to VHAR too, and that extension is in my version].
We only worked on the 'true VLAR' (AR<=0.05), so a much lower cut-off than Marius and Raistmer have used. But very few tasks are issued with an AR between the Fred/Richard cutoff and the Marius/Raistmer cutoff.
The benefit of using the 'true VLAR' and 'true VHAR' cutoffs is that they can be identified by reference to client_state.xml alone. The WU data files do not have to be opened and parsed - indeed, they do not even have to be present: the script will run while the data files are still waiting to download (which may be useful later tonight). The characteristic feature of VLAR is that they have a <rsc_fpops_est> of exactly 80360000000000.000000, and VHARs have a <rsc_fpops_est> of exactly 23780000000000.000000
Because they all have identical <rsc_fpops_est>, they also have identical deadlines (from issue to timeout), which makes the EDF problem easier. No VLAR will ever queue-jump the first VLAR in the queue (FIFO order), and no VHAR will ever queue-jump another VHAR.
I defined the 'danger zone' purely in terms of the number of tasks to be processed before the first 'nasty' - candidate for rebranding - is encountered. For BOINC v6.6.20 (EDF without the option), I stored a list of deadlines as I made a single pass through client_state.xml, and also watched out for the earliest-deadline 'nasty'. Then I simply counted the entries on my stored list which were earlier than the earliest 'nasty'. For v6.6.23 and later (default FIFO), I simply counted the entries as I scanned client_state: there's a bug there, as I didn't exclude completed tasks ready to report. I didn't even consider 'High Priority' until I read your question, because I run a small enough cache (2 days) not to have to worry about it. For my cards, I set the width of the 'danger zone' to be 50 tasks, or about 12 hours processing on my fastest card: running the script every six hours gives me a reasonable safety net.
Look at Fred's script first: his implementation notes are in the zip, and it's de-activated: you have to stop BOINC, and rename the output file, yourself. My script is undocumented (except by comments), and live: it will stop a BOINC service, manipulate the files, and restart the service automatically. It will probably screw up badly on a user (i.e. non-service) installation: another reason for not allowing it to run unless you've examined it and determined it's safe for your envioronment.
Again, NO SUPPORT FOR END USERS: this is offered as a development framework only.
[attachment deleted by admin]
-
Hello Richard,
I have downloaded both attachments, if you want to avoid troubles you can/could delete the attachmens (although you certainly have warned enough <g>).
This discussion is all new for me. I'm running seti since 2000, but except for the beginning i have never paid much attention to all changes behind the screens. Raistmer perl tool came in handy because i was unable to get any cuda units and it was fun recoding it (as a first time perl user).
Your explanation gave new ideas; with the 'true VLAR' and 'true VHAR' from <rsc_fpops_est> i can avoid reading the workunit. This will save some time (not a real bottleneck, but a nice to have). Additional i can read the workunit and get the AR and see if it fits Raistmer's vlar/vhar rules. A new version could support both set of rules (Erik/Richard vlar/vhar rules or Raistmer's vlar/vhar rules).
With the boinc version i know if its a FIFO/EDF. With an user setting which determines how much cuda units they can do per hour (best case scenario) the tool can decide if its wurth to run the tool and to avoid any upcoming vlar/vhar problems. This way boinc does not have to be restarted until a real vlar/vhar problem comes up.
With FIFO i assume that means the order as the <workunit>'s are found in the client_state.xml?
Just wondering. Is there a way to avoid stopping boinc (or boincmgr)? I only need a minute to read/update the client_state.xml? What would happen if i would lock the client_state.xml exclusively? Sounds dangerous though, must be sure before i even try this on my own queue ;)
Btw; I'm kind off suprised users complained about breaking vlar units with an error. Everything is better then spending half a day on 1 single unit. And to be honoust i just killed a 900 unit queue last weekend by accident (:-X i deleted wrong partition)
Greetings,
Marius
-
If you lock config xml file BOINC will complain about that in logs badly.
But it seems it can survive few mins w/o config update.
You caould try this just by opening that file in FAR embedded editor.
(or, even by viewing in embedded viewer). The reason is: BOINC doesn;t update that file. It deletes it completely and recreates.
So, even open file for reading will prevent BOINC from handle this file in a way it prefer.
-
The problem is, so far as I can tell and contrary to speculation last time we went round this circle. the BOINC doesn't read the cleint_state.xml file back again after writing it.
So you can make any changes you want, and it won't make the slightest difference.
The whole purpose behind the BOINC closedown/restart is to make it READ client_state.xml, and see your changes - and that only happens once, at startup.
-
Ah... good point. That is, it will survive w/o access state file but will be shocked by amnesia w/o restart ;D
BUT, there is option in menu for new BOINC clients - re-read state file or smth like this. I know it works for cc_config.xml.
Does it expand on client_state.xml file or not ?
-
No, the only 'read' options are for cc_config.xml and the preferences override file. I very much doubt there will ever be a 're-read' option for the current client_state.xml file, because it changes so darn quickly: if you read it back, all the progress %ages would drop back 5 seconds or whatever. For the moment, I think the only safe thing to do is to treat client_state.xml as read-only while BOINC is running, and only make modifications after the client has fully shut down - that way, all the latest state info will have been flushed to disk and the source for the modifications will be reliable.
In the longer term (but certainly not in any of the BOINC v6.6 range), they've realised that re-writing a statefile with thousands of 'waiting to run' entries every few seconds is very wasteful. There's talk of separating out the fast-changing stuff about active tasks in progress into a much smaller file: the main cache file would then change much more slowly (perhaps only when the client contacts a server, or one task finishes and another starts). It might be possible to modify and read back the cache file then, but it still feels risky to me, and I doubt the developers would include code for it just to accommodate this script. So Lunatics would have to write a modified BOINC core client with read capability.....
..... except that by then, it won't be needed, of course. By then, Raistmer will have solved the VLAR problem and stock crunchers will be using CUDA cards for all MB work, and the Lunatics will be using CUDA for the AP jobs where it really belongs ;D
@ Marius: yes, I think the jobs are listed in client_state in the order they're assigned by the server (i.e. the order you see them in BOINC Manager if you don't have any column sorting in operation)
@ everybody else: 16 downloads already - we have a lot of budding developers lurking silently in our midst :o But remember, the instructions are in Fred's file, and you will get NO SUPPORT unless you contribute to the development effort.
-
;D ;D ;D
-
@ everybody else: 16 downloads already - we have a lot of budding developers lurking silently in our midst :o But remember, the instructions are in Fred's file, and you will get NO SUPPORT unless you contribute to the development effort.
Sorry, but at least 10 of those were me attempting to get Getright to download it, and failing, shut down Getright then got it first time, :-[
not tried it yet as have no fresh Cuda tasks (PC isn't net connected at the moment)
Claggy
-
..... except that by then, it won't be needed, of course.
LOL, i wish ;)
@ Marius: yes, I think the jobs are listed in client_state in the order they're assigned by the server (i.e. the order you see them in BOINC Manager if you don't have any column sorting in operation)
I spend a few hours tracing units in the client_state.xml and i was unable to confirm this. It ran in a very different order, mayby because i have a 10 day queue and boinc is running them almost randomly (and stopping them also, i got about 30 unfinished cuda task which have been started and stopped)
The ordering in 6.6.20 works perfectly with the deadline. With what i have i'm now able to 1) Predict if there is a vlar/vhar is coming up in the next x units. 2) If it needs a rescheduling from cpu->gpu or gpu->cpu. (so it does not run out of workunits and balance between cpu/gpu is proper for the next x hours)
Greetings,
Marius
-
@Richard,
I have an update for your vbscript: VLAR brand info.vbs.
I added time zone support.
Created the objects used once.
Found all the variables not dim'd.
Fixed a bug with nothing to be changed it fell through and tried to run a updated anyway.
Should I attach it here? Then again I might not be able to. Reading the fine print under that Attach box.
Regards,
Kevin
-
That sounds brilliant! Yes, I'd like to see your changes: provided you zip or otherwise compress the file, attaching it should be safe.
-
Allright.
Check this out.
Regards,
Kevin
Updated attached file. Dam fingers always mess up.
[attachment deleted by admin]
-
I have Seti_Enhanced running on my CPU and GPU CUDA. Using the AK_V8 software on the CPU and Seti_Enhanced. Can someone explain how to use this script to move the VLAR problem work units to the CPU's please. I have no idea what to do with it.
-
So I started using the ReSchedule.exe (1.2) from Marius. Question now is how can I make it rebrand GPU to CPU only those that will error out when the GPU crunches them?
-
As far as I know it does this automatically.
If you set the bar to convert 100% to the GPU, it will leave out VLAR and such units that error out, and keep/move them for the CPU to crunch.
-
So I started using the ReSchedule.exe (1.2) from Marius. Question now is how can I make it rebrand GPU to CPU only those that will error out when the GPU crunches them?
With version 1.2 this is not possible (it will always reschedulue). Atatched version 1.3 already has this option (see OnlyVLarVHar). There's a textfile explaining stuff, a ini file for remembering settings + AngleRates and it will create a logfile (in automatic mode)
Have fun,
Marius
[attachment deleted by admin]
-
Thanks Marius.......Exactly what I needed!
;D
-
oooopppsss.....
Been using the Reschedule 1.3 version with no changes to it's configuration file. Noted two of these go through this moring despite Reschedule running each moring at 3:00am.
VLAR WU (AR: 0.009063 )detected... autokill initialised
SETI@home error -6 Bad workunit header
Guess it's not working.
-
...despite Reschedule running each moring at 3:00am....
Which is why I run every hour, since fresh task downloads with closer deadline can preempt tasks in cache and slip through the net. Could still happen even then, but the probability is lower.
-
Understood Jason but nothing was prempted. With a two day cache everything works it's way to the top.
-
Ahhh, I see how that could happen, yes.
...thinking...
[Ignoring DCF fluctuation & outage induced cache shrinkage effects] Let's say one day you run, and server had recently issued you a run of VLAR, so it re-marks half the 2 day cache (1 day worth) to CPU. Now it downloads another day's worth for GPU. Even if no new tasks preempt, you'll still be finished the already checked portion by the end of that day, before the next run of the rebranding, so for all we know the top-up portion that is now reached is loaded with VLARs that slip the net anyway.
-
I'll try scheduling it for twice each day but I still don't believe it's working properly with the default configuration.
-
quite possible, despite my comments. I'm still using 1.2, so effectiveness of 1.3 edition itself I don't know either.
-
quite possible, despite my comments. I'm still using 1.2, so effectiveness of 1.3 edition itself I don't know either.
I will look at it first thing when i get home monday. Personally i haven seen any vlar in over two weeks so it was hard to test.
Greetings,
Marius
-
Maybe it works, but the server send wrong wu...
http://setiathome.berkeley.edu/forum_thread.php?id=54154
-
I will look at it first thing when i get home monday. Personally i haven seen any vlar in over two weeks so it was hard to test.
Finally a couple of vlar's, and there were a couple of problems in the Reschedule 1.3. Most minor but 1 major: It refused to move units to the cpu or do a proper reschedule. All should be solved with the 1.4 though.
Greetings,
Marius
[edit]: attachment removed.
-
Something seriously wrong with this...
81 81 turns into 6 6
388 6 462 81
run again
6 6 turns into 81 81
463 81 387 6
Notice the number of WUs change 462->463 ... and 388 -> 387
Edit: I wanted to move every non V* wu to GPU, so the slider was at 100% and the onlyVlar option was off.
-
Something seriously wrong with this...
Indeed, i must check all possibilties (or don't do any programming when i'm just out of hospital ::))
[attachment deleted by admin]
-
Thanks Marius, I'm sure this will be much better. Get some rest, hope you feel better soon.
:D
-
I hope that hospital thing was nothing serious and you get better soon.
1.5 still can't count: :o
141 139 into 137 137
380 0 377 0
onlyvlar off and 100% to GPU
-
I hope that hospital thing was nothing serious and you get better soon.
1.5 still can't count: :o
Nope, hospital was just regulary maintenance ;)
The difference is probably caused because of finished units waiting to report. The left side still reports those, the right does not. I will filter those out in a next release so that will look neat as well. You could check those by looking at the units and sort on the last column, ready units have a "4"
Greetings,
Marius
-
Using the following settings in the config file......
[Settings]
Position=75
OnlyVLarVHar=1
TrueAngleRate=1
[Automatic]
Automatic=0
Interval=24
CPUPerInterval=50
GPUPerInterval=150
[WorkUnits]
I have many CUDA work units showing computation error. Been unable to upload and report any in a few days but this looks like the rebranding is not working still.
-
I have many CUDA work units showing computation error. Been unable to upload and report any in a few days but this looks like the rebranding is not working still.
I cant do much with this info, what version do you use? Version 1.5 is the latest.
The tool is not on automatic so you yourself have to push the buttons.
I think you know seti is basicly almost down for the last 4 day's
-
I am using 1.5 version. I start the program using a scheduled task once a day. The scheduled task points to a batch file that stops the boinc service, runs rescheduler then restarts the boinc service.
Are you saying that I need to have the option for "Automatic" also set to 1?
Also some have reported now and they were auto killed by the CUDA app.
-
I am using 1.5 version. I start the program using a scheduled task once a day. The scheduled task points to a batch file that stops the boinc service, runs rescheduler then restarts the boinc service.
Batchfile will work just great, but you don't really need it as the tool can schedule itself these days. For the moment i think its best if you start the tool and turn on the automatic checkbox in the second tabsheet. Let it reschedule every 2 hours or so.
When running in automtic it will create a logile witch you can check if it runs properly. Normally you would see somethng like:
Time: 16-06-2009 10:52:52
No reschedule needed
CPU tasks: 790 (272 VLAR/VHAR)
GPU tasks: 122 (0 VLAR/VHAR)
---------------------------
Time: 16-06-2009 11:52:52
VLAR/VHAR within period
CPU tasks: 781 (263 VLAR/VHAR)
GPU tasks: 131 (4 VLAR/VHAR)
After reschedule:
CPU tasks: 782 (264 VLAR/VHAR)
GPU tasks: 126 (0 VLAR/VHAR)
---------------------------
Time: 16-06-2009 12:52:52
VLAR/VHAR within period
CPU tasks: 774 (258 VLAR/VHAR)
GPU tasks: 131 (4 VLAR/VHAR)
After reschedule:
CPU tasks: 777 (261 VLAR/VHAR)
GPU tasks: 127 (0 VLAR/VHAR)
---------------------------
Time: 16-06-2009 13:52:52
No reschedule needed
CPU tasks: 777 (261 VLAR/VHAR)
GPU tasks: 127 (0 VLAR/VHAR)
---------------------------
Time: 16-06-2009 14:52:52
No reschedule needed
CPU tasks: 777 (261 VLAR/VHAR)
GPU tasks: 127 (0 VLAR/VHAR)
Greetings,
Marius
-
Thanks Marius.
I have disabled the scheduled task and started Rescheduler as you suggested. Minimized to the task bar and left it running.
Sorry if my 62 year old brain was too slow to comprehend the instructions given previously. Proper apology offered..............
-
I have disabled the scheduled task and started Rescheduler as you suggested. Minimized to the task bar and left it running.
Running from batch should also work perfectly, but this is the only way to get a log file and get a reason why it doesn't reschedule. Anywhay, let us know how it turns out.
Greetings,
Marius
-
Marius................
After two hours elapsed I could find no sign that the Reschedular actually had run on any of my 4 computers. In fact one of my computers had run out of CUDA and was crunching only on the CPU's. I waited another 15 minutes or so and ran the Reschedular manualy on the cache but nothing was changed into CUDA. I made the following changes.
[Settings]
Position=50
OnlyVLarVHar=0
TrueAngleRate=0
[Automatic]
Automatic=1
Interval=2
CPUPerInterval=50
GPUPerInterval=150
[WorkUnits]
And then half were transposed into CUDA work and the GPU started crunching again. I believe a Position of 50 should be fine for my computers. In one hour the CPU's will crunch 4 and CUDA will crunch 4. So I don't know which change got it working. OnlyVlarVHar and TrueAngleRate were both changed from 1 to 0.
I then put a shortcut to Reschedular into my startup group, to start minimized. This ok?
-
After two hours elapsed I could find no sign that the Reschedular actually had run on any of my 4 computers. In fact one of my computers had run out of CUDA and was crunching only on the CPU's.
That is weird, can you show me the ReSchedule.log please?
I then put a shortcut to Reschedular into my startup group, to start minimized. This ok?
Thats ok, it will now start automaticly and reschedule each 2 hours (if needed) if we can get it working.
-
That's what's weird.....can't find ReSchedule.log anywhere!
[edit]
and the configuration file now has a lot of workunits listed under [WorkUnits] title.
-
This time I got a log.......
---------------------------
Time: 18-06-2009 16:02:57
No reschedule needed
CPU tasks: 225 (173 VLAR/VHAR)
GPU tasks: 212 (0 VLAR/VHAR)
[edit] But with 126 work units to go only 2 are branded for CUDA so it should have done something cause I'll be empy on CUDA in less than 30 minutes again.
[another edit] manually running got me a few more CUDA but approximately the same number that have managed to upload the last two hours. It should have went 50-50. Is it possible it is also looking at the completed work that has not uploaded?
-
Yes, those amounts you mention also include the ready units. But after reporting the ready units are removed from memory and then the tool will decide if it want to reschedule or not.
Anywhay, even with a manual reschedule the maximum you can push to the gpu right now is 53 units (with current gpu speed's thats burned up in less then 8 hours) You suspect you got a pretty big amount of finished units (vlar amount is high also) so mayby there isn't anything usefull left to reschedule to the gpu. I need to inspect this more (and do some better logging) because with these numbers i'm unable to tell what the exact situation is or why it wont reschedule. I'll get back on that this weekend.
-
Ok, thanks. I'll keep pluging away. The way Berkeley is going the project may be totally down before long.
-
A little update with a few simplifications. I extended the logfile, removed a couple of buttons (it wil automaticly stop and start boinc service now), ready units are left out of the display and the presence of a single vlar will always trigger a reschedule.
Seems the berkeley servers are back online and i got a truckload of units from the server yesterday (almost 1200 units in queue now) but i haven't received a single vlar yet :o
Enjoy,
Marius
[attachment deleted by admin]
-
Marius.....copy of the log after running.
---------------------------
Reschedule version 1.6
Time: 20-06-2009 09:26:45
User forced a reschedule
Stopping BOINC service
BOINC service is stopped
CPU tasks: 507 (62 VLAR/VHAR)
GPU tasks: 445 (3 VLAR/VHAR)
Starting BOINC service
BOINC service started
After reschedule:
CPU tasks: 510 (65 VLAR/VHAR)
GPU tasks: 442 (0 VLAR/VHAR)
Looks like it's working now. Thanks
-
And from a different computer.......
---------------------------
Reschedule version 1.6
Time: 20-06-2009 09:36:41
User forced a reschedule
Stopping BOINC service
BOINC service is stopped
CPU tasks: 471 (99 VLAR/VHAR)
GPU tasks: 380 (32 VLAR/VHAR)
Starting BOINC service
BOINC service started
After reschedule:
CPU tasks: 503 (131 VLAR/VHAR)
GPU tasks: 348 (0 VLAR/VHAR)
Thanks again!! ;D
-
Marius
I've downloaded your reschedule 1.6. It's a great little tool, thanks for making the exe. I'm running 64 bit xp and I know you've tested this out for 32 bit, but every time I click the "run" button i get an "Error:Range check error". If i do not have boinc running the tool works fine. It appears from the log file that it's having trouble stopping the boinc service in x64. Is there any way to fix/change this, or do you have any recommendations?
Thanks
Copy of the log:
Reschedule version 1.6
Time: 21-06-2009 10:51:48
User forced a reschedule
Stopping BOINC service
Unable to stop BOINC service
Error:Range check error
-
Same here...
I get the "Error:Range check error"-message, too. I am running Vista x64. When I stop Boinc manually the tool works fine. Log is identical to savac's log.
There is no difference when I start the tool with "run as administrator".
Calypso
-
Marius...........Question please.......... ::)
If I start program with the commmand ReSchedule.exe /Autorun 50 and the configuration file contains Position=75, which file ratio will be used? 50 or 75?
Thanks for the program, it works great!
;D
[edit] Never mind, i figured it out. If OnlyVLarVHar=1 then those are moved to the CPU and no others are moved.
;D
-
I'm running 64 bit xp and I know you've tested this out for 32 bit, but every time I click the "run" button i get an "Error:Range check error". If i do not have boinc running the tool works fine. It appears from the log file that it's having trouble stopping the boinc service in x64. Is there any way to fix/change this, or do you have any recommendations?
Thanks for reporting. I have indeed only tested on win32 and i have no experience with win64 (other then a couple of failing windows 7 installations). But i do have a winxp/64 installation under virtualbox so i will have a look later this week as soon as i have the time.
In te mean time that range error bothers me a lot, so i recompiled without rangechecking and included a crashlog mechanism (nothing else has changed in this new version). Could you or Calypso check if this solves youre problems? And if not could you please post the Reschedule.elf file which is created.
For the record, Vista and windows 7 should theoretically block or ignore any commands to start or stop any service, so i do think you need to run under admin rights.
Thanks,
Marius
[attachment deleted by admin]
-
Got: Error:Error stopping BOINC service with 1.7 - Windows 7 64bit
Tried with "Run as admin", same result
Attaching elf file
[attachment deleted by admin]
-
Hi Marius.
I tested version 1.7
Of course no "Range check error". I get "Error:Error stopping BOINC service" in both cases (running with or without admin rights).
I attached log and elf file. I ran the tool three times. At first without admin rights, then two times with admin rights.
When stopping Boinc manually, the tool works fine.
[attachment deleted by admin]
-
Ok, at least the weird range error is gone and i got the general picture about stopping the service. So thanks to you guys i'm 2 steps further.
Storyline: for some reason windows accept/ignores the commandline "net stop boinc" and just returns with code 0 (succes). The next action in the code is a simple check to see if boinc is really down (by locking the stdoutdae.txt file, one of the files boinc alway's opens). Because it cannot get this lock i assume boinc is still running and raise the error 'Unable to stop BOINC service'.
So the trick question is why does windows/64 allow "net stop boinc" but does not stop boinc. Is there any other valid windows 64 command to do this?
-
Ok, at least the weird range error is gone and i got the general picture about stopping the service. So thanks to you guys i'm 2 steps further.
Storyline: for some reason windows accept/ignores the commandline "net stop boinc" and just returns with code 0 (succes). The next action in the code is a simple check to see if boinc is really down (by locking the stdoutdae.txt file, one of the files boinc alway's opens). Because it cannot get this lock i assume boinc is still running and raise the error 'Unable to stop BOINC service'.
So the trick question is why does windows/64 allow "net stop boinc" but does not stop boinc. Is there any other valid windows 64 command to do this?
Seems like BOINC is not running in service mode as default any longer. Due to some problems with CUDA. So I get this error code when trying to stop BOINC:
C:\Users\Dag Morten>net stop boinc
The service name is invalid.
-
BOINC defaults to 'not service' on Vista and Win 7 because CUDA won't run as a service on those platforms.
Anybody running this tool will be wanting to run CUDA, so you can definitively assume that on Vista and Win 7, BOINC will NOT be running as a service.
Until nVidia works out how to do a CUDA service on Win 7.....
-
Ran Schedule 1.6 with a 50/50 split set in. Seems it took the 4 work units already in progress on the CPU's and rebranded them to CUDA and when Boinc restarted new work units were started. Leaving the newly created CUDA in paused mode. Didn't expect that! Would have been better to leave work already started alone.
-
I see im a bit late to respond, but here is the requested file. Hope it helps. 1.7 does return a boinc service error "Error:Error stopping BOINC service" so i'm running into the same thing with winxp 64.
[attachment deleted by admin]
-
BOINC defaults to 'not service' on Vista and Win 7 because CUDA won't run as a service on those platforms.
Anybody running this tool will be wanting to run CUDA, so you can definitively assume that on Vista and Win 7, BOINC will NOT be running as a service.
Until nVidia works out how to do a CUDA service on Win 7.....
Any idea what commands to use to shutdown and start boinc for the win64 platform? For example "boinccmd --quit", but how to restart it?. Or are there other alternatives?
Greetings,
Marius
-
Ran Schedule 1.6 with a 50/50 split set in. Seems it took the 4 work units already in progress on the CPU's and rebranded them to CUDA and when Boinc restarted new work units were started. Leaving the newly created CUDA in paused mode. Didn't expect that! Would have been better to leave work already started alone.
Yes this is the current behaviour and it indeed leads to a lot of slots. And it will take some time before the stopped units will be restarted again. This is one of the reasons i rather use only the OnlyVLar option (unless CPU/GPU is serious unbalanced or berkeley is down).
And you can take this a step further and workout (with for example a 50% reschedule) a better workload distribution based on current deadlines. For example pushing cpu units to gpu just to lighten the workload stress on cpu side or the other way around. This is something to look at after a proper repear of windowss 64 ;)
Greetings,
Marius
-
Ok, thanks Marius.
Will use the option to rebrand OnlyVLar from now on.
-
VLAR+VHAR rebranding could give better performance.
-
v1.7 and v1.5 doesnt work with x64
what is written from GPU to CPU:
windows_intelx86 to windows_intelx86
v1.3 works with x64
what is written from GPU to CPU:
windows_intelx86 to windows_x86_64
suggestion:
When it reads the client state file, platform should be placed into a variable.
CPU can be windows_intelx86 and windows_x86_64
GPU for now is only windows_intelx86
-
VLAR+VHAR rebranding could give better performance.
Yes it really does in the case of just vlar/vhar rebranding (but i guess people just hate to go to the trouble of installing the additional perl binaries)
Seems it took the 4 work units already in progress on the CPU's and rebranded them to CUDA and when Boinc restarted new work units were started. Leaving the newly created CUDA in paused mode.
I can detect those and can leave them alone if possible. It just needs additional parsing.
v1.7 and v1.5 doesnt work with x64
v1.3 works with x64
AFAIK none of them ever worked on x64 unless the boincmgr (and boinc.exe in the background) is stopped. This is because all versions (should) lock the stdoutdae.txt to make sure boinc isn't running and that changes in client_state.xml wont be corrupted.
I guess what you are suggesting is that i should also change the platform in the results sections while rescheduling because there can be a difference in cpu or gpu application? If thats the ccase thats not a problem. Could you send your client_state.xml so i can see how it looks like (please use winrar or winzip, or use pvt msg).
Greetings,
Marius
-
VLAR+VHAR rebranding could give better performance.
Yes it really does in the case of just vlar/vhar rebranding (but i guess people just hate to go to the trouble of installing the additional perl binaries)
I meant VLAR+VHAR rebranding with your binary will give better performance than just VLAR rebranding.
-
I meant VLAR+VHAR rebranding with your binary will give better performance than just VLAR rebranding.
Oh darn, totally missed the point. Yes you are totally right, and this is what i meant in the first place, the option is called OnlyVLarVHar (and not OnlyVLar like i mentioned to Geek@Play).
-
Marius......Is there a limit to the size of the log file or should it be removed manually, say once a month.
-
Marius......Is there a limit to the size of the log file or should it be removed manually, say once a month.
It has no limit (except for the partition or OS limitations) so it wont hurt to delete the file once in a while. Of cource it wont get that that big even while running once per hour ;)
-
I installed windows 7 x64 and boinc (and spend day's waiting on a 1 freaking workunit) and confirmed the "Error:Error stopping BOINC service". Because there is no decent way to stop boinc in win/64 i need to terminate the boincmgr.exe and run "boinccmd --quit" to stop boinc.exe.
I do not really like this but its the only solution to run the scheduler on win/64 without having to stop boinc manually. Does anybody see any problems in killing boincmgr and boinc or is this method asking for trouble?
Greetings,
Marius
-
Do you even need to close the Manager? I leave mine open while rebranding (if I'm interested), and just stop the daemon. Manager goes blank for a while, shows 'not connected to a client', then repopulates the tabs when boinc.exe is running again.
I think the correct restart command in this case would be
boinc --detach
to avoid getting a redundant command window (see http://boinc.berkeley.edu/wiki/Client_configuration#Command-line_options).
-
Do you even need to close the Manager? I leave mine open while rebranding (if I'm interested), and just stop the daemon. Manager goes blank for a while, shows 'not connected to a client', then repopulates the tabs when boinc.exe is running again.
I think the correct restart command in this case would be boinc --detach
I must admit i wasn't aware of that command and i had indeed trouble restarting the client, thats why i killed and restarted the manager (which in turn also starts the client).
The use of a "boinccmd --quit" and later on a "boinc -detach" does a much cleaner job then killing boincmgr and the same approach will work very niceley on win/64 (it even works for win/32 with service approach).
Thanks,
Marius
-
Be careful with this "detach" option. It has significal delay in execution that led to trashing modified client_state or even to worse situations.
Some pause required.
Maybe better way is to kill boinc.exe process (ungraceful exit, but fast and reliable one).
Need to note that science apps can continue to work after such kill ~30 seconds. Usually they exit much faster.
-
Surely you need the delay after the --quit ?
That's what you do before you edit client_state: how long it takes to start up again afterwards doesn't really matter? :-\
-
I talk not about restart time, I stress that boinc --quit option doesn't stop boinc deamon immediately.
This topic was discussed already on BOINC boards. Some watchdog loop needed to see if BOINC really stopped.
For what reason BOINC devs implemented this options in such way and why they don't provide true shutdown option - covered in darkness... (as most BOINC-related questions BTW ;) )
EDIT: as experimental fact I killed BOINC's client_state completely while experimenting with rebranding script w/o "pause" in bat-file stopping BOINc....
-
...
For what reason BOINC devs implemented this options in such way and why they don't provide true shutdown option - covered in darkness... (as most BOINC-related questions BTW ;) )
...
Not such a mystery if you think about the opposite case, whereby Boincapi kills science applications without prejudice. :-X
-
...
For what reason BOINC devs implemented this options in such way and why they don't provide true shutdown option - covered in darkness... (as most BOINC-related questions BTW ;) )
...
Not such a mystery if you think about the opposite case, whereby Boincapi kills science applications without prejudice. :-X
Well, it kills science app ungracefully pretty often but doesn't allow to do this with itself... not very nice behavior ;)
EDIT: actually, the question doesn't in this area.
I have no objections to wait a little before BOINC will cloase all apps and itself. I have BIG OBJECTION for fact that boinc --quit returns IMMEDIATELY while BOINC still not stopped! This is a "root of evil"
-
Well, it kills science app ungracefully pretty often but doesn't allow to do this with itself... not very nice behavior ;)
Exactly. It's just like the science app has a wife:
" Do this"
"Don't Do that"
"You don't own me!"
"Give me your Credit Card, I'm Going Shopping"
Personally, I'm waiting on Richard's Boinc-Lite edition, which apparently comes with its own gag.
-
...
EDIT: actually, the question doesn't in this area.
I have no objections to wait a little before BOINC will cloase all apps and itself. I have BIG OBJECTION for fact that boinc --quit returns IMMEDIATELY while BOINC still not stopped! This is a "root of evil" ...
Oh... that's the programmatic equivalent of "Yes Dear."
-
;D ;D ;D
-
Oh... that's the programmatic equivalent of "Yes Dear."
ROTFL, oh dear ;)
Doesn't hurt to see if boinc.exe has really closed down i guess ;D
-
A new version of the rescheduler which now also works on the win/64 platform. If you are running this platform *please* make a backup copy first just in case it is not working as expected. Also there are additional settings so please check the configuration (via the tabsheets) as it needs your boinc bin and data path.
Greetings,
Marius
-Running units are now excluded from the rescheduling (better because the
slot info wasn't changed). Because of the changed deadlines it is still
possible that boinc starts other tasks while the previous running tasks
are marked as waiting.
-The platform is now also changed while rescheduling (sorry about any
inconvenience if this has caused problems)
-Because of changed locking there are two new settings for binaries and
datapath. (There is no need to copy reschedule to the datapath anymore)
-If boinc is not installed as a service it will do a "boinccmd.exe --quit"
and after the reschedule a "boinc.exe -detach". This should solve the
problems on any system where boinc is not installed as a service (win/64).
-Changed the locking scheme (it is no longer locking the stderrdae.txt to
test if boinc is running).
-Solved some problems in the test algorithm for the automatic reschedule.
[attachment deleted by admin]
-
-If boinc is not installed as a service it will do a "boinccmd.exe --quit"
and after the reschedule a "boinc.exe -detach". This should solve the
problems on any system where boinc is not installed as a service (win/64).
Expect client_state.xml corruption here... (due to BOINC --quit option behavior).
-
-If boinc is not installed as a service it will do a "boinccmd.exe --quit"
and after the reschedule a "boinc.exe -detach". This should solve the
problems on any system where boinc is not installed as a service (win/64).
Expect client_state.xml corruption here... (due to BOINC --quit option behavior).
No, the command is "boinccmd.exe --quit" not "boinc.exe -quit" or are we talking about the same? Have you experienced this before and what are the circumstances that happened?
if you refer to boinc.exe not exiting immediately, i have that covered by checking if the process has exited. Has been running well for the last couple of days.
Greetings,
Marius
-
if you refer to boinc.exe not exiting immediately, i have that covered by checking if the process has exited. Has been running well for the last couple of days.
Fine, if you do additional check all should be OK then.
Yes, I meant that boinc doesn't exit immediately and boinccmd --quit returns before boinc.exe will finish.
-
Please forgive me if I'm being dense. I'm an engineer, not a programmer, but I can (usually) figure things out ;) I have been using the various Marius versions (currently 1.8 ), but I have noticed an interesting (to me) thing.
I normally run Marius in the "find VLAR/VHAR" mode. In the last day that was almost all of them...sigh. Because a 100 of these puppies waiting for the CPU was a bit excessive, I went for the 75% to GPU option (as an experiment) without the VLAR/VHAR option (but after running VLAR/VHAR).
I got the requested mix, but Marius 1.8 didn't show the change (bug, or perhaps something no one would want?). BOINC showed the change after starting. I manually stop and start BONIC because I don't trust the script (sorry). Anyway, most of the changed VLAR/VHAR (back to the GPU) tasks (previously tagged as CPU) ran fine within normal (wall clock) times.
Three died in Varkill. I can't help but wonder why the others didn't. OK, I understand that Marius has different parameters. Perhaps they are too strict or am I missing something?
My computer is a Q6600 with 8600GTS video card running on Vista.
No big deal, but I kind of wonder why I can process tasks on the GPU that Marius says are poison :)
-
Three died in Varkill. I can't help but wonder why the others didn't. OK, I understand that Marius has different parameters. Perhaps they are too strict or am I missing something?
No big deal, but I kind of wonder why I can process tasks on the GPU that Marius says are poison :)
Other didn't just because they were VHARs, not VLARs.
[
VHAR not so slow as VLAR, it just not as efficient on GPU as midrange AR tasks are. So no reason to "kill"them, but if there is a possibility to send them on CPU - why not ;)
Consider this as further performance optimization
]
-
Please forgive me if I'm being dense. I'm an engineer, not a programmer
;) I'm a programmer in real live, not a astronomer or engineer and seti is just one of my many bad habits..
I got the requested mix, but Marius 1.8 didn't show the change (bug, or perhaps something no one would want?).
If you show the interesting part of your log we can figure out exactly what happened. The tool always pushes V*AR to the CPU just like Raistmer scripts does (bit depending if you checked the True Angle Rate) and additionally it tries to make the proper distribution which is not always possible if you have many V*AR.
Three died in Varkill. I can't help but wonder why the others didn't. OK, I understand that Marius has different parameters. Perhaps they are too strict or am I missing something?
My computer is a Q6600 with 8600GTS video card running on Vista.
No big deal, but I kind of wonder why I can process tasks on the GPU that Marius says are poison :)
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).
Greetings,
Marius
-
OK, I'm kind of getting the idea . VHAR tasks aren't necessarily bad, but send them to the CPU anyway. Perhaps a bit wasteful (in my case). I would prefer to do whatever the GPU can do (at least somewhat efficiently) on the GPU (or at least a choice).
I changed the parameters on the Reschedule after I looked for VLAR/VHAR stuff. I ran it looking for VLHR/VHAR first. Then I ran 75% GPU. I got a bunch more GPU tasks. I'm using CPU tasks to keep the STD down. I'd really like to just run GPU stuff.
I don't discriminate between programmers and engineers. We're both good people even if you people are a bit strange ;D What part of the log is interesting? I'm in the weekly Tuesday SETI hold right now so I've got everything.
Like I said, it's no big deal. I'll make it work or I'll throw up my arms and declare that all the world is against me ;D Actually not, I'm here for the duration !
Rick
-
Thanks for the update Marius. ;D
-
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 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
-
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 ;)
-
Thanks guys. I typically run the reschedule with VLAR/VHAR to CPU. Being an engineer who can't keep his hands off of things ;D , 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.
-
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
-
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 (http://setiathome.berkeley.edu/apps.php) 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.
-
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]
-
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 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. 8)
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
-
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
-
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 %.
-
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
-
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.
-
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
-
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
-
I have been trying to get v1.8 working on a Vista64 machine - not running as a service because I run CUDA (WinXP64 as a service works OK).
According to the registry my directories are :-
PROG C:\Program Files\BOINC
DATA C:\ProgramData\BOINC
Initiallly I had a problem because the DATA directory was hidden so Reschedule couldn't see it.
Having sorted that out it seemed to be working OK except it shows I have zero CPU or GPU tasks when I press test.
If I rename the client_state.xml I see "Error : C:\Programdata\BOINC\cleint_state.xml doers not exist" so it is looking in the right place.
Is there a reason why it would read the client_state.xml but not find any tasks?
I have searched for posts about Vista64 but not come across many.
-
Link to the host please,
Claggy
-
After running V1.8 my config file shows 2 paths are required.
[Settings]
Position=75
OnlyVLarVHar=1
TrueAngleRate=0
DataPath=D:\BOINC\
BoincBinPath=C:\Program Files\BOINC\
[Automatic]
Automatic=0
Interval=4
CPUPerInterval=50
GPUPerInterval=150
-
I have been trying to get v1.8 working on a Vista64 machine - not running as a service because I run CUDA (WinXP64 as a service works OK).
According to the registry my directories are :-
PROG C:\Program Files\BOINC
DATA C:\ProgramData\BOINC
Initiallly I had a problem because the DATA directory was hidden so Reschedule couldn't see it.
Having sorted that out it seemed to be working OK except it shows I have zero CPU or GPU tasks when I press test.
If I rename the client_state.xml I see "Error : C:\Programdata\BOINC\cleint_state.xml doers not exist" so it is looking in the right place.
Is there a reason why it would read the client_state.xml but not find any tasks?
I have searched for posts about Vista64 but not come across many.
Host is :-Vista64 (http://setiathome.berkeley.edu/show_host_detail.php?hostid=3565695)
Ini settings are
[Settings]
Position=75
OnlyVLarVHar=0
TrueAngleRate=1
DataPath=C:\ProgramData\BOINC
BoincBinPath=C:\Program Files\BOINC
[Automatic]
Automatic=0
Interval=4
CPUPerInterval=50
GPUPerInterval=150
Log says :
---------------------------
Reschedule version 1.8
Time: 05-07-2009 00:03:11
User testing for a reschedule
CPU tasks: 0 (0 VLAR/VHAR)
GPU tasks: 0 (0 VLAR/VHAR)
No reschedule needed
I haven't tried any previous versions on this machine either.
-
Log says :
CPU tasks: 0 (0 VLAR/VHAR)
GPU tasks: 0 (0 VLAR/VHAR)
Weird, AFAIK the tool works on 64 bit and i have not heard problems with it. According to the pending tasks you are running version 603 and 608 which should have been counted fine by the tool. Very curious what this problem could be though.
It almost looks like the tool is thinkng you are running other units then 603 or 608 (which aint the problem). Could you send me your "C:\ProgramData\BOINC\client_state.xml" via personal mail (please zip)
I never gonna thrust VISTA this way ;)
Greetings,
Marius
-
Could it be trying to reschedule an abandoned Boinc installation?
-
Thanks for a nice utility, Marius!
One issue with v1.8 and it could well be isolated to my Vista64 installation. The first time I ran it (only V*AR), I stopped BOINC myself to make a backup and it ran fine, moving 21 V*ARs to CPU. I restarted BOINC and three CPU MBs started along with the CUDA and an Einstein unit without a problem.
Having managed to download a few more tasks, I suspended computation (I prefer doing this even if it's not necessary), hit Run and BOINC was stopped, 37 tasks moved and BOINC restarted. Great, I thought. Upon resuming computation however, two VLARs that had earlier been moved to the CPU (AK_v8_win_x64_SSE41) exited with 'SETI@home error -1 Can't create file -- disk full?' The CUDA task and two Einstein tasks restarted fine.
There's no problem with disk space, BOINC is using ~500MB of its allocated 10GB and the partition has more than 100GB free.
For a while, I've had to start BOINC with elevated privileges, otherwise the manager just can't start boinc.exe. I'll try and reduce the upload queue to download some new tasks. Then run your program as administrator to see if that fixes it.
The host is #4719981 (http://setiathome.berkeley.edu/show_host_detail.php?hostid=4719981) and the errors were tasks #1289669959 (http://setiathome.berkeley.edu/result.php?resultid=1289669959) and #1289669920 (http://setiathome.berkeley.edu/result.php?resultid=1289669920)
-
@Marius
BTW, how your tool will handle systems with SETI +SETI beta installations?
Can it be used in such situation? will it rebrand beta tasks?
-
Having managed to download a few more tasks, I suspended computation (I prefer doing this even if it's not necessary), hit Run and BOINC was stopped, 37 tasks moved and BOINC restarted. Great, I thought. Upon resuming computation however, two VLARs that had earlier been moved to the CPU (AK_v8_win_x64_SSE41) exited with 'SETI@home error -1 Can't create file -- disk full?' The CUDA task and two Einstein tasks restarted fine.
There's no problem with disk space, BOINC is using ~500MB of its allocated 10GB and the partition has more than 100GB free.
The host is #4719981 (http://setiathome.berkeley.edu/show_host_detail.php?hostid=4719981) and the errors were tasks #1289669959 (http://setiathome.berkeley.edu/result.php?resultid=1289669959) and #1289669920 (http://setiathome.berkeley.edu/result.php?resultid=1289669920)
There was a bug fix in 6.6.31 for output file errors, which might have something to do with this. Your errors indicate you have 6.6.28 running. Current release version of BOINC is 6.6.36.
-
Having managed to download a few more tasks, I suspended computation (I prefer doing this even if it's not necessary), hit Run and BOINC was stopped, 37 tasks moved and BOINC restarted. Great, I thought. Upon resuming computation however, two VLARs that had earlier been moved to the CPU (AK_v8_win_x64_SSE41) exited with 'SETI@home error -1 Can't create file -- disk full?' The CUDA task and two Einstein tasks restarted fine.
There's no problem with disk space, BOINC is using ~500MB of its allocated 10GB and the partition has more than 100GB free.
The host is #4719981 (http://setiathome.berkeley.edu/show_host_detail.php?hostid=4719981) and the errors were tasks #1289669959 (http://setiathome.berkeley.edu/result.php?resultid=1289669959) and #1289669920 (http://setiathome.berkeley.edu/result.php?resultid=1289669920)
There was a bug fix in 6.6.31 for output file errors, which might have something to do with this. Your errors indicate you have 6.6.28 running. Current release version of BOINC is 6.6.36.
Umm... Refrained from installing 6.6.36 due to the bad press on Seti fora and the 'do not fix if it works' policy. 6.6.28 had worked perfectly. Will try .36 if other methods fail.
Thanks.
-
Having managed to download a few more tasks, I suspended computation (I prefer doing this even if it's not necessary), hit Run and BOINC was stopped, 37 tasks moved and BOINC restarted. Great, I thought. Upon resuming computation however, two VLARs that had earlier been moved to the CPU (AK_v8_win_x64_SSE41) exited with 'SETI@home error -1 Can't create file -- disk full?' The CUDA task and two Einstein tasks restarted fine.
The tool only makes some minor changes in the client_state.xml and does nothing with the applications itself. I googled a bit, but this error "disk full" seems to occur only in combination with very old versions of boinc, but since you run a rather recent version i dont expect that to be the case.
The only thing that is kind of suspicious to me is that you suspend boinc while running the tool. In the basic configuration boinc leaves the applications in memory confronting those with unexpected changes in the client_state.xml. Advise is to stop boinc completely and not suspend it. But i don't think this will cause the disk-full errors though....
Greetings,
Marius
-
@Marius
BTW, how your tool will handle systems with SETI +SETI beta installations?
Can it be used in such situation? will it rebrand beta tasks?
1.8 and lower only do hardcoded 603 and 608 versions.
Richard mentioned about the same for future versions a few messages back. So i made changes to (not released) 1.9 to avoid using hardcoded versions. That one will parse all <app_version> filter those on app_name=setiathome_enhanced, split on plan_class=cuda and use the highest version_num as the default application for cpu and/or gpu. Would this approach work for the beta version as well?
I guess this will not work if you run the combination of seti + beta (not sure this combination is possible though)
-
Could it be trying to reschedule an abandoned Boinc installation?
Unlikely unless he pointed the data directory to a location with an empty client_state. But since the host is running fine i dont think this is the case.
I need to install a vista version this week anywhay so i will use that to test (if i ever get some workunits though :o)
-
I guess this will not work if you run the combination of seti + beta (not sure this combination is possible though)
Such combination possible. SETI and SETI beta are different projects but both use SETI_enhanced tag for SETI MB. The problem is - their tasks reside in different directories (cause they belong to different projects).
So, from client_state workunit record point of view they are almost the same but fi you will need to parse WU itself you should look in another directory for that.
For now beta uses that same 603 and 608 app versions so its MB tasks almost indistinguishable from SETI main ones
-
Such combination possible. SETI and SETI beta are different projects but both use SETI_enhanced tag for SETI MB. The problem is - their tasks reside in different directories (cause they belong to different projects).
So, from client_state workunit record point of view they are almost the same but fi you will need to parse WU itself you should look in another directory for that.
For now beta uses that same 603 and 608 app versions so its MB tasks almost indistinguishable from SETI main ones
Then it sureley wont work because of three problems
1) The tool would need two running instances (because of different data directory), but because of a mutex it will not allow that (just to make sure people don't have 2 or more running instances).
2) It is currently hardcoded on the seti project ...\setiathome.berkeley.edu path. I need to configure project(s) and parse the projects as well to make this work.
3) It currently picks up al workunits for version 603 and 608 (without checking project, kind of a big bug on my side here). Running seti + beta in the same boinc setup would corrupt your client_state as it does not check projects.
But since seti beta is basicly the same i could make this work, but is it wurth the trouble? (its totally designed for a single project now)
-
Marius.........This morning found 2 of my host computers had run out of CUDA work. CPU's had lot's of work. I am incommunicado with Berkeley due to bandwidth maxed out at Berkeley. I set the config file as follows.
[Settings]
Position=50
OnlyVLarVHar=0
TrueAngleRate=1
DataPath=D:\BOINC\
BoincBinPath=C:\Program Files\BOINC\
[Automatic]
Automatic=0
Interval=4
CPUPerInterval=50
GPUPerInterval=150
After running ReSchedule I observed several work units were aborted by the AutoKill function of V11 CUDA app. Is it possible that in the reassignment of work from CPU's to CUDA that some VLARVHAR work was moved but should not have been?
[edit]
Actually more than several. 20 spread out on 4 computers.
-
The only thing that is kind of suspicious to me is that you suspend boinc while running the tool. In the basic configuration boinc leaves the applications in memory confronting those with unexpected changes in the client_state.xml. Advise is to stop boinc completely and not suspend it. But i don't think this will cause the disk-full errors though....
But surely your program stops BOINC first thus removing the (suspended) apps from memory. I certainly saw the manager window empty of tasks.
The client's managed to download some new units, I'll try different approaches after Federer and Roddick have finished.
-
Marius.........This morning found 2 of my host computers had run out of CUDA work. CPU's had lot's of work. I am incommunicado with Berkeley due to bandwidth maxed out at Berkeley. I set the config file as follows.
[Settings]
...
TrueAngleRate=1
...
After running ReSchedule I observed several work units were aborted by the AutoKill function of V11 CUDA app. Is it possible that in the reassignment of work from CPU's to CUDA that some VLARVHAR work was moved but should not have been?
Please uncheck the TrueAngleRate checkbox and do another reschedule. I think you will notice an akward rise in the V*AR unts.
With TrueAngleRate checked it is using a different VLAR/VHAR detection method (see reschedule.txt file). Some of those could be aborted by vlarkill. I will remove that detection method in 1.9 as this is causing to much problems with vlarkill
Greetings,
Marius
-
But surely your program stops BOINC first thus removing the (suspended) apps from memory. I certainly saw the manager window empty of tasks.
You are absolutely right, my mistake ;)
-
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 %.
The i7 I referred to in Boinc_alpha (still has about 10 tasks waiting), says the Seti DCF is 3.18. I did calculate the flops for the app_info but its always possible that I got them wrong. :o
There are a bunch of 608's that have completed with 4 hour elapsed times, quite likely because they were V*AR and didn't get changed over before starting. These have probably skewed the DCF value.
I only keep a 1 day cache so its possible to flush it and reset debts/dcf and recalc flops for the app_info. I was kinda hoping the optimized AP 505 would be available then I could do the app_info and check the other values at the same time.
-
This config...........
[Settings]
Position=50
OnlyVLarVHar=0
TrueAngleRate=0
DataPath=D:\BOINC\
BoincBinPath=C:\Program Files\BOINC\
[Automatic]
Automatic=0
Interval=4
CPUPerInterval=50
GPUPerInterval=150
Resulted with this.........
---------------------------
Reschedule version 1.8
Time: 05-07-2009 09:22:59
User forcing a reschedule
Stopping BOINC service
BOINC service is stopped
CPU tasks: 255 (255 VLAR/VHAR)
GPU tasks: 230 (215 VLAR/VHAR)
Boinc applications
setiathome_enhanced 603 windows_intelx86
setiathome_enhanced 608 windows_intelx86 cuda
After reschedule:
CPU tasks: 470 (470 VLAR/VHAR)
GPU tasks: 15 (0 VLAR/VHAR)
Starting BOINC service
BOINC service started
and I'm trying to get a 50-50 split on the work units.
All this is run from a batch file with this commmand.........
ReSchedule.exe /Autorun 50
-
CPU tasks: 470 (470 VLAR/VHAR)
GPU tasks: 15 (0 VLAR/VHAR)
Starting BOINC service
BOINC service started
and I'm trying to get a 50-50 split on the work units.
All this is run from a batch file with this commmand.........
Yes, didn't i tell you you would see an akward rise in V*AR :o. V*AR are always forced on the cpu no matter what happends to avoid vlarkill, then as a bonus it tries to confirm to the 50% rule but it cannot do this unfortunately.
Compare your's with mine. i have over 1k of f<beep> V*AR! (9 day's queue)
CPU tasks: 1035 (1035 VLAR/VHAR)
GPU tasks: 942 (0 VLAR/VHAR)
The numbers of V*ar are so bad lately i just reschedule with 100% to gpu.
-
OK.....thanks for the explanation.
-
OK.....thanks for the explanation.
If you reschedule 100% to GPU does that not leave the CPU's cold??
Yes, normally it would, but with the current overflow of VLAR/VHAR units i push every unit to cuda that becomes available (and isn't v*ar), this keeps my cuda going for the moment.
-
Yes, didn't i tell you you would see an akward rise in V*AR :o. V*AR are always forced on the cpu no matter what happends to avoid vlarkill, then as a bonus it tries to confirm to the 50% rule but it cannot do this unfortunately.
Suggestions for future versions:
Perhaps only VLAR should be forced to CPU. Allow VHAR to go either way, default to CPU however. Maybe the test function could show the task counts by AR group (VLAR/VHAR/other) before and after with current settings.
Thanks again for your work.
-
Am I the only one having trouble downloading this?
Can't get 1.7 or 1.8..says IE can't d/l from site...
Any other link to it available?
-
Suggestions for future versions:
Perhaps only VLAR should be forced to CPU. Allow VHAR to go either way, default to CPU however. Maybe the test function could show the task counts by AR group (VLAR/VHAR/other) before and after with current settings.
Internally i know exactly those groups, but if you are using Raistmer's MB_6.08_mod_CUDA_V11_VLARKill_refined.exe al vhar's will be automaticly killed AFAIK (true angle rate > 1.127), so i assume you are running a different tool what can handle a VHAR?
Or i'm i wrong here? (i use Raistmer's tool for several years now and don't even know what the original tools are any more)
-
There's no actual need to rebrand VHAR. They run adequately on the GPU, and they don't cause any screen stuttering or other computer-use problems. Raistmer has just observed a slight efficiency gain (i.e. optimisation) by using the CPU instead of the GPU for VHAR, but it's not enough to lose any sleep over. In any case, much of the efficiency gain is lost on Quads and above when there are lots of VHAR about, because they suffer from memory bus contention.
VLAR are different entirely. Their efficiency on GPU is abysmal, and the general screen delay makes the rest of the computer unusable - it's driven away many potential crunchers. Anything you can do to keep them off the GPU is a big step forward - but I prefer rebranding to killing.
-
Suggestions for future versions:
Perhaps only VLAR should be forced to CPU. Allow VHAR to go either way, default to CPU however. Maybe the test function could show the task counts by AR group (VLAR/VHAR/other) before and after with current settings.
Internally i know exactly those groups, but if you are using Raistmer's MB_6.08_mod_CUDA_V11_VLARKill_refined.exe al vhar's will be automaticly killed AFAIK (true angle rate > 1.127), so i assume you are running a different tool what can handle a VHAR?
Or i'm i wrong here? (i use Raistmer's tool for several years now and don't even know what the original tools are any more)
No no no, VHAR runs fine with all Raistmer's apps. Only VLARs are killed (by apps so named). Discussion here (http://lunatics.kwsn.net/12-gpu-crunching/gpu-cpu-pefrmance-dependence-from-ar-value.0.html)
Edit - Richard beat me to it
-
There's no actual need to rebrand VHAR. They run adequately on the GPU, and they don't cause any screen stuttering or other computer-use problems. Raistmer has just observed a slight efficiency gain (i.e. optimisation) by using the CPU instead of the GPU for VHAR, but it's not enough to lose any sleep over. In any case, much of the efficiency gain is lost on Quads and above when there are lots of VHAR about, because they suffer from memory bus contention.
VLAR are different entirely. Their efficiency on GPU is abysmal, and the general screen delay makes the rest of the computer unusable - it's driven away many potential crunchers. Anything you can do to keep them off the GPU is a big step forward - but I prefer rebranding to killing.
Thanks for clearing this up, this could/will save lots of rebranding compared to the current version. And thank you samuel7 for reminding me about it! (so logical when you hear it afterwards :()
-
But since seti beta is basicly the same i could make this work, but is it wurth the trouble? (its totally designed for a single project now)
Not sure that there are many who needs rebranding for beta project (though I needed that for some time, but not too often). The real problem is: peoples who participate in both projects will be unable to use your program on SETI main too, where it is very needed.
-
Log says :
CPU tasks: 0 (0 VLAR/VHAR)
GPU tasks: 0 (0 VLAR/VHAR)
I investigated the client_state.xml you send me and the xml is corrupt causing my xml parser (and also IE8 parser) to truncate large parts of the xml.
IE8 report the following error: End tag 'iax_nbytes' does not match the start tag 'max_nbytes'.
<max_nbytes>65536</iax_nbytes>
Simply fixing that will solve this problem.
Greetings,
Marius
-
Not sure that there are many who needs rebranding for beta project (though I needed that for some time, but not too often). The real problem is: peoples who participate in both projects will be unable to use your program on SETI main too, where it is very needed.
I agree a lot, beta not working isn't the worst thing what can happen, but it should certainly not conflict with main. I'm studying on this as we speak (together with a couple of other items which came up today).
Do you have a project url of seti beta? (or other url for additional info)
Greetings,
Marius
-
Sure.
<master_url>http://setiweb.ssl.berkeley.edu/beta/</master_url>
\projects\setiweb.ssl.berkeley.edu_beta\
-
But since seti beta is basicly the same i could make this work, but is it wurth the trouble? (its totally designed for a single project now)
Not sure that there are many who needs rebranding for beta project (though I needed that for some time, but not too often). The real problem is: peoples who participate in both projects will be unable to use your program on SETI main too, where it is very needed.
Of the 3637 hosts active at Beta, 2741 are also active on SETI main (derived from http://boinc.netsoft-online.com/e107_plugins/boinc/get_cpcs.php ).
Obviously the rebranding should either handle both cleanly, or be recoded to not affect Beta. The problem is that client_state.xml is only similar to real XML and the parts which apply to different projects are only separated positionally rather than being isolated properly by tags.
Joe
-
Thanks for clearing this up, this could/will save lots of rebranding compared to the current version. And thank you samuel7 for reminding me about it! (so logical when you hear it afterwards :()
You're welcome!
My cuda queue is 80% VHAR, so won't run your program now. Waiting for v1.9 with VLARonly... ;)
-
Obviously the rebranding should either handle both cleanly, or be recoded to not affect Beta. The problem is that client_state.xml is only similar to real XML and the parts which apply to different projects are only separated positionally rather than being isolated properly by tags.
LOL, the current xml is indeed kind of a clumbsy approach and i believe they are very well aware of it and are going to change it (over time). Sofar not much harm, it just needs some work on my side ;)
-
Am I the only one having trouble downloading this?
Can't get 1.7 or 1.8..says IE can't d/l from site...
Any other link to it available?
I downloaded ReSchedule 1.8 about 6 hours ago and just did so again 3 minutes ago, just to make sure. Using Firefox 3.5 under Vista x64.
Unfortunately, currently I have no SETI work units to try out ReSchedule. :(
-
There's no actual need to rebrand VHAR. They run adequately on the GPU, and they don't cause any screen stuttering or other computer-use problems.
Ah ha (light bulb goes on)! I think this answers my question from a few days ago. VHAR doesn't error out with VLARKill 11, it just runs slightly (unnoticeably to a human?) slower. This could explain why moving VLAR/VHAR to the CPU, then moving 75% (with unknown, or unremembered settings) to the CPU only caused a little carnage with many more (ultimately successful) GPU tasks.
I apologize if someone patiently explained this to me previously. I just now understand. I sometimes need certain words in a special order :P
Rick
-
Also posted on the SAH Number Crunching Forum
BEWARE - UNEXPECTED SIDE EFFECT OF USING RESCHEDULE PROGRAM
Hi All
Reschedule works at the client level but if you use it to move 6.03 (CPU) units to the GPU when they are returned the server still thinks they were crunched by the CPU. As a result the server thinks you have one hellishly hot CPU and allocates extra units to the CPU accordingly.
Therefore if you have a slow CPU driving a fast video card you are likely to find that the CPU is allocated an impossible number of units for it to complete on time. e.g. I have a 3GHz P4 driving a GTS-250. When the dam broke and I was able to download units again I was allocated 349 units to the CPU and 200 to the GPU. These 349 units represent about a months crunching for the poor old P4. When I used ReSchedule to move some of these units to the GPU, as soon as I restarted BOINC it immediately set about downloading more CPU units to make up for the ones I had shifted.
So, if your using ReSchedule to move CPU units to the GPU be aware of this and keep an eye on the number of units that the server allocares and uploads to the CPU. At the moment I'm having to run "No New Tasks" to avoid CPU overload.
@ Marius.
Would it be possible to add an option to this program to only move VLAR's to the CPU and leave the VHAR's on the video card(s) ? It would help minimise this problem and the issues where a large number of units get moved to the CPU. As Richard said there is really no need for the VHAR's to be moved.
Thanks
Brodo
-
@ Marius.
Would it be possible to add an option to this program to only move VLAR's to the CPU and leave the VHAR's on the video card(s) ? It would help minimize this problem and the issues where a large number of units get moved to the CPU. As Richard said there is really no need for the VHAR's to be moved.
I'll second that ;)
I'm looking for tasks that don't abort, run reasonably well and maximize GPU usage. I use my GPU as an additional processor. Because it's kind of old (8600GTS, bought in May 2008...sigh) it can do the "normal" tasks in 30 to 45 minutes. The Q6600 does "normal" CPU tasks in about 1 hour so they're almost the same in the grand scheme of things. A minute or two one way or the other is insignificant for me.
Of course it's interesting playing with it ;D
Rick
-
@Brodo: Interesting, this would explain why my inputs are so unbalanced these day's. I was thinking this was caused by just swapping the contents of boinc data between different computers (a few week back everything dried up and i swapped a few computers). This not only gives a unbalance in applications but also in computers.
@Brodo/Rabbit: I'm working on the VLAR, and its already finished but i just want to play with it a little more before releasing it. Also want to test a bit more on Vista before i release this as that OS is causing less joy (=pain and problems) then i expected.
The server seems to give indeed a lot of vlar/vhar these day's, i do not know if thats because of rebranding or just bad luck.
Signing off,
Marius
-
Great! I'm all ears ;D
I'm sure version 1.9 (or whatever) will be even better. It's been fun to play with your script just to see what it did. I'm not a programmer (just an old hardware engineer) so I'm allowed to consider these things to be magic. Besides it's ONLY software ;D
Rick
-
@ Marius.
Would it be possible to add an option to this program to only move VLAR's to the CPU and leave the VHAR's on the video card(s) ? It would help minimise this problem and the issues where a large number of units get moved to the CPU. As Richard said there is really no need for the VHAR's to be moved.
Thanks
Brodo
I'll third this suggestion!
That's the best idea yet. Just(ONLY) rebrand a VLAR if it is destined for a GPU. Don't touch/modify anything else. NADA.
Thanks!
Martin
waiting for version 1.9...
-
To bad the low angle range and high angle range to look for is not in INI file. Then people could increase the high angle range to something like 24.999 and the very high angle range tasks would be left on the GPU.
Regards,
Kevin
-
Log says :
CPU tasks: 0 (0 VLAR/VHAR)
GPU tasks: 0 (0 VLAR/VHAR)
I investigated the client_state.xml you send me and the xml is corrupt causing my xml parser (and also IE8 parser) to truncate large parts of the xml.
IE8 report the following error: End tag 'iax_nbytes' does not match the start tag 'max_nbytes'.
<max_nbytes>65536</iax_nbytes>
Simply fixing that will solve this problem.
Greetings,
Marius
Thanks Marius - an excelllent bit of detective work! and apologies I didn't spot it but as BOINC seemed to be working OK I foolishly assumed everything was fine. As per PM I have fixed that error and Reschedule now sees all my WUs.
However I now get :-
Error : List index out of bounds (0)
If I tick the two boxes 'Only VLAR/VHAR to CPU' and 'use True angle rate' it tests OKs. Not sure of your underlying logic as to what might be causing this.
As mentioned I now have suspicions over the health of this machine so if this doesn't ring immediate bells then I'm going to do further checks on the BOINC data files and diagnostics on the machine.
-
I downloaded ReSchedule 1.8 about 6 hours ago and just did so again 3 minutes ago, just to make sure. Using Firefox 3.5 under Vista x64.
Unfortunately, currently I have no SETI work units to try out ReSchedule. :(
Thanks, it was just me or more specifically the browser on the rig I was using.
Got it using a different rig and probably a less choked off browser. :-\
-
@ Marius.
Would it be possible to add an option to this program to only move VLAR's to the CPU and leave the VHAR's on the video card(s) ? It would help minimise this problem and the issues where a large number of units get moved to the CPU. As Richard said there is really no need for the VHAR's to be moved.
Thanks
Brodo
I'll third this suggestion!
(It's amazing how a couple hours sleep can help the thought processes...)
In order to diminish or eliminate the effect of rebranding, which Brodo has brought to everyone's attention, the ratio of GPU-to-CPU MB's should not be altered,
even if all you want to do is keep VLAR/VHAR's from going to a GPU.
So, however many VLAR/VHAR's are rebranded from GPU-toCPU, the same number of CPU bound MB's should be rebranded for the GPU.
This will preserve the ratio the client has received from SETI's servers and will not confuse their bookkeeping.
Thanks to Raistmer (perl scripts) and Marius (ReSchedule) for your efforts to improve the SETI experience!!!
Martin
waiting/hoping for 1.9
-
In order to diminish or eliminate the effect of rebranding, which Brodo has brought to everyone's attention, the ratio of GPU-to-CPU MB's should not be altered,
even if all you want to do is keep VLAR/VHAR's from going to a GPU.
So, however many VLAR/VHAR's are rebranded from GPU-toCPU, the same number of CPU bound MB's should be rebranded for the GPU.
This will preserve the ratio the client has received from SETI's servers and will not confuse their bookkeeping.
Actually, it's not the number of WUs, rather the time estimates which need to be kept in balance to avoid confusing BOINC.
Rebranded to CPU increases BOINC's estimate of how much crunch time the cache represents, to GPU decreases time (assuming the GPU is faster).
While rebranding, one might add up the rsc_fpops_est values for tasks shifted to the CPU then shift tasks to GPU and subtract their values, stop when the total is near zero. That would avoid any drastic work fetch action by the core client when it's restarted. Even that could still leave some oddball situations if there's only one GPU but several CPUs, for instance BOINC's round robin simulation might decide some of the work needs high priority and work fetch would be disabled for awhile.
Options which attempt to achieve a selected balance between CPU and GPU probably can't keep that time balance, but it might be used as a streering factor in deciding which tasks to shift.
Joe
-
In order to diminish or eliminate the effect of rebranding, which Brodo has brought to everyone's attention, the ratio of GPU-to-CPU MB's should not be altered,
even if all you want to do is keep VLAR/VHAR's from going to a GPU.
So, however many VLAR/VHAR's are rebranded from GPU-toCPU, the same number of CPU bound MB's should be rebranded for the GPU.
This will preserve the ratio the client has received from SETI's servers and will not confuse their bookkeeping.
Actually, it's not the number of WUs, rather the time estimates which need to be kept in balance to avoid confusing BOINC.
Rebranded to CPU increases BOINC's estimate of how much crunch time the cache represents, to GPU decreases time (assuming the GPU is faster).
While rebranding, one might add up the rsc_fpops_est values for tasks shifted to the CPU then shift tasks to GPU and subtract their values, stop when the total is near zero. That would avoid any drastic work fetch action by the core client when it's restarted. Even that could still leave some oddball situations if there's only one GPU but several CPUs, for instance BOINC's round robin simulation might decide some of the work needs high priority and work fetch would be disabled for awhile.
Options which attempt to achieve a selected balance between CPU and GPU probably can't keep that time balance, but it might be used as a streering factor in deciding which tasks to shift.
Joe
I think you're saying the same thing I was (trying to say), Joe.
Hopefully, it will be clearer now to everyone.
Martin
-
Have no idea what Reschedule.elf is but Reschedule created it today. Attached for your inspecion.
[attachment deleted by admin]
-
Have no idea what Reschedule.elf is but Reschedule created it today. Attached for your inspecion.
Its just a text file containing information about the failure. Unfortunateley i could not extract the exact reason why it was unable to stop the boinc service. It could be because of the 5 seconds timeout i used, 5 sec could be a bit too tight and i extended this to 15 sec.
-
Better make this timeout value adjustable (with default of 15 sec or whatever you want). With high-performance hosts each idle second counts ;D
-
Better make this timeout value adjustable (with default of 15 sec or whatever you want). With high-performance hosts each idle second counts ;D
lol, if it cant stop boinc under 15 seconds the host doesn't deserve to be running boinc ;)
-
Better make this timeout value adjustable (with default of 15 sec or whatever you want). With high-performance hosts each idle second counts ;D
lol, if it cant stop boinc under 15 seconds the host doesn't deserve to be running boinc ;)
I meant something exactly different:
If it will await 15 seconds when BOINC could be stopped for one second - 14 seconds are lost for processing ;)
I'm using now your 1.8 rebranding tool (in manual mode for now) on my x64 host.
One time it complained about can't stop BOINC service (so some adjustments in this area really needed to be done) (but before it could stop it and start again).
But basic functionality works just fine + additional bonus of work balancing between CPU/GPU is just great (especially in times there was no new wrok from servers and CUDA queue completely dry).
Thank you for such nice looking and very useful tool!
IMHO it should be required tool on any CUDA enabled SETI host now.
-
I meant something exactly different:
If it will await 15 seconds when BOINC could be stopped for one second - 14 seconds are lost for processing ;)
Speaking about junks talking about 10 whole seconds lost :o
I'm using now your 1.8 rebranding tool (in manual mode for now) on my x64 host.
One time it complained about can't stop BOINC service (so some adjustments in this area really needed to be done) (but before it could stop it and start again).
But basic functionality works just fine + additional bonus of work balancing between CPU/GPU is just great (especially in times there was no new wrok from servers and CUDA queue completely dry).
Thank you for such nice looking and very useful tool!
IMHO it should be required tool on any CUDA enabled SETI host now.
Hey thanks man, remember its basicly your tool as i just took your excellent idea and extended it a little bit (basicly i picked it up because my queue went dry back then)
This reminds me that i actually forgot to publish the 1.9
1.9 changes:
-Now display's the amount of VLAR and VHAR
-Changed the parsing of client_state.xml so seti@home beta can be run also
-Automatic detection of the right seti_enhanced applications so this tool
can also work with future versions of the seti applications.
-VHAR is now only optionally rescheduled to the CPU (see settings)
-Alternative detection of VLAR/VHAR (True Angle Rate) has been removed.
-->Also noticed 2 little problems:
-Noticed tool does not automaticly pickup seti paths under vista (security problem)
-Noticed tool crashes when browsing for data path under vista (please enter the path manually)
Enjoy,
Marius
[attachment deleted by admin]
-
This reminds me that i actually forgot to publish the 1.9
Thanks for the new version.
I haven't run it yet as I just ran Raistmer's script but on the settings tab the first option is still 'Only VLAR+VHAR to CPU.' I suppose this is just a cosmetic leftover and the functionality has changed.
Do I understand correctly that the tasks already being crunched are excluded from the figures? If so, the test function returned correct figures.
On my Vista64, the paths were picked up automatically and I was able to browse for the data path.
-
This reminds me that i actually forgot to publish the 1.9
on the settings tab the first option is still 'Only VLAR+VHAR to CPU.' I suppose this is just a cosmetic leftover and the functionality has changed.
I noticed that too and perceive it as "not touch usual tasks and not do % rebranding"
Cause VLAR and VHAR now counted separately (good idea actually) it's very easy to check.
-
I haven't run it yet as I just ran Raistmer's script but on the settings tab the first option is still 'Only VLAR+VHAR to CPU.' I suppose this is just a cosmetic leftover and the functionality has changed.
Yes small leftover, the first checkbox locks out the percentage (it grays some controls also to reflect that) and the second checkbox controls if the vhar are pushed back to the cpu.
Do I understand correctly that the tasks already being crunched are excluded from the figures? If so, the test function returned correct figures.
Yes, the currently running units are always excluded because i can't switch the applications of those because that info has already been entered into the slot directory (previous versions did reschedule those, but i doubt if that had any effect).
On my Vista64, the paths were picked up automatically and I was able to browse for the data path.
Thats good to hear, here with a unpatched vista 64 under virtualbox it just refuses (even when it was run as adminisrator).
Thanks for reporting back,
Marius
-
I feel I must echo Raistmer's comments..........
Thank you for such nice looking and very useful tool!
IMHO it should be required tool on any CUDA enabled SETI host now.
Thank You
-
Enjoy,
Marius
Absolutely! It is a great tool!
Thank you! Marius and Raistmer!!
Martin
-
Yes, this is great! Thanks a bunch.
SETI almost always sends me GPU tasks exclusively although I've asked for everything. Rescheduling not only takes care of the VLAR tasks, it lets me get some more CPU tasks if I need them to keep the STD down to a normal amount.
I'm going away for awhile in a few weeks and I've been wondering if I could leave the GPU tasks running without impacting the other projects with its inflated STD. Running CPU tasks also keeps the duration correction factor at a reasonable value so I don't get a bazillion tasks.
I was lazy when I installed BOINC 6.6.28. Because it doesn't run as a service (like 5.10.45) anymore I just automatically started BOINC Manager when I logged in. When the tool starts and stops BOINC, it drives BOINC Manager crazy (incorrect password). I know the tool only controls BOINC.exe.
"Doctor, it hurts when I do this--Then don't do that ;D " I have no reason to have BOINC Manager running (I use BoincView) so I've changed my ways and start BOINC.exe directly.
Rick
-
Changed thread title to not scare visitors with "perl" mention :)
-
Thanks for this superb tool!
Working great!
Thanks all involved
//lazydude
-
Excellent tool, thanks a lot for the work.
Razamatraz
-
This reminds me that i actually forgot to publish the 1.9
1.9 changes:
-Now display's the amount of VLAR and VHAR
-Changed the parsing of client_state.xml so seti@home beta can be run also
-Automatic detection of the right seti_enhanced applications so this tool
can also work with future versions of the seti applications.
-VHAR is now only optionally rescheduled to the CPU (see settings)
-Alternative detection of VLAR/VHAR (True Angle Rate) has been removed.
-->Also noticed 2 little problems:
-Noticed tool does not automaticly pickup seti paths under vista (security problem)
-Noticed tool crashes when browsing for data path under vista (please enter the path manually)
Enjoy,
Marius
Thanks for a great little utility. I've upgraded to 1.9 on all my cuda hosts tonight.
Cheers,
MarkJ
-
Great tool, Upgraded to 1.9 yesterday, saves a lot of vlar from getting sent back to it's maker.
Claggy
-
Marius,
Re the error below, it was as I supected a problem with my machine. I identified a number of corrupt WU files which I assume meant your software was unable to parse the file correctly :-
However I now get :-
Error : List index out of bounds (0)
If I tick the two boxes 'Only VLAR/VHAR to CPU' and 'use True angle rate' it tests OKs. Not sure of your underlying logic as to what might be causing this.
As mentioned I now have suspicions over the health of this machine so if this doesn't ring immediate bells then I'm going to do further checks on the BOINC data files and diagnostics on the machine.
Thanks again for all your efforts in developing and supporting this excellent tool.
-
Marius, I think I just understood something (it took me a while!).
When I run the v1.9 tool, set for 75% GPU (without any boxes checked), it moves the VLAR tasks as well as adjusting the GPU/CPU ratio. Cool! I had been wondering how to do this. It took me weeks to figure this out ...sigh. I guess that I'm a bit dense...sigh again.
I may have been a bit slow to figure this out (but I did figure it out!). This is exactly what I've been looking for.
Cudos again!
Rick
PS: You might want to mention this in the readme file. I assume it's obvious to most people, but it wasn't for me...sigh a bunch more.
PPS: I ain't your standard idiot, I'm better. I know what I'm doing ;D
-
Cant make this one work. I run the tool, choose run, then nothing happens, it just says reschedule is needed. Before and after the gpu has 863 units, 75 VLAR and 7 VHAR no matter what options i choose :(
this is with boinc shut down:
Reschedule version 1.9
Time: 24-07-2009 21:44:21
User forced a reschedule
Option "Only VLar+VHar to CPU" is enabled
Boinc applications
setiathome_enhanced 608 windows_intelx86 cuda
No SETI main application found
with boinc running:
Reschedule version 1.9
Time: 24-07-2009 21:48:10
User forced a reschedule
Option "Only VLar+VHar to CPU" is enabled
Stopping BOINC application
BOINC application is stopped
Boinc applications
setiathome_enhanced 608 windows_intelx86 cuda
No SETI main application found
Starting BOINC application
BOINC application started
-
Cant make this one work. I run the tool, choose run, then nothing happens, it just says reschedule is needed. Before and after the gpu has 863 units, 75 VLAR and 7 VHAR no matter what options i choose :(
The tool is able to find the cuda application but was unable to determine what CPU application is running, because of this it cannot find the proper version numbers to rebrand the workunits and it aborts. Normally you would see something like this in the log:
Reschedule version 1.9
Time: 24-07-2009 12:01:55
Automatic test for a reschedule
Reschedule needed, found a VLAR
Stopping BOINC service
BOINC service is stopped
Boinc applications
setiathome_enhanced 603 windows_intelx86
setiathome_enhanced 608 windows_intelx86 cuda
CPU tasks: 1085 (482 VLAR, 202 VHAR)
GPU tasks: 311 (3 VLAR, 47 VHAR)
After reschedule:
CPU tasks: 698 (485 VLAR 80 VHAR)
GPU tasks: 698 (0 VLAR 169 VHAR)
Starting BOINC service
BOINC service started
If you send me your zipped client_state.xml to seti[at]finalistonine[dot]nl i will have a look whats causing this problem.
-
sent it and looked in the boinc folders. There are no exe file for cpu work anymore for some reason. Also, the cpu has run totally out of work so that might be it.
-
sent it and looked in the boinc folders. There are no exe file for cpu work anymore for some reason. Also, the cpu has run totally out of work so that might be it.
Actually, the sudden absence of cpu application is kind of weird. Its not only gone from the setiathome.berkeley.edu subdirectory but also seems to be erased from the client_state.xml (at least thats what i think). However a corrupt client_state.xml can also be a possibility.
I see i made a stupid typo in my email adress, it should have been seti[at]finalistonline[dot]nl
-
Want me to send the zipped thing to the correct address? Also, how can i fix it?
-
Want me to send the zipped thing to the correct address? Also, how can i fix it?
Yes please, i'm also curious what the problem is
-
Cpu suddenly got work and now the exe file appeared. So it works now odd enough :/ ill send the thing anyways
-
Cpu suddenly got work and now the exe file appeared. So it works now odd enough :/ ill send the thing anyways
Thanks, no change needed anymore ;) The original clientstate is correct (no corruption) but it just didn't contain any information about the 603 cpu application.
Must say, this is the first time i've seen a client_state without a cpu application!
-
Downloaded the 1.9 rebranding tool, and for the most part, it works great.
I have one problem though, which prevents me from running it in automatic mode.
I have run it a number of times manually, and sometimes after the rebranding is finished, it does not correctly restart Boinc. I get a message saying that Boinc is not connected to a client, "you have entered an incorrect password, please try again"......
Manually exiting Boinc and restarting it sets things right again.
Other times it works correctly. I have not run it enough times yet to notice if the bad restart only occurs when work has actually been rebranded vs when it has not found any VLAR to rebrand.
Anybody else notice this problem?
I should mention that this is on an i7 XP x64 rig, and Boinc is NOT running as a service.
-
I have run it a number of times manually, and sometimes after the rebranding is finished, it does not correctly restart Boinc. I get a message saying that Boinc is not connected to a client, "you have entered an incorrect password, please try again"......
This occasionally happends, but unfortunately its not something i can prevent. From where i stand it looks like a bug in the boincmgr because of credential problems but i'm not absolutely sure about it.
My vista/64 test installation ran without problems, but that doesn't help you much. In the background i use 'boinccmd.exe --quit' to stop boinc, boincmgr detects this and "grayes" out the project. After the reschedule i simply use 'boinc.exe -detach' to restart it, but this credential problem in boincmgr is a blocking factor. You could try these commands manually, its boincmgr whats causing the trouble for sure.
No idea if it can/could be fixed on my side. Any ideas out there?
-
On XP I still use the 'old style' automatic mode. That is with an entry in Windows scheduled tasks, pointing to a batch (.cmd) file that has boinc control in it to control the service:
REM Reschedule.cmd, for automated rebranding
net stop boinc
reschedule.exe /Autorun 75
net start boinc
By linking to a shortcut to that you can set it to run minimised also, so that command window only appears briefly on the taskbar, otherwise invisible. No problems stop/starting boinc that way here, probably since the reschedule process has enough meat in it without additional delays.
That, of course is for service installation, which won't be suitable with Vista+ with the GPU app, so changing the 'net stop & start' line to use boinccmd should work. If some delay is needed you can use 'ping someaddress.com > nul' to make a delay before restarting.
-
does anybody know how to rescheduler 1.9 to work with s@h beta test? i'm having problems with vlars and would like to move them to the cpu.
here is the thread that states my problem and Joe suggestion. any suggestions would be helpful and appreciated.
http://setiweb.ssl.berkeley.edu/beta/forum_thread.php?id=1581
-
Well........
I just had a scare with the rebranding tool.......
Got some new cuda work overnight, and ran the tool to move some VLAR over to the CPU. Tool ran, moved the work, and got the password error when restarting Boinc.
Manually shut Boinc down and restarted it, and when it came back up, the 'attach to project' window came up!!! No projects, no tasks!
Shut it down again and restarted it again, and, praise to the Gods of Seti....my tasks were back. The only ill effect was the loss of a bunch of crunch time on 4 AP wu's it had been crunching on....they exited with computation errors.
I think from now on I will shut down Boinc manually before running the rebranding tool and restart it manuall once it is done, unless the tool can be modified to start and stop Boinc in a safer manner.
Not to diss the tool, mind you.....I am glad it is available for those like me who practice 'no WU left behind'....LOL.
I am just going to be more cautious when using it until a fix is found or a successful non-vlarkill app comes along and I can update my drivers to run it.
-
Non-service BOINC installation bugged by default.
Cause there is no correct method to end BOINC and be sure it's client_state.xml is written already.
You could implement some watchdogs or pinging or simple put pause in bat-file, but "boincmgr --quit" is not enough.
Actually I prefer just to kill boinc.exe process by wkill tool.
This method doesn't give guaranty that all science app are finished, htey can remain actie ~30 seconds after boinc.exe process kill, but at least I can be sure no more client_state.xml writes will be follow.
Regarding rebranding tool AFAIK it will not reschedule already started tasks so it doesn't need science apps exit, it only needs boinc.exe exit to keep client_state.xml safe.
@msattler
In your case it seems client_state_prev.xml was used to restore your BOINC. You are lucky indeed :)
-
I just had a scare with the rebranding tool.......
Don't worry about it to much, for what i know boincmgr just misfired on restart and got credential errors (like you had before i guess). Boincmgr screen will be shown completely blanc without any tasks and projects, i've seen this before and i'm not really worried about it. Restarting boincmgr will solve it all. However those computation errors are weird, they should not have happened as i don't touch any of the the running workunits. Mayby Raistmer is right about reused .._prev.xml, but i'm not sure about that (and difficult to detect, mayby there was a collision with boinc.exe?)
Still this is a sign things can go wrong on 64 bit system (=systems not run with standard boinc service). If you happen to know a safe method on stopping/restarting boinc please do (better safe then sorry). I would appreciate any hint or report with workarounds, i'll happily adopt it in the tool if i can, but for now i dont have any workarounds (other then killing boinc the hard way with "pskill boinc.exe" (don't try this for fun!)).
-
Marius, would you describe more fully what the 1.9 release note relating to SETI Beta means? Is it just avoiding messing with Beta work, or actually meant to allow rebranding of work at Beta? If the latter, it appears not to be working from Jason Keil's experience.
Joe
-
Marius, would you describe more fully what the 1.9 release note relating to SETI Beta means? Is it just avoiding messing with Beta work, or actually meant to allow rebranding of work at Beta? If the latter, it appears not to be working from Jason Keil's experience.
Joe
Sure, previous versions would simply mess up the client_state.xml as it was unable to distinguish units from seti beta and seti main. If you read a few pages back in this thread you problably can find the conversation about it.
1.9 is ONLY able to rebrands for seti main.
If i have time i would like to introduce seti-beta rebranding in a 2.0 version (its exactly the same, only app_name is different).
Greetings,
Marius
-
OK, I was too optimistic when I read the note, wishful thinking I guess :D I did remember the exchanges about the difficulty, I think I even commented therein.
In case it might encourage you to do the 2.0 version, I'll note that the file being split for Beta has a good mix, midrange and VHAR for the first part then VLAR for the end. I'm not sure how much of each, haven't investigated that closely. But there have been at least 6 channels split and the work that brought up the question was from the later part of the first of those. The others will of course have the same pattern, all feeds travel together. At the rate Beta participants get through work, there may be a week or two of non-VLAR work before the next problems. All in all, there's about 3 months of work already split (I think the mb_splitter there is using the same "Results ready to send" queue control values as Main).
Joe
-
Well........
I just had a scare with the rebranding tool.......
Got some new cuda work overnight, and ran the tool to move some VLAR over to the CPU. Tool ran, moved the work, and got the password error when restarting Boinc.
Manually shut Boinc down and restarted it, and when it came back up, the 'attach to project' window came up!!! No projects, no tasks!
Shut it down again and restarted it again, and, praise to the Gods of Seti....my tasks were back. The only ill effect was the loss of a bunch of crunch time on 4 AP wu's it had been crunching on....they exited with computation errors.
The core-client seems to start up, just the manager is unable to connect to it. I usually just click Advanced -> Select Computer and hit the Okay button (or enter) and it will reconnect.
-
I just had a scare with the rebranding tool.......Got some new cuda work overnight, and ran the tool to move some VLAR over to the CPU. Tool ran, moved the work, and got the password error when restarting Boinc.
This happened to me as well when I ran the tool in manual mode. Running via a cmd batch file using the commands posted in this thread there was no error i.e. autorun 75.
Edit: [Snip] Sorry forget I asked!
In accordance with instructions I herewith post my thanks to Raistmer, Marius et al for a marvelous tool. No more killed VLAR's!
thanks
Art
-
Hi , I never had a problem , stopping BOINC, even when using the sleep mode ,availeble when right-clicking on the tasbar - icon.
Never had to use net stop boinc, so time to install this tool, too ::)
You've done a great job Raistmer!
-
Hi , I never had a problem , stopping BOINC, even when using the sleep mode ,availeble when right-clicking on the tasbar - icon.
Never had to use net stop boinc, so time to install this tool, too ::)
You've done a great job Raistmer!
Well, thanks of course ;) but actually you probably using Rebranding tool written by Marius :) So passing congrats to him ;D
-
I have been watching this computer (http://setiathome.berkeley.edu/show_host_detail.php?hostid=3378680) for some time now and noted that it never crunches any AP work. All 4 of my boxes are set up the same and 3 do occasionally crunch AP this one does not. I also noted that it always asks for work for the GPU and never requests work for the CPU which may explain why AP work is never assigned. I have the rescheduler set to run 2 times a day with the slider set at 50. This morning I set the slider to 75 but this one computer (http://setiathome.berkeley.edu/show_host_detail.php?hostid=3378680) is still only requesting work for the GPU. Seems the rescheduler is sending the VLAR work to the cpu's as it should but it seems to never get them done, always downloads more VLAR work which get's reassigned to the cpu's.
Do I have to live with this and wait until the VLAR work is reduced and then see if it requests work for the cpu's? I don't believe I will get any AP work until it actually requests work for the cpu's. Is this the way it is??
From last run of reschedule.....
---------------------------
Reschedule version 1.9
Time: 03-09-2009 12:00:00
User forced a reschedule
Stopping BOINC service
BOINC service is stopped
Boinc applications
setiathome_enhanced 603 windows_intelx86
setiathome_enhanced 608 windows_intelx86 cuda
CPU tasks: 196 (196 VLAR, 0 VHAR)
GPU tasks: 617 (125 VLAR, 196 VHAR)
After reschedule:
CPU tasks: 321 (321 VLAR 0 VHAR)
GPU tasks: 492 (0 VLAR 196 VHAR)
Starting BOINC service
BOINC service started
-
Some possible thoughts on that:
This might be a case where attempting to stabilise the Duration Correction Factor with the <flops> entries can help. The behaviour I see when this is achieved, is swapping WU for WU, that is report 1 request 1.
Now it gets more complicated, as you point out, because the GPU requests large chunks of work, which a largish proportion lately seem to arrive as VLAR, which then up to twelve hours later get rescheduled to CPU, oversubscribing its queue & generating another GPU fetch.
I would suggest in this situation, a DCF instability would magnify the difficulties (oscillation), since completing one GPU WU would throw the mechanism into 'underestimate mode', effectively enabling fetch for GPU again, since that's the one that just finished, and CPU still has plenty of VLARs to chew on (GPU probably fetched because a big chunk of its WUs just got shunted away).
Correcting the instability, if truly present, might have the following effect IMO: CPU WU time estimates, upon completion of a VLAR WU, no longer throw the system into 'overestimate' mode, so won't disable CPU work fetch right when the CPU probably needed it. That would probably be 'in between' the times that the GPU fed it VLAR tasks, since VLAR tasks were probably assigned at reschedule time, and take a-couple-of/a-few hours.
So the opportunity for the CPU to fetch for itself is from a few hours after reschedule, right through to just before the next reschedule. It generally won't do this if the tasks it has just been finishing violently threw time estimates off ... So it waits too long... until after the next reschedule.
For DCF stability reference, my comparatively lower end E8400 dual core w/9600 GSO runs with a DCF ~0.3 +/- 0.02, and fetches CPU tasks as soon as it finishes one, which rescheduling large numbers of VLARs temporarily stalls.
I'd imagine that a Q6600 w/ GTX 260 like that might be harder to stabilise due to greater CPU/GPU performance difference, but that's just guessing since I own neither device.
Jason
[Later: Doh! doing some offline testing, forgot to deactivate my reschedule & managed to trash a lot of work mostly due to panic when it restarted Boinc in the middle of my testing ::) ... Machine no longer suitable reference model :'( ]
-
I agree with Jason about DCF... My AMD X2 6000 (Seti Beta Stcok app's) hates MB 6.03's . If it runs just Cuda (I keep trying) the DCF is 1.4 as soon as it snags a MB 6.03 DCF torques to 3.5. So that would be the example of the wider instability.
Using Optimized with the <flops> it normalizes so that the swings are not a bad.
Al
-
Appreciate the comments. I have used the <flops> values but perhaps they need to be reifined better to reflect the true crunch times of each app. Will keep trying.
-
Hi,
I see a little problem
Reschedule seems to work only the first time I run it.
I don't know what slots are but yesterday evening I had 3 slots and this morning 5
Reschedule was active all night but didn't have made his automatic job.
So I ended and restarted it. And works fine, moving to GPU a lot of Job.
CPU asks for new job and get itm but Rescheduler (in Test) is not able to see the new job.
So I end it again and restart. Now working.
It seems that you do some routine at the begining of the run and not at any Test or Run command.
Second question
In this PC, very strange, BOINC is asking job only for CPU.
http://setiathome.berkeley.edu/show_host_detail.php?hostid=2979049
I have resetted the project yesterday afternoon and receved a few GPU task. Then nothing.
Can you have any idea about this?
GPU is working only because I use rescheduler.exe
Bye,
Franz
-
Second question
In this PC, very strange, BOINC is asking job only for CPU.
http://setiathome.berkeley.edu/show_host_detail.php?hostid=2979049
I have resetted the project yesterday afternoon and receved a few GPU task. Then nothing.
Can you have any idea about this?
GPU is working only because I use rescheduler.exe
This problem now is solved. I See that now BOINC is asking job for CPU and GPU.
Non job in theese days but this is another case.
The first problem is still open.
Franz
-
The first problem is still open.
Franz
Is rescheduler.exe able to "see" setiathome_enhanced 5.28?
Franz
-
hardly...
-
@Marius
Are you still developing your tool? My client_state got truncated in the middle of another project's data when I ran it (v1.9) the other day. The rebranding itself went fine and no errors were reported. The only actual loss was the time spent on the tasks that were running at the time (because the <active_task_set> part was gone).
I didn't want to revert to the backup because after restart BOINC fetched more MB tasks for the GPU. I should have realised something was wrong when it ran benchmarks but I just left it alone as I normally do. :-[
I have the before and after client_state files if you're interested.
-
where i had wrong ?
no application is running on gpu :(
x64 xp q6600 gtx nvidia
Reschedule version 1.9
Time: 09-09-2009 02:13:39
User forced a reschedule
Option "Only VLar+VHar to CPU" is enabled
Stopping BOINC application
BOINC application is stopped
Boinc applications
setiathome_enhanced 603 windows_x86_64
setiathome_enhanced 608 windows_x86_64 cuda
CPU tasks: 276 (95 VLAR, 3 VHAR)
GPU tasks: 0 (0 VLAR, 0 VHAR)
After reschedule:
CPU tasks: 276 (95 VLAR 3 VHAR)
GPU tasks: 0 (0 VLAR 0 VHAR)
Starting BOINC application
BOINC application started
-
try to change cpu/gpu % ratio
-
it is locked can't but transfer 15 unit to do gpu today but they aren't enough
-
Disable "OnlyVLAR+VHAR to CPU" check box (and read description that appears on "mouse over")
With this box enabled app will care ONLY about VLAR+VHAR leaving your GPU idle if no VLAR or VHAR to move.
So if you wanna move "usual" tasks around - you need to disable this option.
-
Raistmer all working fine thank you !
-
The first problem is still open.
Franz
Is rescheduler.exe able to "see" setiathome_enhanced 5.28?
Franz
No sorry, only the newer 6 series are supported.
-
Are you still developing your tool?
Not really, the only thing left to do is to add seti beta support but i'm swamped in work the last months. There's very little time left for seti at this moment.
My client_state got truncated in the middle of another project's data when I ran it (v1.9) the other day. The rebranding itself went fine and no errors were reported. The only actual loss was the time spent on the tasks that were running at the time (because the <active_task_set> part was gone).
I'm sorry to hear that, this is very unusual as i'm locking all files and shutdown boinc (and wait for it to release the files). Is there any reason why it has done this?
I didn't want to revert to the backup because after restart BOINC fetched more MB tasks for the GPU. I should have realised something was wrong when it ran benchmarks but I just left it alone as I normally do. :-[
I have the before and after client_state files if you're interested.
The boinc servers are behaving poorly again so you are right to leave it alone. And yes, i'm interested in those files.
Greetings,
Marius
-
I'm sorry to hear that, this is very unusual as i'm locking all files and shutdown boinc (and wait for it to release the files). Is there any reason why it has done this?
I exit BOINC manually anyway. One additional symptom is that the test feature displays the WU counts correctly but says '0 slots occupied' when there are active MB tasks. I recently added PrimeGrid's PPS Sieve subproject and it seems ReSchedule can't parse beyond the first WU download URL. This:
<url>http://www.primegrid.com/download/pps_sr2sieve_workunit_zz.php?from=958648&to=958649</url>
changes into this:
<url></url></file_info></client_state> and EOF :(
When I remove the PrimeGrid project data ReSchedule works fine.
And yes, i'm interested in those files.
If you still want them please PM me your email addy.
-
Marius..........
I have seen several complaints about all the old client_state.xml files left behind when running your rebranding tool. I persoally run rescheduler from a batch file and the first step command is "Del D:\BOINC\client_state2009*.xml" which removes any old client_state2009 files.
Can you make any changes that would remove the old files that are left behind by the rebranding?
-
So the client_state.xml2009* files are created when run rebrand without shutting down Boinc? These files can be safely deleted? (Assuming boinc shut down )
-
So the client_state.xml2009* files are created when run rebrand without shutting down Boinc? These files can be safely deleted? (Assuming boinc shut down )
You don't have to shut it down as long as you leave the original client_state and client_state_prev file alone.
The client_state yyyyymmdd ones are backup copies of client_state before Reschedule changes the wu information and BOINC doesn't use these.
-
I agree. You dont know when you are going to need any previous client_state.xml file... :(
-
I should like to know why I have two PCs, ... same cpu, os, boinc level, otopmized apps (using unified same installer), cuda (one 250 and other 260) but in one I get only 5.28 (so I can't use reschedule) and in the other I get only 6.03 (so I can use reschedule).
Tell me how I can get 6.03 (prayers, ... mantra, ... software?)
FF
-
I should like to know why I have two PCs, ... same cpu, os, boinc level, otopmized apps (using unified same installer), cuda (one 250 and other 260) but in one I get only 5.28 (so I can't use reschedule) and in the other I get only 6.03 (so I can use reschedule).
Tell me how I can get 6.03 (prayers, ... mantra, ... software?)
FF
Add or fix the section in the app_info.xml file which says you have a 6.03 compliant application installed. The BOINC core client assigns CPU work to the highest numbered CPU application it knows about.
Post the app_info.xml here if you'd like more specific advice.
Joe
-
my app_info.xml must be the standard one, build by the last lunatics unified installer.
what else?
<app_info>
-
<app>
<name>setiathome_enhanced</name>
</app>
-
<file_info>
<name>AK_v8b_win_SSSE3x.exe</name>
<executable/>
</file_info>
-
<app_version>
<app_name>setiathome_enhanced</app_name>
<version_num>528</version_num>
-
<file_ref>
<file_name>AK_v8b_win_SSSE3x.exe</file_name>
<main_program/>
</file_ref>
</app_version>
-
<app_version>
<app_name>setiathome_enhanced</app_name>
<version_num>603</version_num>
-
<file_ref>
<file_name>AK_v8b_win_SSSE3x.exe</file_name>
<main_program/>
</file_ref>
</app_version>
-
<app>
<name>astropulse_v5</name>
</app>
-
<file_info>
<name>ap_5.03r112_SSE3.exe</name>
<executable/>
</file_info>
-
<app_version>
<app_name>astropulse_v5</app_name>
<version_num>503</version_num>
-
<file_ref>
<file_name>ap_5.03r112_SSE3.exe</file_name>
<main_program/>
</file_ref>
</app_version>
-
<app>
<name>astropulse_v505</name>
</app>
-
<file_info>
<name>ap_5.05r168_SSE3.exe</name>
<executable/>
</file_info>
-
<app_version>
<app_name>astropulse_v505</app_name>
<version_num>505</version_num>
-
<file_ref>
<file_name>ap_5.05r168_SSE3.exe</file_name>
<main_program/>
</file_ref>
</app_version>
-
<app>
<name>setiathome_enhanced</name>
</app>
-
<file_info>
<name>MB_6.08_CUDA_V12_VLARKill_FPLim2048.exe</name>
<executable/>
</file_info>
-
<file_info>
<name>cudart.dll</name>
<executable/>
</file_info>
-
<file_info>
<name>cufft.dll</name>
<executable/>
</file_info>
-
<file_info>
<name>libfftw3f-3-1-1a_upx.dll</name>
<executable/>
</file_info>
-
<app_version>
<app_name>setiathome_enhanced</app_name>
<version_num>608</version_num>
<plan_class>cuda</plan_class>
<avg_ncpus>0.040000</avg_ncpus>
<max_ncpus>0.040000</max_ncpus>
-
<coproc>
<type>CUDA</type>
<count>1</count>
</coproc>
-
<file_ref>
<file_name>MB_6.08_CUDA_V12_VLARKill_FPLim2048.exe</file_name>
<main_program/>
</file_ref>
-
<file_ref>
<file_name>cudart.dll</file_name>
</file_ref>
-
<file_ref>
<file_name>cufft.dll</file_name>
</file_ref>
-
<file_ref>
<file_name>libfftw3f-3-1-1a_upx.dll</file_name>
</file_ref>
</app_version>
</app_info>
-
my app_info.xml must be the standard one, build by the last lunatics unified installer.
what else?
...
The "-" characters and unusual spacing are unwanted changes usually caused by some Microsoft "helpful" feature. If that only happened when you copied and pasted here there's no harm done, but if it's that way on disk it may be the cause of the problem. Check by opening it in Notepad or another plain text editor. If it's damaged, the simple solution would be to copy the file from the other similar host which is working correctly, the more thorough solution would be to uninstall and reinstall the optimized apps.
Assuming the file is good, it's hard to guess why BOINC 6.6.36 isn't doing what it should. Perhaps someone will recall a similar case with that version of BOINC. Incidentally, is it host 2979049 (http://setiathome.berkeley.edu/show_host_detail.php?hostid=2979049) or host 2693912 (http://setiathome.berkeley.edu/show_host_detail.php?hostid=2693912) which is stuck on 5.28?
Joe
-
The "-" characters and unusual spacing are unwanted changes usually caused by some Microsoft "helpful" feature. If that only happened when you copied and pasted here there's no harm done, but if it's that way on disk it may be the cause of the problem. Check by opening it in Notepad or another plain text editor. If it's damaged, the simple solution would be to copy the file from the other similar host which is working correctly, the more thorough solution would be to uninstall and reinstall the optimized apps.
Assuming the file is good, it's hard to guess why BOINC 6.6.36 isn't doing what it should. Perhaps someone will recall a similar case with that version of BOINC. Incidentally, is it host 2979049 (http://setiathome.berkeley.edu/show_host_detail.php?hostid=2979049) or host 2693912 (http://setiathome.berkeley.edu/show_host_detail.php?hostid=2693912) which is stuck on 5.28?
Joe
I have reinstalled the the optimized apps just some hours before writing here.
I never edited app_info.xml (it is the original from optimized apps installation in both cases)
The host with GTX 260 (2979049) is going fine. all 6.03
The host with GTS 250 (2693912) is affected by the 5.28 problem
Do you need more info?
FF
-
I have reinstalled the the optimized apps just some hours before writing here.
I never edited app_info.xml (it is the original from optimized apps installation in both cases)
The host with GTX 260 (2979049) is going fine. all 6.03
The host with GTS 250 (2693912) is affected by the 5.28 problem
Do you need more info?
FF
Just a quick controll, done with a file compare software.
app_info.xm in the two hosts are identical.
FF
-
...
Assuming the file is good, it's hard to guess why BOINC 6.6.36 isn't doing what it should. Perhaps someone will recall a similar case with that version of BOINC. Incidentally, is it host 2979049 (http://setiathome.berkeley.edu/show_host_detail.php?hostid=2979049) or host 2693912 (http://setiathome.berkeley.edu/show_host_detail.php?hostid=2693912) which is stuck on 5.28?
Joe
I have reinstalled the the optimized apps just some hours before writing here.
I never edited app_info.xml (it is the original from optimized apps installation in both cases)
The host with GTX 260 (2979049) is going fine. all 6.03
The host with GTS 250 (2693912) is affected by the 5.28 problem
Do you need more info?
FF
Just a quick controll, done with a file compare software.
app_info.xm in the two hosts are identical.
FF
I'm stumped for now, but will think about it some more.
Joe
-
I'm stumped for now, but will think about it some more.
Joe
I have a machine in a similar state. The project is Einstein: there was a project Beta test of ABP1 v3.11
I have an app_info with a set of files, a 310 version block and a 311 version block (both referring to the same files). The host is crunching quite happily, but every new task is getting branded 310. I haven't done an exact byte-by-byte check, but it looks as if the 311 block is present and correct in both app_info.xml and client_state.xml, and both versions were listed in the latest sched_request to the project.
The strange thing is, this host is my old P4 Windows 2000 home server, running BOINC v5.10.13 - so completely unaffected by any recent BOINC developments. My other P4, my daily driver with a very similar app_info, is getting tasks branded 311 with the same version of BOINC.
So it rather seems it's the behaviour of the servers which has changed. Einstein has started limited (anonymous platform only) CUDA testing, so they must have updated their server code a bit - not that you'd know it from looking at their web pages, which haven't changed for a year or more - so I'm wondering if all the new <plan_class> code has undone the certainties like 'will assign highest version available' that we used to rely on.
-
I'm stumped for now, but will think about it some more.
Joe
Just some more info
1) now on both hosts I have installed Boinc Manager 6.6.41
2) on the host receiving only 5.28 I run boincview.exe and (sometimes) BoincTasks.
This last one can manage Day Work and Wanted WU .... so I think that can be involved in the problem
In any case I have not filled those fields with data.
FF
-
The primary server-side change is that the Scheduler now tells the client to use what it considers the "best" app version. What it considers "best" doesn't consider the version number. Instead it just takes the suitable app versions in order, and chooses the one with the highest flops rating. If the flops are equal, the first suitable app is considered "best".
It's possible that simply listing the higher numbered version first in the app_info.xml would help, but that doesn't explain why the current order works on some hosts but not others.
Franz, with 6.6.x you could consider editing in flops settings for the apps, making 6.03 slightly higher than 5.28. That seems like it should correct the situation. MarkJ's app_info for AP503, AP505, MB603 and MB608 (http://setiathome.berkeley.edu/forum_thread.php?id=54801) thread should provide enough detail if you decide to try that.
Joe
-
The primary server-side change is that the Scheduler now tells the client to use what it considers the "best" app version. What it considers "best" doesn't consider the version number. Instead it just takes the suitable app versions in order, and chooses the one with the highest flops rating. If the flops are equal, the first suitable app is considered "best".
I wonder whether that explains the tendency for SETI to fill the CUDA cache before the CPU cache, in times of drought.
(Assuming your CUDA card is faster than your CPU, that is.)
-
Franz, with 6.6.x you could consider editing in flops settings for the apps, making 6.03 slightly higher than 5.28. That seems like it should correct the situation. MarkJ's app_info for AP503, AP505, MB603 and MB608 (http://setiathome.berkeley.edu/forum_thread.php?id=54801) thread should provide enough detail if you decide to try that.
Joe
mmmmmm mumbe mumble ... I don't like to change app_info ... but If I have to do it, I think that the better solution is to delete the 528 section .... isn't it?
So...
<app_version>
<app_name>setiathome_enhanced</app_name>
<version_num>528</version_num>
<file_ref>
<file_name>AK_v8b_win_SSSE3x.exe</file_name>
<main_program/>
</file_ref>
</app_version>
What do you think?
Franz
-
mmmmmm mumbe mumble ... I don't like to change app_info ... but If I have to do it, I think that the better solution is to delete the 528 section .... isn't it?
So...
<app_version>
<app_name>setiathome_enhanced</app_name>
<version_num>528</version_num>
<file_ref>
<file_name>AK_v8b_win_SSSE3x.exe</file_name>
<main_program/>
</file_ref>
</app_version>
What do you think?
Franz
Finish and report any already downloaded work which has been already assigned to 5.28 first, or BOINC will trash it. Other users might be grateful to get the reissues, but with the project having very little new work to deliver your host might be idle for awhile.
Joe
-
Finish and report any already downloaded work which has been already assigned to 5.28 first, or BOINC will trash it. Other users might be grateful to get the reissues, but with the project having very little new work to deliver your host might be idle for awhile.
Joe
Yes, of course. You are right.
But if I stop new work now, I will finish CUDA work in one day, while CPU buffer in 6/7 days.
May be I leave all as now ...
Franz
-
I'm not up-to-date..
Is a Reschedule_prog in work, which can reschedule WUs at SETI@home BETA ?
This would be nice! (http://www.cheesebuerger.de/images/smilie/froehlich/a020.gif)
Thanks!
-
Ahh.. BTW..
Maybe it's possible to extend the DL area with the Reschedule_prog?
Then more people would see it (advertising for free), easier to DL and used more.
:)
-
How to put back WHAR from CPU to GPU? Once it transferred from GPU to CPU it cannot be rescheduled for cuda?
-
Hi all, I tested rescheduler and found the following problem:
boinc is attached to seti and primegrid, after running rescheduler something wrong happened to all my primegrid workunits. These simply disappeared. Eventually these (at least some) come back after awhile (resending lost results)...
I don't know if rescheduler can be used in a "mixed" environemnt...
Any hints?
-
I am sorry I did not read every message but could someone tell me what my "Boinc Main Path" is supposed to be? Everything I put in there it says doesn't exist. I am using Windows 7, Can't seem to set up rescheduler.
Error:C:\BOINC\boinc.exe does not exist.
Error:C:\BOINC\projects\setiathome.berkeley.edu\boinc.exe does not exist.
Error:C:\ProgramData\BOINC\boinc.exe does not exist.
Error:C:\ProgramData\BOINC\projects\boinc.exe does not exist.
Error:C:\ProgramData\BOINC\projects\setiathome.berkeley.edu\boinc.exe does not exist.
Error:C:\ProgramData\BOINC\projects\setiathome.berkeley.edu\boinc.exe does not exist.
Error:C:\ProgramData\BOINC\projects\setiathome.berkeley.edu\boinc.exe does not exist.
Error:C:\ProgramData\BOINC\projects\boinc.exe does not exist.
Error:C:\ProgramData\BOINC\projects\boinc.exe does not exist
EDIT
Weird, when I use the rescheduler to find the path boinc isn't in there. When I just opened explore it is...C:\Program Files\BOINC . Then the path to C:\ProgramData\BOINC wouldn't show up so I had to copy and paste it also using explorer. I have show all files checked also. It worked.
-
The default directory where BOINC will install its executables to is:
Windows 32bit: C:\PROGRAM FILES\BOINC\
Windows 64bit: C:\PROGRAM FILES (x86)\BOINC\
The Big BOINC 6 Answer Thread. (http://boincfaq.mundayweb.com/index.php?language=1&view=376&sessionID=758221370c688cefe83a535db98bf342)
Claggy
-
The default directory where BOINC will install its executables to is:
Windows 32bit: C:\PROGRAM FILES\BOINC\
Windows 64bit: C:\PROGRAM FILES (x86)\BOINC\
The Big BOINC 6 Answer Thread. (http://boincfaq.mundayweb.com/index.php?language=1&view=376&sessionID=758221370c688cefe83a535db98bf342)
Claggy
Not completely agreed, if you're in windows x32 absolutely agree.
if you're in windows x64 there are two options:
1 - setup BOINC x32 and the install path will be C:\PROGRAM FILES (x86)\BOINC\
2 - setup BOINC x64 (the proper option) the install path wil be C:\PROGRAM FILES\BOINC\
-
Hmm.. no ReSchedule 2.0 for SETI@home BETA? :-\
Or I missed something, ReSchedule 1.9 work also with SETI@home BETA?
Not for me.. ;)
It would be nice, so I wouldn't lose much performance if I would test the stock_MB_6.09_CUDA23_app at SETI@home BETA.
Or it's also needed to test this app with VLARs?
I guess - this VLAR prob will be to the time until the nVIDIA devs would be jump in, or?
So current it's not needed to test VLARs?
-
@ Pepi
AFAIK, you can reschedule CPU-GPU and GPU-CPU back and forward.
Like you want.
I make all the time only VLARs to CPU, all WUs to GPU.
With 100 % to GPU.
Maybe, I guess.. if you make less, maybe 50 % - the prog make VLARs to CPU and split all other WUs to CPU (- the VLARs) and GPU.
There are also some check boxes, maybe with this?
@ valterc
I don't use ReSchedule in AUTO mode.
I close/exit BOINC. Start ReSchedule, execute it. Close/exit ReSchedule and start again BOINC.
Everything fine.
Maybe this work also for you with more projects.
-
Hi all, I tested rescheduler and found the following problem:
boinc is attached to seti and primegrid, after running rescheduler something wrong happened to all my primegrid workunits. These simply disappeared. Eventually these (at least some) come back after awhile (resending lost results)...
I don't know if rescheduler can be used in a "mixed" environemnt...
Any hints?
This is a known issue with v1.9, well at least I reported it to Marius here (http://lunatics.kwsn.net/12-gpu-crunching/cpu-gpu-rebranding-perl-script.msg21030.html#msg21030) in this thread.
If you have tasks from the PrimeGrid subprojects that use the sr2sieve application - at least PPSsieve and PSPsieve - running ReSchedule v1.9 could cause your client_state to be truncated. This is (apparently) because it fails to parse the workunit url. If the test function displays correct task counts AND occupied slot count then it should be OK. You probably shouldn't have the reschduler in automatic mode when attached to and allowing work from PrimeGrid.
When I have tasks from these subprojects and need to rebrand MB tasks, I use Raistmer's script which works fine.
-
Anyone want to volunteer how to install this, I installed activepearl but when I try to open the program a black dos type box flashes for a split second before vanishing.
I'm on win 7 64.
-
for Rebranding tool you don't need perl.
My perl-based script completely superseded by Rebranding tool app.
-
Its not in the download section, a search doesn't find it and theres no obvious thread on it in the last 12 months, any clues ?
-
Its not in the download section, a search doesn't find it and theres no obvious thread on it in the last 12 months, any clues ?
Page 13 of this thread, specifically message 19454 (http://lunatics.kwsn.net/12-gpu-crunching/cpu-gpu-rebranding-perl-script.msg19454.html#msg19454).
Joe
-
Thanks Joe
=br />Any reason for not putting it in the download section. I read a few pages in and noticed the original post was getting upd`ted with every new version so gave up there thinking the OP had the latest version.
-
Thanks Joe
Any reason for not putting it in the download section. I read a few pages in and noticed the original post was getting updated with every new version so gave up there thinking the OP had the latest version.
The primary reason is Marius is missing in action and not here to support his program. Need more be said?
Regards
-
My perl-based script completely superseded by Rebranding tool app.
Absolutely not!!! Your script is cross-platform while the app not.
-
My perl-based script completely superseded by Rebranding tool app.
Absolutely not!!! Your script is cross-platform while the app not.
:) I meant "for Windows" (host in question was under Win7x64) but bad formulated again ;)
-
Trying to run Raistmer's perl rebrand script under Ubuntu. It keeps coming up with 0 tasks for CPU and GPU. Placed V5 in data folder and ran script from terminal, 0 tasks. Edited file and replaced all instances of 603 with 528, 0 tasks. Moved script to BOINC folder where client_state.xml resides, 0 tasks. It appears that script is supposed to die with "ERROR: cant open task file" if there is a path issue. Haven't seen that. Any idea what needs to be changed in script to allow it to run?
Thanks
-
1) It should run from BOINC's data directory (where client_state.xml lives).
2) it will not (as far as I can remember) move tasks from CPU to GPU. Aim of that script not to do load balancing but free GPU from crunching non-effective tasks, that is, it will move VLARs and VHARs from GPU to CPU.
Load balancing was added by Marius in his ReShedule app for Windows.
-
As indicated above, the data and client_state.xml are in different directories. Tried script in both directories and get 0 tasks in both.
CUDA crunching on my primary Ubuntu machine has rendered it virtually unusable due to extremely slow graphics. Sometimes it crawls to a standstill other times it will respond fairly well. Suspect the VLAR tasks may be cause for standstill. Considering giving Crunch3r's VLAR killer cuda app a try to see if it makes a difference.
Will give the Reschedule app a try on my Windows 7 machine later today to see how it does.
See I've got clock's to reset this morning, or what's left of it. ;D
Thanks for your assistance.
-
How Reschedule know what is and where is main app?
Why I got this error? ( both app are in same dir)
Reschedule version 1.9
Time: 17-03-2010 00:53:41
User forced a reschedule
Option "Only VLar+VHar to CPU" is enabled
Stopping BOINC application
BOINC application is stopped
Boinc applications
setiathome_enhanced 609 windows_intelx86 cuda23
No SETI main application found
Starting BOINC application
BOINC application started
-
Reschedule1.9 doesn't work with Cuda Wu's branded as 6.09, only 6.08,
as you're a squire, i suggest you head over to the Beta downloads and try out one of the new installers,
which should fix your problem, please give feedback in the Public Release Beta Test Forum. ;D
Claggy
-
The ReScheduler move which kind of VLARs to the CPU?
This are < 0.12 AR WUs like the MB_6.08_CUDA_V12_VLARkill_mod delete?
Which kind of AR WUs are the best for GPU?
The VHAR (shorties) run better on CPU?
AFAIK, the shorties run very fast on GPU.
And because of Cr./hour the shorties give more earnings than the normal AR WUs (on GPU).
Thanks! :)
-
Search these boards. Some time ago I posted curve for GPU/CPU relative performance from AR.
Short answer - ReShedule does the best task distribution when it moves VLARs and VHARs to CPU.
GPU best suited for midrange ARs.
-
It works beautifull, only my X64 host, has sometimes, troubles, lost connection to local host, connecting. . . . .
REVerting to 'older'Drivers, 190.38 & 190.61 put an end to this and 'oher' UNexplained error's, which appeared to be heat problems and 'flat' the 'tower' , :olayed it on it's side
Even on VISTA Home Premium 32BIT, it works
And when I see 1 host with only CUDA and VHAR, then those are partly REbranded again for CPU.
-
Thanks Joe
Any reason for not putting it in the download section. I read a few pages in and noticed the original post was getting updated with every new version so gave up there thinking the OP had the latest version.
The primary reason is Marius is missing in action and not here to support his program. Need more be said?
:o Actually i have never left and i'm still reading threads but not as much as i would like as i'm very busy..
-
:o Actually i have never left and i'm still reading threads but not as much as i would like as i'm very busy..
Rumors of Marius' demise have been greatly exaggerated. ;)
-
It works beautifull, only my X64 host, has sometimes, troubles, lost connection to local host, connecting. . . . .
REVerting to 'older'Drivers, 190.38 & 190.61 put an end to this and 'oher' UNexplained error's, which appeared to be heat problems and 'flat' the 'tower' , :olayed it on it's side
Even on VISTA Home Premium 32BIT, it works
And when I see 1 host with only CUDA and VHAR, then those are partly REbranded again for CPU.
Heat problem you say? I have two comp: one is 24/7 with GTX 260 190.38 drivers and one is GT 240 with latest drivers from Nvidia. Ok I can understood that in noon I have heat problem ( my comp is on my balcony open case covered from sun, but I have same errors in midnight, so I doubt that I have "heat problem" then. So I suspect on older drivers as main reason of those errors :)
GPU temp never rise above 72°C so as I know that is low temperature for GTX 260 ( or maybe my sensor is broken) and card is overheating?
I the other side GT 240 with latest drivers have same error but only one or two in seven days, compared to few that I have with GTX 260 in one day
PROBLEM SOLVED: in my case it was weak power supply :) After replacement I have no more errors.
-
While I agree with Mark and Joe on the commitment to crunch all work assigned to the client computers, in reality it is unrealistic to expect this commitment to be achieved.
Using the Rescheduler tool to move the VLAR work to the CPU's very quickly overwhelms the CPU's. There are days when 2 or 3 times the work being moved than the CPU's are capable of in one day. The CPU's fall behind with the ever increasing larger cache for the CPU's work and eventually work starts being crunched too late.
I have then stopped using the Rescheduler tool to move the VLAR work to the CPU's. The CPU's can crunch the work assigned to them, including the VLAR work. I have also swithed the the "killer" app for the GPU's so the VLAR assigned to the GPU's will error out.
I do not care for this procedure as I feel that I am cherry picking the work. But in fact this is the only way that the client computers can run without constant attention to them.
If there is a better solution I am open for suggestions.
-
Yes if you have a high output machine, that is with many GPU cores, the amount of VLARS gets out of hand very quickly and your CPU can't hope to finish them not even after a month. If you use that machine and you care about it's responsiveness, you don't have other option than to abort them.
Well, if you're really determined to crunch them all, you could wait that month and see at the end that you really can't do them all and you have to ditch them after so much time sitting on them. And that would be worse.
-
I am still in a learning curve here, so this may have been discussed before. Sincs GPU's are not well suited for VLAR's, is there a way for S@H to only brand them for CPU use? That might help to balance the total work load. I recently depleted my cache to prepare for getting my GTX 480's crunching, and it took a coule of days to run out of GPU work, and close to two weeks to run out of CPU work. I attributed this to the VLAR's being rebranded for the CPU. If they came for CPU's in the first place, then it seems that the load would have been more balanced.
-
is there a way for S@H to only brand them for CPU use? That might help to balance the total work load.
This has been questioned before and for the moment the s@h servers doesn't do an AR analyse before sending it to a GPU host on their side.
The only two solutions is either by using Rescheduler for the moment or older series 2xx series and down can use a prepared VLAR kill .exe that checks the wu and if it's a VLAR then it's killed instantly.
Regards Vyper
-
.... Sincs GPU's are not well suited for VLAR's, is there a way for S@H to only brand them for CPU use? That might help to balance the total work load. I recently depleted my cache to prepare for getting my GTX 480's crunching, and it took a coule of days to run out of GPU work, and close to two weeks to run out of CPU work. I attributed this to the VLAR's being rebranded for the CPU. If they came for CPU's in the first place, then it seems that the load would have been more balanced.
I'll wade-in to answer your question Steve, but hope Devs. will correct me if I'm mistaken.
The project doesn't discriminate WUs to specific hardware and a WU can be assigned to any host w/ compatible OS and CPU and/or GPU.
The WU could be assigned to an Atom running Linux, a PowerPC 800 Mhz chip running OSX, or a 9400GT GPU.
From the project's perspective, there are such a wide range of performance differences with all the eligible hosts out there, that WU could just as easily be assigned to a Pentium III, as to a GTX285. Whether fast, or slow, if it falls into a supported HW/SW platform that can complete and validate by deadline, then the project considers it acceptable.
Discriminating VLARs specifically for CPU would essentially require a S@H GPU subproject w/ a separate application, so you could run both S@H CPU and S@H GPU applications at the same time. However, this would significantly complicate the back end project requirements and maintenance by Berkeley.
For a 2nd project, the efficiency/production gain would have to justify the additional expense and resources required at the project level.
Both of which are barely enough to support the current effort.
-
Thank you both. I understand now. I have been reading the threads, and realize that S@H has very few resources, and certainly doesn't need more responsibilities. It is amazing they have come as far as they have with such limited resources.
Steve
-
Thanks Gecko, I knew basically what you said but didn't know exactly how to say it so I stayed out of this one. And Steve, running projects on a shoestring is just what BOINC was designed for. SETI is pretty much the test bed for it though. I don't think they expected the shoestring to be quite as threadbare as SETI is. :-) That it has continued as long as it has with as little as it has is nothing short of a miracle!
-
More on subject though, I have been running the rescheduler since right after it was changed from a PERL script. (I was shaking in my boots thinking about having to figure out PERL! :-) ) I just keep my cache low enough so that it will get me through most outages but not so high that I get stuck with too many VLARs by rebranding that I can't get them done before they time out. I've only had a problem this way once but it was me changing something that required running my cache down right after we went through a VLAR storm. Not much you can do when all they send you are VLARs. I had to abort a few of them so that I could get it done before I chickened out! :-) I also keep the VLARKiller on my machine so that I don't get caught by a VLAR sneaking in after an outage but before the rescheduler kicks in. I've had this happen once or twice.
-
... hope Devs. will correct me if I'm mistaken.
...
Discriminating VLARs specifically for CPU would essentially require a S@H GPU subproject w/ a separate application, so you could run both S@H CPU and S@H GPU applications at the same time. However, this would significantly complicate the back end project requirements and maintenance by Berkeley.
...
It's not necessarily that complex. David Anderson added a feature to BOINC a few months ago intended for this. It requires the splitter to add something to the WU name which the Scheduler then recognizes and doesn't send such WUs to a CUDA host. It would be a fairly trivial splitter change, the code already has to deal with AR in order to set the rsc_fpops_est and related values appropriately. However, if the project were only splitting VLAR data then CUDA hosts might simply not get any work, the Scheduler change didn't include a method to send the work for CPU processing after it was judged unsuitable for GPU.
There was discussion on the boinc_dev mailing list concerning whether project cherry picking was any less reprehensible than user cherry picking. I pointed out that the only thing reprehensible about user cherry picking is the extra load on the servers from aborted tasks. I certainly think using participants' resources efficiently is a good idea, but I also suspect the typical user who reads the forums might find it difficult to see that difference between project and user actions which do similar things. BOINC is sufficiently advanced technology to be "magic" to many participants.
Joe
-
It's not necessarily that complex. David Anderson added a feature to BOINC a few months ago intended for this. It requires the splitter to add something to the WU name which the Scheduler then recognizes and doesn't send such WUs to a CUDA host. Joe
Thanks for the insight Joe. Personally, I'm glad to see this feature included in BOINC and it let's the project decide whether it wants to support this.
-
I had to abort some CPU Vlars a couple months ago or so but since then the reschedurer has done a pretty good job. A couple get thru but I do try and run every unit, so far am lucky my CPU units seem to stay just in reach of completion. I have been running a 7 day cache for about 2 months now.
-
It works beautifull, only my X64 host, has sometimes, troubles, lost connection to local host, connecting. . . . .
REVerting to 'older'Drivers, 190.38 & 190.61 put an end to this and 'oher' UNexplained error's, which appeared to be heat problems and 'flat' the 'tower' , :olayed it on it's side
Even on VISTA Home Premium 32BIT, it works
And when I see 1 host with only CUDA and VHAR, then those are partly REbranded again for CPU.
I had similar problem a few years ago. It turned out that gravity was stronger than the heatsink mounts. Bought a new heatsink with better mounting brackets.
-
For what it's worth, in 6 months of using the rebranding tool and not killing VLARs, I've only had one instance of a VLAR get to my GPU. I did upgrade my GPU to a 285 from an 8800 which does speed up CUDA units but the hourly running of Marius's tool seems to keep me running full out as long as there are work units to crunch.
-
A new rescheduling tool:
http://www.efmer.eu/forum_tt/index.php?topic=432.0
I try to actively maintain the project, so requests are welcome.
-
I tested ReSchedule1.9 on one of my hosts: An ION based HTPC (Intel Atom CPU + NVIDIA 8400M GPU).
Lots of WUs stopped with errors - this didn't happen before.
Questions:
1) Are SETI GPU tasks different from SETI CPU tasks (smaller, need less memory, etc.) ?
2) The GPU on my ION has 512MB (shared memory). Might this be the problem?
-
I tested ReSchedule1.9 on one of my hosts: An ION based HTPC (Intel Atom CPU + NVIDIA 8400M GPU).
Lots of WUs stopped with errors - this didn't happen before.
Questions:
1) Are SETI GPU tasks different from SETI CPU tasks (smaller, need less memory, etc.) ?
2) The GPU on my ION has 512MB (shared memory). Might this be the problem?
1) No, Seti GPU tasks are exactly the same as CPU tasks, but what app(s) are you running? Stock 6.08 and/or 6.09, or optimised V12?, they require different amounts of memory,
2) Maybe, it might be too slow, can you give us a link to the host please, then we can see what type of errors you're got
Claggy
-
1) No, they are exactly the same as CPU tasks, but what app(s) are you running? Stock 6.08 and/or 6.09, or optimised V12?
2) Maybe, can you give us a link to the host please
Claggy
1) I am using MB_6.08_CUDA_V12_VLARKill_FPLim2048.exe ... By the way: 6.09? Is there an optimized app for 6.09?
2) Link to host: http://setiathome.berkeley.edu/show_host_detail.php?hostid=5343396
(no bad WUs have been uploaded yet because of the scheduled outage)
-
1) No, they are exactly the same as CPU tasks, but what app(s) are you running? Stock 6.08 and/or 6.09, or optimised V12?
2) Maybe, can you give us a link to the host please
Claggy
1) I am using MB_6.08_CUDA_V12_VLARKill_FPLim2048.exe ... By the way: 6.09? Is there an optimized app for 6.09?
2) Link to host: http://setiathome.berkeley.edu/show_host_detail.php?hostid=5343396
(no bad WUs have been uploaded yet because of the scheduled outage)
1) the stock apps are 6.08 with Cuda 2.0, and 6.09 with Cuda 2.3, the optimised app can be run with Cuda 2.0, Cuda 2.2 or Cuda 2.3 dll's,
for Normal GPU's it's best run the Cuda 2.3 dll's since there is a 30% speed up with those,
but the Ion is relatively new (compared to the V12 app) and quite slow, and no one has done any tweaking to insure it works correctly, (no testers with Ions)
so you might find running one the stock apps a better choice, Sten-Arne reported on Seti Main that it works better,
Claggy
-
1) the stock apps are 6.08 with Cuda 2.0, and 6.09 with Cuda 2.3, the optimised app can be run with Cuda 2.0, Cuda 2.2 or Cuda 2.3 dll's,
for Normal GPU's it's best run the Cuda 2.3 dll's since there is a 30% speed up with those
Claggy
I am curious: I only see "setiathome_enhanced 6.08 (cuda)" tasks in my BOINC manager. Shouldn't I see something like "setiathome_enhanced 6.09 (cuda)" too?
-
1) the stock apps are 6.08 with Cuda 2.0, and 6.09 with Cuda 2.3, the optimised app can be run with Cuda 2.0, Cuda 2.2 or Cuda 2.3 dll's,
for Normal GPU's it's best run the Cuda 2.3 dll's since there is a 30% speed up with those
Claggy
I am curious: I only see "setiathome_enhanced 6.08 (cuda)" tasks in my BOINC manager. Shouldn't I see something like "setiathome_enhanced 6.09 (cuda)" too?
You're running Anonymous platform, so you'll only see what's referenced in your app_info, you can add Cuda23 and 609 entries as well, but it won't give you any extra speed, or extra Wu's, so don't worry,
if you were running the stock apps, (without an app_info) you might, as long as you had the right drivers and had enough GPU RAM available, then you would also have separate quotas for each app too,
Claggy
-
Hello Fred,
would it be possible to add a reschedule feature to your application to move Astropulse CPU tasks to Astropulse ATI GPU tasks?
-
Hello Fred,
would it be possible to add a reschedule feature to your application to move Astropulse CPU tasks to Astropulse ATI GPU tasks?
Yes, but I need the following
From this folder: C:\ProgramData\BOINC the client_state.xml
And this folder: C:\ProgramData\BOINC\projects\setiathome.berkeley.edu completely, you may remove the lunatics installer.
When you do, first stop the BOINC client, before you copy anything.
And of course the state file must have a Astropulse tasks in it that is not yet running.
The client state must accept the Astropulse ATI task, meaning you must have supplied a app_info.xml
Not to forget my email address is in the program about.
-
Hello Fred,
would it be possible to add a reschedule feature to your application to move Astropulse CPU tasks to Astropulse ATI GPU tasks?
Yes, but I need the following
From this folder: C:\ProgramData\BOINC the client_state.xml
And this folder: C:\ProgramData\BOINC\projects\setiathome.berkeley.edu completely, you may remove the lunatics installer.
Awesome :)
I made a ZIP of those files you requested + one screenshot of BOINC Manager so you can see all the relevant tasks:
- 3 Astropulse CPU Tasks
- 14 Astropulse ATI GPU Tasks
I've deleted all MB WUs from the BOINC directory - otherwise the ZIP would be even bigger. It's already over 100 MB so I can't send it via eMail.
You can access it here:
http://rapidshare.com/files/408888650/BOINC.zip
All the best!
Frizz
-
Awesome :)
I made a ZIP of those files you requested + one screenshot of BOINC Manager so you can see all the relevant tasks:
- 3 Astropulse CPU Tasks
- 14 Astropulse ATI GPU Tasks
I've deleted all MB WUs from the BOINC directory - otherwise the ZIP would be even bigger. It's already over 100 MB so I can't send it via eMail.
You can access it here:
http://rapidshare.com/files/408888650/BOINC.zip
All the best!
Frizz
But rapidshare is you worst nightmare. ;D
Tried it with Firefox with 3 different download managers, Internet Explorer.
All got stuck close to the beginning, free = not working.
Send me the client_state.xml by email lets see if that's enough.
-
But rapidshare is you worst nightmare. ;D
Tried it with Firefox with 3 different download managers, Internet Explorer.
All got stuck close to the beginning, free = not working.
Send me the client_state.xml by email lets see if that's enough.
Ok got it downloaded with JDownloader.
Version 1.4 should do the job. It's not tested live, so take care. http://www.efmer.eu/forum_tt/index.php?topic=463.msg1975#msg1975
-
Version 1.4 should do the job.
Thank you very much.
Version 1.4? Do you have a direct download link? Because all I can find on your page is "BoincTasks", which is version 0.66.
-
Version 1.4 should do the job.
Thank you very much.
Version 1.4? Do you have a direct download link? Because all I can find on your page is "BoincTasks", which is version 0.66.
version 1.4 is posted in this thread:
http://www.efmer.eu/forum_tt/index.php?topic=428.0 (http://www.efmer.eu/forum_tt/index.php?topic=428.0)
Claggy
Edit: I'm pleased i now have the capability to reschedule Astropulse_v505 between CPU and ATI GPU, but what will happen if used on a host with both ATI and Nvidia GPU's on a project with apps for both? ;D
-
Hi Fred,
Looks good, was able to move tasks from the GPU to the CPU then back again ;D
-
ReScheduling tasks from GPU to CPU works for me. But not the other way round.
The WUs get killed with this error message:
7/31/2010 5:58:26 PM SETI@home [error] No application found for task: windows_intelx86 506 ati13ati; discarding
This is what I have in my app_info.xml:
<name>astropulse_v505</name>
</app>
<file_info>
<name>ap_5.05_win_x86_SSE2_ATI_r434.exe</name>
<executable/>
</file_info>
<file_info>
<name>AstroPulse_Kernels.cl</name>
<executable/>
</file_info>
<app_version>
<app_name>astropulse_v505</app_name>
<version_num>506</version_num>
<avg_ncpus>0.01</avg_ncpus>
<max_ncpus>0.01</max_ncpus>
<plan_class>ati13ati</plan_class>
<coproc>
<type>ATI</type>
<count>1</count>
</coproc>
<flops>305987654321</flops>
<file_ref>
<file_name>ap_5.05_win_x86_SSE2_ATI_r434.exe</file_name>
<main_program/>
</file_ref>
<file_ref>
<file_name>AstroPulse_Kernels.cl</file_name>
<copy_file/>
</file_ref>
</app_version>
-
Put the following into your app_info, straight after the <version_num>506</version_num> entry:
<platform>windows_intelx86</platform>
But make sure you don't have any existing GPU tasks when you do it, otherwise you'll loose them too,
Claggy
Edit: added a dump file from my Atom for fred, then removed once downloaded.
-
The 2005 and 2010 compiler complain about an old not supported format.
Maybe the setting or the Atom. Probably the Atom.
-
Could you add re-schedule option for ATI MB too. It would simplify debugging a lot, especially with half of week outages...
I use next app_version for ATI MB now:
<app_version>
<app_name>setiathome_enhanced</app_name>
<version_num>610</version_num>
<platform>windows_intelx86</platform>
<avg_ncpus>0.05</avg_ncpus>
<max_ncpus>0.05</max_ncpus>
<plan_class>ati13ati</plan_class>
<file_ref>
<file_name>MB_6.10_win_SSE3_ATI_r101.exe</file_name>
<main_program/>
</file_ref>
<file_ref>
<file_name>MultiBeam_Kernels.cl</file_name>
<copy_file/>
</file_ref>
<coproc>
<type>ATI</type>
<count>1</count>
</coproc>
</app_version>
-
Could you add re-schedule option for ATI MB too. It would simplify debugging a lot, especially with half of week outages...
That should work, but I have no conformation from anybody yet.
Press test and the Preferred use box should be filled with all available classes.
Check if ATI is in that list.
-
ATI MB ... where can we get it? :)
-
ATI MB ... where can we get it? :)
In Russia ;)
-
Press test and the Preferred use box should be filled with all available classes.
Check if ATI is in th`t list.
Looks like you should put one more string in signature - for resheduler app ;)
-
ATI MB ... where can we get it? :)
In Russia ;)
LoL ;D
But the right question would be not where (here, of course, is the answer :) ) but when. Currently I debugging its behavior under BOINC. Hope alpha version will be soon, but who knows...
-
Press test and the Preferred use box should be filled with all available classes.
Check if ATI is in that list.
Looks like you should put one more string in signature - for resheduler app ;)
Let me know if it works.... or not.
-
Press test and the Preferred use box should be filled with all available classes.
Check if ATI is in that list.
Looks like you should put one more string in signature - for resheduler app ;)
Let me know if it works.... or not.
Ok, now I running your program and ready to make some comments:
1) No mention of ATI GPU at all. Preferred use checkbox has 2 options: none; 608,cuda
2) I have no ATI MB version in app_info now but have ATI AP in app_info - looks like app ignores AP tasks. At least it says there are 0 such tasks(0 GPU tasks at all) (actually it's 1 running, 2 downloading)
3) I checked box to prevent -177 errors. Now app shows in log:
14 August 2010 - 19:07:21 Out of range: rsc_fpops_bound < 500000000000000000.000000, total: 145
What it means? I have no issues with those SETI MB tasks, but over-estimated 3 AP tasks not shown.
-
Ok, now I running your program and ready to make some comments:
1) No mention of ATI GPU at all. Preferred use checkbox has 2 options: none; 608,cuda
2) I have no ATI MB version in app_info now but have ATI AP in app_info - looks like app ignores AP tasks. At least it says there are 0 such tasks(0 GPU tasks at all) (actually it's 1 running, 2 downloading)
3) I checked box to prevent -177 errors. Now app shows in log:
14 August 2010 - 19:07:21 Out of range: rsc_fpops_bound < 500000000000000000.000000, total: 145
What it means? I have no issues with those SETI MB tasks, but over-estimated 3 AP tasks not shown.
1) Means there is no app info in the client state.
2) Ap are ignored, the other tab can reschedule them but can't adjust any runtimes.
3) Checks enhanced only. The 145 don't have the rsc_fpops_bound updated to the higher value.
-
I see, OK. Nex run will be with ATI MB in place :)
-
I tried to use Fred's rescheduler, but is dows not have an option for the 610 ATI version and said there is no app.
Fred, is it possible to fix? New app already in alpa and soon will come to beta, we need your tool for it
-
I tried to use Fred's rescheduler, but is dows not have an option for the 610 ATI version and said there is no app.
Fred, is it possible to fix? New app already in alpa and soon will come to beta, we need your tool for it
False alarm, it works, I just checked it by myself. It rebraned 5 tasks from my CPU cache (still have some CPU MB work) to ATi GPU.
-
Hi, I have to say that it's about one month or more that I have errors in optimized applications:
Program crash and microsoft notification. 4 or 5 times a day (sometimes more) on 2 Horts witth Nvidia GPU.
So I have installed all news versions of BOINC, Cuda Drivers and your last optimize apps (win 32).
But the problem (program abort) is still the same.
On this hosts I was using rebranding but after update to last versions if I run this program I loose al tasks.
What else can I tell you to help you?
Franz
-
what exactly app do you use? (name of executable) What rebranding tool you use? (Fred's or Marius or? )
And, of course - stderr of failed task.
-
what exactly app do you use? (name of executable) What rebranding tool you use? (Fred's or Marius or? )
And, of course - stderr of failed task.
1) your last optimized apps (what else?) for win 32 [Win32 Lunatics' Unified Installer v0.37¨] with BOINC 6.10.58)
2) reschedule 1.9 (what else?)
3) How can I get it? I see only (after hours, when I see my monitor in the morning) the error message used by windows xp to communicate me that some application was in error during night. I don't know the run unit. How can I know it?
Franz
here some info
02.10.2010 17:04:40 Starting BOINC client version 6.10.58 for windows_intelx86
02.10.2010 17:04:40 Config: GUI RPC allowed from:
02.10.2010 17:04:40 Config: 192.168.1.36
02.10.2010 17:04:40 log flags: file_xfer, sched_ops, task
02.10.2010 17:04:40 Libraries: libcurl/7.19.7 OpenSSL/0.9.8l zlib/1.2.3
02.10.2010 17:04:40 Data directory: G:\Documents and Settings\All Users\Dati applicazioni\BOINC
02.10.2010 17:04:40 Running under account Francesco
02.10.2010 17:04:40 Processor: 2 GenuineIntel Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz [Family 6 Model 15 Stepping 6]
02.10.2010 17:04:40 Processor: 4.00 MB cache
02.10.2010 17:04:40 Processor features: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss htt tm pni ssse3 cx16 nx lm vmx tm2 pbe
02.10.2010 17:04:40 OS: Microsoft Windows XP: Home x86 Edition, Service Pack 3, (05.01.2600.00)
02.10.2010 17:04:40 Memory: 2.00 GB physical, 3.85 GB virtual
02.10.2010 17:04:40 Disk: 86.39 GB total, 56.27 GB free
02.10.2010 17:04:40 Local time is UTC +2 hours
02.10.2010 17:04:40 NVIDIA GPU 0: GeForce GTS 250 (driver version 25896, CUDA version 3010, compute capability 1.1, 1024MB, 470 GFLOPS peak)
02.10.2010 17:04:40 SETI@home Found app_info.xml; using anonymous platform
02.10.2010 17:04:41 SETI@home URL http://setiathome.berkeley.edu/; Computer ID 2693912; resource share 100
02.10.2010 17:04:41 SETI@home General prefs: from SETI@home (last modified 02-Jul-2010 07:50:06)
02.10.2010 17:04:41 SETI@home Computer location: home
02.10.2010 17:04:41 SETI@home General prefs: no separate prefs for home; using your defaults
02.10.2010 17:04:41 Reading preferences override file
02.10.2010 17:04:41 Preferences:
02.10.2010 17:04:41 max memory usage when active: 1023.55MB
02.10.2010 17:04:41 max memory usage when idle: 1842.39MB
02.10.2010 17:04:41 max disk usage: 43.20GB
02.10.2010 17:04:41 (to change preferences, visit the web site of an attached project, or select Preferences in the Manager)
02.10.2010 17:04:41 Not using a proxy
02.10.2010 17:04:41 SETI@home Restarting task 29my10ab.18955.495397.11.10.27.vlar_0 using setiathome_enhanced version 603
02.10.2010 17:04:41 SETI@home Restarting task 29my10ab.18955.495397.11.10.26.vlar_0 using setiathome_enhanced version 603
02.10.2010 17:04:41 SETI@home Restarting task 29my10ab.12384.188548.13.10.35_1 using setiathome_enhanced version 608
Readin log I see also 30 errors like this one
02.10.2010 18:53:24 SETI@home Aborting task 29my10ab.18955.495397.11.10.27.vlar_0: exceeded elapsed time limit 11359.349872
Should be them?
Franz
-
2) reschedule 1.9 (what else?)
Fred's rescheduler is better.
http://www.efmer.eu/forum_tt/index.php?topic=428.0
-
1) Lunatics installer can't be science application that perfomr work. It _installer_, it contains other apps.
I asked what executable you see in task manager (Ctrl-Shift-Esc in Windows to summon it).
2) There is eFmer (Fred's) Re-schedule, it should be used with latest builds, 1.9 deprecated now and not compatible with Lunatics 0.37 installer.
-
2) There is eFmer (Fred's) Re-schedule, it should be used with latest builds, 1.9 deprecated now and not compatible with Lunatics 0.37 installer.
1.9 works fine IF you edit app_info and changes <plan_class> to cuda and only have <version_num> of 608.
I don't need the other tools, as fixing -177, in the new reschedule program.
-
Readin log I see also 30 errors like this one
02.10.2010 18:53:24 SETI@home Aborting task 29my10ab.18955.495397.11.10.27.vlar_0: exceeded elapsed time limit 11359.349872
Should be them?
Those are "-177" errors caused by a new server side est. time adjustments. You can find out how to avoid them in the New Recheduler thread (http://setiathome.berkeley.edu/forum_thread.php?id=60712).
Also, you might wanna try using <flops>xxx</flops> entries in your app_info.xml (http://setiathome.berkeley.edu/forum_thread.php?id=60427) in order to hold your DCF arround 1.0
If you feel uncomfortable to manualy edit your app_info file, you can still use Fred's nice tool for that purpose too.
-
1.9 works fine IF you edit app_info and changes <plan_class> to cuda and only have <version_num> of 608.
I don't need the other tools, as fixing -177, in the new reschedule program.
You'll need to do this when you have no cuda tasks though, otherwise you need to edit the client_state as well, if yu don't you trash all your cuda tasks (as I found out to my cost :o)
-
I tried to use the rebrander and it didn't move any work. I recognized the ati card and app but didn't move any work.
-
2) There is eFmer (Fred's) Re-schedule, it should be used with latest builds, 1.9 deprecated now and not compatible with Lunatics 0.37 installer.
1.9 works fine IF you edit app_info and changes <plan_class> to cuda and only have <version_num> of 608.
I don't need the other tools, as fixing -177, in the new reschedule program.
I find that myself minutes ago ;D, but some people just doesn't feel so techie to manually overhaull their setups.
In which case, Fred's tool seems like a good option.
-
1) Lunatics installer can't be science application that perfomr work. It _installer_, it contains other apps.
I asked what executable you see in task manager (Ctrl-Shift-Esc in Windows to summon it).
2) There is eFmer (Fred's) Re-schedule, it should be used with latest builds, 1.9 deprecated now and not compatible with Lunatics 0.37 installer.
Ok, I have downoaded eFmer (Fred's) Re-schedule
About exe:
1) AK_v8b_win_SSE3x.exe
2) Lunatics_x32f_win32_cuda30_preview.exe
The xexecutable in error is alwais AK_v8b_win_SSE3x.exe
FF
-
The xexecutable in error is alwais AK_v8b_win_SSE3x.exe
FF
It's CPU-only app, so CUDA drivers will not help. Check if your CPU has SIMD of SSE3 level. If error arise from re-schedule - try new re-scheduler tool.
-
Ok, I have downoaded eFmer (Fred's) Re-schedule
About exe:
1) AK_v8b_win_SSE3x.exe
2) Lunatics_x32f_win32_cuda30_preview.exe
The xexecutable in error is alwais AK_v8b_win_SSE3x.exe
FF
On the expert tab put a check in "Limit rsc_fpops_bound": Normally unchecked. When checked, it will adjust the maximum runtime limit, to a way higher value, to avoid -177 errors.
The "exceeded elapsed time limit 11359.349872" errors you were getting are the -177 code.
Joe
-
Ok, I have downoaded eFmer (Fred's) Re-schedule
About exe:
1) AK_v8b_win_SSE3x.exe
2) Lunatics_x32f_win32_cuda30_preview.exe
The xexecutable in error is alwais AK_v8b_win_SSE3x.exe
FF
On the expert tab put a check in "Limit rsc_fpops_bound": Normally unchecked. When checked, it will adjust the maximum runtime limit, to a way higher value, to avoid -177 errors.
The "exceeded elapsed time limit 11359.349872" errors you were getting are the -177 code.
Joe
Ok, in the last week I have seen errors only in one host: http://setiathome.berkeley.edu/show_host_detail.php?hostid=2693912
So I have installed eFmer (Fred's) Re-schedule on that host and I have run it with the suggested option.
I will say you if the problem is solved.
Running "test for lost files" I see 31 ones. It's the same case (previuos errors)?
FF
-
Ok, in the last week I have seen errors only in one host: http://setiathome.berkeley.edu/show_host_detail.php?hostid=2693912
So I have installed eFmer (Fred's) Re-schedule on that host and I have run it with the suggested option.
I will say you if the problem is solved.
Running "test for lost files" I see 31 ones. It's the same case (previuos errors)?
FF
No it's not, and there is nothing to worry about. Sometimes BOINC can produce junk files (like tmp files in Windows) for a different reason i.e. wu errored out, bsod, power outage... and Fred was kind enough to implement an option to seek & destroy such files. Feel free to delete them but it is always recommended to backup your boinc data folder before using the tool. Just in case :)
-
Ok, in the last week I have seen errors only in one host: http://setiathome.berkeley.edu/show_host_detail.php?hostid=2693912
So I have installed eFmer (Fred's) Re-schedule on that host and I have run it with the suggested option.
I will say you if the problem is solved.
3 days without any error.
Good.
FF
-
3 days without any error.
Good.
FF
Good, and now 3 days without any new WU's ;D
-
2) reschedule 1.9 (what else?)
Fred's rescheduler is better.
http://www.efmer.eu/forum_tt/index.php?topic=428.0
so how can i move units to be a ratio of the total to gpu and cpu like in reschedule.exe??
-
so how can i move units to be a ratio of the total to gpu and cpu like in reschedule.exe??
Works by absolute and not relative figures - so not currently possible to give it % . You could ask Fred to add that?
But as Marius' 1.9 Rescheduler doesn't work with x32f...
-
I agree....
The simple slider setting of % to allocate between the CPU and GPU was a convenient way to do it.
-
The Seti servers try to figure out how long a wu will take on the assigned hardware and software and assign that time limit to the wu. If you then reschedule the task are you not inviting the dreaded -177 errors? Not to mention the flops values that the servers work out for your client computers is then all messed up.
For these reasons I have stopped using the reschedule tool and have not had a -177 error since before the major failure. And the flops values that Seti have are very accurate and in my app_info file.
No problems since not using the reschedule tool.
I should add......I rum MB on my GPU's only and AP on the CPU's.
-
Fred's rescheduling tool fixes the WUs to avoid the -177s.......
-
I do never use a rescheduler, I have no problem ;D
-
so how can i move units to be a ratio of the total to gpu and cpu like in reschedule.exe??
Works by absolute and not relative figures - so not currently possible to give it % . You could ask Fred to add that?
But as Marius' 1.9 Rescheduler doesn't work with x32f...
Ok, I just started seti again after a long long time..... (And now looking for a nvidia dual and amd solution)
Obvously i've not been paying attention the last year(s), i've just been reading a couple of private mesages and i will have a look if i can upgrade it. Or is the tool from Fred good enough in which case i will gladly pull back my Reschedule.
-
I happened to like the way your rescheduler worked....
And somebody else commented that they like the way you proportioned work between the CPU and GPU with the percentage slider, rather than by having to enter specific totals to shift back and forth.
If you have the time and are willing to have a go at updating it, I am sure many would like to have it available again.
Glad to have you back, Marius.
-
I happened to like the way your rescheduler worked....
And somebody else commented that they like the way you proportioned work between the CPU and GPU with the percentage slider, rather than by having to enter specific totals to shift back and forth.
If you have the time and are willing to have a go at updating it, I am sure many would like to have it available again.
Glad to have you back, Marius.
The main problem with the slider is that is messes up the server side estimates.
The only way to get this done properly is remember the one that are scheduled to the CPU of GPU. So the rescheduler moves them back first when needed. But that shouldn't be a mayor problem.
I've plenty of work with my other projects, and with the VLARS gone, there is only sporadic use of the scheduler.
-
I did have to use it during this last little outage. I just got a GTS450 and my cache still hadn't figured out how much work was needed to feed it when we went out. I had plenty of 6.03s but ran out of cuda work. Fed half of the CPU work over to the GPU, ran through them in no time and finally gave up and just moved all that I had left over to the GPU. Of course then I sat with no work for two days but..... such is life in the big city! ;D
-
V 0.25 allows VLARS to be moved to the Gpu.
It seems that some AMD Gpu's handle VLARS better than the CPU.
http://www.efmer.eu/forum_tt/index.php?topic=428.0
-
V 0.26 Has a Astropulse tab.
http://www.efmer.eu/forum_tt/index.php?topic=428.0
-
I have 4 CPU and 2 GPU (cuda) AP units on my host - but BoincRescheduler shows
before reschedule: 0/0
after reschedule: 0/0
I'm running BOINC Rescheduler64.exe
-
Morning Fred, I was thinking about rescheduling a couple before the got things going again but was a little worried about what it would do to the DCF. How bad will it mess up the timing on tasks if APs are rescheduled from CPU to GPU ?
-
Morning Fred, I was thinking about rescheduling a couple before the got things going again but was a little worried about what it would do to the DCF. How bad will it mess up the timing on tasks if APs are rescheduled from CPU to GPU ?
Depends on how efficient the GPU application is.
if you keep moving everything over to the GPU things will stabilize.
Best to disable the CPU AP altogether.
-
I have 4 CPU and 2 GPU (cuda) AP units on my host - but BoincRescheduler shows
before reschedule: 0/0
after reschedule: 0/0
I'm running BOINC Rescheduler64.exe
They are all still in 0.00%?
Did you enable the debug mode in the log?
Does the log show any errors?
If I could see the client state file client_state.xml. b#o#i#n#c at efmer dot com.
-
any activity on reschedule(r)?
-
any activity on reschedule(r)?
Question?
-
Not related to the rescheduler tool, Fred, but why do I not find your wonderful priority tool on your website?
Or am I not looking in the right place.
I would have wished to refer some folks to it from time to time, but did not know where to link them.
-
Not related to the rescheduler tool, Fred, but why do I not find your wonderful priority tool on your website?
Or am I not looking in the right place.
I would have wished to refer some folks to it from time to time, but did not know where to link them.
Hi, try this link:
http://www.efmer.eu/boinc/download.html
or
http://efmer.eu/download/boinc/priority/Priority_1_2.zip
or this thread:
http://www.efmer.eu/forum_tt/index.php?topic=198.15
for version 1.2 of priority
-
Thank you.
I must have missed it last time I looked.
Shall make a bookmark now.