Too hurry to remove older VS projects :/
Current one doesn't work well:

David's in charge of the VS builds. He has a tendency to check things in before they work. (Eventually I intend to replace the stock build with one done on MinGW cross compile.)

---

Too hurry to remove older VS projects :/
Current one doesn't work well:

David's in charge of the VS builds. He has a tendency to check things in before they work. (Eventually I intend to replace the stock build with one done on MinGW cross compile.)

So far I got crash reports for those non-graphics builds I was able to make with VS.
BTW, VS ones link against FFTW 3.3.4

---

News about SETI opt app releases: https://twitter.com/Raistmer

I've looked through the Ubuntu package manager, installed the packages that come with autoconf, and libtool. What package would I install to give me bonic-master or whatever else I would need to compile a seti_v8 cpu app?
For some reason I have this sudden urge to compile an app with at least ssse3 and fftw 3.3.4. Oh, fftw 3.3.4 is also in the package manager.

First one done, 4 minutes to overflow :/

Slight glitch: the task has validated, but according to the WU page none of the replications have been sent yet!

Yeah, that's why I linked to the task pages.

The second is now 50% done after 14 hours so looks like it'll be around 4 times longer than Arecibo workunits.

Eric, what about AstroPulse and new data sources? Will it be extended to them as MultiBeam does currently?

---

News about SETI opt app releases: https://twitter.com/Raistmer

The picture says it all.

---

_\|/_
U r s

Very nice.....

Edit..

Nice noticed VLAR?

August, 2013? I didn't realize the project had been acquiring GBT data for that long. Just how much has been stockpiled, I wonder?

August, 2013? I didn't realize the project had been acquiring GBT data for that long. Just how much has been stockpiled, I wonder?

Ah, I'd been wondering about that for my data distribution history charts. So the first numeric group in the WU name is the MJD of the recording?

If it were dedicated observations they all would be VLARs. No point to move telescope around sky if you control it :)
Though there will be no Gaussians then?

---

News about SETI opt app releases: https://twitter.com/Raistmer

If it were dedicated observations they all would be VLARs. No point to move telescope around sky if you control it :)
Though there will be no Gaussians then?

It depends, if the data recorder was stopped during repositioning of the telescope then there would be only VLARs. Otherwise we will see higher AR as well.

---

_\|/_
U r s

They did a search back in 2011.

UC Berkeley SETI survey focuses on Kepler’s top Earth-like planets
SETI at the Green Bank Telescope

So far I have completed just the one task that ended in overflow. App version details look like this:

SETI@home v8 7.99 x86_64-pc-linux-gnu
Number of tasks completed    1
Max tasks per day           34
Number of tasks today        1
Consecutive valid tasks      1
Average processing rate    891.51 GFLOPS
Average turnaround time      0.02 days

I thought overflow tasks weren't supposed to be counted?

Here's what my machine says;
SETI@home v8 7.99 x86_64-pc-linux-gnu
Number of tasks completed 4
Max tasks per day 37
Number of tasks today 0
Consecutive valid tasks 4
Average processing rate 8.82 GFLOPS

Here's v7
SETI@home v7 (anonymous platform, CPU)
Number of tasks completed 1413
Max tasks per day 752
Number of tasks today 0
Consecutive valid tasks 31
Average processing rate 23.59 GFLOPS

They did a search back in 2011.

UC Berkeley SETI survey focuses on Kepler’s top Earth-like planets
SETI at the Green Bank Telescope

I found this bit quite interesting:

Once UC Berkeley astronomers acquire 24 hours of data on a total of 86 Earth-like planets, they’ll initiate a coarse analysis and then, in about two months, ask an estimated 1 million SETI@home users to conduct a more detailed analysis on their home computers.

Perhaps a "month" is measured differently in Berkeley than elsewhere?? ;^)

Same observation as TBar's:

SETI@home v8 7.99 x86_64-pc-linux-gnu
Number of tasks completed 23
Max tasks per day 57
Number of tasks today 0
Consecutive valid tasks 24
Average processing rate 12.75 GFLOPS
Average turnaround time 1.69 days

SETI@home v7 7.01 i686-pc-linux-gnu
Number of tasks completed 229
Max tasks per day 87
Number of tasks today 0
Consecutive valid tasks 56
Average processing rate 19.51 GFLOPS
Average turnaround time 0.57 days

I'm not surprised to see problems with FLOPs estimates. It'll take a while to decide if they are real or not.

---

APR is relative to rsc_fpops_est and suffers from credit_new trauma.
New apps are especially traumatic what with the way ramp up works.
(iow you can trust APR as much as you can trust credit ;) )

you'll probably get a better ballpark number if you manually compare the runtime/AR intrahost and check if v8 stock does really have a speed difference compared to v7 stock.

edit: and remember we ended up with the wrong FFTW lib, so you can't really compare them anyway.

---

A person who won't read has no advantage over one who can't read. (Mark Twain)

OK, here is a v8 task, http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=76256, around 10 hours.
Here is a v7 VLAR on the same machine, http://setiathome.berkeley.edu/result.php?resultid=4511710802
10 hours verses a little over 2 hours?
Current v8 APR, 9.31 GFLOPS
Current v7 APR, 23.83 GFLOPS
I don't think it would be anywhere close even if you did use the stock v7 App.

OK, here is a v8 task, http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=76256, around 10 hours.
Here is a v7 VLAR on the same machine, http://setiathome.berkeley.edu/result.php?resultid=4511710802
10 hours verses a little over 2 hours?
Current v8 APR, 9.31 GFLOPS
Current v7 APR, 23.83 GFLOPS
I don't think it would be anywhere close even if you did use the stock v7 App.

You're comparing an SSSE3 optimised application with a test app built for accuracy checking only - and as Eric confirmed last week, with an old, slow, version of FFTW. All that proves is that optimised apps are faster: the trick is to make them accurate at the same time. That will come in all due time.