perhaps VLARs should be disabled for GPUs again.
Very negative attitude on SETI main boards to VLARs on GPU, even on ATi GPUs though NV GPUs mentioned more often.
It's worth to distribute VLAR to GPU only if GPU is idle and server can't offer another work. Kind of "backup work". In other way GPU will be idle or drift to another project. If it's possible to implement such logic it's worth to do. If not maybe worth to disable VLARs again.

Have you heard there's odd Credit awards going on for Astropulse v6 now at the Main project, around 15 to 25 Credits per AP Wu:

That's odd, since I haven't updated anything related to AP over there.

---

The right way to do this (and I indicated this to David a long time ago) is to use an estimate of the median rather than weighted averages, as medians are not strongly affected by outliers.

I could change the current code make an estimate of the running median...

Oooh, sounds much more robust :D

Now on the client side, having experimented with stabilising estimates for work fetch & task scheduling, I used a tuned PID controller for dead-reckoning with feedback. That made estimates much more stable, tuned for very slight overshoot for rapid convergence (system usage change etc) without ringing (sufficiently damped still).

If I switch from using (custom) per application DCF as the control (fudge factor), over to adaptive flops as suggested by Joe some time back, does the server receive the (application) flops value on each contact ? and, if so, could you possibly combine the more robust longer term median processing rate(s) with the flops using something like a Kalman filter ? My basis for thought there is why recalculate something the client already knows, if you don't have to. or alternatively if the calculations are in different time scales, combine (Kalman filter) them to get the best of both.

To me anyway, stable & adaptive estimates proved to solve a lot of problems... On a relatively fast system I typically see stable estimate convergence track system usage or hardware change on the order of minutes, as opposed to APR's days to weeks.

Have you heard there's odd Credit awards going on for Astropulse v6 now at the Main project, around 15 to 25 Credits per AP Wu:

http://setiathome.berkeley.edu/forum_thread.php?id=71827&postid=1374823

Valid AstroPulse v6 tasks for computer 6910524

I grabbed some Stock OpenCL AP work, and got very low awarded Credit too:

All AstroPulse v6 tasks for computer 5427475

Claggy

I have a couple of more with low credits on main.

http://setiathome.berkeley.edu/workunit.php?wuid=1257047105
http://setiathome.berkeley.edu/workunit.php?wuid=1257039458

Have you heard there's odd Credit awards going on for Astropulse v6 now at the Main project, around 15 to 25 Credits per AP Wu:

http://setiathome.berkeley.edu/forum_thread.php?id=71827&postid=1374823

Valid AstroPulse v6 tasks for computer 6910524

I grabbed some Stock OpenCL AP work, and got very low awarded Credit too:

All AstroPulse v6 tasks for computer 5427475

Claggy

I have a couple of more with low credits on main.

http://setiathome.berkeley.edu/workunit.php?wuid=1257047105
http://setiathome.berkeley.edu/workunit.php?wuid=1257039458

I wouldn't worry about that, we need to populate the project's app version Peak Flop Count Average' for all app versions, that has probably happened for GPU versions already, it'll be a few days before it's done for the CPU AP app,
also none of those hosts had reached their 10 validations yet,

Claggy

Have you heard there's odd Credit awards going on for Astropulse v6 now at the Main project, around 15 to 25 Credits per AP Wu:

http://setiathome.berkeley.edu/forum_thread.php?id=71827&postid=1374823

Valid AstroPulse v6 tasks for computer 6910524

I grabbed some Stock OpenCL AP work, and got very low awarded Credit too:

All AstroPulse v6 tasks for computer 5427475

Claggy

I have a couple of more with low credits on main.

http://setiathome.berkeley.edu/workunit.php?wuid=1257047105
http://setiathome.berkeley.edu/workunit.php?wuid=1257039458

I wouldn't worry about that, we need to populate the project's app version Peak Flop Count Average' for all app versions, that has probably happened for GPU versions already, it'll be a few days before it's done for the CPU AP app,
also none of those hosts had reached their 10 validations yet,

Claggy

Now I see, it's wingman that needs 10 validations.

YAY - cuda32 is speeding up - APR is 101, and cuda50 only 97. So of course, cuda32 rules.

Doesn't it?

YAY - cuda32 is speeding up - APR is 101, and cuda50 only 97. So of course, cuda32 rules.

Doesn't it?

Could do. Still doesn't make David any better at statistics than me, which is pretty bad.

Something is definetly wrong.
Host stas on main

number of completed tasks 1
consecutive valid tasks 646
APR 7740

---

With each crime and every kindness we birth our future.

Something is definetly wrong.
Host stas on main

number of completed tasks 1
consecutive valid tasks 646
APR 7740

Link to host would help, please.

Here's an interesting one on main.
http://setiathome.berkeley.edu/show_host_detail.php?hostid=6739873
Looks to me like if 'completed tasks' stays zero, i.e. it's spitting out only invalids, then max tasks per day never goes down ?

Something is definetly wrong.
Host stas on main

number of completed tasks 1
consecutive valid tasks 646
APR 7740

Link to host would help, please.

http://setiathome.berkeley.edu/results.php?hostid=5735690

---

With each crime and every kindness we birth our future.

The right way to do this (and I indicated this to David a long time ago) is to use an estimate of the median rather than weighted averages, as medians are not strongly affected by outliers.

I could change the current code make an estimate of the running median...

Oooh, sounds much more robust :D

Now on the client side, having experimented with stabilising estimates for work fetch & task scheduling, I used a tuned PID controller for dead-reckoning with feedback. That made estimates much more stable, tuned for very slight overshoot for rapid convergence (system usage change etc) without ringing (sufficiently damped still).

If I switch from using (custom) per application DCF as the control (fudge factor), over to adaptive flops as suggested by Joe some time back, does the server receive the (application) flops value on each contact ? and, if so, could you possibly combine the more robust longer term median processing rate(s) with the flops using something like a Kalman filter ? My basis for thought there is why recalculate something the client already knows, if you don't have to. or alternatively if the calculations are in different time scales, combine (Kalman filter) them to get the best of both.

To me anyway, stable & adaptive estimates proved to solve a lot of problems... On a relatively fast system I typically see stable estimate convergence track system usage or hardware change on the order of minutes, as opposed to APR's days to weeks.

Since you mention it here - my idea was always, that APR shpuld be calculated with the same contril circuit you did for aDCF. You don't feel like doing a spot of server code, perhaps? ;)

---

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

YAY - cuda32 is speeding up - APR is 101, and cuda50 only 97. So of course, cuda32 rules.

Doesn't it?

Could do. Still doesn't make David any better at statistics than me, which is pretty bad.

I still think David is using the completely wrong type of statistics for CreditNew.
With all modelling (and statistics are a type of modelling) you need to know the assupmtions and the limitations of the model.

I maintain that the nature of the data distribution here is not one where the type of statistical analysis David does can be used.

But that's only my mathematician's gut feeling :(

---

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

Since you mention it here - my idea was always, that APR shpuld be calculated with the same contril circuit you did for aDCF. You don't feel like doing a spot of server code, perhaps? ;)

Since, by control theory, cascading different controllers in different time domains ( i.e. one slow tracking, one rapid/fine ) tends to be better than one, a server side longer term figure is fine (if done correctly & independently). Ideally the final control 'output' (currently raw APR) would instead be a fusion weighted by trust. You might for example, trust a client generating good results more than one spitting out invalids or errors. These host examples might then allow responsive estimates & conservative/overdamped response respectively.

Eric's move to median should help a lot. If after that, it proves too unresponsive when hosts up/downgrade, use machines heavily periodically while crunching, change number of tasks etc, I wouldn't mind taking a look.

The basic concept is the same as navigation systems using a fusion of erratic/noisy GPS readings with dead-reckoning. Neither on their own is perfect, but combined is stable, responsive and more accurate.

Well, I got my wish with the VLARs for cuda32. By the time the next 30 have run through, that version should be dead and buried.

Hm....
This host http://setiweb.ssl.berkeley.edu/beta/host_app_versions.php?hostid=39394 has such AP app table:

AstroPulse v6 6.06 windows_intelx86 (opencl_ati_100)
Number of tasks completed 83
Max tasks per day 163
Number of tasks today 34
Consecutive valid tasks 130
Average processing rate 618.37064112399
Среднее оборотное время 0.50 days
AstroPulse v6 6.06 windows_intelx86 (ati_opencl_100)
Number of tasks completed 2
Max tasks per day 45
Number of tasks today 0
Consecutive valid tasks 12
Average processing rate 742.57870281709
Среднее оборотное время 2.74 days
AstroPulse v6 6.06 windows_intelx86 (cal_ati)
Number of tasks completed 7
Max tasks per day 40
Number of tasks today 0
Consecutive valid tasks 7
Average processing rate 56.793048610545
Среднее оборотное время 1.12 days


Note, not fastest app recives all the work now.
Fastest (by current APR) app can't even collect enough tasks to pass 10 eligible tasks threshold!
Is it normal? I think no. All compatible apps shoudl get their 10 eligibles before the best will imprinted in server's mind, right ?

EDIT: also note that Mv7 GPU tasks were relatively fast and host was configured with big cache. So, it had opportunity to recive tasks for all apps just because of quota limits. Here, with AP, task takes longer, cache was reduced (intentionally) so we have some another situation to test. And looks like test not passed OK :/

perhaps VLARs should be disabled for GPUs again.
Very negative attitude on SETI main boards to VLARs on GPU, even on ATi GPUs though NV GPUs mentioned more often.
It's worth to distribute VLAR to GPU only if GPU is idle and server can't offer another work. Kind of "backup work". In other way GPU will be idle or drift to another project. If it's possible to implement such logic it's worth to do. If not maybe worth to disable VLARs again.

+1

A simple <VlartoGPU>0|1<VlartoGPU> switch in the client side, could allow us to choose if we want or no crunch the VLARs on the GPU´s, and solve a lot of problems.

perhaps VLARs should be disabled for GPUs again.
Very negative attitude on SETI main boards to VLARs on GPU, even on ATi GPUs though NV GPUs mentioned more often.
It's worth to distribute VLAR to GPU only if GPU is idle and server can't offer another work. Kind of "backup work". In other way GPU will be idle or drift to another project. If it's possible to implement such logic it's worth to do. If not maybe worth to disable VLARs again.

+1

A simple <VlartoGPU>0|1<VlartoGPU> switch in the client side, could allow us to choose if we want or no crunch the VLARs on the GPU´s, and solve a lot of problems.

Or maybe make Vlar's more attractive.

.vlar=3 times credit

perhaps VLARs should be disabled for GPUs again.
Very negative attitude on SETI main boards to VLARs on GPU, even on ATi GPUs though NV GPUs mentioned more often.
It's worth to distribute VLAR to GPU only if GPU is idle and server can't offer another work. Kind of "backup work". In other way GPU will be idle or drift to another project. If it's possible to implement such logic it's worth to do. If not maybe worth to disable VLARs again.

+1

A simple <VlartoGPU>0|1<VlartoGPU> switch in the client side, could allow us to choose if we want or no crunch the VLARs on the GPU´s, and solve a lot of problems.

Or maybe make Vlar's more attractive.

.vlar=3 times credit

I like that, but is not just about credits, the main problem is the video lag the Vlars crunching produces in some not dedicated crunching hosts, even with changes in the configuration file, specialy when more than one Vlar is crunching on multiple GPU hosts that makes the host simple unuseable to do other simple tasks.

Maybe limit the number of vlars allowed to run simultaneusly on the host could fix that problem on fasters GPUs, but not sure if that could work fine on the slowers models.