Hello Darren, the first thing to do is get used to the information available in the "advanced" view. This will tell you which tasks are running, how long they have been running for and give you access to the first level of optimising your system.
BOINC is designed to provide a "fit and forget" environment for projects such as SETI to run in, it does much of the day to day stuff for you - fetching work, controlling when work runs, reporting it. It is really your call on how much fiddling you do - you can sit back and watch the numbers click up or your sit there worrying that this task is taking a few seconds longer than the previous one and how can you get them all to run in the same time (the answer to the latter is "you can't, each task is unique".

Once you've got used to how your computer runs you might want to consider a bit of tuning, or you may decide its doing OK, your call, and provided it is returning valid results don't be bullied to do something "because Joe told me to".

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Since the core is going to get used anyway, why not use it the most efficient way to crunch those VLARS?

Efficient is to send a task to a processing unit, which can process it fastest compared to other type of work on the same PU. Sending a VLAR to a GPU, which could crunch 3-4 mid-AR tasks (according to message 1779961) in the same time is waisting of ressources, since a CPU does the VLAR in nearly same time as a mid-AR WU.

---

Hello Darren, the first thing to do is get used to the information available in the "advanced" view. This will tell you which tasks are running, how long they have been running for and give you access to the first level of optimising your system.
BOINC is designed to provide a "fit and forget" environment for projects such as SETI to run in, it does much of the day to day stuff for you - fetching work, controlling when work runs, reporting it. It is really your call on how much fiddling you do - you can sit back and watch the numbers click up or your sit there worrying that this task is taking a few seconds longer than the previous one and how can you get them all to run in the same time (the answer to the latter is "you can't, each task is unique".

Once you've got used to how your computer runs you might want to consider a bit of tuning, or you may decide its doing OK, your call, and provided it is returning valid results don't be bullied to do something "because Joe told me to".

Extremely good advice and stick to the advice by those with similar hardware and operating system to yours (if the person has their PC's hidden or won't give you a link to similar hardware then don't take it). ;-)

[edit] click on their user name to check

Cheers.

Efficient is to send a task to a processing unit, which can process it fastest compared to other type of work on the same PU. Sending a VLAR to a GPU, which could crunch 3-4 mid-AR tasks (according to message 1779961) in the same time is waisting of ressources, since a CPU does the VLAR in nearly same time as a mid-AR WU.

Again, this is only correct for CUDA. The VLAR issue does not affect OpenCL so GUPPI work units would complete in about the same time. Most people are going to have both platforms available, as far as I know. All we ask for is to be able to make the decision to run them ourselves.

---

Efficient is to send a task to a processing unit, which can process it fastest compared to other type of work on the same PU. Sending a VLAR to a GPU, which could crunch 3-4 mid-AR tasks (according to message 1779961) in the same time is waisting of ressources, since a CPU does the VLAR in nearly same time as a mid-AR WU.

Again, this is only correct for CUDA. The VLAR issue does not affect OpenCL so GUPPI work units would complete in about the same time. Most people are going to have both platforms available, as far as I know. All we ask for is to be able to make the decision to run them ourselves.

What about 1779961? As I understand it, the performance is decreased by factor 3-4, so OpenCL is affected, but the issue is "just" performance. I don't see why someone would want to do only 1/3 or 1/4 of what he can actually do for the project.

---

I don't see why someone would want to do only 1/3 or 1/4 of what he can actually do for the project.

I estimate we have from hundreds to thousands of times greater of a chance finding ETI in a GBT work unit than an Arecibo one, because it is targeted to stars that are nearby, known to have exoplanets, and known (or thought) to have them in favourable positions for life (as we know it, Jim.)

It comes down to quality over quantity. And it's rather sadly ironic that the people who have contributed to this project the most over the years in terms of work done and time/money/effort invested in doing so are now mostly excluded from its most anticipated and promising venture.

---

I don't see why someone would want to do only 1/3 or 1/4 of what he can actually do for the project.

I estimate we have from hundreds to thousands of times greater of a chance finding ETI in a GBT work unit than an Arecibo one, because it is targeted to stars that are nearby, known to have exoplanets, and known (or thought) to have them in favourable positions for life (as we know it, Jim.)

It comes down to quality over quantity. And it's rather sadly ironic that the people who have contributed to this project the most over the years in terms of work done and time/money/effort invested in doing so are now mostly excluded from its most anticipated and promising venture.

It should be improved even more when Parkes data comes online. ;-)

Cheers.

I don't see why someone would want to do only 1/3 or 1/4 of what he can actually do for the project.

I estimate we have from hundreds to thousands of times greater of a chance finding ETI in a GBT work unit than an Arecibo one, because it is targeted to stars that are nearby, known to have exoplanets, and known (or thought) to have them in favourable positions for life (as we know it, Jim.)

It comes down to quality over quantity. And it's rather sadly ironic that the people who have contributed to this project the most over the years in terms of work done and time/money/effort invested in doing so are now mostly excluded from its most anticipated and promising venture.

It should be improved even more when Parkes data comes online. ;-)

Cheers.

Maybe we need also ntpckr?

Mine was not a question, only a statement. I get what credit every project gives me, no problem.
Tullio

---

Hello guys
I have a question, how will ET or T signal look on this graph?

Flopcounter: 21396376633963.023000

Spike count: 2
Autocorr count: 1
Pulse count: 0
Triplet count: 0
Gaussian count: 1

How can I possibly know that it's not a quiet signal?
Is there any example of terrestrial signal to look at the graph?

Eric Korpela wrote:

The VLARs go out to ATI GPUs, but are held back from NVIDIA. If I could find a way to send VLAR to only NVIDIA OpenCL and not NVIDIA CUDA, I would...

I myself wrote:

The *guppi*.vlar's or also the normal .vlar's go to AMD/ATI GPUs?

The normal .vlar tasks lasts 4 times more, the *guppi*.vlar tasks lasts 3 times more - than a mid-AR task (on one of my four FuryX VGA cards) - (I'm a SETI-Beta tester).

If the AMD/ATI GPU PCs have good luck and get just this *guppi*.vlar tasks, their RAC will decrease /3, if also the normal .vlar tasks then the RAC will decrease /4. Not funny.

One of my FuryX calculate a (*guppi*).vlar task, in this time the card could calculate (3) 4 mid-AR tasks.

The nVIDIA GPUs don't get (*guppi*).vlar tasks...

It's not about Credits (only).
I (the most members here also) use the RAC for to compare (members/PCs/teams).

This would be like the AMD/ATI VGA card user do the 'dirty work' and the nVIDIA VGA cards are protected for them, that's like cherry-picking.
Fairness, equality?

If it ever would work, that the SETI server send the (*guppi*).vlar tasks to nVIDIA's OpenCL app and not to the CUDA app, the APR (average processing rate) of the OpenCL app will go so down, that the server 'use' just the CUDA app for the PC... with the result that no (*guppi*).vlar tasks will be send to the PC - or?


It's not possible to send the (*guppi*).vlar tasks just to CPUs?


I'm disappointed, I have set SETI in BOINC to 'no new tasks'.
I don't know when, or if I will set it again to 'allow new tasks'.
I'll follow the process and decide then...

I'm very sad (a hardcore SETIzen). :-(

I looked to other AMD/ATI VGA card PCs - if I looked correct they don't get the *guppi*.vlar tasks for their GPUs.

I set 'allow new tasks' again.

I don't know if it's really true what I saw... - if I'm wrong I set again 'no new tasks'. :-(

---

What about this result? What does "triplet count 30" mean?
Spike count: 0
Autocorr count: 0
Pulse count: 0
Triplet count: 30
Gaussian count: 0

What about this result? What does "triplet count 30" mean?
Spike count: 0
Autocorr count: 0
Pulse count: 0
Triplet count: 30
Gaussian count: 0

http://setiathome.berkeley.edu/sah_glossary.php

---

I read about triplets, I meant there are so many of the them on this graph. How can I get that that is a significant signal? Even if it's a T signal.

Don't get hung up or excited about seeing a triplet, a spike, or whatever.

There is a second stage in the process, once we have done the filtering to get rid of the stuff from known sources (human and natural). This stage (which isn't running just now) will compare the data from a given sky location and see what is going on. Then a third stage, a more detailed and protracted monitoring of that spot, and eventually someone will make a declaration that a probable ET signal has been detected at this point (direction) in the sky.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

I don't see why someone would want to do only 1/3 or 1/4 of what he can actually do for the project.

I estimate we have from hundreds to thousands of times greater of a chance finding ETI in a GBT work unit than an Arecibo one, because it is targeted to stars that are nearby, known to have exoplanets, and known (or thought) to have them in favourable positions for life (as we know it, Jim.)

It comes down to quality over quantity. And it's rather sadly ironic that the people who have contributed to this project the most over the years in terms of work done and time/money/effort invested in doing so are now mostly excluded from its most anticipated and promising venture.

From the project's point of view it doesn't matter which computer completes a particular task, they all have to be done regardless of the "quality". However, IMHO it should matter to use the resources they get from us in most efficient way possible. Not doing that slows down the processing of all "tapes". All our computers work on the same thing, assigning work in an intelligent way speeds up the progress and that's all we should be interested in.

BTW, the MESSIER031 tasks are non-VLAR as far as I see and can be crunched on GPU, so no one is excluded.

---

BTW, the MESSIER031 tasks are non-VLAR as far as I see and can be crunched on GPU, so no one is excluded.

Yes, getting them and very happy about that. :^) Unfortunately about 90% of them are going into -9 due to 30 or more triplets... hope it's just an initial hiccup. (These results are matching up with others', so not just my machines.)

I'm also curious what "MESSIER031" really means... Messier catalog object 31 is the Andromeda galaxy, and I doubt we are looking for ETI signals from that distance! Perhaps the area of?

---

I remember reading that Green Bank will scan the local group of galaxies, including the Maffei galaxies.
Tullio

---

...yeh, that was some gig ;-)

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

I had two tasks on the 32-bit Linux CPU. They ended soon.
Tullio

---