Message boards :
Number crunching :
Shameless Plug for Lunatics - ReSchedule 1.7 - 1.9
Message board moderation
Previous · 1 · 2 · 3 · Next
Author | Message |
---|---|
Lint trap Send message Joined: 30 May 03 Posts: 871 Credit: 28,092,319 RAC: 0 |
The rebranding tools may work fine as long as you have a cache built up and the tool can analyze wu's before they begin crunching, but so far today I've had only two MB wu's show up. One was a VLAR and Raistmer's kill feature did it's job, the other was worked and returned normally. Martin |
Questor Send message Joined: 3 Sep 04 Posts: 471 Credit: 230,506,401 RAC: 157 |
On my Vista 64, the BOINC data directory is C:\Users\All Users\BOINC but Reschedule can't see this path. Looking at All Users it is a shortcut to C:\ProgramData and the data is actually in C:\ProgramData\BOINC However, ProgramData was a hidden directory and I had to unhide it for Reschedule to see it. Don't know if this is standard or just how mine ended up. Might be the same on W7 also. [Edit : going to have to go back and check through lunatics thread. I thought I had sorted this out - hadn't yet tried it on my Vista 64 machine, but although it is now able to find the client_state.xml it says I have no tasks at all CPU or GPU. GPU Users Group |
Terror Australis Send message Joined: 14 Feb 04 Posts: 1817 Credit: 262,693,308 RAC: 44 |
The idea of this program is to make "VLAR Kill" redundant by reassigning the VLAR units to the CPU where they crunch much more efficiently. If your going to use the program you have to disable VLAR kill ! You cannot reassign a killed unit. The program can reassign a unit even after its begun to crunch. It just waits until the desired processor is free to continue. Brodo |
Lint trap Send message Joined: 30 May 03 Posts: 871 Credit: 28,092,319 RAC: 0 |
You missed my point. What I am saying is that if you have no cache as many of us do today because of the recent lack of downloads, the rebrand tool may not get a chance to analyze an incoming wu because it begins crunching immediately. In that case, you could still end up with a VLAR going to a GPU. Martin |
Fred W Send message Joined: 13 Jun 99 Posts: 2524 Credit: 11,954,210 RAC: 0 |
But if you hadn't been running the VLAR autokill, then the VLAR would have been marked to run on the CPU and the non-VLAR would have run on the GPU and you would have returned 2 completed WU's instead of 1 completed and 1 "error". Read again the last sentence of Brodo's post (the sentence that you omitted to quote). F. |
Lint trap Send message Joined: 30 May 03 Posts: 871 Credit: 28,092,319 RAC: 0 |
Well, that's great! For once, I didn't edit my quote, but I missed Brodo's statement that reassignment can happen even after crunching begins. I'm going to have to try the latest 1.8 version then. I was hesitant because I believed I could still end up 'stuck' with a VLAR on the GPU. Thanks to both you and Brodo for the education! Martin |
CryptokiD Send message Joined: 2 Dec 00 Posts: 150 Credit: 3,216,632 RAC: 0 |
finally got it to work on windows 7, however i cant get the program to assign vlars to cpu only. my gpu still gets vlar. however going from no gpu work at all to some vlar is still welcomed. at least my gpu is doing something. |
Lint trap Send message Joined: 30 May 03 Posts: 871 Credit: 28,092,319 RAC: 0 |
1.8: -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 above statement is from Reschedule.txt in the 1.8 version. It seems that rebranding after crunching has begun is no longer true. I have a VLAR killer and the 1.8 version running now. [edited] Martin |
Terror Australis Send message Joined: 14 Feb 04 Posts: 1817 Credit: 262,693,308 RAC: 44 |
I'm running V1.7 which is why I made the above post, in that version you can change a running unit. [political rant] NOT aimed at anyone in particular Something that's been bugging me for a while. I really don't understand what the big issue over VLAR's is about. On my 8600GT cards they take around 2.5 hours to crunch, on the GTS250 they chew through in just over an hour. The way people talk about them anyone would think they took longer than an AP to complete. If you let them go you will see that the estimated time increases out until they're about 25% completed and yes this can sometimes read as 4 or 5 hours, But this is only an estimate remember. Once they reach their trigger point the estimated time to completion will fall rapidly, often by as much as one minute per second of crunching time and they finish in the times stated above, quicker if your running a GTX295 or similar. Occasionally you will get one that's particularly "chewy" (the ones from the 06dec08 series are in this class) but mostly a restart of the client will fix things, if it doesn't, then it can be aborted. I've noticed that some "normal" units can have "chewy" bits in them too, where the estimated time will start to blow out till the card has sorted itself out. All GPU crunched units start slow and finish fast. VLAR's are nothing to be scared of, it's just a case of "give a dog a bad name" because GPU units don't behave like CPU ones we're used too. Re the above paragraph. Isn't it better to abort just one unit rather than bouncing anything up to 60% of your allocated units, clogging up the servers and passing the buck onto someone else ? Afterall SOMEONE has to crunch them, VLAR Kill is nothing but pure selfishness ! [/political rant] Brodo |
JohnDK Send message Joined: 28 May 00 Posts: 1222 Credit: 451,243,443 RAC: 1,127 |
I love VLAR Kill since Boicn can't figure out that it should allocate them to CPU. |
OzzFan Send message Joined: 9 Apr 02 Posts: 15691 Credit: 84,761,841 RAC: 28 |
I love VLAR Kill since Boicn can't figure out that it should allocate them to CPU. BOINC shouldn't figure it out. BOINC is just a management program that retrieves workunits and sends them back. It should be the science app that makes the proper distinction and shuffles them accordingly. |
Fred W Send message Joined: 13 Jun 99 Posts: 2524 Credit: 11,954,210 RAC: 0 |
I love VLAR Kill since Boicn can't figure out that it should allocate them to CPU. But you do now have an alternative - to re-direct them to your CPU for processing there and save the bandwidth of them being sent out again (and again - and again). F. |
JohnDK Send message Joined: 28 May 00 Posts: 1222 Credit: 451,243,443 RAC: 1,127 |
I love VLAR Kill since Boicn can't figure out that it should allocate them to CPU. If I understand you correctly, SETI could do it if programed for it? I guess only a very few of of all those doing SETI reads these forums and notice this plug-in. |
JohnDK Send message Joined: 28 May 00 Posts: 1222 Credit: 451,243,443 RAC: 1,127 |
I love VLAR Kill since Boicn can't figure out that it should allocate them to CPU. I would do it if my machine wasn't so slow, I'm not getting that many VLARs, sometimes days where there isn't any, don't want to install another program for that. |
OzzFan Send message Joined: 9 Apr 02 Posts: 15691 Credit: 84,761,841 RAC: 28 |
I love VLAR Kill since Boicn can't figure out that it should allocate them to CPU. Yes. The SETI science application could be programmed to check the workunit before loading it, and if the workunit is a VLAR, it could redirect it to the CPU if it was originally intended for the GPU. |
Grant (SSSF) Send message Joined: 19 Aug 99 Posts: 13751 Credit: 208,696,464 RAC: 304 |
Yes. The SETI science application could be programmed to check the workunit before loading it, and if the workunit is a VLAR, it could redirect it to the CPU if it was originally intended for the GPU. Of course the ideal situation would be to fix the CUDA application so it didn't choke enough on those Work Units to upset the crunchers & make them feel the need to bump it off to someone else. Grant Darwin NT |
Josef W. Segur Send message Joined: 30 Oct 99 Posts: 4504 Credit: 1,414,761 RAC: 0 |
The SETI science application could be programmed to check the workunit before loading it, and if the workunit is a VLAR, it could redirect it to the CPU if it was originally intended for the GPU. Easily, but the BOINC core client is assuming the task is fully ocuupyimg a GPU so won't start another GPU task there, and it's assuming that most of the CPU is free to be used, so will start another CPU task. Since tasks come in similar groups both are likely to be VLAR, so it might not be practical to swap that next task to the GPU. What's needed is a feedback capability from the science app to the core client. Simply telling the core client the work is going to fully occupy the CPU and not use the GPU might be enough for this VLAR situation, probably something more general should be figured out (it'll be needed for some project, I'm sure). Joe |
FiveHamlet Send message Joined: 5 Oct 99 Posts: 783 Credit: 32,638,578 RAC: 0 |
Forgive me if I missed something somewhere. Is there a way that a ReSchedule prog can be reworked so that 6.03 tasks can be done by the GPU's. Over the last 24 hrs I have received 1300 6.03 tasks even though I have 2 GPU's idle. Requests are sent for gpu work but none arrive. |
Gundolf Jahn Send message Joined: 19 Sep 00 Posts: 3184 Credit: 446,358 RAC: 0 |
Forgive me if I missed something somewhere. If I have understood correctly ReSchedule works in both directions. Gruß, Gundolf Computer sind nicht alles im Leben. (Kleiner Scherz) SETI@home classic workunits 3,758 SETI@home classic CPU time 66,520 hours |
FiveHamlet Send message Joined: 5 Oct 99 Posts: 783 Credit: 32,638,578 RAC: 0 |
Thanks for that. I have tried to set ReSchedule up but cant seem to put it in the right place,and set the directories correct. I am running Vista 64bit and the directories are wrong. Can anyone point me in the right direction. |
©2024 University of California
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.