In script ... /usr/bin/perl^M ... not found or something
try typing
whereis perl <enter>
on a terminal window.

I guess it finds it ok. Then edit the ^M (Ctrl+M) away from the script file. It is a DOS remnant.

Typing whereis perl finds Perl OK

perl: /usr/bin/perl5.22-x86_64-linux-gnu /usr/bin/perl /etc/perl /usr/share/perl /usr/share/man/man1/perl.1.gz

But I can't find ^M (Ctrl+M) anywhere in the script.

On linux, Perl is already installed (type 'whereis perl' to know where the perl binary is located).
so change the first line "#!/usr/bin/perl" to your perl path "#!/<mypath>/perl" where mypath is your
perl path.
or you can run the script using :
'perl cpu2gpu.pl -i'

http://www.w3perl.com/seti/

"#!/usr/bin/perl" in the script seem to be OK, typing perl cpu2gpu.pl -i works:

#CPU,GPU,AP wu
95,195,0

Tried a simulation run: perl cpu2gpu.pl -r -u

GPU version found : 801 - (class : cuda80)
CPU version found : 800
AP version found : 704
Completed wu : blc05_2bit_guppi_57903_46950_HIP9480_0002.10206.409.24.47.45.vlar_1 (800)
Completed wu : blc05_2bit_guppi_57903_46950_HIP9480_0002.7287.818.24.47.37.vlar_0 (801)
Completed wu : blc05_2bit_guppi_57903_47289_HIP8825_0003.7853.818.24.47.81.vlar_1 (801)
Completed wu : blc05_2bit_guppi_57903_47289_HIP8825_0003.7853.818.24.47.72.vlar_1 (801)
Active wu : 01mr08ac.6628.24208.12.39.19_1 (800)
Active wu : 21oc08ac.15280.21745.4.31.139.vlar_2 (800)
Active wu : 21oc08ac.24024.1704.9.36.38_1 (800)
Active wu : 21oc08ac.10891.5385.7.34.153.vlar_1 (800)
Active wu : blc05_2bit_guppi_57903_47289_HIP8825_0003.7853.818.24.47.53.vlar_0 (801)
Active wu : blc05_2bit_guppi_57903_47289_HIP8825_0003.7853.818.24.47.56.vlar_0 (801)
Found GPU version used : 801 in /var/lib/boinc-client/client_state.xml (cuda80 / x86_64-pc-linux-gnu)
Found CPU Version used : 800 in /var/lib/boinc-client/client_state.xml
300 wu found
----- MODE SIMULATION
cannot write /var/lib/boinc-client/client_state_new.xml at cpu2gpu.pl line 441.

So I'm still stuck :(

cannot write /var/lib/boinc-client/client_state_new.xml at cpu2gpu.pl line 441.

Try running as SuperUser 'sudo'

cannot write /var/lib/boinc-client/client_state_new.xml at cpu2gpu.pl line 441.

Try running as SuperUser 'sudo'

That worked, thanks.

Sudo this sudo that...

I just leave a SuperUser window (did I say Window? LOL) open so that everything you do is a sudo
sudo bash - makes you SuperUser.

I've searched the thread and didn't come up with an answer to a question I have about what does "Sigma" represent in the stderr.txt output. It varies quite a bit over large values. Is a Sigma value of 3 good? Or is a Sigma value of 400 good?

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

I've searched the thread and didn't come up with an answer to a question I have about what does "Sigma" represent in the stderr.txt output. It varies quite a bit over large values. Is a Sigma value of 3 good? Or is a Sigma value of 400 good?

Sigma refers to the width of a Gaussian search. The bigger the value the wider the search under the Gaussian curve (more work). No bad or good meanings.

Petri

---

To overcome Heisenbergs:
"You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones

Thanks Petri. Just wondered what it represented and if it had anything to do with a low value in my case, being represented a lot more in my Inconclusives list. I figured it probably didn't since my increase in the past week was of my own doing. But was curious anyhow.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Sigma refers to the width of a Gaussian search. The bigger the value the wider the search under the Gaussian curve (more work). No bad or good meanings.

Petri

With one sigma, you get 68% of the signal, two sigma 95%, 3 sigma 99.7% and 5 sigma 99.999%
In science, most people require a 3 sigma signal to be relevant. In particle physics, they need 5 sigma to make an announcement.

---

Thanks Petri. Just wondered what it represented and if it had anything to do with a low value in my case, being represented a lot more in my Inconclusives list. I figured it probably didn't since my increase in the past week was of my own doing. But was curious anyhow.

The value being output is an old debug print out. I was figuring out what the software does with different ar and WU type. Some WU's do not do any Gaussian searches, some do not do any pulse finds with small FFT lengths. Vlars/Guppi do a lot of pulse find work with FFT len 8, 16, 32,..., 1024 and that is SLOW even with the special app.

Some workloads spread nicely over all of the GPU compute units, some do not. There is a lot of places for optimisations still to do. That keeps me in this hobby. I would not do this for money.

---

To overcome Heisenbergs:
"You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones

There is a lot of places for optimisations still to do. That keeps me in this hobby. I would not do this for money.

:-)
Reminds me of when I used to repair VCRs, cameras and the like for a living. When my VCR broke down, I didn't repair it for about 3 months, and only then because my brother kept hassling me about it.
When you have to do something, it tends to take a lot of the enjoyment out of it.

---

Grant
Darwin NT

Anybody know if the Special App was tested against the 4-bit WUs in Beta? The reason I ask is that I've had some odd Invalids on two different machines over the last couple days. They're -9 overflows where the Pulse and Triplet counts differ significantly from the wingmen who successfully validated.

I'm pretty sure there's also been an increase in my Inconclusives, with a sampling of those looking like these:

Workunit 2669316379 (01mr08ac.6680.72.14.41.0)
Task 6005913251 (S=0, A=0, P=29, T=1, G=0, BG=0) v8.22 (opencl_nvidia_SoG) windows_intelx86
Task 6005913252 (S=0, A=0, P=0, T=30, G=0, BG=0) x41p_zi3v, Cuda 8.00 special

Workunit 2670652172 (10oc08af.29544.82164.10.37.255)
Task 6008700184 (S=0, A=0, P=29, T=1, G=0, BG=0) v8.20 (opencl_ati5_SoG_mac) x86_64-apple-darwin
Task 6008700185 (S=0, A=0, P=10, T=20, G=0, BG=0) x41p_zi3t2b, Cuda 8.00 special

Workunit 2671281097 (14dc08ab.28268.66735.15.42.1)
Task 6010004517 (S=0, A=0, P=14, T=16, G=0, BG=0) v8.22 (opencl_nvidia_SoG) windows_intelx86
Task 6010004518 (S=0, A=0, P=0, T=30, G=0, BG=0) x41p_zi3t2b, Cuda 8.00 special

Workunit 2671421404 (14dc08ab.30525.69598.16.43.0)
Task 6010297125 (S=0, A=0, P=30, T=0, G=0, BG=0) v8.22 (opencl_nvidia_SoG) windows_intelx86
Task 6010297126 (S=0, A=0, P=0, T=30, G=0, BG=0) x41p_zi3t2b, Cuda 8.00 special

This may not be limited to Cuda80, though, as I also got an Invalid for a similar Pulse/Triplet mismatch on my daily driver running Cuda50. Only my 4th Invalid on that machine in over 4 years of crunching.

Hmmm - I'm seeing a number of invalids across my Linux boxes, all of which are running the special app. Some are guppies, but one set are ex-Arecibo, not sue if they were 2 or 4 bit deliveries....

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

I've just watched a pile of downloads - it would appear that most, if not all, tasks (including ex-Arecibo) we are getting now are 4-bit, despite many being labeled 2-bit

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

I've been seeing a lot of inconclusives too. Additional new ones beyond the ones I admit were caused by me. I am seeing a single count difference either in Triplets or Pulses against my wingmen. They seem to be associated mostly with the new larger tasks.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

I've just watched a pile of downloads - it would appear that most, if not all, tasks (including ex-Arecibo) we are getting now are 4-bit, despite many being labeled 2-bit

From Eric in Beta when they were first released for testing-

There won't be any easy way to tell what you've got apart from the file size. 2-bit WUs are about 360K. 4-bit WUs are about 620K. The "2bit" or "8bit" designation in the file name is about the input data that the splitter operated upon. (And it's wrong anyway. The 2bit input data is actually 4 bits per complex sample.)

In the workunit file itself, there's a relatively new entry called wu_bits_per_sample which should be 2 past data, and in the new data should say 4.

---

Grant
Darwin NT

The batch I watched were coming in at ~700k rather than the ~360k of late

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

From Eric:

Double size is the new standard for both Arecibo and GBT (and eventually Parkes). Unless UC complains about the extra traffic. I don't think they'll even notice it.

Yes, same here. Based on the FIFO ordering of tasks, I still am processing that big slug of 700K sized tasks. The recent ones today seem to be the older 357K size.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Strange, my 3x1080 rig does not have one 350k file on it.

Strange, my 3x1080 rig does not have one 350k file on it.

Likewise, all 705kB files here as well.

EDIT- just picked up a 360kB file; resend of a resend.

---

Grant
Darwin NT