I dont get driver 10.10 working with SDK 2.3.
Tried ten times with reboot and all that.
Dont find a source for 2.2 anymore.
For gods sake i do have a system backup from last week.

Maybe i´ll try it next week.

So no MB crunching the next days cause i have to get rid of 30 AP units with deadline 1/12.

Would be great to be able running 2 tasks a time.

Edit: Very confusing is CPU is still used up to 50% with original max ncpus .01.

---

With each crime and every kindness we birth our future.

Edit: Very confusing is CPU is still used up to 50% with original max ncpus .01.

this app_info field not limiting anything, it's just info, hint for BOINC how much resources app would use. App free to use very different amount still.

If you set flops value to 1 (for example) will you think app will do only 1 float add and immediately exit after? ;)

Edit: Very confusing is CPU is still used up to 50% with original max ncpus .01.

this app_info field not limiting anything, it's just info, hint for BOINC how much resources app would use. App free to use very different amount still.

If you set flops value to 1 (for example) will you think app will do only 1 float add and immediately exit after? ;)

Sure not.
I just thought because its called "max"

I see i have to learn a lot still.
Its very frustrating.

---

With each crime and every kindness we birth our future.

I see i have to learn a lot still.
Its very frustrating.

Why? Learning can be quite fun, no need to be frustrated if you still have smth to learn :)

I have the ncpu = 1. From what I can tell it did reduce my crunching time by a noticeable bit.

In the table I made it looks like I'm getting about a 44% increase in speed with tasks having similar blanking %'s with ncpu=1.

Though I've also seen task times vary by up to 33% with ncpu=1 and the exact same blanking %. So most / all could have been normal variation instead of a free CPU core. No real way to tell unless I could crunch the same WU twice.

---

I had the same but not anymore.

Edit i can see SDK 2.2 installed.
No wonders.

---

With each crime and every kindness we birth our future.

I had the same but not anymore.

Edit i can see SDK 2.2 installed.
No wonders.

2.3 uses less CPU than 2.2? If so I'll need to switch. I've been putting off upgrading my drivers until the next Cat release.

---

Normal completion times for 0 - 10% blanked units are ~ 90 minutes on my 5850.
Running 2 parallel.

But for some reason my last 8 units only took 30 - 50 minutes each.
Murphys law ?

Anyone else noticed such shorties ?

---

With each crime and every kindness we birth our future.

Normal running times on r512 are 105 minutes running one at a time on my HD5770,

Two of my last 4 Wu's finished early, the last one with:

Found 30 single pulses and 30 repeating pulses, exiting

That one took 30 minutes, the previous short one took 60 minutes:

single pulses: 26
repetitive pulses: 30

That one was speeded up because it had already found it's 30 repetive pulses,

Claggy

Thats what i´ve expected Claggy.
But 8 in a row.

Since the servers are off i just wanted to make sure.

Thank you once more.

---

With each crime and every kindness we birth our future.

Thats what i´ve expected Claggy.
But 8 in a row.

Since the servers are off i just wanted to make sure.

Thank you once more.

Mike, would you list the names of those 8?

BOINC tries to run GPU tasks in FIFO order, but when you get a large number of AP tasks for one request they all have identical "sent" times so BOINC chooses the order among those by name. That means those 8 may have been very closely related, perhaps a sequence from the same "tape" and channel.

                                                                   Joe

No problem.
I will post it tomorrow Joe.

---

With each crime and every kindness we birth our future.

No problem.
I will post it tomorrow Joe.

Actually I don't really need the list, but I am curious whether my guess they were closely related was correct. Hence this bump.

                                                                  Joe

could be they were just noisy WU's and nothing more

---

In a rich man's house there is no place to spit but his face.
Diogenes Of Sinope

could be they were just noisy WU's and nothing more

Certainly I'm assuming RFI was the most likely cause of the short run times, but if the WUs were from unrelated times and positions on the sky getting 8 in a row is highly unlikely. For instance if we guess that such AP WUs occur at a similar rate as MB result_overflow cases and characterize that as probability 0.05, getting 8 in a row has probability 0.0000000000390625 unless some other factor influences the statistics. That is, if it looks like 8 separate RFI events then I start to wonder if something in the ATI drivers wasn't performing correctly or there was some other common cause. OTOH, if the WUs are from the same "tape" and all recorded within a few minutes then a single RFI event could easily have extended that long and be the cause.

                                                                   Joe

The two short Wu's i had were:

ap_17se10ae_B4_P0_00106_20110203_28406.wu

single pulses: 26
repetitive pulses: 30
percent blanked: 0.00

and

ap_17se10ae_B5_P1_00025_20110203_09236.wu

Found 30 single pulses and 30 repeating pulses, exiting.
percent blanked: 0.00

I've got another 40 odd Wu's completed, 4 remaining to do,

Claggy

---

With each crime and every kindness we birth our future.

Thanks, what I see is they're all from the same 17se10ae tape and within about a 15 minute period. Four different channels makes the RFI explanation even more likely.

                                                                   Joe

Raistmer wrote:

[Run-time] strongly depends from blanking % value. Senseless to post any time w/o saying how much blanking this particular task has. Think about it just as AR value for MB task.

Just a quick question, if anyone is willing and able to answer, please: How does the blanking percentage affect run-times? Greater blanking tends to produce longer run-times? I ask because I decided to let a very long AP WU go through (running OpenCL application) with an estimated final run-time of around 23 hours (it's only 78% complete, so I can't say what the blanking percentage is).

For comparison, average times I used to get on the optimised CPU-only application was around 12-14 hours. Hybrid Brook/CPU application was about 10-11 hours, and average times I've noticed for the OpenCL application (on my humble HD 4850) was around 4-6 hours. So 23 hours is quite a big hit. I wouldn't mind it taking so long, if it wasn't making my GUI so unresponsive. Command-line switches don't make a difference: it's simply using the GPU completely - is there a way to give the GUI priority over OpenCL?

---

Soli Deo Gloria

Time dependance from % of blanking is absolutely linear.
Here is the graph



And here is the data used for r512:

blanking Elapsed CPU
4.7 13180.752 1419.547
2.8 13065.127 1333.653
77 18521.115 6034.165
64 17595.801 5258.263
0 12715.372 1148.011
4.0 13047.082 1425.693
0 12699.293 1133.394
0 12665.574 1086.422
0 12639.591 1056.47
7.5 13265.27 1599.806
11 13413.63 1677.011
17 14128.032 2367.346
83 19105.481 6398.069
81 18780.749 6411.735
81 18670.527 6325.965
80 18716.698 6408.412
83 18966.523 6399.926
86 19209.423 6573.351
79 18828.982 6132.899
75 18481.39 6176.407
8.1 13277.732 1590.68
5.4 13067.039 1426.333
2.4 12832.771 1222.252
73 18137.09 5849.195
73 18151.079 5855.076
79 18627.18 6290.74
77 18484.529 6167
84 19083.849 6507.816
89 19481.722 7045.504
51 16595.794 4426.544
30 15187.079 3363.662
11 13769.835 2123.111