Abuse (?) of the manual assignment system

[Andrew Usher]

Those two belong in the category of erroneous LLDCs I just mentioned - some LL tests were incorrectly classified as DCs, and therefore not expired after one result (as a DC needs to be verified to be completed).

[storm5510]

Originally Posted by S485122

I think some users don't realize they have that many assignments (for instance because of a misconfiguration a client could ask for assignments again and again...

I became virtually choked by assignments pulled in by Misfit several years ago. I didn't think I would ever get all of them finished, but I did. This is what I got for not paying close attention to what was going on. Lesson learned.

[xilman]

Originally Posted by Madpoo

From what I understand, the user was extremely confused about what Primenet is all about and had no idea what they were doing when getting a lot of assignments. Not so much malicious as just woefully ignorant.

Hanlon's Razor.

[Andrew Usher]

For the purpose of assignments, though, ignorance is as bad as malice or stupidity - that's why I specified 'honest and informed' users - informed meaning not only knowing the idea of the assignment system, but having a reasonable idea of how long it will take to complete various tasks.

Those hung-up LL assignments (there are only a couple hundred) can be cleared, as LordJulius just did on M111597749, by PRP/proof as well as LL. But it's still annoying that they MUST be poached; someone else could have been in the middle of an LL or PRP on the same exponent.

[slandrum]

Originally Posted by Andrew Usher

For the purpose of assignments, though, ignorance is as bad as malice or stupidity - that's why I specified 'honest and informed' users - informed meaning not only knowing the idea of the assignment system, but having a reasonable idea of how long it will take to complete various tasks.

Those hung-up LL assignments (there are only a couple hundred) can be cleared, as LordJulius just did on M111597749, by PRP/proof as well as LL. But it's still annoying that they MUST be poached; someone else could have been in the middle of an LL or PRP on the same exponent.

This assignment was a glitch in the system. The first LL result turned in on 2021-05-04 should have cleared the assignment that was issued on 2021-04-08. This wasn't a case of abuse of the assignment system, it was a case of an error on the server. There are occasionally errors on the server, and when they are discovered they can be corrected.

[Madpoo]

Originally Posted by slandrum

This assignment was a glitch in the system. The first LL result turned in on 2021-05-04 should have cleared the assignment that was issued on 2021-04-08. This wasn't a case of abuse of the assignment system, it was a case of an error on the server. There are occasionally errors on the server, and when they are discovered they can be corrected.

Well, I don't know if I'd throw the server under the bus on that one. There are clear times when the server does unexpected things, but in this case, the user kept requesting the same exponent each time the old one expired, and eventually it successfully finished one.

In a case like that, each assignment had a unique assignment ID, so when the last of those finally checked in, it completed that one assignment for it, but it still shows the other, older ones as expired.

When his one actual result checked in, it "converted" the most recent of his other assignments to a double check which would have taken it MUCH longer to expire due to the rules, only expiring recently because a PRP test was done which finally rendered that double check LL assignment moot.

There's actually quite a few cases like that where there was still some valid assignment for a first-time LL test, and then someone poached it before it had expired, turning it into a DC which can linger for years.

So, in essence it's all working as expected, it's just a little quirky, and in that one case, the user must have had something funky going on with their client. Their assignment would expire, but then they'd check in with some work in progress afterwards which would auto-create a new assignment, rinse and repeat. It happens... rarely, but it does. Normally if it's an exponent near where current assignments are, it'll be snapped up by someone else before the same user checks in and gets a new assignment for it, but it can happen.

[Andrew Usher]

It may be operating as intended, but I think to most people it would seem surprising and unexpected that
a FTC assignment could be automatically converted into a DC assignment, or not expire when the work is
apparently done. I assume the utility of this behavior was when the assignments were to different users,
not the same one, and ideally that should be (or should have been) checked for.

I already mentioned that that exponent is not alone - it's the first one I found because of its
proximity to the milestone, and I reported it in the server problems thread, which is probably where
LordJulius got it.

It appears from the 'expired assignments' history that user's assignment expired twice because of the
60-day check-in rule (which I don't think would be enforced today so far above the wavefront) until he
finally was able to complete it within 60 days and submit it.

[Madpoo]

Originally Posted by Andrew Usher

...It appears from the 'expired assignments' history that user's assignment expired twice because of the
60-day check-in rule (which I don't think would be enforced today so far above the wavefront) until he
finally was able to complete it within 60 days and submit it.

Here's my best guess at what happened with that one, and it probably applies to other assignments (in fact I'm almost certain there are others currently in this same boat).

First assignment 2020-11-14... somehow he gets 6% done when it updates on that same day, but then no contact since then, and it expires 2021-01-13 (about 60 days, which makes sense)

Second assignment 2021-02-02, presumably because his machine finally decides to check in again and since it already had some progress on it (up to 10.7% now) it created a new assignment since nobody else was assigned that exponent yet. Once again, no further check-ins and it expired 60 days later on 2021-04-03.

Third assignment 2021-04-08 where the machine again decides it's going to check in (5 days after it expired), this time up to a whopping 14.4%. As before, since nobody else was assigned that exponent yet, the user got a new one. This 3rd time was the charm and apparently the user got that computer out of first gear and it finished and reported the result on 2021-05-04.

The mystery here is why didn't that final result serve as a completion for that 3rd assignment, which apparently got converted to a double-check and then finally expired when LordJulius turned in a PRP result with verification.

Here's my theory... remember how that first expired assignment showed a magical 6% done on the same day it was assigned? I think there was actually an assignment even earlier than that, and it was that assignment ID that the user used when checking in the final result. Once an assignment is checked in, that matching assignment ID goes away so we don't have a record of it. If I really wanted to, I could dig up the old log files for that date and confirm that the ID used when it checked in was different than those other ones, but I'd wager that's what I would find.

The way it's setup may be confusing, but it's done with the intention that if a user does happen to keep on reporting in sporadically, and the exponent is still available, it'll give that user 2nd, 3rd, and nth chances. Eventually it'll either get poached or the exponent is assigned to someone else if the user doesn't get their computer back into gear.

[slandrum]

Keeping a reservation of FTC and converting it to DC may have made sense when DC was trailing FTC by a couple years, but when it's closer to a decade doesn't really make sense. Once the FTC is turned in, it's unlikely that anyone is immediately going to be looking to DC it (unless the exponent is particularly interesting).

If the assignment is poached (even self-poached because they turned in a result with no AID or the wrong AID) then the FTC assignment should be expired.

If someone keeps working on it and eventually turns in a result, nothing is lost, the result will be accepted as a double check. The reservation isn't really needed in this case. Holding the reservation for very long periods of time on presumably abandoned assignments prevents SRBASE from advancing the TF level on the exponent, and other useful things from happening.

Of course, all of this is late in the game since few people should be doing LL FTC, and the most likely poaching to occur now is PRP with proof which will expire out any outstanding LL or PRP assignments on the exponent.

[Andrew Usher]

Another reason, though, is that we don't want partial work that may prove a useful DC to be abandoned, and expiring the assignment might be seen as an indication to do so. But this only applies, as I indicated, if it's done by a different user. If it's what you call self-poaching, as most and maybe all of these hung exponents are, there should be no partial work to worry about. So turning in one LL/PRP result should expire all other assignments by the same user, but not necessarily by someone else.

Actually there's no reason a user should ever have more than one assignment on the same number for the same worktype, and the server is arguably at fault if that is what happened.

[Uncwilly]

Originally Posted by Andrew Usher

Actually there's no reason a user should ever have more than one assignment on the same number for the same worktype, and the server is arguably at fault if that is what happened.

Five or six machines doing ECM on the same number is a foreseeable circumstance that disproves your assertion.