More than hour difference just because of different OS.... too much!
You said there is drop(increase) in timings for Windows since last check. Same app version ot those were from 8.00 and now you testing 8.01 ?

All the Windows runs were under v8.01 windows_intelx86, but if you look at my two posts, you'll see that the first group (with AR=1.152455) all ran in under 2 hours, 10 minutes, while the second group (with AR=1.223888) all took about 3 hours, 45 minutes. I really don't understand that at all.

I just added an "EDIT" to my last post because I remembered that I upgraded BOINC from 7.6.6 to 7.6.9 between those two batches, although I doubt very much that such upgrade could have degraded the run times like that.

I'm not getting any new work from Beta, so I assume cause I'm forced by circumstances to use 266.58(Win 7 Pro x64), that this is why NO new gpu work and a nag-line from time to time, instead of the snobbish insistence on 350+ drivers.

And I suppose this will spread to main too, plenty of people might be upset I'd think, I am.

Only CPU apps are available for v8 thus far, so nobody's GPUs will get any v8 work at this stage.

I'm not getting any new work from Beta, so I assume cause I'm forced by circumstances to use 266.58(Win 7 Pro x64), that this is why NO new gpu work and a nag-line from time to time, instead of the snobbish insistence on 350+ drivers.

And I suppose this will spread to main too, plenty of people might be upset I'd think, I am.

Only CPU apps are available for v8 thus far, so nobody's GPUs will get any v8 work at this stage.

See this link on what Richard said(that I agree with) on Raistmer..

I'm not getting any new work from Beta, so I assume cause I'm forced by circumstances to use 266.58(Win 7 Pro x64), that this is why NO new gpu work and a nag-line from time to time, instead of the snobbish insistence on 350+ drivers.

And I suppose this will spread to main too, plenty of people might be upset I'd think, I am.

Only CPU apps are available for v8 thus far, so nobody's GPUs will get any v8 work at this stage.

See this link on what Richard said(that I agree with) on Raistmer..

Well, until now emotions was not able to change driver behavior :P
It's known that 340.xx line of drivers produce incorrect result.
It's known that 350.xx line produces correct result.
Agreement or disagreement with anyone along with being upset and so on can't change this.

As I already stated, no one cared to check how older driver revisions behave.
If you want to add something real to discussion besides of being upset I can send link to unrestricted version - try it on own system and prove or disprove 266.xx drivers usage.

---

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

More than hour difference just because of different OS.... too much!
You said there is drop(increase) in timings for Windows since last check. Same app version ot those were from 8.00 and now you testing 8.01 ?

All the Windows runs were under v8.01 windows_intelx86, but if you look at my two posts, you'll see that the first group (with AR=1.152455) all ran in under 2 hours, 10 minutes, while the second group (with AR=1.223888) all took about 3 hours, 45 minutes. I really don't understand that at all.

I just added an "EDIT" to my last post because I remembered that I upgraded BOINC from 7.6.6 to 7.6.9 between those two batches, although I doubt very much that such upgrade could have degraded the run times like that.

Well, there is slight possibility that this small AR change crosses some threshold and then this difference becomes important. Worth to dig into my old graphs for v7 performance vs AR as start and even more worthy to produce new ones for v8.
BOINC version change adds even smaller possibility to be important in this case... What about boinc.exe process CPU consumption?

Best of all would be if you could master offline bench usage for both Windows and Linux - that's would allow direct and exactly same tasks comparison.
Another way is statistical one with run time vs AR plot.
I will start to collect such statistics on own hosts for RC opt build leaving stock binary exploration to others for now.

---

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

What about boinc.exe process CPU consumption?

I wasn't really watching that machine while the tasks were running. However, I keep a small monitor window running in the corner of the screen to show temps and total CPU usage. Occasional spot checks showed all 8 cores running at or near 100%. I'm sure I would have noticed if they weren't.

Best of all would be if you could master offline bench usage for both Windows and Linux - that's would allow direct and exactly same tasks comparison.

Probably not going to happen. I'm sure I could do just fine with Windows, but with Linux I'm still learning to crawl, so any advanced gymnastics would likely be way beyond my ability! ;^)

At the moment, I still have some tasks running on the Linux side of the box, but once those finish in a couple hours, I'll probably try to grab a third batch of similar tasks for both Windows and Linux from whatever the server is offering at the time. Maybe those runs will show me if the second batch was an aberration or not.

I'm sure I would have noticed if they weren't.

The idea was if boinc.exe shows excessive CPU usage over time there can be excessive cache thrashing because of that and hence increase in both CPU and elapsed times for Windows application. That could be as consequence of BOINC version change... but as I said, probability quite small.

At the moment, I still have some tasks running on the Linux side of the box, but once those finish in a couple hours, I'll probably try to grab a third batch of similar tasks for both Windows and Linux from whatever the server is offering at the time. Maybe those runs will show me if the second batch was an aberration or not.

Then the best is to try to get exactly same ARs for comparison (or plot time vs AR curve) to not to fall inside AR difference trap.
Hour of difference is big enough to pay attention...

---

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

Well, until now emotions was not able to change driver behavior :P
It's known that 340.xx line of drivers produce incorrect result.
It's known that 350.xx line produces correct result.
Agreement or disagreement with anyone along with being upset and so on can't change this.

As we found, and said, last time we had a problem like this, all you can say at this stage is that there is an incompatibility between your (MB) programming and drivers before 350 on those cards.

That incompatibility does not appear to exist between your (AP) programming and those same drivers. I'm not sure that points exclusively to a driver bug, though it's certainly possible, as we've demonstrated before.

The idea was if boinc.exe shows excessive CPU usage over time there can be excessive cache thrashing because of that and hence increase in both CPU and elapsed times for Windows application. That could be as consequence of BOINC version change... but as I said, probability quite small.

I can certainly get Process Explorer running and see what that shows me, but since I haven't paid attention to boinc.exe CPU usage previously, I don't think I'd really know what would constitute "excessive" usage.

Then the best is to try to get exactly same ARs for comparison (or plot time vs AR curve) to not to fall inside AR difference trap.
Hour of difference is big enough to pay attention...

Yeah, that's why I start these comparisons with empty queues, then grab at least 8 tasks for Linux, suspend and shut down, then immediately grab at least 8 for Windows. That's why each of the first 2 groups had the same ARs within the group.

You could also test the release candidate v7.6.22 BOINC from http://boinc.berkeley.edu/download_all.php. There were some rather badly thought out client priority changes in earlier v7.6.xx builds which could have affected runtimes and even failure rates: those have all been stripped back to optional, configurable, settings, with the default values equivalent to v7.6.6

I can't remember immediately which build first had the client runtime priority reduced, but I'll go and check. Expect an edit.

Edit - and here is is. Client priority changes were first attempted in v7.6.13 (unreleased), so the upgrade from v7.6.6 to v7.6.9 wouldn't have been affected. You can see exactly what was changed a little earlier in the linked thread - I remember it as being mostly cosmetic.

Well, until now emotions was not able to change driver behavior :P
It's known that 340.xx line of drivers produce incorrect result.
It's known that 350.xx line produces correct result.
Agreement or disagreement with anyone along with being upset and so on can't change this.

As we found, and said, last time we had a problem like this, all you can say at this stage is that there is an incompatibility between your (MB) programming and drivers before 350 on those cards.

That incompatibility does not appear to exist between your (AP) programming and those same drivers. I'm not sure that points exclusively to a driver bug, though it's certainly possible, as we've demonstrated before.

What it adds to issue? I would prefer data about compatibility with pre-340 drivers actually.

EDIT: last time there were SDK examples that completed OK and there were SDK samples that demonstrated issues too. Is it not too enigmatic from your point of view? Not ALL SDK samples failed with buggy driver - can it be ?!
Then why again and again comparison between AP and MB made as argument???
They are different programs using different "parts" in driver hence show different behavior. Period.
As I try to bring to alpha testers TIME TO TEST (!).

---

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

You could also test the release candidate v7.6.22 BOINC from http://boinc.berkeley.edu/download_all.php. There were some rather badly thought out client priority changes in earlier v7.6.xx builds which could have affected runtimes and even failure rates: those have all been stripped back to optional, configurable, settings, with the default values equivalent to v7.6.6

I can't remember immediately which build first had the client runtime priority reduced, but I'll go and check. Expect an edit.

Edit - and here is is. Client priority changes were first attempted in v7.6.13 (unreleased), so the upgrade from v7.6.6 to v7.6.9 wouldn't have been affected. You can see exactly what was changed a little earlier in the linked thread - I remember it as being mostly cosmetic.

Okay, so I'll stick with 7.6.9 for my next text sequence.

The T7400 still had 7.6.6 on it because it hadn't been used since we were testing those changes for Stderr truncation fixes back in July. I don't remember having any problems with it then, but yesterday it seemed like it might be having an issue when I was accessing it remotely with BOINC Manager from here on my daily driver, which is on 7.6.9. It seemed that each time one of the running tasks finished, or at least reached about 99+% progress, BOINC Manager here would either lose the connection or simply lock up. If I went into the next room and checked BOINC Manager on the T7400, it would still be working just fine. However, I'd generally have to use Task Manager here on my daily driver to forcibly shut down both the BOINC Manager task and process. So I switched the T7400 to 7.6.9 and the problem seemed to go away. Very odd! Whether 7.6.9 had anything to do with that strange increase in run times remains to be seen. I think I should give it another chance. ;^)

What it adds to issue? I would prefer data about compatibility with pre-340 drivers actually.

EDIT: last time there were SDK examples that completed OK and there were SDK samples that demonstrated issues too. Is it not too enigmatic from your point of view? Not ALL SDK samples failed with buggy driver - can it be ?!
Then why again and again comparison between AP and MB made as argument???
They are different programs using different "parts" in driver hence show different behavior. Period.
As I try to bring to alpha testers TIME TO TEST (!).

By all means test, and seek data. All I'm saying it that it should remain as a test - separate and distinct from the v8 launch - until we have time and resources (especially human resources) to get to the bottom of why the earlier drivers for five year old hardware can't handle your application. I've tried to explain the background to my suggestion in a lengthy post on another board.

What it adds to issue? I would prefer data about compatibility with pre-340 drivers actually.

EDIT: last time there were SDK examples that completed OK and there were SDK samples that demonstrated issues too. Is it not too enigmatic from your point of view? Not ALL SDK samples failed with buggy driver - can it be ?!
Then why again and again comparison between AP and MB made as argument???
They are different programs using different "parts" in driver hence show different behavior. Period.
As I try to bring to alpha testers TIME TO TEST (!).

By all means test, and seek data. All I'm saying it that it should remain as a test - separate and distinct from the v8 launch - until we have time and resources (especially human resources) to get to the bottom of why the earlier drivers for five year old hardware can't handle your application. I've tried to explain the background to my suggestion in a lengthy post on another board.

You might check into why a good number of the OSX machines have a Large inconclusive to valid ratio with the nVidia MB App. Some of the machines don't have a problem while others have almost a 50/50 ratio of inconclusive to valids. That BTW is Higher than Petri's 'Special' CUDA App, on My machine. It was also the same in Beta, some machines didn't have a problem while others did, and I don't think it was the driver as the driver is built into the OS. The 'Stock' CUDA App is much better with very few inconclusives.

Although not part of any formal test comparisons I was trying to make, I just noticed some rather puzzling run times on several Linux tasks.

There were 4 tasks which started within 14 minutes of each other, 2 of them under the v8.01 x86_64-pc-linux-gnu app and 2 under v8.02 i686-pc-linux-gnu. Each pair of tasks included one VLAR, with AR=0.019474 and one "normal", with AR=0.415050. In both cases, the VLAR task took much less time to run than the "normal" AR. That seems really odd to me. None of the tasks were overflows.

v8.01 x86_64-pc-linux-gnu
Task 21515760 (AR=0.019474) : Run Time 3:28:38 | v_vGetPowerSpectrumUnrolled; sse2_ChirpData_ak8; v_vTranspose4; BH SSE folding
Task 21515371 (AR=0.415050) : Run Time 5:24:53 | v_vGetPowerSpectrumUnrolled; sse2_ChirpData_ak8; v_vTranspose4; AK SSE folding

v8.02 i686-pc-linux-gnu
Task 21515782 (AR=0.019474) : Run Time 3:59:56 | v_vGetPowerSpectrum; sse3_ChirpData_ak8; v_vTranspose4x16ntw; BH SSE folding
Task 21516351 (AR=0.415050) : Run Time 5:33:45 | v_vGetPowerSpectrum; sse2_ChirpData_ak8; v_vTranspose4; AK SSE folding

Could this possibly be an issue due to the VLARs containing Green Bank data while the non-VLARs are from Arecibo? Is there that much difference in the processing?

Anyway, my third group of Linux vs. Windows tests is now under way, starting on the Windows side. It looks like I've got a nice group of both VLAR and normal AR tasks from the matching batches, so it will be interesting to see if this VLAR vs. "normal" behavior is repeatable under more controlled conditions. I don't expect to have results from both OSes today, however.

8.03 is released for the linuxes. I'll do a Windows build (with identical build flags) as soon as I can, probably Saturday.

The major difference is that doing transposes with FFTW is now an option in the transpose list. There were also a couple small bug fixes that Charlie Fenton sent me. None of them affect the results, so far as I can tell.

---

The good news is I'm able to build a v8 Mac CPU App. The bad is it immediately crashes with SIGSEGV: segmentation violation. The same configure worked in v7, so, why does it now give;

20:42:43 (35960): Can't open init data file - running in standalone mode
Not using mb_cmdline.txt-file, using commandline options.
SIGSEGV: segmentation violation

Crashed executable name: MBv8_8.0r3257_sse41_x86_64-apple-darwin
Machine type Intel 80486 (64-bit executable)
System version: Macintosh OS 10.8.5 build 12F2560
Thu Dec 24 20:42:43 2015

0   MBv8_8.0r3257_sse41_x86_64-apple-darwin 0x00000001002eacab std::_Rb_tree<int, std::pair<int const, PROCINFO>, std::_Select1st<std::pair<int const, PROCINFO> >, std::less<int>, std::allocator<std::pair<int const, PROCINFO> > >::_M_create_node(std::pair<int const, PROCINFO> const&) + 1099
1   MBv8_8.0r3257_sse41_x86_64-apple-darwin 0x00000001002db966 COPROCS::clear() + 4198
2   libsystem_c.dylib                   0x00007fff8740690a _sigtramp + 26
3   ???                                 0x0000003000000010 0x0 + 206158430224
4   MBv8_8.0r3257_sse41_x86_64-apple-darwin 0x00000001001bcdf3 std::string x_csv_encode<char>(char const*, unsigned long) + 2675
5   MBv8_8.0r3257_sse41_x86_64-apple-darwin 0x00000001001b9768 std::vector<unsigned char, std::allocator<unsigned char> >::_M_insert_aux(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, unsigned char const&) + 23800
6   MBv8_8.0r3257_sse41_x86_64-apple-darwin 0x00000001001beaf3 std::string x_csv_encode<char>(char const*, unsigned long) + 10099
7   MBv8_8.0r3257_sse41_x86_64-apple-darwin 0x00000001001a5497 MBv8_8.0r3257_sse41_x86_64-apple-darwin + 1725591
8   MBv8_8.0r3257_sse41_x86_64-apple-darwin 0x0000000100001154 MBv8_8.0r3257_sse41_x86_64-apple-darwin + 4436
9   ???                                 0x0000000000000001 0x0 + 1

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0100001f  rbx: 0x00000028  rcx: 0x7fff5fbfca28  rdx: 0x00000028
  rdi: 0x7fff5fbfca90  rsi: 0x00000003  rbp: 0x7fff5fbfca70  rsp: 0x7fff5fbfca28
   r8: 0x00000107   r9: 0x00000000  r10: 0x000003b0  r11: 0x00000206
  r12: 0x00000003  r13: 0x7fff5fbfca90  r14: 0x00000107  r15: 0x000003b0
  rip: 0x7fff8bb1d686  rfl: 0x00000206

Binary Images Description:
       0x100000000 -        0x100373fff /Users/Tom/MBbench/CPU1/./MBv8_8.0r3257_sse41_x86_64-apple-darwin
    0x7fff84244000 -     0x7fff842c5fff /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata
    0x7fff8454c000 -     0x7fff8454cfff /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
    0x7fff8454d000 -     0x7fff84557fff /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition
    0x7fff8462b000 -     0x7fff84fc5fff /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics
    0x7fff84ffb000 -     0x7fff85003fff /usr/lib/system/libsystem_dnssd.dylib
    0x7fff85004000 -     0x7fff85023fff /usr/lib/libresolv.9.dylib
    0x7fff850dd000 -     0x7fff85105fff /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib
    0x7fff85106000 -     0x7fff85113fff /System/Library/PrivateFrameworks/AppleFSCompression.framework/Versions/A/AppleFSCompression
    0x7fff8518a000 -     0x7fff8518cfff /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print
    0x7fff851da000 -     0x7fff851e9fff /usr/lib/libxar.1.dylib
    0x7fff851fb000 -     0x7fff851fbfff /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
...

Seems there is also a problem with the OSX ATI5 App, it fails with;

../../src/GPU_lock.cpp:521:9: error: use of undeclared identifier 'swi'
        switch(swi.analysis_cfg.gauss_pot_length){
               ^
../../src/GPU_lock.cpp:582:5: error: use of undeclared identifier 'swi'
        if(swi.analysis_cfg.autocorr_fftlen)    strcat(bin_file_name,"_V7");
           ^
../../src/GPU_lock.cpp:584:9: error: use of undeclared identifier 'swi'
        switch(swi.analysis_cfg.gauss_pot_length){
...
clang: error: no such file or directory: 'seti_boinc-GPU_lock.o'
cp: seti_boinc: No such file or directory
error: strip: can't open file: MBv8_8.0r3257_sse41_clGPU_x86_64-apple-darwin (No such file or directory)

Although not part of any formal test comparisons I was trying to make, I just noticed some rather puzzling run times on several Linux tasks.

There were 4 tasks which started within 14 minutes of each other, 2 of them under the v8.01 x86_64-pc-linux-gnu app and 2 under v8.02 i686-pc-linux-gnu. Each pair of tasks included one VLAR, with AR=0.019474 and one "normal", with AR=0.415050. In both cases, the VLAR task took much less time to run than the "normal" AR. That seems really odd to me. None of the tasks were overflows.

v8.01 x86_64-pc-linux-gnu
Task 21515760 (AR=0.019474) : Run Time 3:28:38 | v_vGetPowerSpectrumUnrolled; sse2_ChirpData_ak8; v_vTranspose4; BH SSE folding
Task 21515371 (AR=0.415050) : Run Time 5:24:53 | v_vGetPowerSpectrumUnrolled; sse2_ChirpData_ak8; v_vTranspose4; AK SSE folding

v8.02 i686-pc-linux-gnu
Task 21515782 (AR=0.019474) : Run Time 3:59:56 | v_vGetPowerSpectrum; sse3_ChirpData_ak8; v_vTranspose4x16ntw; BH SSE folding
Task 21516351 (AR=0.415050) : Run Time 5:33:45 | v_vGetPowerSpectrum; sse2_ChirpData_ak8; v_vTranspose4; AK SSE folding

Could this possibly be an issue due to the VLARs containing Green Bank data while the non-VLARs are from Arecibo? Is there that much difference in the processing?

Anyway, my third group of Linux vs. Windows tests is now under way, starting on the Windows side. It looks like I've got a nice group of both VLAR and normal AR tasks from the matching batches, so it will be interesting to see if this VLAR vs. "normal" behavior is repeatable under more controlled conditions. I don't expect to have results from both OSes today, however.

Yeah, I'm noticing the same surprising behaviour with "guppi" VLAR WU's. VLAR's running faster than "normal" AR's. That's something new.

8.03 is released for Windows too now.

This is from my first WU running 8.03 (taken from the stderr in the slot, because it is still running)

http://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=7816119
Running on this computer: http://setiweb.ssl.berkeley.edu/beta/show_host_detail.php?hostid=75292


setiathome_v8 8.00 DevC++/MinGW/g++ 4.8.1
libboinc: 7.7.0

Work Unit Info:
...............
WU true angle range is : 0.415154
Optimal function choices:
--------------------------------------------------------
name timing error
--------------------------------------------------------
v_BaseLineSmooth (no other)
v_avxGetPowerSpectrum 0.000039 0.00000
avx_ChirpData_b 0.003828 0.00000
v_vTranspose4x16ntw 0.001927 0.00000
JS AVX_a folding 0.000272 0.00000

Seems to be a bug above eh? (in bold).
In WU's for 8.01, it read "v_avxTranspose4x16ntw"

Does anyone know where I can find a file called export.h?
I searched all of the repository, nothing. It's mentioned here;
47 #include "export.h"
That's just one of the errors, but it appears it's the one stopping the build...for now.

readwu.cpp:47:10: fatal error: 'export.h' file not found
#include "export.h"
^
8 warnings and 1 error generated.
make[2]: [readwu_so-readwu.o] Error 1 (ignored)
mv -f .deps/readwu_so-readwu.Tpo .deps/readwu_so-readwu.Po
mv: rename .deps/readwu_so-readwu.Tpo to .deps/readwu_so-readwu.Po: No such file or directory
make[2]: [readwu_so-readwu.o] Error 1 (ignored)