The easy things to describe are things to describe are the (conceptually, if not effort wise) small changes.

SETI@home v7 now supports the AVX instruction set used on Intel Sandybridge and later processors. That gives a significant speedup on those processors. For GPUs SETI@home enhanced used to support 3 different versions of CUDA, CUDA 2.2, CUDA 2.3, and CUDA 3, which we called cuda_fermi, because it was the only version that would run on Fermi and later GPUs. Now we have 5 versions for NVIDIA GPUs (CUDA 2.2, CUDA 2.3, CUDA 3.2, CUDA 4.2 and CUDA 5.0) under windows, two versions for AMD/ATI GPUs under windows, and two versions for AMD/ATI GPUs under linux.

Don't be surprised if you get more than one of these early on. We can tell that CUDA 2.2 and 2.3 won't run on Fermi and later cards, but we can't tell, for example, if CUDA 3.2 will be faster than CUDA 4.2 on your card. So we'll be sending you some of each in order to see which is faster. The server was supposed to be doing this all along, but there was a bug in it that I only discovered a few weeks ago. If you think the server is behaving incorrectly, let me know. There may be further bugs to squash.

The big deal, and it is a big deal, is something known as autocorrelation. Now autocorrelation isn't a new thing. It's been in the radio astronomer's tool box for a long time. In fact the original SERENDIP was an analog autocorrelator. What's different is the way we're using it.

Autocorrelation is different than the standard FFT in that the FFT looks for sine waves. That makes it great for looking for signals that have very narrow bandwidth, because anything with narrow bandwidth looks like a sine wave. But once you put information into a transmission, its bandwidth gets wider and it looks less like a sine wave. The more information you add, the wider the bandwidth and harder it is to detect using an FFT.

Autocorrelation, on the other hand, looks for anything that looks like itself. I know that doesn't make a lot of sense at first glance because everything looks like itself. And an autocorrelation will tell you that if you didn't already know it. But it will also tell you if the same signal waveform shows up half a second later.

Why is that important? One way an ET civilization could send a signal that contains information, but is still easily detectable would be to send a signal, and then send exactly the same signal delayed by a small amount of time (say half a second). You could pack in a lot of information, and the signal would still be easily detected using autocorrelation. Theoretically, its nearly as sensitive to wide band signals as the FFT is to narrow band signals, and it only uses a little bit more than twice the computation.

No, this wasn't my idea, although I wish it was. Autocorrelation was brought back to the forefront of our minds by Gerry Harp, the current Director of SETI at the SETI Institute. @SETIEric

The easy things to describe are things to describe are the small changes.

SETI@home v7 now supports the AVX instruction set used on Intel Sandybridge and later processors. That gives a significant speedup on those processors. For GPUs SETI@home enhanced used to support 3 different versions of CUDA, CUDA 2.2, CUDA 2.3, and CUDA 3, which we called cuda_fermi, because it was the only version that would run on Fermi and later GPUs. Now we have 5 versions for NVIDIA GPUs (CUDA 2.2, CUDA 2.3, CUDA 3.2, CUDA 4.2 and CUDA 5.0) under windows, two versions for AMD/ATI GPUs under windows, and two versions for AMD/ATI GPUs under

Don't be surprised if you get more than one of these early on. We can tell that CUDA 2.2 and 2.3 won't run on Rermi and later cards, but we can't tell, for example, if CUDA 3.2 will be faster than CUDA 4.2 on your card. So we'll be sending you some of each in order to see which is faster. The server was supposed to be doing this all along, but there was a bug in it that I only discovered a few weeks ago. If you think the server is behaving incorrectly, let me know. There may be further bugs to squash.

The big deal, and it is a big deal, is something known as autocorrelation. Now autocorrelation isn't a new thing.

If's been in the radio astronomer's tool box for a long time. In fact the original SERENDIP was an analog autocorrelator. What's different is the way we're using it.

Autocorrelation is different than the standard FFT in that the FFT looks for sine waves. That makes it great for looking for signals that have very narrow bandwidth, because anything with narrow bandwidth looks like a sine wave. But once you put information into a transmission, its bandwidth gets wider and it looks less like a sine wave. The more information you add, the wider the bandwidth and harder it is to detect using an FFT.

Autocorrelation, on the other hand, looks for anything that looks like itself. I know that doesn't make a lot of sense at first glance because everything looks like itself. And an autocorrelation will tell you that if you didn't already know it. But it will also tell you if the same signal waveform shows up half a second later.

Why is that important? One way an ET civilization could send a signal that contains information, but is still easily detectable would be to send a signal, and then send exactly the same signal delayed by a small amount of time (say half a second). You could pack in a lot of information, and the signal would still be easily detected using autocorrelation. Theoretically, its nearly as sensitive to wide band signals as the FFT is to narrow band signals, and it only uses a little bit more than twice the computation.

No, this wasn't my idea, although I wish it was. Autocorrelation was brought back to the forefront of our minds by Gerry Harp, the current Director of SETI at the SETI Institute.

Thanks Eric for the explanation. I do have 1 question and please forgive my ignorance if it sounds stupid. Is the autocorrelation running throughout the duration of processing the work unit file or does it occur at the end of processing? I've noticed that many, if not all work units seem to start out moving at a slow rate and speed up as percentage completed increases. I can't recall whether this also occurred with V6 seti.

The autocorrelation runs throughout the processing, whenever we are working at the finest spectral resolution (0.075 Hz which is an FFT length of 128k points.) Those transforms are not performed at every Doppler drift rate, but are concentrated on the low Doppler drift rate. (<30 Hz/s) So that does result in increased processing for the first third of the result. In theory the progress bar is supposed to be adjusted for that, but the adjustment isn't nearly as good as it could be.

That's what we do for now anyway. Depending on how clean the results are of interference, we may expand them to cover the full range. But we don't want to do that until we're sure the probably less interesting results won't swamp the more interesting ones. @SETIEric

Why is that important? One way an ET civilization could send a signal that contains information, but is still easily detectable would be to send a signal, and then send exactly the same signal delayed by a small amount of time (say half a second).

You could pack in a lot of information, and the signal would still be easily detected using autocorrelation. Theoretically, its nearly as sensitive to wide band signals as the FFT is to narrow band signals, and it only uses a little bit more than twice the computation.

Thanks so much Eric for the heads-up that everyone looked forward to.
I'm trying to write a statement in french for my team about it.
Not easy to popularize these ideas ! ;)
I have a small question : does the processing units work focuses exclusively on the detection of a signal using the autocorrelation ?

Many thanks for the update. I like the sound of the new detection function lots.
Over the years I have been concerned that we were perhaps searching in too narrow an envelope. ...The best we could do at the time of course. Volumes have been written about advanced compression algorithms and their impact on broadcast waveform. With this extension I suspect that you are looking in the right place.

Optimistically speaking, to date we may have been doing a good job searching only for what we expected - and doing so based on the past (and presumed future) 100 years or so of broadcast technology. Fingers crossed.
I hope the upgrade goes peacefully for you.

Thanks Eric for taking the time to explain to us, in terms we can understand, the rationale behind V7, even I could follow it! As with anything new, it will take a time to settle down and be fine tuned as necessary. Keep up the good work.

Oh and btw, congrats on recently passing your own Seti 20 million :-)Those are my principles, and if you don't like them ... well, I have others.
Groucho Marx 1895-1977

I also have mine, and if you don't like them ... tough, live with it.
Chris S 2017

The version numbers in SETI@home and AstroPulse aren't synchronized either to each other or to BOINC. It's mainly an accident that SETI@home and BOINC have the same major version.

But that does raise the question about why we haven't put autocorrelation in AstroPulse. It's not that I haven't thought about it, it's that I haven't finished thinking about it. A signal from an extraterrestrial civilization is chirped by accelerations, dispersed by interstellar gas and then chirped again by the Earth's accelerations. In SETI@home the signals are so narrow that the chirps are additive and the dispersion is essentially zero. For astropulse the signals are so wide that the chirping doesn't matter. For autocorrelation you don't really know how wide the signal is so you need to dedisperse and dechirp, which means you need to do N times as much work, where N is the number of Doppler drift rates you compute. So I need to think about whether its possible to get N down to a manageable number. @SETIEric

The version numbers in SETI@home and AstroPulse aren't synchronized either to each other or to BOINC. It's mainly an accident that SETI@home and BOINC have the same major version.

Yeah, I was about to request that a next update does a double check at what the BOINC version of the time is and then do a different version number. If BOINC 8, make Seti v13. That way all of the easily confused won't be so confused. :)Jord

Ancient Astronaut Theorists suggest that in many ways, you can be considered an alien conspiracy!

Hi My computer crashes and restarts after 3 min. running seti@home 7.2 on my screen saver I have a FX 8150 AMD processor,ATI 6950 video card and 16gb. of 2133 running at 1866 ram windows 8 pro my processor was running very hot when the screen saver would come on and shut off so I installed a very large heat sink and fans and the temp. decreased about 25deg. went from 68.c to 38.c I would like to run program but forced to opt out.Thank You

Hi My computer crashes and restarts after 3 min. running seti@home 7.2 on my screen saver I have a FX 8150 AMD processor,ATI 6950 video card and 16gb. of 2133 running at 1866 ram windows 8 pro my processor was running very hot when the screen saver would come on and shut off so I installed a very large heat sink and fans and the temp. decreased about 25deg. went from 68.c to 38.c I would like to run program but forced to opt out.Thank You

Charles, check in the Number Crunching Forum, there are folks who hang out there that are much better at helping diagnose and solve hardware problems than most of us who read this section.Donald
Infernal Optimist / Submariner, retired

Hi Eric, thanks for letting us know what is going on with the new application version. I have one question. Sometime ago Matt said that the run time the work units was going to be extended. I have noticed the average work unit on my 660 TI is running around 18 minutes was was this the intention with version 7 or was this a pleasant side-effect, are there still claims to pack more than one job into a task?

Thanks for the heads up! Question about the future of SETI@home, if you have a moment.

Every so often a new version of S@H comes out with increased sensitivity or a new type of search. Wouldn't it be easier to simply release a version of S@H that has it's sensitivity cranked up to the limits of the sensitivity of Arecibo, rather than ratcheting it up every couple years?

Sometime ago Matt said that the run time the work units was going to be extended. I have noticed the average work unit on my 660 TI is running around 18 minutes was was this the intention with version 7 or was this a pleasant side-effect, are there still claims to pack more than one job into a task?

Hi Speedy,

There used to be a four processor DEC VAX-6000 with that name at the University of Wisconsin. It was impressively fast in 1988, but most peoples' cell phones could probably outrun it now. :)

The longer run time is a side effect of the autocorrelation. The longer term plan was to increase the size of workunits to keep the number of request on our server down to a reasonable value. The move to the colocation facility seems to have helped somewhat, so there less pressure to do that at this point.

But when it comes to the Kepler/GBT observations workunits, a larger size and run time is unavoidable. So we are working on that development as rapidly as we can. @SETIEric

Wouldn't it be easier to simply release a version of S@H that has it's sensitivity cranked up to the limits of the sensitivity of Arecibo, rather than ratcheting it up every couple years?

In most cases we can alter the signal threshold by changing parameters in the work unit without releasing a new version. For example, we could do the autocorrelation out to 100Hz/s or change the autocorrelation detection threshold without releasing a new version. That sort of change wasn't possible for a lot of parameters in the early versions of SETI@home.

Most of the recent versions have been to add new analyses and signal types (pulses, triplets, autocorrelation) or to change how the analysis is done (optimizations for specific instruction sets and bug fixes for problems that reduced our sensitivity) or to add new types of applications (GPU, android). In the cases where a new version improved sensitivity it's probably because there was a bug in the way we were performing the analysis.

But the real reason that changes to the science take a couple years rather than a couple months is manpower related. Even simple changes like autocorrelation take long time for me to test and deploy because I can't devote a large fraction of my time to it.

There is a sensitivity boost we got recently by changing the data splitter on the server side to use a different algorithm to generate the workunits. Nobody expect the people who watch the server status page probably noticed the change.

We are close to the limits of what Arecibo can provide for us with this data recorder. There's really only a couple knobs left to turn. In theory, I was considering those knobs when I was writing SETI@home enhanced and no changes should be required if those knobs are turned. But if I made a mistake, we may never turn them. By the time I got it fixed we might have a new and better data recorder (cough, SERENDIP VI, cough) capable of recording much wider bandwidth on every receiver Arecibo and GBT have. But that's a different story. @SETIEric