There now is BM 7.0.64 and it does not have the REC-based shedule anymore.

Untrue.

Ok.

Workfetch procedure is in my opinion alot better.

That is exactly because of the REC-based scheduler!

---

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

A bunch of VLARs was holding things up again. I cleared them out.

But how about to allow some of ATi GPUs to crunch them ?

When I was checking yesterday for the extent of the VLAR stretch I did see one assigned to an ATI IIRC.

---

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

A bunch of VLARs was holding things up again. I cleared them out.

But how about to allow some of ATi GPUs to crunch them ?

When I was checking yesterday for the extent of the VLAR stretch I did see one assigned to an ATI IIRC.

link would be good (to host)

A bunch of VLARs was holding things up again. I cleared them out.

But how about to allow some of ATi GPUs to crunch them ?

When I was checking yesterday for the extent of the VLAR stretch I did see one assigned to an ATI IIRC.

I managed to get about a dozen VLARs for my HD7770 too.

Claggy

And how GUI respond with default settings ?

As a test I'm sending VLARs to comp-cap 3.0+ NVIDIA cards. Anyone with a Kepler or higher let me know how they work.

---

I'll try and snag some on 63280.

One question which comes to mind: the expectation is that they'll run accurately and successfully, but slower than estimated by fpops. What would that do for APR, and subsequent application selection?

I'll try and give you a subjective indication of usability, especially if I get two running at once (the usual mode for that host) on the GPU with the monitor attached.

It could potentially reduce APR by a factor of about (N-1)/N where N is the on the app details page as "number of tasks completed" which could change app selection temporarily.

If it becomes a problem we could just include VLAR results as outliers so they won't be included in APR calculation.

---

On that host, it wouldn't really matter if it kept switching between cuda42 and cuda50 - I think the current disparity (149 to 163) is a bit wider than normal, because of the balance of ARs last time I was running (I disabled fetch during the VLAR storm).

But if the slowdown was enough - and enough VLARs were run in a short time - to bring cuda32 into fastest place, that would be a pity. The ~50% penalty for that app is genuine (though thank goodness we don't have to worry about 22/23).

I'll try to work out what the actual per-task APR equivalent speed is, for whichever app(s) I get VLAR allocated to run.

Looks like I've received some VLAR on Cuda 3.2 for my GTX 680, so 3.2 APR shunt could end up beneficial here. I do have my pulsefinding and priority set aggressively, though just use single instance at this time (Older patched Boinc 6.10.58 having no app_config), so I should hopefully notice subjective display change here for comparison.

[Edit:] 3.2 variant, with aggressive settings running now. Subjectively there is perceptable 'microstutter' if dragging Windows around quickly on 120Hz Display. GPU usage appears somewhat higher than single instance at medium/HighAR, though looks like[, as a system,] it would tolerate an extra VLAR instance even if I had to relax the settings to defaults.

and trial reduction of settings to defaults reduced the (perceptible) 'micro-stutter' to normal imperceptible levels here. I'll probably return to more aggressive settings for normal crunching, just wanted that subjective feel comparison for 680/690 owners.

Took me a while to clear other projects out of the way, but I've completed 120 tasks overnight, and got another 170 to work on. No sign of a VLAR yet - this research may take a little while.

Took me a while to clear other projects out of the way, but I've completed 120 tasks overnight, and got another 170 to work on. No sign of a VLAR yet - this research may take a little while.

haha, yeah I got lucky :D

VLARs were cleared just before decision was made to allow GPUs for them... Perhaps that clearing was too perfect ;)

VLARs were cleared just before decision was made to allow GPUs for them... Perhaps that clearing was too perfect ;)

Here's three that validated: wuid=5347882 , wuid=5347824 , wuid=5347777 .

VLARs were cleared just before decision was made to allow GPUs for them... Perhaps that clearing was too perfect ;)

Here's three that validated: wuid=5347882 , wuid=5347824 , wuid=5347777 .

How about sluggishness and GUI lags ? I have little doubts in task validations (no big difference vs non-vlars here), but GUI lags still possible, especially if few tasks running at once.

VLARs were cleared just before decision was made to allow GPUs for them... Perhaps that clearing was too perfect ;)

Here's three that validated: wuid=5347882 , wuid=5347824 , wuid=5347777 .

Credit looks good & elapsed time looks fantastic :D, about 1-2 min faster than my 680. CPU time looks pretty high (~50% ? hybridised longer pulsefinds ? ), but probably nothing that won't improve with Raistmer's ongoing refinements.

Two more tasks wasted for nothing... and cause it's Brook AP it costed much more than aborted MB task...

14027050 5343580 23 May 2013, 21:19:57 UTC 25 May 2013, 9:22:36 UTC Ошибка при расчёте 24,032.81 22,418.23 --- AstroPulse v6 v6.05 (cal_ati)
14027020 5311626 23 May 2013, 21:19:57 UTC 25 May 2013, 9:16:52 UTC Ошибка при расчёте 24,032.78 23,839.50 --- AstroPulse v6 v6.05 (cal_ati)

BOINC estimated execution time as 40 min while each task takes 8 hours to complete. So, 2 tasks were aborted.

What would prevent BOINC to abort next 2? Estimate remains the same.
I will suspend Brook+ AP work on this host until something will be changed to prevent such needless abortions!

Took me a while to clear other projects out of the way, but I've completed 120 tasks overnight, and got another 170 to work on. No sign of a VLAR yet - this research may take a little while.

haha, yeah I got lucky :D

OK, now we have VLARs - I've got about 80 of them. Let the fun begin.

The good news - even with four VLARs running at the same time (two tasks on each of two GTX 670), there's no sign of any screen lag in normal desktop usage. I didn't try any graphic-intensive work, but with this particular combo we wouldn't have the sort of volunteer walk-out that we saw with the very early cuda apps and VLAR tasks.

The bad news - they still run very, very slowly. Note that apart from the 'two tasks at once' (via app_config.xml), I'm running the host exactly as stock: I've no doubt performance could be increased via application parameter tuning, but that's not what I'm reporting on here.

The most recent completed task is WU 5348248 - that's one of the first to complete under '4 VLARs at once'. 5,286 seconds - almost an hour and a half - works out at an equivalent APR just below 35, compared to ~150 - 160 for the general 'non-VLAR' mix of work. It will be interesting to see what APR is recorded for cuda50 at the end of this streak - I'll run all 80 consecutively. The APR might not end up as bad as those figures suggest, because I have over 400 tasks pending and their validation (as wingmates trickle in) will push APR back up towards normal levels.

The other question to consider is that of credit (I know, I know - but the punters like it). Presumably, if I validate against another CUDA, we both get the normal rate of credit for the extended runtime. But if, as in this case, I validate against a CPU host with normal runtime, the actual credit will be 'normal for CPU', and the rate of credit will be low. Since the rates of Kepler-Kepler validation on the main project will be low for a year or two yet, it might be worth thinking a bit before extending this configuration.

I'm re-jigging the configuration slightly, to run another project on one card, and two VLARs together on the other. I'll leave it untouched like that for at least 24 hours to get some steady figures, then perhaps try a period with just one task at a time.

... that's one of the first to complete under '4 VLARs at once'. 5,286 seconds - almost an hour and a half - works out at an equivalent APR just below 35, compared to ~150 - 160 for the general 'non-VLAR' mix of work.

These VLAR take some 4 hours each on 3.0GHz core2 (1 core). verifying 4 at once in 1.5 hours ? Is that 2 per card on 2 cards ? othwerwise That sounds quite a bit more efficient somehow than my 680. (faster bus & CPU perhaps...) 1 in ~44 mins (Cuda32), multiples [& Cuda50] not tested here with VLAR live yet.