How do I tell the difference from tasks split from Aercibo and Green Banks?

By the task name. The Arecibo recordings are identified by date (ddmmyy) as previously. The GBT tasks we've seen so far have task names staring guppi_, but the splitters have been made as general-purpose as possible - there may be other data sources in future.

And, when will GPU tasks be ready for testing?

The tasks, as always, are undifferentiated. It doesn't matter what sort of (co-)processor they're crunched on. But the first step is to get the CPU apps returning consistently accurate results, across all platforms. Once the reference point is established, GPU apps can be tested for compatibility.

OpenCL ones currently in alpha testing on my hosts.
One can look their statistics.

In particular:
SETI@home v8 (анонимная платформа, Тип ЦП)
Число завершённых заданий 37
Максимум заданий в день 71
Число заданий сегодня 0
Правильные задания завершённые подряд 38
Средняя скорость обработки 12.67 GFLOPS
Среднее время обработки 0.79 days
SETI@home v8 (анонимная платформа, ГП ATI)
Число завершённых заданий 56
Максимум заданий в день 90
Число заданий сегодня 2
Правильные задания завершённые подряд 57
Средняя скорость обработки 109.12 GFLOPS
Среднее время обработки 0.44 days

So, 56 completed and validated tasks for ATi HD5 build already. No invalids, no inconclusives, no errors.

---

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

Unfortunately I have only really ancient NV hardware for testing and there is no new downloads and reports on Lunatics site.
Alpha testers, wake up...

---

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

I rely on a volunteer for Intel MacOS compiles. I can suggest compiler settings, but I can't enforce them, and the time between versions is going to be longer.

Right now My CPU & OpenCL builds all fail with what appears to be the same error. I haven't been able to compile a CPU app since around 2955 and now the v8 GPU app build also fails. I think the problem starts around here, but not sure;

Undefined symbols for architecture x86_64:
  "boinc_resolve_filename_s(char const*, std::string&)", referenced from:
      _main in seti_boinc-main.o
      seti_init_state() in seti_boinc-seti.o
      worker() in seti_boinc-worker.o
  "std::__1::__vector_base_common<true>::__throw_length_error() const", referenced from:...

Undefined symbols for architecture x86_64:
  "boinc_resolve_filename_s(char const*, std::string&)", referenced from:
      _main in seti_boinc-main.o
      seti_init_state() in seti_boinc-seti.o
      worker() in seti_boinc-worker.o
      initializeCL(char const*) in seti_boinc-GPU_lock.o
  "std::__1::__vector_base_common<true>::__throw_length_error() const", referenced from:...

Now that Jason has changed things around that doesn't work either, so, I'm just watching Petri's app produce an amazing amount of completed files.

Now that Jason has changed things around that doesn't work either, so, I'm just watching Petri's app produce an amazing amount of completed files.

And unfortunately Petri hasn't done any official Beta testing since 2012:

Computers belonging to petri33

Until we can get all volunteer developers and testers to agree on a common quality control protocol, we are in danger of undermining the project we claim to support.

Hey people. I'm running s@home beta on my computer but i dont understand anything about c++ etc programming language.

Unfortunately I have only really ancient NV hardware for testing and there is no new downloads and reports on Lunatics site.
Alpha testers, wake up...

After the New Year I'll be in position to do Windows CPU/NV/ATI alpha testing, and not before.

Claggy

The work is the same for 8.01 and 8.00 and 8.02. When released to main they'll all call themselves 8.00 (to avoid confusion). I think at this point we prefer you run results to completion regardless of whether a newer version has come out. The statistics are helpful.

---

The work is the same for 8.01 and 8.00 and 8.02. When released to main they'll all call themselves 8.00 (to avoid confusion). I think at this point we prefer you run results to completion regardless of whether a newer version has come out. The statistics are helpful.

Cause version number is voluntarily defined thing and will be reset to 8.00 when releasedf to main I would suggest (in case any new update will be needed) to mark binaries with same features and from same code revisions with same version numbers. Having 8.0 for mac, 8.01 for Windows and 8.02 for Linux with actually same code changes... makes things harder, not simplier.

---

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

I have a question, will v8 need a newer Nvidia graphics driver than 266.58? I just had to ask.

I ask this as currently I'm running a crippled PC here and the 266.58 driver is normally the only driver I can use that allows crunching in this PC's current state, right now the video card is waiting to be exchanged for a clean card, since the current one has dust and muck in and on the radiator of My Zotac GTX580 Infinity card(that's what a swamp cooler will do, make dust into something canned air won't budge, I do have a solution of course, but it means getting the card near the sink and it's rather involved, but I'm sure it will work), I have an EVGA GTX570 ready to fill in, but I have to change brackets, since the current bracket is bent(My fault).

The reason I can't use a newer driver than 266.58 is mainly cause the circuit that allows power to be distributed across the motherboard is damaged and has been slowly losing power and My system as a result has been slowing down and at times the PC goes into a wait state(this can be frustrating at times), My replacement PC is nearly finished, I just have to do two things, 1. get the energy to exchange the dead cpu cooler for one that works and 2. take the battery off the motherboard to clear the bios settings(in this exact order, since I don't want to kill a cpu, heat will do that), it's that or do a motherboard/cpu swap and yes I'm prepared to do that, I have an Asus Rampage IV Extreme motherboard and i7 3820 cpu on standby to replace the EVGA X79 Classified motherboard and its i7 3820 cpu, just in case, last resort really.

I have a question, will v8 need a newer Nvidia graphics driver than 266.58? I just had to ask.

Raistmer has told me that his OpenCL application for NVidia "requires 350.x+ drivers to operate properly" on your card. I think that's an absurdly restrictive requirement for a mass-circulation application, and I've suggested it should be restricted to a "for advanced users only" specialist role for people prepared to guarantee compliance - especially since that application doesn't fail (error) with an older driver, but quietly returns incorrect results.

In the past, the CUDA applications have been much more tolerant in their driver range, but so far I haven't even had a whisper of a CUDA v8 build, let alone had an opportunity to test one. I hope they will be made available in time for testing before the public release.

Regarding "absurdity" and so on - file objections to nVidia, I'll sign under them. Not topic for discussion here cause no one here writes NV drivers.

Regarding what drivers needed:
Absolutely same requirements as for OpenCL NV v7 that available here for MANY MONTHS (!).
If you able to run OpenCL NV v7 here you will able to run v8.

Reference: http://setiweb.ssl.berkeley.edu/beta/forum_thread.php?id=2250#54446

---

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

Currently if I were to run anything newer than 266.58 on this motherboard, the gpu would max out at either 51MHz or 405MHz.

Yeah I know no one here writes or works for Nvidia.

Cause almost no one cared to establish exact boundaries of compatible driver versions for OpenCL MB v7, v8 will go with 350+ restriction for FERMI+ embedded in absence of more fine grained limitations.

---

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

I think I remember something about the newer version of bonic-master. Which version should I use to try to compile a v8 Mac App? I downloaded a copy from here, https://github.com/BOINC/boinc, yesterday but the only version info I can find is;
#define PACKAGE_STRING "BOINC 7.7.0"
#define PACKAGE_BUGREPORT ""

Is there any known 'good' version to be used with seti_v8?

I'm using a checkout of the master (i.e. HEAD) branch from a few weeks ago.

---

My T7400 has both Linux (Mint 17.2) and Windows (8.1) installed, so I thought it would be interesting to attempt to run similar tasks from the same batch of data through both OSes to see how they perform on the identical hardware. I thought this might help me decide which OS would be more productive once v8 goes into "production".

I had hoped to get both v8.01 x86_64-pc-linux-gnu and v8.02 i686-pc-linux-gnu tasks running at the same time, also, but haven't achieved that with this first group. However, I was able to get both VLAR and non-VLAR (slightly high AR) tasks for both OSes in the first group.

The performance in both OSes, for both VLAR and non-VLAR, seems to be remarkably consistent. I did notice that function choices seem to vary considerably, even though the hardware is identical. (For each OS, the initial, or only, 8 tasks kicked off within a few seconds of each other since I started each test with an empty queue.)

===============================

06ap11ag.19682.1703.6.40.nnn_n (AR=1.152455)
v8.01 windows_intelx86
Task 21511167 : Run Time 2:06:53 (Credit=44.71) | v_vGetPowerSpectrumUnrolled; sse3_ChirpData_ak8; v_pfTranspose4; AK SSE folding
Task 21511161 : Run Time 2:07:42 (Credit=45.37) | v_vGetPowerSpectrumUnrolled; sse2_ChirpData_ak8; v_pfTranspose2; AK SSE folding
Task 21511381 : Run Time 2:02:01 (Credit=TBD) | v_vGetPowerSpectrumUnrolled; sse2_ChirpData_ak8; v_vTranspose4; AK SSE folding
Task 21511456 : Run Time 2:08:35 (Credit=TBD) | v_vGetPowerSpectrumUnrolled; sse3_ChirpData_ak8; v_pfTranspose2; AK SSE folding

v8.01 x86_64-pc-linux-gnu
Task 21510535 : Run Time 2:10:29 (Credit=34.60) | v_vGetPowerSpectrumUnrolled; sse2_ChirpData_ak8; v_vTranspose4; AK SSE folding
Task 21511249 : Run Time 2:06:55 (Credit=TBD) | v_vGetPowerSpectrumUnrolled; sse1_ChirpData_ak8h; v_vTranspose4np; BH SSE folding
Task 21511110 : Run Time 1:35:26 (Credit=TBD) | v_vGetPowerSpectrumUnrolled; sse1_ChirpData_ak; v_Transpose; BH SSE folding
Task 21511399 : Run Time 1:36:37 (Credit=29.82) | v_vGetPowerSpectrumUnrolled; sse1_ChirpData_ak8e; v_vTranspose4; BH SSE folding

NOTE: These 4 Linux tasks essentially ran in pairs, with the 3rd and 4th ones kicking off as the 2nd and 1st finished, respectively. The other 6 cores were concurrently occupied by the VLAR tasks shown below, so the difference in run times for these tasks would seem to indicate that there was more contention for system resources during the earlier part of the VLAR runs (when the first two of these tasks were running) as opposed to the VLARs' latter stages.

===============================

guppi_8bit_56520_6_VOYAGER1_0012.21525.209.19.22.nnn.vlar_n (AR=0.019474)
v8.01 windows_intelx86
Task 21511163 : Run Time 3:41:19 (Credit=76.86) | v_vGetPowerSpectrumUnrolled; sse3_ChirpData_ak8; v_vTranspose4; AK SSE folding
Task 21511384 : Run Time 3:41:57 (Credit=82.73) | v_vGetPowerSpectrumUnrolled; sse3_ChirpData_ak8; v_pfTranspose2; AK SSE folding
Task 21511482 : Run Time 3:40:58 (Credit=TBD) | v_vGetPowerSpectrumUnrolled; sse2_ChirpData_ak8; v_vTranspose4; AK SSE folding
Task 21511169 : Run Time 3:43:27 (Credit=80.04) | v_vGetPowerSpectrumUnrolled; sse3_ChirpData_ak8; v_pfTranspose4; AK SSE folding

v8.01 x86_64-pc-linux-gnu
Task 21510885 : Run Time 3:40:59 (Credit=TBD) | v_vGetPowerSpectrumUnrolled; sse3_ChirpData_ak8; v_vTranspose4; BH SSE folding
Task 21510488 : Run Time 3:40:53 (Credit=64.91) | v_vGetPowerSpectrumUnrolled; sse1_ChirpData_ak; v_vTranspose4; BH SSE folding
Task 21511252 : Run Time 3:37:43 (Credit=66.76) | v_vGetPowerSpectrumUnrolled; sse1_ChirpData_ak8e; v_pfTranspose4; BH SSE folding
Task 21510967 : Run Time 3:44:08 (Credit=TBD) | v_vGetPowerSpectrumUnrolled; sse1_ChirpData_ak8h; v_vTranspose4np; BH SSE folding
Task 21511467 : Run Time 3:43:11 (Credit=TBD) | v_vGetPowerSpectrumUnrolled; sse1_ChirpData_ak8h; v_Transpose2; BH SSE folding
Task 21510697 : Run Time 3:54:15 (Credit=63.79) | v_vGetPowerSpectrumUnrolled; sse2_ChirpData_ak8; v_Transpose; BH SSE folding

===============================

I currently have another group of 8 (all non-VLAR) tasks running under Windows, with a corresponding group of v8.02 i686-pc-linux-gnu tasks that I'll run after those are done. I won't see the v8.02 Linux results until tomorrow morning, since it appears, from looking at the current progress of the Windows tasks (only about 65% after 2.5+ hrs), that this group of non-VLARs (AR=1.223888) is going to take much longer to run than the first group (where AR=1.152455). Perhaps running 8 non-VLARs concurrently causes each to run much more slowly than when there were 4 non-VLARs running concurrently with 4 VLARs?

I've also included the Credit numbers for the tasks that have validated thus far because, although it's certainly not a debate that I ever want to get into, I think it's highly likely that, if the apparent Windows/Linux discrepancy continues on beyond the Beta environment, it will add some fuel to the fire. ;^)

Well, comparison between x86 Windows and x64 Linux not only about OSes comparison, but also (mostly?)about platforms comparison. In x64 mode hardware (CPU) works in different configuration with different cache behavior and number of available registers.
Would be interesting to compare different OSes inside same platform (cause no x64 binary for Windows so far it has to be x86).

Variation in function choices may lead to variation in run times (as seen) and speaks about imperfection of benching system even in its refined form. From other side, difference only in ~4-5 seconds places hard limit for bench length. Absolute no sense to make bench (that is, time for all tasks) longer in same scale as this difference.

---

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

As a follow-on to last evening's post, here's a comparison of similar tasks from the same batch of data run on my old T7400, with 8 tasks under Linux (Mint 17.2) and 8 under Windows (8.1).

I really have no idea what to make of the much longer run times for the Windows tasks when compared not only with the Linux tasks shown here, but also with the Windows tasks in my post from last evening (which had a similar AR of 1.152455). In all cases, the CPU times are only slightly less than the run times.

06ap11ag.25755.2930.6.40.nnn_n (AR=1.223888)
v8.01 windows_intelx86
Task 21513713 : Run Time 3:47:10 (Credit=50.24) | v_vGetPowerSpectrumUnrolled; sse3_ChirpData_ak8; v_pfTranspose4; AK SSE folding
Task 21513578 : Run Time 3:44:40 (Credit=37.13) | v_vGetPowerSpectrumUnrolled; sse3_ChirpData_ak; v_vTranspose4; AK SSE folding
Task 21514033 : Run Time 3:47:17 (Credit=37.24) | v_vGetPowerSpectrumUnrolled; sse2_ChirpData_ak; v_vTranspose4; AK SSE folding
Task 21514021 : Run Time 3:49:12 (Credit=52.29) | v_vGetPowerSpectrumUnrolled; sse1_ChirpData_ak8h; v_Transpose2; BH SSE folding
Task 21514011 : Run Time 3:47:04 (Credit=40.73) | v_vGetPowerSpectrumUnrolled; sse1_ChirpData_ak8e; v_vTranspose4; AK SSE folding
Task 21513994 : Run Time 3:36:00 (Credit=39.90) | v_vGetPowerSpectrumUnrolled; sse2_ChirpData_ak8; v_vTranspose4; AK SSE folding
Task 21513991 : Run Time 3:43:54 (Credit=40.32) | v_vGetPowerSpectrum; sse1_ChirpData_ak8e; v_pfTranspose2; AK SSE folding
Task 21513988 : Run Time 3:38:08 (Credit=47.20) | v_vGetPowerSpectrumUnrolled; sse2_ChirpData_ak8; v_vTranspose4; AK SSE folding

v8.02 i686-pc-linux-gnu
Task 21513725 : Run Time 2:44:42 (Credit=58.46) | v_vGetPowerSpectrumUnrolled; sse1_ChirpData_ak8h; v_Transpose2; AK SSE folding
Task 21513467 : Run Time 2:45:58 (Credit=51.61) | v_vGetPowerSpectrumUnrolled; sse3_ChirpData_ak8; v_pfTranspose2; AK SSE folding
Task 21513933 : Run Time 2:42:08 (Credit=40.80) | v_vGetPowerSpectrumUnrolled; sse3_ChirpData_ak8; v_vTranspose4; BH SSE folding
Task 21513868 : Run Time 2:40:40 (Credit=TBD) | v_vGetPowerSpectrumUnrolled; sse1_ChirpData_ak8h; v_vTranspose4; AK SSE folding
Task 21513823 : Run Time 2:44:30 (Credit=41.22) | v_vGetPowerSpectrumUnrolled; sse3_ChirpData_ak8; v_vTranspose4; AK SSE folding
Task 21513816 : Run Time 2:44:14 (Credit=34.32) | v_vGetPowerSpectrumUnrolled; sse1_ChirpData_ak8h; v_vTranspose4; AK SSE folding
Task 21513813 : Run Time 2:39:46 (Credit=33.53) | v_vGetPowerSpectrumUnrolled; sse1_ChirpData_ak; v_pfTranspose2; BH SSE folding
Task 21513791 : Run Time 2:39:46 (Credit=36.84) | v_vGetPowerSpectrumUnrolled; sse1_ChirpData_ak; v_vTranspose4; AK SSE folding

In addition to the initial group of 8 tasks that all ran concurrently, I'm including 2 more of the Linux tasks that ran later, simply because these 2 tie directly to 2 of the Windows tasks listed above. Linux task 21513711 and Windows task 21513713 both came from WU 7814017, while Linux task 21513577 and Windows task 21513578 both came from WU 7813972. I figure there can't be a much more direct performance comparison than running 2 tasks from the same WU on the same hardware under 2 different OSes.

Task 21513711 : Run Time 2:43:59 (Credit=50.24) | v_vGetPowerSpectrumUnrolled; sse2_ChirpData_ak8; v_vTranspose4; BH SSE folding
Task 21513577 : Run Time 2:46:02 (Credit=37.13) | v_vGetPowerSpectrumUnrolled; sse1_ChirpData_ak8e; v_vTranspose4; AK SSE folding

EDIT: I just had a thought about the increase in Windows task run times. Before this last batch ran, I upgraded BOINC from 7.6.6 to 7.6.9 (which I thought might be a more stable release). Is there any possibility that this BOINC upgrade could have degraded the run times like that?? (It doesn't seem likely to me that it would, but since that was definitely a change in the environment from one batch to the next, I just thought I should mention it.)

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 ?

---

News about SETI opt app releases: https://twitter.com/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.