Please rise the limits... just a little...

My two cents worth for this topic......

I think an increase of wu alloted is a good idea, HOWEVER!! i think is should only be implimented for and based on systems and users them meet X criteria where X is a numerical value based on how many wu said user and machines have done and how long said user and machine have been crunching.

example a+b+c=x

a = number of years user has been actively crunching (if you started crunching in 2000 but have only been actively crunching since 2008 a would = 5)

b = number of years or months of active crunching machine has been crunching

c = number of processors usable for crunching

this way only people with proven records get more work. anybody else think this is a good way to go?



____________
I RTFM and it was WYSIWYG then i found out it was a PEBKAC error

In that case GPUs shouldn't be used all then.

I've done hundreds of VLARs on my GPUs at every angle that they sent me.
I crunch them there to allow my old slow CPU to crunch the quicker MBs.
That's how I judge my setup to be most efficient as to how I use it.

The problem is in people giving out false information to other people that don't know it's not true. That you and others have not been able to run VLARS on NVIDIA GPUs does not make it true in all instances.

It may well be that Fermi and Kepler GPUs don't suffer as much with previous NV generations.

I didn't have any GUI unresponsiveness or anything like that whenever VLAR WUs went on NV GPUs, pre-Fermi, but run-times were horribly long. With the current lack of WUs (maybe I'm just unlucky), I've redirected a single VLAR WU to an NV GPU, just to see what happens - also no lack of responsiveness, but the run-time looks to be very long. Judging by current progress, it'll be nearly an hour before it's completed, compared with 2 or 8 minutes for non-VLAR WUs. Ouch.
____________
Soli Deo Gloria

I'm aware of the crashing issue on lower-end GPUs. But obviously the concept of opportunity cost is completely lost. No matter, it's still the case that GPU calculations are not quite as precise as those made on the CPU.

I was referring to the inherent limitations of the hardware, not the applications. But I know a lot of hard work has gone into improving the accuracy of the applications - many thanks to all involved in that.
____________
Soli Deo Gloria

What on earth has

a) VLAR not going to NV

and

b)the accuracy of the different apps

to do with the current limits on task in progress?! i.e. with the topic of this thread?!

But since the OP seems to be fine with it...
So, after I've had a good scream in a dedicated place, I'll be with you and try to sift fact from fiction.
____________
A person who won't read has no advantage over one who can't read. (Mark Twain)

Ok...

Let me do the easier one first - precision. [on second thought it's not easy at all...]

Disclaimer: I'm neither omniscient nor do I speak ex cathedra. Some points may end up slightly wrong. Don't blame me if your eyes glaze over.

Any of you ever heard of the law of error propagation? Or of the different precisions computers can work at? How simple do I need to put it?

Let me cite Gauss: 'Nothing shows mathematical illiterateness as much as the excessive accuracy of numbers.'

As a scientist, the rule is to carry as much precision as feasible through the whole calculation and only reduce to a sensible number of decimal points when presenting the result.

For us, precision is vital. Minimal errors expand to large ones. So, we'd like to have as much precision as possible in the calculations. In computer terms that comes at a cost - double precision takes up double the space. So there is a tradeoff between the accuracy of a calculation and the memory it requires. For that reason sometimes lower precision is used. Also higher precision can sometimes result in higher error. And last but not least, GPUs often don't support double precision in the first place.

Now, let's look at the stock application level. The CPU app was developed first and AFAIK uses varying precision. The NV app was ported from there and due to the hardware available at that time (end of 2008) was single precision.
That invariably leads to small discrepancies. This is most notable in the number of signals reported - when the signal is very close to the reporting threshold it may be reported in one app but not the other. The validator has been designed to cope with the inherent variance of computational calculations. In such cases it will get another opinion - and if the mismatch is only one signal (to be precise if more than 50% of the results match) both (all three) results will be valid.

Obviously this shortcoming is annoying to an excellent engineer and programmer.
That lead to improvements in the precision of the optimised app. x32f was an initial release - x38g already came with precision improvements that were further refined in x41g and x41zc.
The aim was not so much to get better precision but to improve cross-platform accuracy. At this point it became clear that any further improvements to bring CPU and GPU results closer had to come from the CPU side. This led to 6.98 and 6.99 going into beta testing. (well looks like 6.99 is going to finally go out as 7.00 or so.)

Sorry I neglected to mention ATI/OpenCL. Precision improvements similar to those developed for NV were incorporated a bit later.

So when V7 finally reaches main all the applications will be as close in precision as the hardware allows and we should see far less cross-platform inconclusives. Some other issues that lead to inconclusives (such as the processing order) will be looked at in detail and hopefully addressed in the next development cycle.
____________
A person who won't read has no advantage over one who can't read. (Mark Twain)

At risk of being declared off-topic...

Let me cite Gauss: 'Nothing shows mathematical illiterateness as much as the excessive accuracy of numbers.'

I think that Williams recent post was very helpful indeed, thank you.

excessive accuracy of numbers.'

For us, precision is vital. Minimal errors expand to large ones. So, we'd like to have as much precision as possible in the calculations. In computer terms that comes at a cost - double precision takes up double the space. So there is a tradeoff between the accuracy of a calculation and the memory it requires. For that reason sometimes lower precision is used. Also higher precision can sometimes result in higher error. And last but not least, GPUs often don't support double precision in the first place.

Now, let's look at the stock application level. The CPU app was developed first and AFAIK uses varying precision. The NV app was ported from there and due to the hardware available at that time (end of 2008) was single precision.
That invariably leads to small discrepancies.

Let me cite Gauss: 'Nothing shows mathematical illiterateness as much as the excessive accuracy of numbers.'

As a scientist, the rule is to carry as much precision as feasible through the whole calculation and only reduce to a sensible number of decimal points when presenting the result.

For those of us who think visually... :^)


____________
“Never doubt that a small group of thoughtful, committed citizens can change the world; indeed, it's the only thing that ever has.”
--- Margaret Mead

$ cat /proc/cpuinfo

$ cat /proc/cpuinfo

$ cat /proc/cpuinfo

Your point being?

The 100 wu's I get last Me about 2 hours and 35 minutes on this Zotac closed loop liquid cooled Infinity Edition GTX580 and I have equipment for 2 more of these cards, that would be about 51 minutes each, so I hear ya, if it was 100 wu's per gpu I sure wouldn't mind...
____________
Pluto is still a planet.

Beep! Beep!

$ cat /proc/cpuinfo

Your point being?

Just the irony of a 100 WU limit when there are machines that can run 244 at a time (theoretically...).