[QUOTE=chalsall;399245]Hmmm... Interesting.

One thing I notice querying the MySQL database on GPU72 is each of these have been "extended". Most probably a very SPE on my part.

Tomorrow I'll drill down further. Thanks for bring this to my attention (sincerely).[/QUOTE]

Right, I noticed they were about to expire so I extended them, recreated the work and put them on one of my systems. Should have checked to see if they were done already, but didn't.

No problem, no rush... Thanks for checking :-)

Could there be value in a weekly State-Of-The-Union?
 

Something as basic as:...just making up stuff for dramatic effect :)

LL-TF: 10 days Ahead of the Curve: YELLOW
DC-TF: 30 days Ahead of the Curve: GREEN
P-1: 1 day Ahead of the Curve: RED

Then those of us who are flexible in where we put our resources could accommodate accordingly.
Because even if I use "Let GPU72 Decide"; if I am working on a less necessary work type it doesn't help

[QUOTE=petrw1;401354]Something as basic as:...just making up stuff for dramatic effect :)[/QUOTE]

OK... Not a bad idea. It's been a while since I did a "FYI" post. Not sure I can commit to doing it every week; perhaps every fortnight -- it takes a bit of work to interpret all the trends and "signals".

I'll put together a "report" at the end of this next Sunday, after Xyzzy and Oliver will (most likely) dump their (huge) weekly batch.

Short version right now: we're looking OK for TF'ing ahead for all of the DC and LL multiple categories (can't tell you exactly how many days ahead without a bit of work). This means, for LLTF, at least 74 for Cat 1 and Cat 2, and at least 75 for Cat 3 and Cat 4 (with P-1 done).

What we're continuing having some difficulty doing currently is staying ahead of the P-1'ing. Many P-1's are being handed out via Primenet at "only" 74, and a few P-1's are being handed out via GPU72 (mostly to Oliver) at only 73.

(Just because I feel like gloating, I seem to remember a certain David claiming we couldn't sustain going to 73....)

[QUOTE=chalsall;401358]Not sure I can commit to doing it every week; perhaps every fortnight -- it takes a bit of work to interpret all the trends and "signals".[/QUOTE]Didn't [url=http://mersenneforum.org/showpost.php?p=288006&postcount=447]someone once say[/url] "[i]Never send a human to do a machine's job[/i]" ?

:whistle:

[QUOTE=James Heinrich;401362]:whistle:[/QUOTE]

You are an astute observer. Just the way we like it! :smile:

GPU72 Status...
 

OK, as requested, here's a snapshot of where we're currently at with regards to TF'ing in front of the various ranges.

[CODE][B]Range Available LL'ed 30 Day LL'ed Day Days Ahead TF'ed Day[/B]
DC 29017 4225 140.83 206.04 81.42

LL 1 & 2 6788 2212 73.73 92.06 0.00
LL 3 2121 4715 157.17 13.50 190.47
[U]LL 4 3572 595 19.83 180.10 95.47[/U]
LL Totals 12481 7522 250.73 285.66 285.94
[/CODE]

Please note that we're comfortably ahead of the DC'ers, so I batched all of the "Categories" together. DC Cat 4 is where the "churners" live, so although many tens of thousands of candidates are currently assigned, approximately 97% of them will be recycled. We /are/ slowly falling behind the DC'ers (by about 59.4 a day), but we have enough of a buffer to not worry about this for quite some time.

Similarly, interestingly, there are very few LL Cat 2 assignments issued, so I combined the Cat 1 and Cat 2 ranges (all already TF'ed to at least 74 bits). Cat 3 is the most worked, and everything being assigned for it and Cat 4 are TF'ed to at least 75 bits (with P-1 done).

As previously mentioned however, we're currently having difficulty keeping ahead of the P-1'ers. Thus, although we've got a comfortable buffer for LL assignment, I would ask that people not think that additional LLTF'ing is not still critical -- it is!

Further to this, please know that currently "Let GPU72 Decide" is mostly assigning work in the 74M range to 74 bits which have not yet had a P-1 run done. Once we get a reasonable buffer, this will move back to 75 bits. This is because 74M is far enough ahead of the LL Cat 4 wave-front that "Spidy" can pull its rip-cord and release candidates for P-1'ers without risk of them being assigned to LL workers.

Please let me know if there are any questions or comments. And, as always, thanks for all the cycles everyone! :tu:

Whoops!!! I made a serious error in my spreadsheet: I summed all of the last row for the "LL Totals". Instead for the "Days Ahead" column I should have extended the calculation for the entire column (read: it should be "B7/D7", rather than "sum(E4:E6)").

The correct (I think) calculations are:

[CODE][B]Range Available LL'ed 30 Day LL'ed Day Days Ahead TF'ed Day[/B]
DC 29017 4225 140.83 206.04 81.42

LL 1 & 2 6788 2212 73.73 92.06 0.00
LL 3 2121 4715 157.17 13.50 190.47
[U]LL 4 3572 595 19.83 180.10 95.47[/U]
LL Totals 12481 7522 250.73 49.78 285.94
[/CODE]

This means we're only ~50 days ahead for LLTF'ing, rather than the ~285 days originally reported.

Sorry about the error.

(Just goes to show you: spreadsheets are code, and thus SPE's should be watched out for (as the [URL="http://www.bloomberg.com/bw/articles/2013-04-18/economists-spreadsheet-error-upends-the-debt-debate"]Economics and Policy world discovered the hard way a couple of years ago[/URL]... Edit: [URL="http://www.reuters.com/article/2013/04/18/us-global-economy-debt-herndon-idUSBRE93H0CV20130418"]A second article on this which doesn't downplay the significance as much as the first[/URL]...).)

Temporal Worker's Progress reports...
 

Just to let everyone know, I fixed a couple of SPEs on the temporal Workers Progress reports over the weekend.

There were two issues. First of all, for those who did some work of a particular type (for example, DCTF) but then stopped didn't "slide off" the report. I had a "left outer join" in the query which I thought would take care of this, but for some reason it didn't.

The second issue was I was using the datediff() function instead of the more appropriate timestampdiff() function. This meant that the totals were from midnight (UTC) to current time, rather than the appropriate time period. This was most evident in the "Last Day" reports.

Please review the reports (for example, for [URL="https://www.gpu72.com/reports/workers/dctf/day/"]DCTF over the last Day[/URL] and for [URL="https://www.gpu72.com/reports/workers/lltf/day/"]LLTF over the last Day[/URL]) and let me know if you see anything strange.

Thanks! The since-midnight thing was annoying :)

Excellent! I was always having to check just before midnight UTC to see a full day's worth of work. Now I can check anytime. :smile:

[QUOTE=chalsall;402618]This meant that the totals were from midnight (UTC) to current time, rather than the appropriate time period. [/QUOTE]
Ahaaa... This would make davieddy very proud :razz:, one of the main reasons of his arguments (for which he was banned once) was that one table was sync'd from midnight and the other from midday, hehe...