[QUOTE=kracker;356238]:ermm: I haven't tested/done anything here/there, I only have OpenCL cards.(at the moment)[/QUOTE]

OK. Maybe my confusion had to do with the area of involvement. I see a lot of feedback from you in Trial Division with OpenCL (mfakto).

[QUOTE=chalsall;356135]OK, the first draft of the requested [URL="https://www.gpu72.com/reports/current_level/"]Current Trial Factoring Depth for all Candidates[/URL] report is now online.

The table for LL candidates is complete. The DC table below it needs some attention, but I figured the LL data was what most people were interested in, so I figured I'd release the report now.

The back-end is also calculating the data for those candidates without P-1 done. I'll expose that once I get the DC table finished (it will be available via a sub-menu for the new "Current TF Levels" menu).[/QUOTE]
Lovely! That shows the picture well - thank you.
And that was done quickly! (I was away from the forum for a few days, so now I'm replying to posts two pages back!)
[QUOTE=chalsall;356151]For expediency I just re-used the code which renders the "Estimated Completion" report.[/QUOTE]
I hoped that report would be a good place to start from. Thanks again.

Pls let me replace "Manual" on the "Get Assignments" form
 

Chris, please allow me to request (again) some feature that allows me to replace the "Manual" computer name when requesting work. I now have (at least) 50 assignments that were probably lost in network timeouts. Knowing for which machine they were requested would save me a lot of trouble determining if they really were lost.

Unfortunately I cannot use any of the automation tools for most of my machines ... therefore almost all my assignments are "Manual" and I have to search all machines for traces of the aging assignments :-(.

[QUOTE=Bdot;366209]Unfortunately I cannot use any of the automation tools for most of my machines ... therefore almost all my assignments are "Manual" and I have to search all machines for traces of the aging assignments :-(.[/QUOTE]

Copy you. Thanks for the "squeak". :smile:

I'll try to get to this this weekend.

www.mersenne.info often out of sync
 

I sometimes see that statistics are one, two or more days out of date (beyond the apparent 24 hour update cycle), over many months now.
Further, I note that on such occasions, looking at other regions of the exploration space, I see that the information can have a different level of currency, so the evidence I see is that such outages are not across the whole space.
This would be consistent with an interrogation of the PrimeNet server to scrape statistics, but upon communication delays such process doesn't entirely recover to adequately retry and fulfill regions.
Please don't tell me that the current mechanism is a http viewable page scrape!

With increasing reliance on .info, would it be useful to negotiate a more efficient and reliable issue of information from PrimeNet?

[QUOTE=snme2pm1;376291]I sometimes see that statistics are one, two or more days out of date (beyond the apparent 24 hour update cycle), over many months now.[/QUOTE]

Could you please give specific examples? URLs welcome.

Please note that mersenne.info goes out of its way not to negatively impact mersenne.org, and thus does not spider those ranges which have not had a state change (as previously documented).

[QUOTE=chalsall;376327]Could you please give specific examples? URLs welcome.

Please note that mersenne.info goes out of its way not to negatively impact mersenne.org, and thus does not spider those ranges which have not had a state change (as previously documented).[/QUOTE]

Well, I had best look at this previously documented algorithm that is alluded to before further comment.
A link to your algorithm description would help.

Regarding recent observations, which I wasn't in a hurry to particularly emphasise, you might recall that I have been working the early 78M region, and almost completed such thrust.
Today again [url]http://www.mersenne.info/trial_factored_tabular_delta/4/78000000/[/url]
is not aware of changes, though I certainly did lodge some results that I imagined would have been noticed.
Back a few days, I had the impression, without recording precise information, that such was three days without update.

[QUOTE=snme2pm1;376335]Today again [url]http://www.mersenne.info/trial_factored_tabular_delta/4/78000000/[/url]
is not aware of changes, though I certainly did lodge some results that I imagined would have been noticed.[/QUOTE]

The spider will only "notice" work (in a 1M range) if there's a state-change on [URL="http://mersenne.org/primenet/"]the Primenet Exponent Status Distribution[/URL] report.

A state-change is defined as a change in the number of factors, the number of LL/DC candidates, or the number of assignments (of any class -- TF/P-1/LL/DC). Thus, if you didn't actually get the assignments from Primenet AND didn't find a factor, the system won't detect any TFing changes.

Note that the system also scans 30 additional 1M ranges without a state-change, sorted by last scanned date. Thus, a range which has had TFing work done on it without a factor being found OR an official assignment being made, it can take up to ~30 days for the range to be updated.

Thus, if you want a range to be scanned simply get an assignment from Primenet and hold onto it for 24 hours.

I notice that the /account/factoring_cost/ only shows exponents up to 70M. It would be nice to have it show up to 74M to include the current TF assignments being handed out. :)

I would be weighting in favor of adding few lines to the [URL="http://www.gpu72.com/reports/current_level/"]current levels[/URL] DC table too... (like to 55M or so? is there any work to be done there, or it was already stomped all when we did LLTF in that range?)

[QUOTE=Mark Rose;379042]I notice that the /account/factoring_cost/ only shows exponents up to 70M. It would be nice to have it show up to 74M to include the current TF assignments being handed out. :)[/QUOTE]

Thanks for pointing that out. Fixed.