I've been crunching mostly Beta since last week since it has a 3 to 1 ratio with main. Last night I ran out of Bata work, so BOINC started crunching my reserve cache of 80 WU from main. Now down 60 WU including 28 resend (3 AP), I pickup overnight. I figure I've still got another 8 to 10 hrs before my GPU falls back on Milkyway and Einstein.

EDIT: Got a full (50 WU) cache from BETA, so I'm good for 36 hrs.

---

Boinc V7.2.42
Win7 i5 3.33G 4GB, GTX470

Well my lucks in today, just got another 2 MB tasks.. Last lot were resends, but a WU is a WU just the same:-)

Regards,

---

Cliff,
Been there, Done that, Still no damm T shirt!

+1

Well my lucks in today, just got another 2 MB tasks.. Last lot were resends, but a WU is a WU just the same:-)

Regards,

---

+1

Well my lucks in today, just got another 2 MB tasks.. Last lot were resends, but a WU is a WU just the same:-)

Regards,

+2

---

rOZZ
Music
Pictures

Update on my Beta crunching: my i7 crunched through all the cuda32s and cuda42s (and a few cuda50s) it was sent, and got sent more 32s. Looking at the processing times, though, it seems to my amateur eye like the 42s were more efficient. Does the scheduler think differently than I do? (Probably...)

The Average processing rate (APR) shown on the Application details for host 66539 is 72.81 GFLOPS for CUDA32 and 64.93 GFLOPS for CUDA42. That's the basis on which the Scheduler logic considers CUDA32 faster.

However, the Scheduler choice of which to send has a random factor applied. It's based on the normal distribution so is usually small, and it is further scaled down by the number of completed tasks in the host average. The idea is that the host averages will get more reliable as more tasks are averaged in. But the host averages are calculated using exponential smoothing such that about half the average is based on the most recent 69 values, so they can actually vary considerably for GPU processing.

The "GFLOPS" are derived from the estimate of floating point operations the splitters provide. For SaH v7 those estimates are based on angle range (AR), and are a compromise between how AR affects processing on CPU or GPU. That compromise means that very high AR "shorties" provide a lower APR than normal midrange AR tasks when processed on GPU. It looks like all the CUDA42 tasks you got were shorties but CUDA32 has gotten a mix. Perhaps the next time the random factor makes the Scheduler send CUDA42 you'll get a batch of midrange AR tasks which will increase the APR for those.

                                                                  Joe

Update on my Beta crunching: my i7 crunched through all the cuda32s and cuda42s (and a few cuda50s) it was sent, and got sent more 32s. Looking at the processing times, though, it seems to my amateur eye like the 42s were more efficient. Does the scheduler think differently than I do? (Probably...)

The Average processing rate (APR) shown on the Application details for host 66539 is 72.81 GFLOPS for CUDA32 and 64.93 GFLOPS for CUDA42. That's the basis on which the Scheduler logic considers CUDA32 faster.

However, the Scheduler choice of which to send has a random factor applied. It's based on the normal distribution so is usually small, and it is further scaled down by the number of completed tasks in the host average. The idea is that the host averages will get more reliable as more tasks are averaged in. But the host averages are calculated using exponential smoothing such that about half the average is based on the most recent 69 values, so they can actually vary considerably for GPU processing.

The "GFLOPS" are derived from the estimate of floating point operations the splitters provide. For SaH v7 those estimates are based on angle range (AR), and are a compromise between how AR affects processing on CPU or GPU. That compromise means that very high AR "shorties" provide a lower APR than normal midrange AR tasks when processed on GPU. It looks like all the CUDA42 tasks you got were shorties but CUDA32 has gotten a mix. Perhaps the next time the random factor makes the Scheduler send CUDA42 you'll get a batch of midrange AR tasks which will increase the APR for those.

                                                                  Joe

A sidenote perhaps interesting to some: In addition to the averages being volatile with work mix and other aspects ignoring any hardware or app change not managed, the estimate mechanism already contains several 'noisy' inputs with various offsets/scales and variances in practice. Those sources of noise easily swamp those random factors inducing chaotic behaviour and making those random offsets more or less redundant.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

And now we have less than 900K MBs out in the field.

---

Update on my Beta crunching: my i7 crunched through all the cuda32s and cuda42s (and a few cuda50s) it was sent, and got sent more 32s. Looking at the processing times, though, it seems to my amateur eye like the 42s were more efficient. Does the scheduler think differently than I do? (Probably...)

The Average processing rate (APR) shown on the Application details for host 66539 is 72.81 GFLOPS for CUDA32 and 64.93 GFLOPS for CUDA42. That's the basis on which the Scheduler logic considers CUDA32 faster.

However, the Scheduler choice of which to send has a random factor applied. It's based on the normal distribution so is usually small, and it is further scaled down by the number of completed tasks in the host average. The idea is that the host averages will get more reliable as more tasks are averaged in. But the host averages are calculated using exponential smoothing such that about half the average is based on the most recent 69 values, so they can actually vary considerably for GPU processing.

The "GFLOPS" are derived from the estimate of floating point operations the splitters provide. For SaH v7 those estimates are based on angle range (AR), and are a compromise between how AR affects processing on CPU or GPU. That compromise means that very high AR "shorties" provide a lower APR than normal midrange AR tasks when processed on GPU. It looks like all the CUDA42 tasks you got were shorties but CUDA32 has gotten a mix. Perhaps the next time the random factor makes the Scheduler send CUDA42 you'll get a batch of midrange AR tasks which will increase the APR for those.

                                                                  Joe

A sidenote perhaps interesting to some: In addition to the averages being volatile with work mix and other aspects ignoring any hardware or app change not managed, the estimate mechanism already contains several 'noisy' inputs with various offsets/scales and variances in practice. Those sources of noise easily swamp those random factors inducing chaotic behaviour and making those random offsets more or less redundant.

Thanks, gentlemen.

---

David
Sitting on my butt while others boldly go,
Waiting for a message from a small furry creature from Alpha Centauri.

I think they may have disabled or changed the built in degradation part of RAC. Normally it should drop at least once a week, but I have machines that have had their RAC flat for ~3 weeks.

My RAC is continuing to fall.

---

David
Sitting on my butt while others boldly go,
Waiting for a message from a small furry creature from Alpha Centauri.

I've received 11 resends so far today, including a V7 AP. :-D

Cheers.

Hi Wiggo,

Yeah I got a whole 1 AP resend:-) However AP's don't seem to be getting validated, since the AP validator is seemingly offline..

Guess that's no surprise considering the AP database problems.

But I still have a couple of MB tasks waiting in the wings:-)

Regards,

---

Cliff,
Been there, Done that, Still no damm T shirt!

I notice that the SSP seems to cough up this hairball,

Warning: number_format() expects parameter 1 to be double, string given in /disks/carolyn/b/home/boincadm/projects/sah/html/seti_boinc_html/sah_status.php on line 417

any time the "Results received in last hour" for AP drops to zero. Perhaps a "divide by zero" type of error that's now showing up as we start to hit bottom.

This lark is getting beyond a joke now, not only is S@H effectively down for work, but a darn backup project has now gone down as well..

Maybe its server flu or summat.. going the rounds from one project to the next..


Regards,

---

Cliff,
Been there, Done that, Still no damm T shirt!

Enabled work fetch on Einstein.

No work for my GPU for hours and my CPU is almost freezing while crunching .
Wont happen anymore.

---

With each crime and every kindness we birth our future.

Enabled work fetch on Einstein.

No work for my GPU for hours and my CPU is almost freezing while crunching .
Wont happen anymore.

All of mine are fetching, crunching and reporting as requested.

http://einstein.phys.uwm.edu/hosts_user.php?userid=144054

Check that your preferences are up-to-date for the applications you were expecting to crunch.

Enabled work fetch on Einstein.

No work for my GPU for hours and my CPU is almost freezing while crunching .
Wont happen anymore.

All of mine are fetching, crunching and reporting as requested.

http://einstein.phys.uwm.edu/hosts_user.php?userid=144054

Check that your preferences are up-to-date for the applications you were expecting to crunch.

Richard i`m no newbe.

27.11.2014 23:17:17 Einstein@Home update requested by user
27.11.2014 23:17:21 Einstein@Home [sched_op] Starting scheduler request
27.11.2014 23:17:21 Einstein@Home Sending scheduler request: Requested by user.
27.11.2014 23:17:21 Einstein@Home Requesting new tasks for CPU and ATI GPU
27.11.2014 23:17:21 Einstein@Home [sched_op] CPU work request: 1.00 seconds; 0.00 CPUs
27.11.2014 23:17:21 Einstein@Home [sched_op] ATI GPU work request: 1.00 seconds; 1.00 GPUs
27.11.2014 23:17:23 Einstein@Home Scheduler request completed: got 0 new tasks
27.11.2014 23:17:23 Einstein@Home [sched_op] Server version 611
27.11.2014 23:17:23 Einstein@Home No work sent
27.11.2014 23:17:23 Einstein@Home see scheduler log messages on http://einstein5.aei.uni-hannover.de/EinsteinAtHome/host_sched_logs/3647/3647123
27.11.2014 23:17:23 Einstein@Home Jobs for CPU are available, but your preferences are set to not accept them

---

With each crime and every kindness we birth our future.

From the Server Status page:

http://setiathome.berkeley.edu/sah_status.html

Results ready to send: 3

Apparently it became 0 once again.

Yes, I know about the current problems.

http://setiathome.berkeley.edu/forum_thread.php?id=76174&postid=1605524

Please click on the links there will you?

I guess you all missed what he said.

Richard i`m no newbe.

You are in this case, you're running a Boinc without OpenCL detection:

http://einstein5.aei.uni-hannover.de/EinsteinAtHome/host_sched_logs/3647/3647123

2014-11-27 22:24:31.7574 [PID=28773] Request: [USER#xxxxx] [HOST#3647123] [IP xxx.xxx.xxx.3] client 6.12.34
2014-11-27 22:24:31.7580 [PID=28773] [send] effective_ncpus 2 max_jobs_on_host_cpu 999999 max_jobs_on_host 999999
2014-11-27 22:24:31.7580 [PID=28773] [send] effective_ngpus 1 max_jobs_on_host_gpu 999999
2014-11-27 22:24:31.7581 [PID=28773] [send] Not using matchmaker scheduling; Not using EDF sim
2014-11-27 22:24:31.7581 [PID=28773] [send] CPU: req 0.00 sec, 0.00 instances; est delay 0.00
2014-11-27 22:24:31.7581 [PID=28773] [send] ATI: req 1.00 sec, 1.00 instances; est delay 0.00
2014-11-27 22:24:31.7581 [PID=28773] [send] work_req_seconds: 0.00 secs
2014-11-27 22:24:31.7581 [PID=28773] [send] available disk 85.37 GB, work_buf_min 345600
2014-11-27 22:24:31.7581 [PID=28773] [send] active_frac 0.955851 on_frac 0.988101 DCF 1.274796
2014-11-27 22:24:31.7589 [PID=28773] [send] [HOST#3647123] is reliable
2014-11-27 22:24:31.7590 [PID=28773] [send] set_trust: random choice for error rate 0.000010: yes
2014-11-27 22:24:31.7882 [PID=28773] [version] Checking plan class 'BRP4G-opencl-ati'
2014-11-27 22:24:31.7901 [PID=28773] [version] reading plan classes from file '/BOINC/projects/EinsteinAtHome/plan_class_spec.xml'
2014-11-27 22:24:31.7901 [PID=28773] [version] numerical Windows version: 601760100 (Microsoft Windows 7 Ultimate x64 Edition, Service Pack 1, (06.01.7601.00))
2014-11-27 22:24:31.7901 [PID=28773] [version] parsed project prefs setting 'gpu_util_brp': 1.000000
2014-11-27 22:24:31.7901 [PID=28773] [version] ATI device (or driver) doesn't support OpenCL
2014-11-27 22:24:31.7901 [PID=28773] [version] Checking plan class 'BRP4G-cuda32'
2014-11-27 22:24:31.7902 [PID=28773] [version] parsed project prefs setting 'gpu_util_brp': 1.000000
2014-11-27 22:24:31.7902 [PID=28773] [version] No CUDA devices found
2014-11-27 22:24:31.7902 [PID=28773] [version] Checking plan class 'BRP4G-cuda32-nv301'
2014-11-27 22:24:31.7902 [PID=28773] [version] parsed project prefs setting 'gpu_util_brp': 1.000000
2014-11-27 22:24:31.7902 [PID=28773] [version] No CUDA devices found
2014-11-27 22:24:31.7902 [PID=28773] [version] Checking plan class 'BRP4G-opencl-ati'
2014-11-27 22:24:31.7902 [PID=28773] [version] parsed project prefs setting 'gpu_util_brp': 1.000000
2014-11-27 22:24:31.7902 [PID=28773] [version] ATI device (or driver) doesn't support OpenCL
2014-11-27 22:24:31.7902 [PID=28773] [version] no app version available: APP#25 (einsteinbinary_BRP4G) PLATFORM#9 (windows_x86_64) min_version 0
2014-11-27 22:24:31.7902 [PID=28773] [version] no app version available: APP#25 (einsteinbinary_BRP4G) PLATFORM#2 (windows_intelx86) min_version 0
2014-11-27 22:24:31.7912 [PID=28773] [version] Checking plan class 'opencl-intel_gpu'
2014-11-27 22:24:31.7912 [PID=28773] [version] parsed project prefs setting 'gpu_util_brp': 1.000000
2014-11-27 22:24:31.7912 [PID=28773] [version] No Intel GPU devices found
2014-11-27 22:24:31.7912 [PID=28773] [version] Checking plan class 'opencl-intel_gpu'
2014-11-27 22:24:31.7912 [PID=28773] [version] parsed project prefs setting 'gpu_util_brp': 1.000000
2014-11-27 22:24:31.7912 [PID=28773] [version] No Intel GPU devices found
2014-11-27 22:24:31.7912 [PID=28773] [version] no app version available: APP#19 (einsteinbinary_BRP4) PLATFORM#9 (windows_x86_64) min_version 0
2014-11-27 22:24:31.7912 [PID=28773] [version] no app version available: APP#19 (einsteinbinary_BRP4) PLATFORM#2 (windows_intelx86) min_version 0
2014-11-27 22:24:31.7913 [PID=28773] [version] Checking plan class 'BRP5-opencl-ati'
2014-11-27 22:24:31.7913 [PID=28773] [version] parsed project prefs setting 'gpu_util_brp': 1.000000
2014-11-27 22:24:31.7913 [PID=28773] [version] ATI device (or driver) doesn't support OpenCL
2014-11-27 22:24:31.7913 [PID=28773] [version] Checking plan class 'BRP5-cuda32'
2014-11-27 22:24:31.7913 [PID=28773] [version] parsed project prefs setting 'gpu_util_brp': 1.000000
2014-11-27 22:24:31.7914 [PID=28773] [version] No CUDA devices found
2014-11-27 22:24:31.7914 [PID=28773] [version] Checking plan class 'BRP5-cuda32-nv301'
2014-11-27 22:24:31.7914 [PID=28773] [version] parsed project prefs setting 'gpu_util_brp': 1.000000
2014-11-27 22:24:31.7914 [PID=28773] [version] No CUDA devices found
2014-11-27 22:24:31.7914 [PID=28773] [version] Checking plan class 'BRP5-opencl-ati'
2014-11-27 22:24:31.7914 [PID=28773] [version] parsed project prefs setting 'gpu_util_brp': 1.000000
2014-11-27 22:24:31.7914 [PID=28773] [version] ATI device (or driver) doesn't support OpenCL
2014-11-27 22:24:31.7914 [PID=28773] [version] no app version available: APP#23 (einsteinbinary_BRP5) PLATFORM#9 (windows_x86_64) min_version 0
2014-11-27 22:24:31.7914 [PID=28773] [version] no app version available: APP#23 (einsteinbinary_BRP5) PLATFORM#2 (windows_intelx86) min_version 0
2014-11-27 22:24:31.7915 [PID=28773] [version] Checking plan class 'FGRP4-SSE2'
2014-11-27 22:24:31.7915 [PID=28773] [version] plan class ok
2014-11-27 22:24:31.7915 [PID=28773] [version] Don't need CPU jobs, skipping version 104 for hsgamma_FGRP4 (FGRP4-SSE2)
2014-11-27 22:24:31.7915 [PID=28773] [version] Checking plan class 'FGRP4-Beta'
2014-11-27 22:24:31.7915 [PID=28773] [version] beta test app versions not allowed in project prefs.
2014-11-27 22:24:31.7915 [PID=28773] [version] no app version available: APP#27 (hsgamma_FGRP4) PLATFORM#9 (windows_x86_64) min_version 0
2014-11-27 22:24:31.7915 [PID=28773] [version] no app version available: APP#27 (hsgamma_FGRP4) PLATFORM#2 (windows_intelx86) min_version 0
2014-11-27 22:24:31.8019 [PID=28773] [debug] [HOST#3647123] MSG(high) No work sent
2014-11-27 22:24:31.8019 [PID=28773] [debug] [HOST#3647123] MSG(high) see scheduler log messages on http://einstein5.aei.uni-hannover.de/EinsteinAtHome/host_sched_logs/3647/3647123
2014-11-27 22:24:31.8020 [PID=28773] Sending reply to [HOST#3647123]: 0 results, delay req 60.00
2014-11-27 22:24:31.8030 [PID=28773] Scheduler ran 0.049 seconds

Claggy

I'm hoping the donations earned from crunching at BU will allow for some new hardware purchases.

---

Still got 20 tasks in cache. It helps that I'm being maimed to death by killer eagles in Far Cry 4 most of the day. :)

---