It's still a way to go.

Before the current app can be considered for release to run as stock.

Before VLAR could be enabled on main, perhaps? Don't mix things up.

Yes indeed, and that keeps us on topic for this thread. I don't think that GBT VLARs should be sent to (NVidia) GPUs until we have an application ready to handle them, and I don't think we have such an application - either CUDA or OpenCL - yet.

So far, there has been enough non-VLAR work to keep my GPUs busy. My cache dives a bit now and again, but seems to recover well enough.
It should improve when Eric has the time to start splitting AP work from the Green Bank datasets, which he has indicated he will do.

---

"Time is simply the mechanism that keeps everything from happening all at once."

It's still a way to go.

Before the current app can be considered for release to run as stock.

Before VLAR could be enabled on main, perhaps? Don't mix things up.

Yes indeed, and that keeps us on topic for this thread. I don't think that GBT VLARs should be sent to (NVidia) GPUs until we have an application ready to handle them, and I don't think we have such an application - either CUDA or OpenCL - yet.

So far, there has been enough non-VLAR work to keep my GPUs busy. My cache dives a bit now and again, but seems to recover well enough.
It should improve when Eric has the time to start splitting AP work from the Green Bank datasets, which he has indicated he will do.

As I recall one of the reason for MB v8 was to be able to accommodate data from sources other than Arecibo. So we will probably need a new AP app as well? I believe the only thing I have read so far was Eric mentioning there are plans to do AP for the GBT data as well.

Maybe they can get some summer inters to bang out the new splitter and base apps.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

It's still a way to go.

Before the current app can be considered for release to run as stock.

Before VLAR could be enabled on main, perhaps? Don't mix things up.

Yes indeed, and that keeps us on topic for this thread. I don't think that GBT VLARs should be sent to (NVidia) GPUs until we have an application ready to handle them, and I don't think we have such an application - either CUDA or OpenCL - yet.

So far, there has been enough non-VLAR work to keep my GPUs busy. My cache dives a bit now and again, but seems to recover well enough.
It should improve when Eric has the time to start splitting AP work from the Green Bank datasets, which he has indicated he will do.

As I recall one of the reason for MB v8 was to be able to accommodate data from sources other than Arecibo. So we will probably need a new AP app as well? I believe the only thing I have read so far was Eric mentioning there are plans to do AP for the GBT data as well.

I am not sure a new app will be required. AP is a different animal than MB. And indications I have are that the current app will work properly.
Of course, subject to change as the winds blow...LOL.

---

"Time is simply the mechanism that keeps everything from happening all at once."

I've started SETI Beta to use my AMD HD 7770. The first task ended in about a minute and is waiting for validation. But what is SoG? It's the first time i see this in a task on my SuSE Linux 42.1 host.
Tullio

---

A 0.005 guppi vlar under 10 minutes. No screen lag. System fully usable.
How many credits do you get from a guppi vlar?

02:28:42 (1018): Can't open init data file - running in standalone mode
02:28:42 (1018): Can't open init data file - running in standalone mode
setiathome_CUDA: Found 4 CUDA device(s):
  Device 1: GeForce GTX 980, 4095 MiB, regsPerBlock 65536
     computeCap 5.2, multiProcs 16 
     pciBusID = 1, pciSlotID = 0
  Device 2: GeForce GTX 780, 3071 MiB, regsPerBlock 65536
     computeCap 3.5, multiProcs 12 
     pciBusID = 2, pciSlotID = 0
  Device 3: GeForce GTX 980, 4095 MiB, regsPerBlock 65536
     computeCap 5.2, multiProcs 16 
     pciBusID = 3, pciSlotID = 0
  Device 4: GeForce GTX 780, 3071 MiB, regsPerBlock 65536
     computeCap 3.5, multiProcs 12 
     pciBusID = 4, pciSlotID = 0
In cudaAcc_initializeDevice(): Boinc passed DevPref 1
setiathome_CUDA: CUDA Device 1 specified, checking...
   Device 1: GeForce GTX 980 is okay
SETI@home using CUDA accelerated device GeForce GTX 980
Using pfb = 8 from command line args
Using pfp = 120 from command line args

setiathome v8 enhanced x41p_zn, Cuda 7.50 special
Compiled with NVCC 7.5, using 6.5 libraries. Modifications done by petri33.



Detected setiathome_enhanced_v8 task. Autocorrelations enabled, size 128k elements.
Work Unit Info:
...............
WU true angle range is :  0.005109
Sigma 639
Sigma > GaussTOffsetStop: 639 > -575
Thread call stack limit is: 1k
cudaAcc_free() called...
cudaAcc_free() running...
cudaAcc_free() PulseFind freed...
cudaAcc_free() Gaussfit freed...
cudaAcc_free() AutoCorrelation freed...
1,2,3,4,5,6,7,8,9,10,10,11,12,cudaAcc_free() DONE.
13
Flopcounter: 30954930943609.285156

Spike count:    0
Autocorr count: 1
Pulse count:    4
Triplet count:  0
Gaussian count: 0
02:38:15 (1018): called boinc_finish(0)

---

To overcome Heisenbergs:
"You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones

How many credits do you get from a guppi vlar?

Looking at my current test at Beta, the answer seems to be "it depends on the runtime". But Beta averages and workload distributions will be different from what we (currently) have at Main.

How many credits do you get from a guppi vlar?

Looking at my current test at Beta, the answer seems to be "it depends on the runtime". But Beta averages and workload distributions will be different from what we (currently) have at Main.

Yeah, sadly CreditNew penalises optimisation (i.e. computational efficiency) no matter what the designer states.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

I am getting guppi vlars on my Windows 10 PC with its Nvidia GTX 750 TI OC board.
Tullio

---

noticed them before ... run times just under an hour ... they seem to take longer than they do on my cpus

---

Hmm, 750Ti running 1 vlar Plus 1 non vlar (2 tasks).

vlar time increased by 70% vs non vlar
non vlar time increased by 95%

GPU vs CPU(i5), GPU is approx half the time.

Interesting note, my CPU temps jumped about 4C, and my GPU went down 4C, on both computers.

I was expecting guppi .vlars on my Linux box with its AMD HD 7770 but I got none in SETI Beta. Now I am getting them on the Windows PC with its Nvidia GTX 750 Ti OC. They take about 55 minutes.
Tullio

---

My 750Ti is a little faster;
http://setiathome.berkeley.edu/result.php?resultid=4923071938
This one is about the same;
http://setiathome.berkeley.edu/result.php?resultid=4923086322
Those are running 1 task at a time.

Running Raismter's SoG on my Titan X's

Running 3 at a time on each GPU with commandlines from Mike,

Each are taking just under 1 hour (56-58 minutes)

http://setiathome.berkeley.edu/result.php?resultid=4923517925

http://setiathome.berkeley.edu/result.php?resultid=4923517967

http://setiathome.berkeley.edu/result.php?resultid=4923517729

anyone want to have a guess at what will happen RAC ...

---

RAC = Really Aren't Crediting anyone.

In Einstein@home I am getting 2000 credits for a CPU task that lasts 90k s and 4400 credits for a GPU task that takes 9k s.
Tullio

---

RAC = Really Aren't Crediting anyone.

love it

---

Guppi vlars are coming in and they are done in 9-12 minutes one at a time.

I suspect they are not doing gaussian searching: Sigma > GaussTOffsetStop: 498 > -434

The difference between singma and GaussTOffsetStop would be 64 if the TOffsetStop would be positive ...

analyzePoT.cpp:      PoTInfo.GaussTOffsetStart   = static_cast<int>(floor(swi.analysis_cfg.pot_t_offset * PoTInfo.GaussSigma+0.5));
analyzePoT.cpp:      PoTInfo.GaussTOffsetStop    = swi.analysis_cfg.gauss_pot_length - PoTInfo.GaussTOffsetStart;
gaussfit.cpp:  

should probably be

analyzePoT.cpp:      PoTInfo.GaussTOffsetStart   = static_cast<int>(floor(swi.analysis_cfg.pot_t_offset * PoTInfo.GaussSigma+0.5));
analyzePoT.cpp:      PoTInfo.GaussTOffsetStop    = PoTInfo.GaussTOffsetStart + swi.analysis_cfg.gauss_pot_length;
gaussfit.cpp:  

Just my thoughts.

---

To overcome Heisenbergs:
"You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones

Sounds about right Petri. Gaussian Search requires a drift over a spot on the sky. i.e. pass the telescope beam over a specific direction and get a bell shaped signal from a constant source. VLAR targeted searches (unblinking eye at one spot) don't pass over a spot, but travel with it.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Sounds about right Petri. Gaussian Search requires a drift over a spot on the sky. i.e. pass the telescope beam over a specific direction and get a bell shaped signal from a constant source. VLAR targeted searches (unblinking eye at one spot) don't pass over a spot, but travel with it.

Yes, I know what a gaussian is and how it is formed in to the signal.

I have noticed the same negative value in test wu PG009.

I wonder if ths is a bug in cuda code base or in all sw versions. See edit in my other message.

---

To overcome Heisenbergs:
"You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones