Shameless Plug for Lunatics - ReSchedule 1.7 - 1.9

Message boards : Number crunching : Shameless Plug for Lunatics - ReSchedule 1.7 - 1.9
Message board moderation

To post messages, you must log in.

Previous · 1 · 2 · 3 · Next

AuthorMessage
Profile Lint trap

Send message
Joined: 30 May 03
Posts: 871
Credit: 28,092,319
RAC: 0
United States
Message 913957 - Posted: 4 Jul 2009, 12:28:30 UTC


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
ID: 913957 · Report as offensive
Profile Questor Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 3 Sep 04
Posts: 471
Credit: 230,506,401
RAC: 157
United Kingdom
Message 913959 - Posted: 4 Jul 2009, 12:33:24 UTC
Last modified: 4 Jul 2009, 13:26:41 UTC

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



ID: 913959 · Report as offensive
Terror Australis
Volunteer tester

Send message
Joined: 14 Feb 04
Posts: 1817
Credit: 262,693,308
RAC: 44
Australia
Message 913962 - Posted: 4 Jul 2009, 12:48:08 UTC - in response to Message 913957.  
Last modified: 4 Jul 2009, 12:51:09 UTC


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


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
ID: 913962 · Report as offensive
Profile Lint trap

Send message
Joined: 30 May 03
Posts: 871
Credit: 28,092,319
RAC: 0
United States
Message 913963 - Posted: 4 Jul 2009, 12:56:50 UTC - in response to Message 913962.  


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


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.

Brodo


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
ID: 913963 · Report as offensive
Fred W
Volunteer tester

Send message
Joined: 13 Jun 99
Posts: 2524
Credit: 11,954,210
RAC: 0
United Kingdom
Message 913964 - Posted: 4 Jul 2009, 13:05:39 UTC - in response to Message 913963.  


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


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.

Brodo


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

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.
ID: 913964 · Report as offensive
Profile Lint trap

Send message
Joined: 30 May 03
Posts: 871
Credit: 28,092,319
RAC: 0
United States
Message 913971 - Posted: 4 Jul 2009, 13:45:48 UTC - in response to Message 913964.  



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
ID: 913971 · Report as offensive
CryptokiD
Avatar

Send message
Joined: 2 Dec 00
Posts: 150
Credit: 3,216,632
RAC: 0
United States
Message 913986 - Posted: 4 Jul 2009, 14:45:49 UTC - in response to Message 913971.  

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.
ID: 913986 · Report as offensive
Profile Lint trap

Send message
Joined: 30 May 03
Posts: 871
Credit: 28,092,319
RAC: 0
United States
Message 913989 - Posted: 4 Jul 2009, 14:53:08 UTC
Last modified: 4 Jul 2009, 15:39:18 UTC

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
ID: 913989 · Report as offensive
Terror Australis
Volunteer tester

Send message
Joined: 14 Feb 04
Posts: 1817
Credit: 262,693,308
RAC: 44
Australia
Message 914037 - Posted: 4 Jul 2009, 18:45:35 UTC
Last modified: 4 Jul 2009, 18:51:39 UTC

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
ID: 914037 · Report as offensive
JohnDK Crowdfunding Project Donor*Special Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 28 May 00
Posts: 1222
Credit: 451,243,443
RAC: 1,127
Denmark
Message 914050 - Posted: 4 Jul 2009, 19:49:12 UTC

I love VLAR Kill since Boicn can't figure out that it should allocate them to CPU.
ID: 914050 · Report as offensive
OzzFan Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 9 Apr 02
Posts: 15691
Credit: 84,761,841
RAC: 28
United States
Message 914053 - Posted: 4 Jul 2009, 19:52:48 UTC - in response to Message 914050.  

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.
ID: 914053 · Report as offensive
Fred W
Volunteer tester

Send message
Joined: 13 Jun 99
Posts: 2524
Credit: 11,954,210
RAC: 0
United Kingdom
Message 914057 - Posted: 4 Jul 2009, 20:03:52 UTC - in response to Message 914050.  

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.


ID: 914057 · Report as offensive
JohnDK Crowdfunding Project Donor*Special Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 28 May 00
Posts: 1222
Credit: 451,243,443
RAC: 1,127
Denmark
Message 914089 - Posted: 4 Jul 2009, 21:44:05 UTC - in response to Message 914053.  
Last modified: 4 Jul 2009, 21:47:47 UTC

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.

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.
ID: 914089 · Report as offensive
JohnDK Crowdfunding Project Donor*Special Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 28 May 00
Posts: 1222
Credit: 451,243,443
RAC: 1,127
Denmark
Message 914092 - Posted: 4 Jul 2009, 21:46:31 UTC - in response to Message 914057.  

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.


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.
ID: 914092 · Report as offensive
OzzFan Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 9 Apr 02
Posts: 15691
Credit: 84,761,841
RAC: 28
United States
Message 914160 - Posted: 5 Jul 2009, 0:48:36 UTC - in response to Message 914089.  

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.

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.


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.
ID: 914160 · Report as offensive
Grant (SSSF)
Volunteer tester

Send message
Joined: 19 Aug 99
Posts: 13720
Credit: 208,696,464
RAC: 304
Australia
Message 914161 - Posted: 5 Jul 2009, 0:59:16 UTC - in response to Message 914160.  

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
ID: 914161 · Report as offensive
Josef W. Segur
Volunteer developer
Volunteer tester

Send message
Joined: 30 Oct 99
Posts: 4504
Credit: 1,414,761
RAC: 0
United States
Message 914216 - Posted: 5 Jul 2009, 3:28:58 UTC - in response to Message 914160.  

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
ID: 914216 · Report as offensive
FiveHamlet
Avatar

Send message
Joined: 5 Oct 99
Posts: 783
Credit: 32,638,578
RAC: 0
United Kingdom
Message 914276 - Posted: 5 Jul 2009, 7:40:10 UTC

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.

ID: 914276 · Report as offensive
Profile Gundolf Jahn

Send message
Joined: 19 Sep 00
Posts: 3184
Credit: 446,358
RAC: 0
Germany
Message 914285 - Posted: 5 Jul 2009, 8:15:36 UTC - in response to Message 914276.  

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.

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
ID: 914285 · Report as offensive
FiveHamlet
Avatar

Send message
Joined: 5 Oct 99
Posts: 783
Credit: 32,638,578
RAC: 0
United Kingdom
Message 914286 - Posted: 5 Jul 2009, 8:19:15 UTC - in response to Message 914285.  

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.
ID: 914286 · Report as offensive
Previous · 1 · 2 · 3 · Next

Message boards : Number crunching : Shameless Plug for Lunatics - ReSchedule 1.7 - 1.9


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