Oh, you're going to love this one

		Jason	Holmis	Claggy	Zombie	Zombie (Mac)
Host:		11363	2267	9008	6490	6109
		GTX 780	GTX 660	GT 650M	TITAN	GTX 680MX

Credit for BRP4G (GPU)						

Maximum		1170.48	1036.86	10239.0	1654.85	11847.50
Minimum		115.82	88.84	153.90	25.79	94.88
Average		548.33	463.98	3875.88	874.96	2256.70
Median		468.80	390.21	2977.38	865.33	1591.80
Std Dev		431.90	268.52	2873.26	362.30	2395.61

I'll upload a graph after lunch, when my monitor has cooled down and I've stopped laughing.

For your info, my GT650M is running one task at a time, and I'm only running two CPU tasks at a time too,
(It runs very hot, the 2.5GHz i5-3210M is a dual core with hyper threading, with it running on it's turbo mode of 2.89GHz the CPU cores sit at 99°C,
add another core crunching, or the intel GPU crunching and it starts downclocking, both CPU and Nvidia GPU)

Since I've now got Intel GPU tasks, the CPU is flucturating between 1.90GHz and 2.89GHz in 0.1GHz steps, ie 2.89, 2.79, 2.69, 2.59, 2.50, 2.40, 2.20, 2.10, etc,
and the GT650M is switching between 950MHz and 118MHz, while the HD Graphics 4000 is switching between 950MHz, 1.0GHz, 1.05GHz and 1.10GHz,
expect all task durations to flucturate. ;-)

Claggy

Interesting. I was just noticing on the task list that you had two tasks reported at 15:49 and 15:51 today (not the top two, #4 and #5 currently) with over 10K credit each. Ruined my nice trumpet-shaped graph! ;)

Same wingmate! I think 10320 Jacob Klein might go on my spare page.

So here's an enlarged view.



I wonder why two laptops validating each other should do that?

I tried to resend those BRP (Arecibo, GPU) tasks, but got them expired instead (I had use ATI GPU set to No), So managed to get fresh GPU tasks, a mixture of BRP (Arecibo, GPU) and BRP (Perseus Arm Survey),
the (Arecibo, GPU) tasks now have estimates of 13 minutes, while they take an hour, so they are now completeable, the (Perseus Arm Survey) tasks have estimates of 16 seconds, so aren't, i'll let the ones I have run and error:

All tasks for computer 8143

Application details for host 8143

Claggy

I have fixed fpops intel_GPU issue using app_info.xml containing tag

<flops>14479075542.794144</flops>

for BPR4, BPR4G and BPR5 intel_GPU applications. Seems to work at both HD4000 and HD4600. Is it correct way?

Intel GPUs are now being shown by the project in the computer details pages:

Computer 9008

But 'Use Intel GPU' isn't being shown on the Albert project preferences page in spite of there being intel GPU apps available, perhaps those apps need their settings adjusted?

Claggy

Yes, the (old) web code hasn't been updated and probably won't be at all, due to the envisioned (but again postponed) migration to Drupal (see other news).

BM

So here's an enlarged view.
...
I wonder why two laptops validating each other should do that?

With Claggy's clocking up & down all over the shop, (and probably Jacob's too), then you have an exaggerated form of what happens anyway. noisy elapsed times that are unsmoothed, and account for all sorts of klingons that had nothing to do with proccessing. Sampled averages don't cut it for this process.

Think of the moving sampled average as a conveyor belt perhaps. One small sample drops off to make room for a new much larger one, then a large one drops off making room for the next, and so on. Nothing smooth about it, but will lurch around like some sortof crazed Frankenstein's monster on a rampage. When two meet they could cancel or add.

---

On two occasions I have been asked, "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" ... I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. - C Babbage

So here's an enlarged view.
...
I wonder why two laptops validating each other should do that?

With Claggy's clocking up & down all over the shop, (and probably Jacob's too), then you have an exaggerated form of what happens anyway. noisy elapsed times that are unsmoothed, and account for all sorts of klingons that had nothing to do with proccessing. Sampled averages don't cut it for this process.

Think of the moving sampled average as a conveyor belt perhaps. One small sample drops off to make room for a new much larger one, then a large one drops off making room for the next, and so on. Nothing smooth about it, but will lurch around like some sortof crazed Frankenstein's monster on a rampage. When two meet they could cancel or add.

Just provided they don't multiply...

So here's an enlarged view.
...
I wonder why two laptops validating each other should do that?

With Claggy's clocking up & down all over the shop, (and probably Jacob's too), then you have an exaggerated form of what happens anyway. noisy elapsed times that are unsmoothed, and account for all sorts of klingons that had nothing to do with proccessing. Sampled averages don't cut it for this process.

Think of the moving sampled average as a conveyor belt perhaps. One small sample drops off to make room for a new much larger one, then a large one drops off making room for the next, and so on. Nothing smooth about it, but will lurch around like some sortof crazed Frankenstein's monster on a rampage. When two meet they could cancel or add.

Just provided they don't multiply...

Well sadly, rampaging monsters everywhere :-O , because those averages feed scales (which multiply), 2 cascaded providing 'gain' to the noise, like an audio amplifier.

One totally impractical theoretical solution would be just to take many more samples (than 11...). Could work if you didn't mind waiting a few days/weeks/months for estimates to settle in...but worse for the onramp period, which is a lot of the problem.

Better (proven) approaches will be tried... nearly ready to set those short & medium term goals.

---

On two occasions I have been asked, "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" ... I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. - C Babbage

just remember that it's nice to quickly converge from a bad initial estimate, but if the tasks ends up Time limit exceeded it doesn't give any clue as to the eventual runtime. And we don't want to wind out the rsc_fpops_bound too much either, because hung apps occasionally happen. So we really need to do something about the initial runtime estimate for GPU too.

---

Queen of Aliasses, wielder of the SETI rolling pin, Mistress of the red shoes, Guardian of the orange tree, Slayer of very small dragons.

just remember that it's nice to quickly converge from a bad initial estimate, but if the tasks ends up Time limit exceeded it doesn't give any clue as to the eventual runtime. And we don't want to wind out the rsc_fpops_bound too much either, because hung apps occasionally happen. So we really need to do something about the initial runtime estimate for GPU too.

Which seems to be specifically an initial FLOPs estimate problem. David initially dismissed it as a local Einstein phenomenon, so we ought to check that possibility and find out where the enormous values reported in this thread really came from.

And then we need a way to assign a realistic starting point for GPU speeds, across all projects and extensible to new cards as they are released without waiting for BOINC client updates. We have the problem that the NV API won't report shaders per SM, so estimates for new cards are always faulty until the hard-wired multiplier is updated: and I believe detection of new ATI cards like the R 290 is even more flawed.

I'm still monitoring credits, though the flow of validations seems to be slowing.

CPU tasks seem to be continuing as before, so let's concentrate on GPU for a while.

		Jason	Holmis	Claggy	Zombie	ZombieM	Jacob
Host:		11363	2267	9008	6490	6109	10320
		GTX 780	GTX 660	GT 650M	TITAN	680MX	FX 3800M

Credit for Gw-CasA							

Maximum		1503.78	1357.46	10951.9	1933.46	11847.5	10951.96
Minimum		115.82	88.84	153.90	91.50	94.88	508.73
Average		733.95	592.45	4200.42	994.85	2092.67	3640.96
Median		945.84	492.55	3037.38	1054.49	1642.95	1710.08
Std Dev		499.17	373.86	3179.62	374.42	2019.66	3970.94

Is it my imagination, or is that trend continuing upwards? I think it was Eric that warned us that 'pure GPU' apps (without a CPU app_version to keep them grounded) tended to explode in the end.

Edit - yes:

Its best to always have a max granted credit in your assimilator, unless the value really is indeterminant. BOINCs estimates for GPU FLOPS are often 20x what is actually achieved. Credit grants tend to float through the roof under credit_new without a CPU version of the app to pull them back to Earth.
6/6/2014

...
Is it my imagination, or is that trend continuing upwards? I think it was Eric that warned us that 'pure GPU' apps (without a CPU app_version to keep them grounded) tended to explode in the end.

Edit - yes:

Its best to always have a max granted credit in your assimilator, unless the value really is indeterminant. BOINCs estimates for GPU FLOPS are often 20x what is actually achieved. Credit grants tend to float through the roof under credit_new without a CPU version of the app to pull them back to Earth.
6/6/2014

basically mentally subtracting the noise is fine, then you see the shape of the convergence. Initial estimates appear about 1/3rd what they should be (credit terms not time), which you could regard as 'fine' if convergence was more prompt... though obviously better would be a nice goal. Since my 780 was running around 10% of expected credits at the beginning, and Zombie's TITAN about 1/3rd, you can either accept that Zombie's multiple tasks per GPU from the beginning is a special situation, or not.

If you accept that Zombie's TITAN config is a special case, then you need to consider mine as 'normal', in which case the expected credits start about one tenth of what they should be. IOW the earlier observation from Holmis (?) seems correct, along with my observation of 3 second estimates, in that the estimates that are supposed to be conservative with respect to time bound, and generous with credit, are in fact the opposite... There is some math upside down.


Trends-wise, I'd say for certain that what you're seeing is there, since averages are in play. What's wrong with the shape is that the convergence (from wrong numbers toward ballpark) is way too slow (too many tasks), and as much as it looks like it's trending upward now, downward compensation after will be just as slow and obvious. It's [the rising edge] part of a long term oscillation. You could easily say that some of those machines are trending down.

---

On two occasions I have been asked, "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" ... I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. - C Babbage

Let's wait and see. I've seen some projects go exponential (literally - into the millions of credits) when they start like this.

Let's wait and see. I've seen some projects go exponential (literally - into the millions of credits) when they start like this.

That unstable ? interesting... Yeah with instabilities it can ring or run completely off the rails... A bit hard for me to predict that :P (both conditions are unstable)

---

On two occasions I have been asked, "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" ... I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. - C Babbage

Let's wait and see. I've seen some projects go exponential (literally - into the millions of credits) when they start like this.

That unstable ? interesting... Yeah with instabilities it can ring or run completely off the rails... A bit hard for me to predict that :P (both conditions are unstable)

One of my hosts is still showing that I reached a user RAC of 99,952,529.17 at AQUA - they were multithreaded CPU apps, rather than GPU, but they still blew up.

Edit:

    <daily_statistics>
        <day>1309910400.000000</day>
        <user_total_credit>16831271.163956</user_total_credit>
        <user_expavg_credit>37773.342884</user_expavg_credit>
        <host_total_credit>4602266.488011</host_total_credit>
        <host_expavg_credit>8549.212942</host_expavg_credit>
    </daily_statistics>
    <daily_statistics>
        <day>1309996800.000000</day>
        <user_total_credit>743356375.874693</user_total_credit>
        <user_expavg_credit>127074513.727733</user_expavg_credit>
        <host_total_credit>4602266.488011</host_total_credit>
        <host_expavg_credit>6283.249755</host_expavg_credit>
    </daily_statistics>
    <daily_statistics>
        <day>1310256000.000000</day>
        <user_total_credit>743402121.576823</user_total_credit>
        <user_expavg_credit>99952529.170651</user_expavg_credit>
        <host_total_credit>4602266.488011</host_total_credit>
        <host_expavg_credit>5661.725458</host_expavg_credit>
    </daily_statistics>

July 2011

Let's wait and see. I've seen some projects go exponential (literally - into the millions of credits) when they start like this.

That unstable ? interesting... Yeah with instabilities it can ring or run completely off the rails... A bit hard for me to predict that :P (both conditions are unstable)

One of my hosts is still showing that I reached a user RAC of 99,952,529.17 at AQUA - they were multithreaded CPU apps, rather than GPU, but they still blew up.

you must admit AQUA was a special case and they went rather suddenly offline before we had the slightes chance to investigate.
2011? feels like yesterday...

---

Queen of Aliasses, wielder of the SETI rolling pin, Mistress of the red shoes, Guardian of the orange tree, Slayer of very small dragons.

AQUA was made by D-Wave, which says it has built quantum computers and sold them for about a hundred million dollars each.
Tullio

---

AQUA was made by D-Wave, which says it has built quantum computers and sold them for about a hundred million dollars each.
Tullio

And still did, up to last year at least.

Google and NASA team up to use quantum computer

I really appreciate what you guys are doing for ALL of us crunching grunts <thumbsup>

I have some hardware I can bring on board but I don't have the time to provide the ins and outs of log files etc. Is there a particular app mix that would be most helpful?

[u]OS     BOINC    CPU     GPU         [/u]
Win7   7.2.42   980x    670 + 660Ti
Win7   7.2.42   920     7950
[u]Win7   7.2.42   4670k   Intel       [/u]

I also have some other gpus I could mix/ match if your looking for some diversity ... 7850, 7770, GTX480, GTX295.
For GPU would it be better if I ran 1 per card or is it enough for your modeling if I just let you know what multiplier I am using?
Any value in providing overclock settings?