GPU to 72 status...

[flashjh]

Originally Posted by chalsall

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).

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 :-)

[petrw1]

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

[chalsall]

Originally Posted by petrw1

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

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....)

[James Heinrich]

Originally Posted by chalsall

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".

Didn't someone once say "Never send a human to do a machine's job" ?

[chalsall]

Originally Posted by James Heinrich

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

[chalsall]

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

Range   Available   LL'ed 30 Day   LL'ed Day   Days Ahead   TF'ed Day
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
LL 4         3572            595       19.83       180.10       95.47
LL Totals   12481           7522      250.73       285.66      285.94

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!

[chalsall]

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:

Range   Available   LL'ed 30 Day   LL'ed Day   Days Ahead   TF'ed Day
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
LL 4         3572            595       19.83       180.10       95.47
LL Totals   12481           7522      250.73        49.78      285.94

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 Economics and Policy world discovered the hard way a couple of years ago... Edit: A second article on this which doesn't downplay the significance as much as the first...).)

[chalsall]

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 DCTF over the last Day and for LLTF over the last Day) and let me know if you see anything strange.

[Mark Rose]

Thanks! The since-midnight thing was annoying :)

[Chuck]

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.

[LaurV]

Originally Posted by chalsall

This meant that the totals were from midnight (UTC) to current time, rather than the appropriate time period.

Ahaaa... This would make davieddy very proud , 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...