[QUOTE=Dubslow;276129]It seems like it would be better to just use PrimeNet, but if George doesn't have the time, this is the next best option.[/QUOTE]

Eventually all new test assignments and expiries will be already TFed to the optimum 72, and our project will come to an end, no change to Primenet needed. It's also worth noting that all our efforts are saving just a handful of LL tests per day. George's time is certainly better spent on implementing an AVX FFT.

[QUOTE=Dubslow;276129]It seems like it would be better to just use PrimeNet, but if George doesn't have the time, this is the next best option.[/QUOTE]

Of course -- if PrimeNet could do the work, that would be optimal.

Thinking a bit more about this...

1. With regards to my point 1 above, there's no reason my system couldn't do the reservations itself, in addition to or instead of human effort.

2. With regards to my point 3 above, if a worker only "pledged" to take an exponent up to, say, 70 but it was agreed that it would be better to not release exponents until they were up to, say, 71, the system could then reassign the exponent to another worker pledging to take it from 70 to 71 once the first worker had completed their work.

But an observation / question... Would this not result in the LL wave front temporarily being pushed ahead? Although, with a long-term net benefit to the GIMPS effort.

Thoughts?

I'd only invest the effort if everyone (including George) agrees it's a good idea.

[QUOTE=chalsall;276113]If it would help this sub-project, I'd be willing to invest a bit of time to modify my "MiniPrimeNet" code to facilitate this.

I'm thinking something along the lines of:

1. Mr. P-1 and anyone else collecting expired candidates uploads the exponents after getting them assigned as Anonymous.[/QUOTE]

Is there any reason MiniPrimeNet couldn't collect the expired candidates itself?

[QUOTE]2. "Workers" log into the server and ask for some number of assignments and what bit level they're going to work them up to.[/QUOTE]

Default to 70, with the option of going higher than 70, if the worker insists. We strongly want to encourage workers to do more assignments to 70, rather than fewer to higher levels. Over a period of months, we will need to raise that limit first to 71, and then, to davieddy's delight, to 72.

Also exponents already TFed to low levels (currently 68) should be prioritised over those TFed to high (currently 69). High exponents at the same TF level should be prioritised over low.

[QUOTE]3. The server watches these exponents (once a day or so, to not have too high an impact on the real PrimeNet server), and automatically unassigns them once it sees the pledged bit level has been achieved.[/QUOTE]

I presume you mean unreserve them on the real PrimeNet server, and not merely record them as unassign in its own internal database.

OK, but I'd also like it to keep hold of small exponents TFed to 70 (or whatever the current default is) and needing P-1, as I and perhaps others would want to take some of these on.

[QUOTE=Mr. P-1;276146]Is there any reason MiniPrimeNet couldn't collect the expired candidates itself?[/QUOTE]

Our messages crossed.

Yes, MiniPrimeNet could certainly collect the candidates. I already have code for that kind of work.

[QUOTE=Mr. P-1;276146]Default to 70, with the option of going higher than 70, if the worker insists. We strongly want to encourage workers to do more assignments to 70, rather than fewer to higher levels. Over a period of months, we will need to raise that limit first to 71, and then, to davieddy's delight, to 72.[/QUOTE]

Agreed. As davieddy said, "breadth first". But there should be some thought about how wide the "breadth" should be.

[QUOTE=Mr. P-1;276146]Also exponents already TFed to low levels (currently 68) should be prioritised over those TFed to high (currently 69). High exponents at the same TF level should be prioritised over low.[/QUOTE]

A simple "order by ..." clause in the SQL query.

[QUOTE=Mr. P-1;276146]I presume you mean unreserve them on the real PrimeNet server, and not merely record them as unassign in its own internal database.[/QUOTE]

Yes -- that's what I meant.

[QUOTE=Mr. P-1;276146]OK, but I'd also like it to keep hold of small exponents TFed to 70 (or whatever the current default is) and needing P-1, as I and perhaps others would want to take some of these on.[/QUOTE]

Three options here:

1. You keep to yourself and work those low exponents you yourself have reserved.

2. There be an option in MiniPrimeNet which says: "I claim ownership of this Exponent until I tell you otherwise.

3. A possible bonus option: MiniPrimeNet does not unreserved low exponents once the agreed upon TF level has been reached so that P-1 workers like you have an opportunity to claim and work them.

There would have to be a balance between the number of exponents reserved by this system vs. the amount of "fire power" available.

Further thoughts?

We crossposted. You've already addressed some of my earlier points.

[QUOTE=chalsall;276141]1. With regards to my point 1 above, there's no reason my system couldn't do the reservations itself, in addition to or instead of human effort.[/quote]

At the moment, I take all expiries less than 53M, filter out those TFed to 70 and higher (except for small P-1 ready exponents at 70 which I want to do myself), and unreserve these. The rest are added to my reserves.

The overwhelming majority of assignments I've seen over 53M are already TFed to 70 or higher.

[QUOTE]2. With regards to my point 3 above, if a worker only "pledged" to take an exponent up to, say, 70 but it was agreed that it would be better to not release exponents until they were up to, say, 71, the system could then reassign the exponent to another worker pledging to take it from 70 to 71 once the first worker had completed their work.[/QUOTE]

At the moment there are so few TFed to 68 that it's probably not worth even offering the option to just TF to 69. My guess is, that by the time we raise the limit from 70 to 71, there will be very few TFed to just 69.

[QUOTE]But an observation / question... Would this not result in the LL wave front temporarily being pushed ahead? Although, with a long-term net benefit to the GIMPS effort.[/QUOTE]

Yes it will. It already has, by a few thousand exponents. As you point out, this is temporary.

[QUOTE]I'd only invest the effort if everyone (including George) agrees it's a good idea.[/QUOTE]

Indeed. When I started, I only had three volunteers and a few hundred assignments. I didn't then think it necessary to contact him. Now it's burgeoned to a dozen volunteers and thousands of exponents. But he knows about it, and he hasn't objected.

I think chalsall's offer is generous and we should take it. I would much prefer a semi-automated system to messing around with PMs and emails.

You could easily code some logic into your mini-Primenet that would unreserve exponents after a certain dynamic bit-level which would be based on the rate at which work is being completed/P-1 status etc. etc. I will happily volunteer to be your first client.

[QUOTE=chalsall;276147]Our messages crossed.[/QUOTE]

Ping-pong!

[QUOTE]Three options here:

1. You keep to yourself and work those low exponents you yourself have reserved.

2. There be an option in MiniPrimeNet which says: "I claim ownership of this Exponent until I tell you otherwise.[/QUOTE]

Neither of these would work for me. I don't have a GPU and won't be taking any TF assignments.

[QUOTE]3. A possible bonus option: MiniPrimeNet does not unreserved low exponents once the agreed upon TF level has been reached so that P-1 workers like you have an opportunity to claim and work them.[/QUOTE]

Many of the assignments already have had P-1 done, but there may also be testers who would like small assignments TFed and P-1ed.

[QUOTE]There would have to be a balance between the number of exponents reserved by this system vs. the amount of "fire power" available.[/QUOTE]

Of course. At the moment the firepower has increased as such a rate that I don't feel that my reserves have become excessive, but I always assumed that I would probably have to start unreserving stuff eventually. When that happened, I was still intending to do a full grab every day. Then I would keep the highest priority assignments and drop the lowest.

[QUOTE=garo;276150]I think chalsall's offer is generous and we should take it. I would much prefer a semi-automated system to messing around with PMs and emails.[/QUOTE]

I agree. Of course, this will leave me [url=http://www.youtube.com/watch?v=XTe7M7gBgvs]completely redundant[/url].

[QUOTE=Mr. P-1;276156]I agree. Of course, this will leave me [url=http://www.youtube.com/watch?v=XTe7M7gBgvs]completely redundant[/url].[/QUOTE]

:smile: There is an old saying... Never send a human to do a machine's job...

Based on your and Garo's support, I'm beginning implementation.

[QUOTE=Mr. P-1;276139]Eventually all new test assignments and expiries will be already TFed to the optimum 72, and our project will come to an end, no change to Primenet needed. It's also worth noting that all our efforts are saving just a handful of LL tests per day. George's time is certainly better spent on implementing an AVX FFT.[/QUOTE]

Not just for this mini project, I meant a GPU-TF assignment option on the manual page, so that we can take lower exponents to a higher limit, beyond what CPU's should or can do. The risk with just upping bounds is that some CPU could easily get stuck with an assignment meant for a GPU. It just happens that such an option implemented now would automate this mini-project, as only a side effect, not primary cause.

[QUOTE=garo;276150]I think chalsall's offer is generous and we should take it. I would much prefer a semi-automated system to messing around with PMs and emails.[/QUOTE]
[QUOTE=chalsall;276163]:smile: There is an old saying... Never send a human to do a machine's job...

Based on your and Garo's support, I'm beginning implementation.[/QUOTE]
Standing on the side lines (I don't have a GPU), I think that your offer is dynamite. Go forth and prosper.:tu::bow: