There are no real changes except the version number, the FFTW dll is included, and the executables are stripped and compressed the way they would be in the main project. No need to abort results or reset the project unless you are having problems with 6.94.

---

Besides from a high estimation (~94h) of the time needed to finish the workunit, all looks OK until now.

---

Noticed that too, but I guess that the application is new to Boinc and therefore Boinc resets the DCF. Strange thing is that the DCF is at 4.5 now while I would expect 1.0.

I'm not sure how initial DCF for an app is calculated. Probably an average of all the apps for a project.

---

I am seeing what appears to be a case of poor performance that is angle range sensitive on my Sandy Bridge (i7-2820QM) laptop which is running Windows 7 Ultimate x64. (Computer 51584)

I have tested with releases 6.91, 6.91 r246, 6.94 and 6.95, but I only see the issue with releases 6.94 and 6.95. Eric mentioned that 6.94 included explicit support for the Sandy Bridge AVX 256bit SSE extensions in
message 40881.

In general, the 6.94 & 6.95 releases appear to perform as well as or better than the previous releases, except at angle ranges of .4148, .4145, and .4144. These are the only mid-ARs I've seen in my testing so far and they all run much longer than those with 6.91 r246. I did not get any mid-AR WUs when testing with 6.91. I have seen more VHAR & VLAR WUs than I have mid-AR WUs, and all the VHAR & VLAR WUs run faster than these mid-AR WUs.

Mid-AR results for 6.91 r246:

  AR      CPU time (seconds)
.3940     6385
.4148     5625
.4148     5845
.6100     4959

Mid-AR results for 6.94 & 6.95:

  AR      CPU time (seconds)
.4144     10801
.4144     10954
.4145     11380
.4148     11152

Additional results from 6.94 & 6.95 for comparison purposes:

  AR       CPU time (seconds)
.0088      9608
.0088      9480
.0090      8766
.0090      8749
1.172      3397
1.203      3409
1.203      3554
1.466      3166

Maybe someone familiar with the code could please explain why this performance issue exists at these angle ranges in these two releases and not in the previous release. Is it normal for these mid-ARs to run longer than VLAR WUs, or is something amiss with the AVX implementation?

...
Maybe someone familiar with the code could please explain why this performance issue exists at these angle ranges in these two releases and not in the previous release. Is it normal for these mid-ARs to run longer than VLAR WUs, or is something amiss with the AVX implementation?

Yes, there's something amiss with the AVX implementation. It's not pinned down yet, and your Beta testing is greatly appreciated.

Urs Echternacht has localized at least one problem. There might be others lurking since I did the AVX coding somewhat in the blind, hoping that the function tests performed during initialization would be sufficient protection.

                                                                 Joe

Hey folks,
I am running the beta application on my notebook, which has a Sandy Bridge processor and thus supports AVX extensions.
Apparently, the application is not "bug free" yet. During the first run (v. 6.94), there was little progress, despite normal (100%) CPU utilization. Next, I restarted BOINC and the first (out of four) task started. Even after 40 minutes, the other tasks progress were in the 0.00x% range. After a further restart, a second task started and so on, until all were running. About 25 tasks finished without a problem, until I decided to run a second project (RNAworld) on my notebook.
After the RNAworld tasks (two of them) had started, the SETI-tasks kept running normally until they finished, but the newly downloaded tasks "failed" again (0,00x% after a few hours).
RNAworld was set to "new no task" and I aborted the remaining SETI work units. Then I reset SETI, exited BOINC, restarted the notebook and allowed new work for SETI (and hence upgraded to 6.95). Since then, not a single task (out of eight) ran as intended, even after a runtime more than four hours (a regular task takes 1.5 to two hours to finish), progress was at 0.00x%.

Host id: 51854

---

Yours sincerely
Oliver

If I remember correctly, that is the the bug that Urs isolated.

hi is the problem solved ??

---

hi is the problem solved ??

The last major puzzling symptom was understood yesterday and code has been designed which should fix the known problems. I expect there will be new builds to test when Eric has time to make them. Those of you with Sandy Bridge CPUs will be needed to prove whether the fixes are complete, or whether there are other problems which were hidden.

                                                                   Joe

Getting low on WU's.

How or what is the present state of play?

There doesn't appear to be any news lately almost a month news wise is it ready for migration to seti@home or still work to be carried on.

Michael

Currently on the wrong side of the planet to do much about beta. We'll be ready for a new release when I get back to Berkeley, so running out is OK. We get all fresh results with the new release.

---

hi

when can we sandy bridge cruncher test the new release

---

I made some minor code changes yesterday. I should be able to get a new version out today.

---