SETI Orphans. Can we go back to E@H?

Jim1348
Jim1348
Joined: 19 Jan 06
Posts: 458
Credit: 233,122,964
RAC: 917

Ron Kosinski wrote:Will

Ron Kosinski wrote:
Will someone let me know if Einstein and MilkyWay programs will share resources nicely?

I have frequently run MilkyWay N-body on the CPU and Einstein (either GW or Pulsar) on the GPU.  That works well, but I think my RX 570 gets a lot of the credit.  You could do it the other way too, with the RX 570 on MilkyWay and Einstein on the CPU.

But I would avoid Nvidia cards on MilkyWay; they don't have either good dual-precision or OpenCl performance.  The people who claim they get good output are getting terrible efficiency.

mikey
mikey
Joined: 22 Jan 05
Posts: 8,775
Credit: 923,921,386
RAC: 4,194,948

Ron Kosinski wrote:Just heard

Ron Kosinski wrote:
Just heard about SETI@Home shutting down.  I have been crunching both Einstein and SETI@Home for many years.  I have got them to play nice together sharing resources on CPU and nvidia GPU work units.  I was considering joining up with MilkyWay@Home.  Will someone let me know if Einstein and MilkyWay programs will share resources nicely?

I have 2 Nvidia 760 gpu's in a machine that runs both MilkyWay and Einstein workunits and the only problem is the 10 minute backoff time to get new gpu workunits from MilkyWay. That is a Server side problem that the new Admins don't know how to fix, the cpu workunits flow just fine.

And I also agree that AMD cards do much better at MilkyWay than Nvidia cards do.

mohavewolfpup
mohavewolfpup
Joined: 8 Mar 20
Posts: 9
Credit: 5,768,052
RAC: 0

Former seti@home Team Art

Former seti@home Team Art bell orphan here. When my primary workhorse is done processing units, then it will join up here.

Even though I know there is a bunch of math involved here, at least I don't have to figure out fully what is going on! My least favorite subject in school due to teachers and their rhetoric, so the idea of the other boinc projects doing general processing for math involving long strings of numbers and god knows what else? Pass.

At least helping find a Gravitational wave even if I can't see it with the naked eye it's easier to look skyward and go "cool, I helped a small fraction with that"

If seti@home ever processes all it's data and comes back online, would jump back there. But this will be my new home for the meantime since that will be a long time coming, if at all

archae86
archae86
Joined: 6 Dec 05
Posts: 3,071
Credit: 6,022,999,237
RAC: 2,424,151

While I joined SETI far over

While I joined SETI far over a decade ago, I have not contributed any computing power there in years, and no longer check the forums.

Still, I extend a warm welcome to people coming here from SETI.  Here are a few tips which could make your first days easier on Einstein, easier on your fellow participants, and more productive for you.

Brief version:

1. set a really short queue depth until you see how your choices and your hardware play together, and completion time estimates stabilize.  Try 0.1 days.

2. Consider only enabling one particular type of Einstein task to run on a given system--then alter that choice to see what works best for you.

Long-winded version:

The way Einstein guesses how long it will take an Einstein task to run on your system gives wildly wrong answers at first.  While it should converge to a good estimate within a few dozen task completions if you run only a single work type, it can not only stay wildly wrong, but fluctuate in a problematic way if you mix work.

While Einstein has had outages, most of the time work supply has been very reliable.  Plenty of serious users here run queue depths of about 0.1 day.  There are good reasons you might choose a longer number, but none of them require you to do so right at the beginning.

If you choose to run both Gravity-wave and Gamma-Ray pulsar GPU jobs at the same time, the hugely different converged values will never settle down--so you'll bang around between massive overfetching and quick completion.  If you over-fetch enough that your tasks time out, you actually cost the project extra resources to cancel your task and send out a new one.  You also delay your fellow participants' chance to figure out whether their task ran properly, and to get credit.  

So I suggest you visit your account page here at Einstein, go to the project preferences section, and opt out of most kinds of work on offer, preferably arranging to get just one flavor.  You'll need to know which location (a.k.a. venue) your machine of interest is assigned to.

In the interest of not making this post so long no one will read it, I'll stop here.  There is plenty of help available here or in Problems and Bug Reports if you have difficulty navigating the preference items.  Just ask.

 

 

 

wandrr
wandrr
Joined: 1 Dec 17
Posts: 4
Credit: 329,457,715
RAC: 0

archae86 wrote:While I joined

archae86 wrote:

While I joined SETI far over a decade ago, I have not contributed any computing power there in years, and no longer check the forums.

Still, I extend a warm welcome to people coming here from SETI.  Here are a few tips which could make your first days easier on Einstein, easier on your fellow participants, and more productive for you.

<snip>

 

Thanks very much, Archae86. You have already helped me with the "different types of work" question. As a SETI Orphan, I miss the highly optimized code that exists back there, but I now have four of my five crunchers switched over. Now to let things settle a bit and see what the server serves up. One more small part-time machine to go.

Arnie

Keith Myers
Keith Myers
Joined: 11 Feb 11
Posts: 2,410
Credit: 6,754,317,017
RAC: 23,926,122

I agree there is an issue

I agree there is an issue with mixed project scheduling.  Because of the wildly different estimations of task times.  I have been able to successfully run a mixed project host with a 0.2 day cache setting. GW cpu and GW gpu and GRP gpu tasks get along together pretty well.

 

Speedy
Speedy
Joined: 11 Aug 05
Posts: 22
Credit: 10,571,507
RAC: 4,554

Quote:But I would avoid

Quote:
But I would avoid Nvidia cards on MilkyWay; they don't have either good dual-precision or OpenCl performance.  The people who claim they get good output are getting terrible efficiency.

I would like to point out there is a considerable number of Nvidia cards over at MilkyWay

Mike Hewson
Mike Hewson
Moderator
Joined: 1 Dec 05
Posts: 6,358
Credit: 185,076,579
RAC: 612,109

AMD OpenCL drivers are more

AFAIK/IIRC : AMD OpenCL drivers are more efficient than NVIDIA OpenCL drivers, at least because NVDIA implements OpenCL via an extra  layer ( CUDA ) that AMD doesn't have.

Cheers, Mike.

I have made this letter longer than usual because I lack the time to make it shorter ...

... and my other CPU is a Ryzen 5950X :-) Blaise Pascal

Keith Myers
Keith Myers
Joined: 11 Feb 11
Posts: 2,410
Credit: 6,754,317,017
RAC: 23,926,122

I have enough cards that I

I have enough cards that I don't need to go out and buy AMD specifically for MW.  The Nvidia cards are good enough for the resource share I allot MW.  They work fine at GPUGrid and Einstein.

If a user was starting from scratch, sure go ahead and get the better platform if this project is all you will crunch for.

 

mikey
mikey
Joined: 22 Jan 05
Posts: 8,775
Credit: 923,921,386
RAC: 4,194,948

Keith Myers wrote:I have

Keith Myers wrote:

I have enough cards that I don't need to go out and buy AMD specifically for MW.  The Nvidia cards are good enough for the resource share I allot MW.  They work fine at GPUGrid and Einstein.

If a user was starting from scratch, sure go ahead and get the better platform if this project is all you will crunch for.

And for me that's always been the quandry get the best card for project a which is not the best card for project b or get the best card for the money and settle for the results being great at project a and medicore at project b, but still getting credits at 2, or more, projects instead of just the few that support one brand or the other. Personally over time I am able to buy both types of cards but since they are aquired over years they are not all the same quality they once were so project a may get a less than ideal gpu put on it because project d has a much better gpu on it.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.