[QUOTE=chalsall;412245]LaurV, could you please give this a try?

For that particular machine, the GPU72 database doesn't see a change for each Computer_CPU record since 2013-11-26.

Again, it's probably a Stupid Programmer Error (SPE) (:wink:) on my part, but it would be interesting to analyse the logs generated by the attempt.[/QUOTE]

Butting in here, uninvited...

Since Primenet stores user preferences on the server and hands out assignments based on that, is it a fair assumption that when using the GPU72 proxy, since it can't divine those user preferences itself, it has it's own (hopefully matching) settings for the user? And the only way it would know is if it sees the client trying to change those settings as it's proxying that particular request?

Thus the "fix" of changing and setting back the work type will allow GPU72 to pick that up and assign the expected work?

Butting back out now...

[QUOTE=Madpoo;412251]Butting in here, uninvited...[/QUOTE]

Please always feel free to "butt in". :smile:

[QUOTE=Madpoo;412251]Thus the "fix" of changing and setting back the work type will allow GPU72 to pick that up and assign the expected work?[/QUOTE]

That's the hope.

The Primenet API is rather complicated. And, I'm not convinced all the clients fully honer the protocol.

"Just in time" in LLTF, well over a year ahead in DCTF.
 

Now that James has brought (back) to the table [URL="http://www.mersenne.ca/status/tf/"]Delta Reports[/URL] for the GIMPS project (thanks again mate; great job!), I thought it might be time to do another Status Report on the GPU72 sub-project.

[CODE]Range Available LL'ed 30 Day LL'ed Day Days Ahead TF'ed 30 Day TF'ed Day Days G/L
DC 75187 5657 188.57 398.73 31423 1047.43 4.55

LL 1 & 2 4386 1044 34.80 126.03 3 0.10 -1.00
LL 3 7182 5275 175.83 40.85 8486 282.87 0.61
[U]LL 4 1018 2018 67.27 15.13 3004 100.13 0.49
[/U]Totals 12586 8337 277.90 45.29 11493 383.10 0.38[/CODE]

Some notes:

1. "Days G/L" == "Days Gained/Lost".

2. As we are so far ahead in the DCTF'ing domain, I simply merged all the "Categories" together.

2.1. In fact, we're even further ahead than 399 days; I simply counted the appropriately TF'ed candidates up to (but not including) 45M. There are another 15,000 or so candidates already ready between 45M and 50M.

3. As before, very little LL Cat 2 is being done, so I merged it with Cat 1.

4. The -1 value for the "LL 1 & 2" row is a bit misleading, as just about everything in those categories is already appropriately TF'ed.

5. What is not readily apparent from this is just how close to the wire we are with "feeding" the P-1'ers. We're ~45 days ahead of the LL'ers, but still only a few days ahead of the P-1'ers.

Please let me know if anyone has any questions or comments.

How far ahead of P-1 are we if we change strategy so that rather than attempt a full TF before P-1, we plan to TF to one bit level lower, currently 74, before P-1, then complete the final bit level after P-1? With the excess P-1 power right now, it should be much easier to stay ahead of LL.

[QUOTE=frmky;412521]How far ahead of P-1 are we if we change strategy so that rather than attempt a full TF before P-1, we plan to TF to one bit level lower, currently 74, before P-1, then complete the final bit level after P-1? With the excess P-1 power right now, it should be much easier to stay ahead of LL.[/QUOTE]

"Spidy" is already coded for this. It releases P-1 candidates at "only 74" if needed.

We actually have the firepower to take everything to 75, so long as there is not unexpected (and great immediate demands) for P-1 candidates.

I hope that makes sense.

[QUOTE=chalsall;412523]I hope that makes sense.[/QUOTE]
Sure it does. Thanks. I advocated for a long time for what Greg said. The 75th bit is a bit too much unless you do it on AMD cards (and then it worth because openCL FFT library is slower, therefore LL tests are slower on these cards, which make them much more appropriate for TF - I myself have a 7970 which were (and is) running DCTF since it was installed, without stop, except for my annual leaving holiday - and there was a time when a 7990 was doing that too, but I sold it)
(edit: I didn't forget that I said I will bring my LLTF contribution to 1.8THzD/D after I finish the current LL/DC work - about 6-7 days left).

[QUOTE=LaurV;412540]Sure it does. Thanks. I advocated for a long time for what Greg said. The 75th bit is a bit too much unless you do it on AMD cards (and then it worth because openCL FFT library is slower, therefore LL tests are slower on these cards, which make them much more appropriate for TF - I myself have a 7970 which were (and is) running DCTF since it was installed, without stop, except for my annual leaving holiday - and there was a time when a 7990 was doing that too, but I sold it)[/QUOTE]

When I look at the graph on mersenne.ca for a [url=http://www.mersenne.ca/cudalucas.php?model=12]GTX 580[/url] it shows the cutoff to be 75 bits above 66M (76 above 84M). What is the reason for saying the 75th bit is too much?

[QUOTE=Mark Rose;412542]When I look at the graph on mersenne.ca for a [URL="http://www.mersenne.ca/cudalucas.php?model=12"]GTX 580[/URL] it shows the cutoff to be 75 bits above 66M (76 above 84M). What is the reason for saying the 75th bit is too much?[/QUOTE]

My 580s take a hit at 71 and 72 bits on wavefront TF. They open up at 73. Of course, things are different in the 320M zone.

Yes, also those tables are "theoretical" values, they don't consider how much P-1 was done, etc. Expected factors at 75 bits can go down from "1 in 75" to as low as "1 in a hundred" or so. We already discussed this many times, you have to "tune" your system. Do TF for few days, do P-1 few days, see how many exponents you clear (finding factors). Double the numbers for LL range (because you save two LLs if you find a factor, and a little bit of P-1), multiply by some under-unit number for DC range (due to huge amount of P-1 done in the area, your chances to find factors by TF are lower), [B]then[/B], if you can [U]clear more exponents[/U] by doing TF to 80 bits, than you would do LL and/or DC tests [U]with your particular system[/U] then go for TF. You can go to 81 if you consider yourself lucky :wink: (this was a joke, in spite of the fact that I behave like that sometimes - also please consider that 80 and 81 are intentionally exaggerated, you should do your homework for [U]your particular rig[/U] which includes gpgpu card, memory, cpu, etc (a very busy cpu will slow LL or TF rate of the GPU card, in spite of the fact they don't "wait for each other").
There are many factors to consider which are not "in the tables". At the end, consider that doing TF you provide free lunch for others; doing LL/DC you have a "negligible" chance to find a prime (lunch for yourself).

P95 take off a percent of GPU usage on both my cards when it kicks in. However, this is not so true running Small FFT Torture Test. This leads me to believe that memory contention is the culprit on this FX-8350, dual-channel-memory system.

There are other system tasks which eat into GPU usage, but none so demonstrably.

EDIT 2: This only concerns mfaktc. CUCALucas [U]always[/U] runs at 99% GPU, at least the way I have it set.

Yeah, my DCTF factors found are 10% below expected, probably due to all the P-1 effort. But that shouldn't be a problem in front of the P-1 wave, right?

I don't do any LL. I usually use my available CPU power for SoB. Sometimes I'll help out with the random DC work Madpoo comes up with, or when someone wants an immediate triple check.

My three GTX 580's run at factory overclocks, getting 430 to 433 GHz-d/d doing current DCTF work after mfaktc.ini tweaks. That's all they've ever done. I've never even plugged a monitor into them :)