V8 how are the CPU and Run times being calculated all seem to be high??

Run times aren't calculated - they are measured and reported. That's how long they are taking on your machine - have a look there.

WINDOWS 10 Professional x64 Edition, (10.00.10586.00)
BOINC 7.6.9
Error while computing 29.41 28.81 --- SETI@home v8 v7.99 windows_intelx86
my Computer 76658
All tasks for my computer 76658

Number of processors 8 --- Dual CPU's --- four cores per CPU
no Hyper Threading
Memory 4093.58 MB
Cache 256 KB
Swap space 5885.58 MB
CPU Intel Xeon CPU E5507 @ 2.27GHz [Family 6 Model 26 Stepping 5]
Total disk space 223.08 GB
Free Disk Space 173.38 GB
Measured floating point speed 2739.83 million ops/sec
Measured integer speed 6502.05 million ops/sec
Average upload rate 88.45 KB/sec
Average download rate 899.44 KB/sec
Average turnaround time 0.11 days

<core_client_version>7.6.9</core_client_version>
<![CDATA[
<message>
The system cannot find the path specified.
 (0x3) - exit code 3 (0x3)
</message>
<stderr_txt>
setiathome_v8 7.99 DevC++/MinGW/g++ 4.8.1
libboinc: 7.7.0

Work Unit Info:
...............
WU true angle range is :  0.020647
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc

</stderr_txt>
]]>

same here, an 8bit task dropped dead with a runtime error (XP so I got a nice waring window to ok) 7 min in (on a AMD 1Ghz) same stderr breakoff point.
that cruncher is offline, and just doing a plain voyager, so far apears fine.

---

A person who won't read has no advantage over one who can't read. (Mark Twain)

And the same here, e.g. task 20775392.

This is beginning to look endemic to the tasks with '_8bit_' in the name, which have been split with a new splitter - they show the intended application name in the WU header, which the plain guppies don't.

This looks wrong. All the header data looks the same (by eye only, no guarantee), _except_:

from the earlier guppi task:

  <name>guppi_56520_1_VOYAGER1_0012.27866.209.20.23.236.vlar</name>
  ...
  <receiver_cfg>
    <s4_id>20</s4_id>
    <name>Green Bank Telescope, Rcvr8_10, Pol 1</name>
    <beam_width>2.4587973414132e-08</beam_width>
    <center_freq>8418749952</center_freq>

and the newer one

  <name>guppi_8bit_56520_VOYAGER1_0012.16007.1.20.23.159.vlar</name>
  ...
  <receiver_cfg>
    <s4_id>20</s4_id>
    <name>Green Bank Telescope, Rcvr8_10, Pol 1</name>
    <beam_width>0.024587973414132</beam_width>
    <center_freq>8418749952</center_freq>

The beam width has changed by six orders of magnitude?

First 23 have come in with 5 pending and 18 valid, 27 to go, on my 4770K, Win7(x64) machine. Fastest clock time seems to be approx. 1.37 hrs. and the slowest approx. 1.45 hrs.

All tasks seem to be VLARs, will the majority of CPU tasks be VLARs or will there be a healthy mix. I would sure like to see VLARs assigned to GPUs as I remember they were processed quite well back when I did them on my GTX460SC & GTX660SC, when it was a trend for a while to transfer the to the GPU via BOINCTasks, even though they were still credited as CPU tasks.

---

I don't buy computers, I build them!!

This is beginning to look endemic to the tasks with '_8bit_' in the name, which have been split with a new splitter - they show the intended application name in the WU header, which the plain guppies don't.

I've got a similar problem with my self compiled r3173 app, I had two 8bit Wu's showing as waiting to run,
looking at task properties shows Virtual memory size as 4.79GB, with a Working set size of 2.97 GB,
upping the Memory use settings to 95% got one of the tasks running, but it cycles, repeatatly,
looking at System Monitor shows the app using up to 3.3 GiB of memory,
looking at the slot shows the app doesn't get as far as doing it function choices,
looks as it only gets as far as trying to generate the wisdom file, before it restarts, no state file is generated.

http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=20775251

http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=20775479

setiathome_v8 7.99 Revision: 3173 g++ (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4
libboinc: BOINC 7.7.0

Work Unit Info:
...............
WU true angle range is : 0.020647
setiathome_v8 7.99 Revision: 3173 g++ (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4
libboinc: BOINC 7.7.0

Work Unit Info:
...............
WU true angle range is : 0.020647
setiathome_v8 7.99 Revision: 3173 g++ (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4
libboinc: BOINC 7.7.0

Switching to the Stock 6.99 app produces the same result:

http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=20782592

http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=20775197

setiathome_v7 7.99 Revision: 3112 g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)
libboinc: BOINC 7.7.0

Work Unit Info:
...............
WU true angle range is : 0.020647
setiathome_v7 7.99 Revision: 3112 g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)
libboinc: BOINC 7.7.0

Work Unit Info:
...............
WU true angle range is : 0.020647
setiathome_v7 7.99 Revision: 3112 g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)
libboinc: BOINC 7.7.0

Work Unit Info:
...............
WU true angle range is : 0.020647
setiathome_v7 7.99 Revision: 3112 g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)
libboinc: BOINC 7.7.0

Work Unit Info:
...............
WU true angle range is : 0.020647
setiathome_v7 7.99 Revision: 3112 g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)
libboinc: BOINC 7.7.0

Work Unit Info:
...............
WU true angle range is : 0.020647

Claggy

Just had a bunch error out on this computer after several successes. May be a bad batch????

Also had trouble downloading on this one. Will try resetting project.

---

Tasks with '_8bit_' - error (bad_alloc) after allocation 1.964.776 Kb RAM

I took an '_8bit_' WU from the cache and modified it to run offline.

Taking out the <app_name> line made no difference - it still crashed.

Modifying the <beam_width> line to

<beam_width>2.4587973414132e-08</beam_width>

(taken from my post earlier) is letting it run OK (offline), with a normal memory footprint.

I hear an error beep from the speakers when it crashes, but - under Windows 7 - nothing appears on screen. But I'm getting a report that under older operating systems, an error message appears on screen and has to be dismissed before a new task can start.

Yup, '_8bit_' work units are throwing errors after 12 secs and virtual ram of 1910.2MB and real 965 MB real Memory

Yup, '_8bit_' work units are throwing errors after 12 secs and virtual ram of 1910.2MB and real 965 MB real Memory

lol. mine need 6 Minutes to come to the same conclusion. plus a very annoying 'this app threw a runtime exception, contact the programmers' window I need to ok, before it goes on to stop the task and start the next. edit: that's under XP
Which mean instead of babysitting and clicking ok every 6 minutes I might just as well abort the batch :D

---

A person who won't read has no advantage over one who can't read. (Mark Twain)

Just to see what the stderr says I looked at one of the error work units

<core_client_version>7.4.42</core_client_version>
<![CDATA[
<message>
The system cannot find the path specified.
(0x3) - exit code 3 (0x3)
</message>
<stderr_txt>
setiathome_v8 7.99 DevC++/MinGW/g++ 4.8.1
libboinc: 7.7.0

Work Unit Info:
...............
WU true angle range is : 0.020647
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc

</stderr_txt>

I only ran these after I saw everyone reporting them. Stopped all GPU work and only allowed 1 work unit at a time to run. All with the same results. Hope they can figure out what the issues are.

I suspended all tasks to force my PC (Windows 7 64-bit) to run the 5 8-bit tasks I had. Big mistake - the PC locked solid. Left it for about 5 mins and then gave it the one finger salute to restart it.

Fortunately, all 5 tasks errored out on reboot and I was able to regain control. Not entirely sure why the tasks locked the PC for so long as, according to the results, they ran for less than a minute before erroring out

http://setiweb.ssl.berkeley.edu/beta/results.php?userid=14462&offset=0&show_names=0&state=6&appid=38

I guess I'll need to put a Windows 10 system together for testing.
I wouldn't expect it to have a problem with a command line executable like the setiathome app.

Hi Eric,
I have the following Computer for testing:

WINDOWS 10 Professional x64 Edition, (10.00.10586.00)
BOINC 7.6.9
Error while computing 29.41 28.81 --- SETI@home v8 v7.99 windows_intelx86
my Computer 76658
All tasks for my computer 76658

Number of processors 8 --- Dual CPU's --- four cores per CPU
no Hyper Threading
Memory 4093.58 MB

I guess I'll need to put a Windows 10 system together for testing.
I wouldn't expect it to have a problem with a command line executable like the setiathome app.

WINDOWS 10 Professional x64 Edition, (10.00.10586.00)
BOINC 7.6.9

Hi Eric
I just had a successfully SETI@home v8 v7.99 windows_intelx86 on my Windows 10 Computer.

<Edit>

Oops I see it's a noisy WU
SETI@Home Informational message -9 result_overflow
NOTE: The number of results detected equals the storage space allocated.

</Edit>

http://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=7529670

Stderr output
<core_client_version>7.6.9</core_client_version>
<![CDATA[
<stderr_txt>
setiathome_v8 7.99 DevC++/MinGW/g++ 4.8.1
libboinc: 7.7.0

Work Unit Info:
...............
WU true angle range is :  0.019086
Optimal function choices:
--------------------------------------------------------
                            name   timing   error
--------------------------------------------------------
                v_BaseLineSmooth (no other)
     v_vGetPowerSpectrumUnrolled 0.000124 0.00000 
              sse2_ChirpData_ak8 0.007487 0.00000 
             v_vTranspose4x16ntw 0.003387 0.00000 
                  AK SSE folding 0.001452 0.00000 
SETI@Home Informational message -9 result_overflow
NOTE: The number of results detected equals the storage space allocated.

Flopcounter: 21766708094942.828000

Spike count:    1
Autocorr count: 1
Pulse count:    27
Triplet count:  1
Gaussian count: 0
08:22:27 (6804): called boinc_finish(0)

</stderr_txt>
]]>

Is the problem on the _8bit_ WUs with the data or the app? I see I just got 2 in the queue on my old ThinkCentre running Win XP, both of which have already had multiple fails (including an abortion by Richard).

If the problem is the data, I'll just preemptively abort them, but if it's an app problem, I can put them in suspense until the app has a fix, and then see if the fix works.

Task 20653938 hung-up Computer 71964 for several hours before I noticed it. Had to power-off to restart. When BOINC booted back up, the unit aborted itself. That is, I did not manually abort the unit. Stderr output says "finish file present too long".


AMD E-240 Processor [Family 20 Model 1 Stepping 0]
Microsoft Windows 10
Professional x64 Edition, (10.00.10240.00)
BOINC 7.6.9

---

Is the problem on the _8bit_ WUs with the data or the app? I see I just got 2 in the queue on my old ThinkCentre running Win XP, both of which have already had multiple fails (including an abortion by Richard).

If the problem is the data, I'll just preemptively abort them, but if it's an app problem, I can put them in suspense until the app has a fix, and then see if the fix works.

Eric reports that there is a 2nd Batch of 8Bit work that is supposed to fix this issue, I have no idea how to tell them apart.

Claggy

Is the problem on the _8bit_ WUs with the data or the app? I see I just got 2 in the queue on my old ThinkCentre running Win XP, both of which have already had multiple fails (including an abortion by Richard).

If the problem is the data, I'll just preemptively abort them, but if it's an app problem, I can put them in suspense until the app has a fix, and then see if the fix works.

Eric reports that there is a 2nd Batch of 8Bit work that is supposed to fix this issue, I have no idea how to tell them apart.

Claggy

So, a data or splitter issue it would seem. And since the two in my queue have already been proven bad, it's probably best I just abort them.