RAC inaccurate with ReScheduler ?

Message boards : Number crunching : RAC inaccurate with ReScheduler ?
Message board moderation

To post messages, you must log in.

Previous · 1 · 2 · 3 · Next

AuthorMessage
Profile HAL9000
Volunteer tester
Avatar

Send message
Joined: 11 Sep 99
Posts: 6534
Credit: 196,805,888
RAC: 57
United States
Message 961448 - Posted: 7 Jan 2010, 5:15:22 UTC - in response to Message 961444.  


Ahh.. BTW..

Not only VLARs to CPU (and the other stay there for what they're DLed), I can set the ReScheduler to send only VLARs to CPU.
This would mean, all the nomal & VHAR WUs of CPU will be send to the GPU.



That makes sense, then you have all work being downloaded being sent to the "resource" that can handle it most effeciently. Keeping the CPU(s) and the GPU(s) working to the best of their ability. That would provide the most stable Maximum RAC.

Then by setting a moderate Cache you get the best turnaround time.

Regards


I think if BOINC clients would talk to each other over a local network. Then be able to move tasks around to the computers that can process them most effectively that would be good as well.

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[
ID: 961448 · Report as offensive
Profile Sutaru Tsureku
Volunteer tester

Send message
Joined: 6 Apr 07
Posts: 7105
Credit: 147,663,825
RAC: 5
Germany
Message 961449 - Posted: 7 Jan 2010, 5:18:48 UTC - in response to Message 961440.  
Last modified: 7 Jan 2010, 5:21:15 UTC

I don't think RAC gets effected to much. It's knows the CUDA overclaims credit, but that seems to get corrected. I don't know if it gets correct if two cuda do the same task.


No, no.. I don't speak about overclaim or others..

Only about, how accurate the RAC of a PC will be (compared to a PC which send back in the WU cache settings time and a PC) which use the ReScheduler and send back in an other 'result turnaround time'.


Sure, the CUDA overclaim is an other topic.
If two CUDA results will be compared, both PC get the overclaim granted.


____________
[Optimized project applications, for to increase your PC performance (double RAC)!][Overview of abbreviations, which are used often in forum and their meaning.]
ID: 961449 · Report as offensive
Profile Sutaru Tsureku
Volunteer tester

Send message
Joined: 6 Apr 07
Posts: 7105
Credit: 147,663,825
RAC: 5
Germany
Message 961451 - Posted: 7 Jan 2010, 5:35:20 UTC - in response to Message 961447.  
Last modified: 7 Jan 2010, 5:40:15 UTC

[...]
Ban VLARkill!.


You calculate VLAR WUs on CPU, because you use the ReScheduler?

I should now 'babysit' my PCs for to make ReSchedule, for to have max. performance of my GPUs.
No, thanks.. I have also other things to do.

If I would use the noVLARkill mod, the calculation time will increase ~ x6 (or much more, Raistmer made a graph) compared to normal AR WUs.

So, why to limit a PC with GPU and high performance (with calculation of VHAR & normal AR WUs on GPU), with to calculate also CUDA VLAR WUs?
In this time the GPU calculate a VLAR WU, he could calculate ~ 6 times more WUs.

So in which way the project could profit more?


____________
[Optimized project applications, for to increase your PC performance (double RAC)!][Overview of abbreviations, which are used often in forum and their meaning.]
ID: 961451 · Report as offensive
Luke
Volunteer developer
Avatar

Send message
Joined: 31 Dec 06
Posts: 2546
Credit: 817,560
RAC: 0
New Zealand
Message 961454 - Posted: 7 Jan 2010, 5:41:24 UTC - in response to Message 961451.  

[...]
Ban VLARkill!.


You calculate VLAR WUs on CPU, because you use the ReScheduler?

I should now 'babysit' my PCs for to make ReSchedule, for to have max. performance of my GPUs.
No, thanks.. I have also other things to do.

If I would use the noVLARkill mod, the calculation time will increase ~ x6 (or much more, Raistmer made a graph) compared to normal AR WUs.

So, why to limit a PC with GPU and high performance (with calculation of VHAR & normal AR WUs), with to calculate also VLAR WUs?
In this time the GPU calculate a VLAR WU, he could calculate ~ 6 times more WUs.

So in which way the project could profit more?


____________
[Optimized project applications, for to increase your PC performance (double RAC)!][Overview of abbreviations, which are used often in forum and their meaning.]


The project doesn't profit more in any way, since those (6x more) workunits will get crunched eventually by others.
It's a waste of resources at Berkeley (money, bandwidth, server usage) and for the wingman who suffers through it as well.

Also, I don't really think it's fair to quote my post out of context. That gives people the wrong impression as to my reasoning.
- Luke.
ID: 961454 · Report as offensive
Terror Australis
Volunteer tester

Send message
Joined: 14 Feb 04
Posts: 1817
Credit: 262,693,308
RAC: 44
Australia
Message 961455 - Posted: 7 Jan 2010, 5:42:55 UTC

Not 100% sure on this but, do the "killed" units count when working out the RAC ? i.e.they count in the number of returned units but with "zero" score.

Taking the simple average as [(1+2+3+n)/n], A computer running VLAR Kill would have a lower RAC than a computer running ReSchedule because of the high number of zero scores.

Does anyone more knowledgeable have a comment ?

Brodo
ID: 961455 · Report as offensive
Profile Sutaru Tsureku
Volunteer tester

Send message
Joined: 6 Apr 07
Posts: 7105
Credit: 147,663,825
RAC: 5
Germany
Message 961456 - Posted: 7 Jan 2010, 5:54:39 UTC - in response to Message 961454.  
Last modified: 7 Jan 2010, 5:58:54 UTC

The project doesn't profit more in any way, since those (6x more) workunits will get crunched eventually by others.
It's a waste of resources at Berkeley (money, bandwidth, server usage) and for the wingman who suffers through it as well.

Also, I don't really think it's fair to quote my post out of context. That gives people the wrong impression as to my reasoning.


Hmm.. you understood me correct?

My PC will delete this CUDA VLAR WU. This will be calculate on an other PC.
The other PC (with CPU) will not be hurted (he have a 1 1/2 hour crunching time).
In this time I calculate 6 (times more) WUs.
= 7 WUs.

The other way.
I calculate this CUDA VLAR WU. For example it will last 1 1/2 hours.
The other PC (which I mentioned before) calculate also one WU (in the same time).
= 2 WUs.

So, where profit more the science?


Why I should quote your whole message, if the people could read your whole message? For to stretch the thread? I answered related to your 'ban of the VLARkill mod'.


____________
[Optimized project applications, for to increase your PC performance (double RAC)!][Overview of abbreviations, which are used often in forum and their meaning.]
ID: 961456 · Report as offensive
Luke
Volunteer developer
Avatar

Send message
Joined: 31 Dec 06
Posts: 2546
Credit: 817,560
RAC: 0
New Zealand
Message 961457 - Posted: 7 Jan 2010, 6:08:07 UTC - in response to Message 961456.  

The project doesn't profit more in any way, since those (6x more) workunits will get crunched eventually by others.
It's a waste of resources at Berkeley (money, bandwidth, server usage) and for the wingman who suffers through it as well.

Also, I don't really think it's fair to quote my post out of context. That gives people the wrong impression as to my reasoning.


Hmm.. you understood me correct?

My PC will delete this CUDA VLAR WU. This will be calculate on an other PC.
The other PC (with CPU) will not be hurted (he have a 1 1/2 hour crunching time).
In this time I calculate 6 (times more) WUs.
= 7 WUs.

The other way.
I calculate this CUDA VLAR WU. For example it will last 1 1/2 hours.
The other PC (which I mentioned before) calculate also one WU (in the same time).
= 2 WUs.

So, where profit more the science?


Why I should quote your whole message, if the people could read your whole message? For to stretch the thread? I answered related to your 'ban of the VLARkill mod'.


____________
[Optimized project applications, for to increase your PC performance (double RAC)!][Overview of abbreviations, which are used often in forum and their meaning.]


Workunits just don't pop out of thin air if someone requests them. S@H piggyback a finite amount of data here. All the data gets crunched eventually.

So there is no science gain for the project, and you seem to be ignoring the fact that it costs S@H money and bandwidth to kill these WU's.

I don't think your on the same page...
- Luke.
ID: 961457 · Report as offensive
Profile Sutaru Tsureku
Volunteer tester

Send message
Joined: 6 Apr 07
Posts: 7105
Credit: 147,663,825
RAC: 5
Germany
Message 961458 - Posted: 7 Jan 2010, 6:08:34 UTC - in response to Message 961455.  


No, VLARkill WUs/results won't be counted.

The RAC is a calculation of well returned results.


____________
[Optimized project applications, for to increase your PC performance (double RAC)!][Overview of abbreviations, which are used often in forum and their meaning.]
ID: 961458 · Report as offensive
Profile HAL9000
Volunteer tester
Avatar

Send message
Joined: 11 Sep 99
Posts: 6534
Credit: 196,805,888
RAC: 57
United States
Message 961459 - Posted: 7 Jan 2010, 6:13:44 UTC - in response to Message 961455.  

Not 100% sure on this but, do the "killed" units count when working out the RAC ? i.e.they count in the number of returned units but with "zero" score.

Taking the simple average as [(1+2+3+n)/n], A computer running VLAR Kill would have a lower RAC than a computer running ReSchedule because of the high number of zero scores.

Does anyone more knowledgeable have a comment ?

Brodo


I looked over a few of my results & found these two.

Stock app.
wuid 551357574
Anonymous platform autokill enabled
wuid 551569374

Looks like the behavior is the same. Making autokill irrelevant.

However, back to Sutaru Tsureku's topic.
Credit seems to be more based on how much processing there is in a given task. It doesn't really matter what hardware processed the task. With rescheduler you are just making sure all of your processors are running tasks. Which may increase the machines RAC.

I see your machine 4789793 with 4 CPU & 4 GPU processors. Looking at the data on the web page. That is everything I know about your machine. It doesn't tell me if you run that machine 24/7, 1 hour a week, if your run 1 task at a time or 8.

I think you have said before you only run GPU. So I would expect another machine with the same hardware that runs GPU & CPU 24/7 to be a bit higher maybe.

I saw maybe because there is still much unknown about running GPU & CPU tasks at the same time. Unless someone is willing to run the same tasks over and over in different configurations & share the data. Then we may not ever know.

It could be that running 4 GTX 260's makes a lower RAC then 3 GTX 260's in the same motherboard.
SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[
ID: 961459 · Report as offensive
Profile Sutaru Tsureku
Volunteer tester

Send message
Joined: 6 Apr 07
Posts: 7105
Credit: 147,663,825
RAC: 5
Germany
Message 961460 - Posted: 7 Jan 2010, 6:18:40 UTC - in response to Message 961457.  


I see, you don't understand me.

You can't calculate 1 + 1 = 2 WUs. And 6 + 1 = 7 WUs?
We are here to calculate WUs. Why not so fast as possible?

Luke, please if you would like to post your meaning about VLARkill mod usage or not, open a new thread about (this is not the subject here).


____________
[Optimized project applications, for to increase your PC performance (double RAC)!][Overview of abbreviations, which are used often in forum and their meaning.]
ID: 961460 · Report as offensive
Profile HAL9000
Volunteer tester
Avatar

Send message
Joined: 11 Sep 99
Posts: 6534
Credit: 196,805,888
RAC: 57
United States
Message 961461 - Posted: 7 Jan 2010, 6:28:18 UTC - in response to Message 961460.  


I see, you don't understand me.

You can't calculate 1 + 1 = 2 WUs. And 6 + 1 = 7 WUs?
We are here to calculate WUs. Why not so fast as possible?

Luke, please if you would like to post your meaning about VLARkill mod usage or not, open a new thread about (this is not the subject here).


____________
[Optimized project applications, for to increase your PC performance (double RAC)!][Overview of abbreviations, which are used often in forum and their meaning.]


You are questioning if "VLARkill mod" & "no VLARkill mod + ReScheduler" = same RAC?
SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[
ID: 961461 · Report as offensive
Profile Sutaru Tsureku
Volunteer tester

Send message
Joined: 6 Apr 07
Posts: 7105
Credit: 147,663,825
RAC: 5
Germany
Message 961462 - Posted: 7 Jan 2010, 6:33:08 UTC - in response to Message 961461.  

You are questioning if "VLARkill mod" & "no VLARkill mod + ReScheduler" = same RAC?


Sure, but Luke talk about to ban the VLARkill mod.

We talk here about RAC.


Because of your other message, I'll answer later, I need to go now..


____________
[Optimized project applications, for to increase your PC performance (double RAC)!][Overview of abbreviations, which are used often in forum and their meaning.]
ID: 961462 · Report as offensive
kittyman Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 9 Jul 00
Posts: 51468
Credit: 1,018,363,574
RAC: 1,004
United States
Message 961471 - Posted: 7 Jan 2010, 7:20:26 UTC
Last modified: 7 Jan 2010, 7:23:01 UTC

My 3 Cuda rigs are all running the vlarkill app......only because I have been too lazy to download the non-vlarkill version and modify my app-info file to run it since I last detached and reattached to Seti.

BUT....I check the rescheduler tool and run it when necessary to shift any vlar work from the GPU to the CPU. I do this once or twice a day, so I suspect you will find very few if any vlarkilled WUs from my Cuda rigs.

I know that many who run the vlarkill app are not so inclined to do the monitoring and use the rescheduler tool so kindly provided at Lunatics to achieve the same end that I do.
This does allow the app to 'cherry pick' and was the main reason I held off on engaging in Cuda crunching as long as I did.

Once the rescheduler tool was made available, as well as the non-vlarkill app, I could get involved with Cuda crunching without betraying my staunch distaste for anything involving cherry picking of work to maximize a cruncher's output.

I have expressed my absolute disdain for picking and choosing what to crunch based on it's 'profitability' many times in this forum....those who have been around for a while know that.

Sooooooooo.....
Until the Lunatics folks come up with a better solution....and they ARE working on it.....
I suggest that folks make use of the rescheduler tool to let their rigs process all the work that their rigs are allocated by the Seti servers.

Do not burden the servers further by allowing the vlarkill app to toss out what doesn't Cudaspeak well.

I could go along with banning the vlarkill app......

That would force users to either use the rescheduler to make sure their Cuda cards do not process vlar work, or accept the fact the if they do not, they will have to process some dogs. Just like everybody else.
"Freedom is just Chaos, with better lighting." Alan Dean Foster

ID: 961471 · Report as offensive
Profile HAL9000
Volunteer tester
Avatar

Send message
Joined: 11 Sep 99
Posts: 6534
Credit: 196,805,888
RAC: 57
United States
Message 961500 - Posted: 7 Jan 2010, 9:49:19 UTC - in response to Message 961471.  


BUT....I check the rescheduler tool and run it when necessary to shift any vlar work from the GPU to the CPU. I do this once or twice a day, so I suspect you will find very few if any vlarkilled WUs from my Cuda rigs.


When I had a cuda card to use I ram rescheduler & just set it to auto check every 2 hours. At that time the 8500 was doing 30 min per task.
SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[
ID: 961500 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14650
Credit: 200,643,578
RAC: 874
United Kingdom
Message 961503 - Posted: 7 Jan 2010, 10:02:32 UTC

OK, I'll bite, and add my tuppence-worth.

Personally, I find RAC a completely (well, almost completely) useless measure of scientific progress. It's affected by far too many things independent of the performance of the host or user being 'measured': wingmate turnround, server stability, work availability and so on. Any holdup in the task pre- or post-processing pipeline will have an impact on RAC.

Having said that, is RAC inaccurate as a result of using any particular application or task-management technique? No, of course not. RAC is a mathematical derivative of the number of tasks validated (i.e. credit awarded) per unit time, per host computer. It takes no account of the resources applied (CPUs, GPUs, or the backs of envelopes) to achieve those validations. RAC just 'is', as a historical fact, and you can draw your own conclusions from it if you wish to.
ID: 961503 · Report as offensive
Profile Michael Goetz
Avatar

Send message
Joined: 14 May 99
Posts: 56
Credit: 622,268
RAC: 0
United States
Message 961517 - Posted: 7 Jan 2010, 12:52:18 UTC - in response to Message 961438.  
Last modified: 7 Jan 2010, 13:18:16 UTC

It seems the topic of the thread has been changed/clarified, so I'll rewrite this post appropriately.

Use of Reschedulers and VLARkill should increase the amount of science done on the computer running those tools, so one would expect the RAC to increase as a result.

That's pretty straightforward IMHO. The interesting discussion is whether more science gets done at SETI overall, or at all projects cumulatively, considering many of us crunch for multiple projects. I think it does, but I certainly understand why others don't think so.
Want to find one of the largest known primes? Try PrimeGrid. Or help cure disease at WCG.

ID: 961517 · Report as offensive
Profile Michael Goetz
Avatar

Send message
Joined: 14 May 99
Posts: 56
Credit: 622,268
RAC: 0
United States
Message 961520 - Posted: 7 Jan 2010, 13:06:03 UTC - in response to Message 961457.  
Last modified: 7 Jan 2010, 13:19:22 UTC

Post removed by author... see above for details.
ID: 961520 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 961521 - Posted: 7 Jan 2010, 13:11:11 UTC

Pretty interesting question.
It was stated many times that RAC by itself not very accurate measures host performance (cause RAC will be granted only after validation, sometimes there are no work at all and so on and so forth), but at least it's most closer thing to host performance.

What will give better performance - VLARKill or Re-schedule (@Sutaru, BTW, Re-schedule works in auto-mode too, no babysitting required) ?

What VLARKill does: it rejects task for crunching on GPU looking at task'a AR value. Usually it takes ~5 seconds to kill task. And in case of low-work state it may leave GPI completely idle. That is, we lost ~5 secs for each VLAR task.

What Re-schedule does: it shuts BOINC down, then marks all VLARs (looking at the very same AR value) as CPU jobs, then it starts BOINC again.
What we lost here: all active GPU tasks should be re-initialized. It's much longer than 5 seconds. What we gain here - such operation can be done only once per many hours and (in case of Marius app) BOINC will not restarted if no VLARs in GPU queue, that is, no addtitional overheads.
That is, let's say typical initialization time for GPU is ~20 secs, for host with 4 GPUs installed each re-schedulling will eat 20x4 seconds + few seconds (not much actually) for rebranding itself. This will roughly equal of killing 16 VLAR tasks (16*5=20*4).

If single rebranding session will rebrand more than 16 tasks, better do rebranding for such host, it will give better host performance (RAC).

That is, IMO the best way is to use Re-scheduling auto-running each ~10 (or more) hours and VLARkill app to cover few VLAR cases that can occur between rebranding sessions.
ID: 961521 · Report as offensive
Cruncher-American Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor

Send message
Joined: 25 Mar 02
Posts: 1513
Credit: 370,893,186
RAC: 340
United States
Message 961522 - Posted: 7 Jan 2010, 13:32:59 UTC

I don't get this whole thread.

I use Opt. apps (including VLARkill CUDA app) AND Reschedule. Am running BOINC 6.10.18.

SETI almost NEVER sends me CUDA WUs for some reason. And Reschedule doesn't kill any VLARs by sending them to GPU, and then having VLARkill skip them, but simply gives my CUDA cards something to do - it never sends them VLAR WUs, so my CPUs process them...

So how is this "cherry picking"???? (which I agree is wrong)? Or am I misunderstanding what the thread says or what I am doing?
ID: 961522 · Report as offensive
Profile Sutaru Tsureku
Volunteer tester

Send message
Joined: 6 Apr 07
Posts: 7105
Credit: 147,663,825
RAC: 5
Germany
Message 961729 - Posted: 8 Jan 2010, 0:57:01 UTC


Hmm..

My one & only question was: 'How accurate is a RAc of a PC which use the ReScheduler.'
Nothing more, nothing less.

I was only curious about how stable, because I thought the 'result turnaround time' will vary.
A PC have a 3 day WU cache. He DL a WU for GPU. The owner let run the ReScheduler. This GPU WU will be pushed to the CPU WU list.
If there are a lot of other CPU WUs, this WU will be crunched and the result will be sent to SETI@home later as the WU cache settings. Later than 3 days.

AFAIK, for a stable RAC it's important to have a 'result turnaround time' like the WU cache settings.

You could follow me?

So WUs which are meaned for GPU, will be crunched later.
Also possible, WUs for CPU will be crunched on GPU (later/earlier).

You could follow me?


It was only because of how accurate is the RAC for to compare with other PCs with a stable 'result turnaround time'.

Not because of: 'How I can increase my RAC to the max. possible?'

You could follow me?


O.K., O.K., .. this is only theoretically.. but also seen practically?


BUT, OTOH - this question isn't longer important (for me) (if I see this reaction on this forum) ..



HAL9000, because of my machines..
On both machines I let run CPU MB & CUDA MB. 24/7. If this RAC would be only after 1 hour/day, I would be happy..! :-D
QX6700 -> 4x MB & 1x CUDA
940 BE -> 4x MB & 4x CUDA

I use Fred's nice prog eFMer Priority.
It can increase the priority of the CUDA_app.

In past I didn't crunched on the CPU, because I saw a very big (x3 - x4) slowdown on GPUs. (Disturbed because of crunching on CPU. 'Bad' (too low) priority of the CUDA_app)
Now with the current settings only a very small slowdown/vary of the GPU results.


Raistmer, I saw messages about, that people had bad experiences to let run the ReScheduler in AUTO mode.
I have on my GPU cruncher ~ 2,000 WUs (3 day WU cache).
Only for calculate better.. 1x WU = 10 min./GPU
6 WUs/GPU/hour -> 144 WUs/GPU/day -> 576 WUs/4x GPU/day (maybe ~ 50 WUs on CPU) -> 626 WUs/day/whole machine
If also with shorties.. a shorty in ~ 2:10 min:s . Much more WUs.

Maybe this is too much work for the ReScheduler?


____________
[Optimized project applications, for to increase your PC performance (double RAC)!][Overview of abbreviations, which are used often in forum and their meaning.]
ID: 961729 · Report as offensive
Previous · 1 · 2 · 3 · Next

Message boards : Number crunching : RAC inaccurate with ReScheduler ?


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