Abuse (?) of the manual assignment system

[Andrew Usher]

That's a good start, though it seems that it was limited to LL/PRP. I just checked the 100Mdigit range, and immediately saw 'Siarhei P.', one of the users mentioned previously in this thread - the LL assignments were made in _2015_ and show no progress (they keep checking in, but have not started). That seems long enough to expire without doubt.

I know the manual assignments page states that all manual assignments expire after six months if not renewed; that may not always be enforced, but there has to be some limit, again, no type of assignment (manual or not) deserves to stick around for ever.

[jwnutter]

Originally Posted by S485122

The following might have been greedy in collecting assignments. All depend on their age :

jwnutter   TF 10029  5000 results in the last year (2 years work)

If you'll look closer, you will find that this statement is not entirely accurate.

The truth is.... The PrimeNet Get Manual GPU Assignments page has been extremely painful to use for many years. But, this is likely unique to a handful of people who are doing a lot of TF work. I try to complete ~90k GHz-days of LL work per month, and I don't really care much about the values being tested. So, I generally default to "What makes sense", which has also been problematic in the past.

That said, I will also add that there are times when I unintentionally turn my assignments in late. Although I generally do not check to see if another user has been assigned these values, I support the idea of crediting my efforts (or the efforts of anyone that turns an assignment in late) to those users who receive the assignment after me. I was late so I should be punished, not the other way around. That said, I do believe the root cause goes back to the clunky nature of the PrimeNet Get Manual GPU Assignments page - at least for someone that is attempting to reserve a large number of assignments. At one time I solved this problem with MISFITS, but I ran into issues with MISFITS a few years ago following an OS update. In any event, this is just my 2 cents.

At this point, I've turned in all my LL assignments and I'm currently receiving this error message from the
PrimeNet Get Manual GPU Assignments using the default settings:

(a) Error code: 40
Error text: No assignment available for GPU trial factoring

I can continue TF'ing or I can stop - up to you guys. But, if I'm going to continue please fix the error code listed above and please allow me to pull at least 100k GHz-days of manual assignments at a time. I don't really care where these assignments are in the range.

[James Heinrich]

Originally Posted by jwnutter

please fix the error code listed above and please allow me to pull at least 100k GHz-days of manual assignments at a time.

I have asked George to look into the specific query that generates these assignments.

[jwnutter]

Thanks. I thought about sending him a dm but decided to post instead assuming he might stumble upon this thread at some point, if not already.

Also, after reading my previous post I need to make a correction: LL = TF. Not sure why I typed LL.

[Madpoo]

Originally Posted by James Heinrich

I have asked George to look into the specific query that generates these assignments.

This hasn't been forgotten about.

Right now I'm installing some patches on the server, and I was hoping this weekend to get around to fixing that query.

We talked about a few options. One was to extend the range of exponents that qualify for this setting (right now, there aren't any eligible exponents by TF bit size until we get up to about 130e6, but the preselected range doesn't go up that high).

The second option was to bump up the ideal bit level by one bit, or at least adjust the thresholds at which exponent size is related to the TF bit level. Those current levels were set many years ago and are probably in need of adjustment since modern GPUs make it more efficient to TF to higher levels to offset the potential savings of doing LL/PRP.

On the flip side, doing PRP with cert does actually work in the other direction, where TF to higher levels doesn't save the same amount of work as when we were faced with doing a pair of LL tests, so I don't know how that might affect our overall TF strategy.

Right now, the "do what makes sense" will target those optimal TF levels, but only for exponents just few million higher than the current DC and first-time wavefronts. Ranges that have LONG since been cleaned out thanks to everyone doing such awesome TF work. So, that's where it is now... we'll figure it out.

I would think that before bumping up a bit level, it may be best in the short run to extend the ranges out so we're going maybe 20M higher than the wavefronts, which I estimate will free up around 130,000 or so TF assignments. Once those are exhausted we can look at adjusting the ideal bit levels. Along the lines of casting our nets wider before going deeper.

[Andrew Usher]

If I understand this correctly, the assignments you're talking about do go up to the recommended GPU level already (77 at 130M) and as you said it's doubtful increasing that in general is a good idea when PRP/proof almost halves the test work. But the range, it seems, should be extended as much as needed to give work to everyone that requests it.

In the particular case of jwnutter, though, I thought his TF assignments were mainly at 350M and higher, and therefore would not be affected by anything near the wavefront. There has been no change that would make it more difficult to get those, has there?