Team drive #12 k=2000-3000 n=50K-425K

[mdettweiler]

Reserving 2400-2425 for Sloth PRPnet.

[Sloth]

Please add 2426-2475 to the prpnet server. It looks like psp is going to take a while to get up and running with the new server and I don't want to have to keep up with things over the holidays.

[mdettweiler]

Originally Posted by Sloth

Please add 2426-2475 to the prpnet server. It looks like psp is going to take a while to get up and running with the new server and I don't want to have to keep up with things over the holidays.

Okay, I've extended your reservation to k=2475 and the new candidates are being loaded into the server right now.

[mdettweiler]

Sloth has completed k=2400-2475, n=250K-350K. The processed results have been sent to Gary, and a list of all the primes found in this range is attached.

[MyDogBuster]

On the drive progress chart http://www.noprimeleftbehind.net/sta...drive_progress there is a hole for k=2500-2600 for n=0-250K. Looked to be a part of drive 12a. Anyone know what happened here? If someone would send me the candidates I could finish it.

[mdettweiler]

Originally Posted by MyDogBuster

On the drive progress chart http://www.noprimeleftbehind.net/sta...drive_progress there is a hole for k=2500-2600 for n=0-250K. Looked to be a part of drive 12a. Anyone know what happened here? If someone would send me the candidates I could finish it.

That range has been a bit of a mess in the DB for a year or two now; we had initially attempted to test it with a PRPnet 2.4.x server, but discovered partway through that the non-multithreaded PRPnet 2.4 was unable to handle the load of more than a few clients on such small numbers, and Bruce offered to do the whole k=2400-2600 range (including some parts that were already in the database from the PRPnet server) manually. The plan, as outlined at the time, was to leave the original PRPnet data in the database, since it was accurate for the results that did get put in there, so that the original contributors wouldn't lose their credit, and then import the remainder from Bruce's manual run. His results that duplicated ones already in the database would then be credited as doublechecks in the future when we get that database mechanism set up.

Since then, Dave and I have been working off and on to develop an alternate data-loading mechanism that will allow us to import Bruce's manual results to the DB while logging which ones are already there (so we know which to later import to the doublecheck database). Both Dave and I have been rather cramped for time of late, so we've been making progress rather gradually, but we're nonetheless working on it.

The simplest fix would be to just delete all the data from the initial, incomplete PRPnet run, and load Bruce's manual results to replace it. This would, however, cause those who contributed to the PRPnet test run (mostly Lennart, if I remember correctly) to lose credit, which is why we have been pursuing the more complicated solution outlined above.

When Dave and I finish working on the alternate loading mechanism, we'll actually be able to kill two birds with one stone: in addition to cleaning up the Drive 12a mess, we can use the same scripts to handle the re-import of certain results from the 1st Drive that were never actually imported in the first place (back then it was all a manual process and we must have skipped over these). This will clean up the results in the database erroneously credited to user "Unknown", leaving only truly "Unknown" results (for instance, those credited to usernames like "PG_Username", the default userid in PrimeGrid PRPnet packages) credited as such.

[MyDogBuster]

Thanks Max, I was just trying to get the chart to look purdy. LOL

[MyDogBuster]

I'll pick up Drive 12 again as soon as I get a new PS for the machine running it.

POOF.

[gd_barnes]

Reserving k=2477 to 2600 for port 7000.

[gd_barnes]

Reserving k=2600 to 3000 for port 7000. This will be all for n=250K-350K. n=350K-425K remains.

[gd_barnes]

Reserving k=2000-2400/n=350K-425K for port 7000.