Modifications to DC assignment rules

[retina]

I notice the Cat 4 assignments do not fetch the lowest available exponents. According the the thresholds page cat 4 starts at 42702950 as of today. But newer assignments skip over many available exponents and primenet is giving out exponents in the 50M range. It appears as though older expired assignments above the threshold are left in limbo. Is this an oversight or by design?

[Siegmund]

I notice the Cat 4 assignments do not fetch the lowest available exponents

I've been wondering about that too. Going to be mighty interesting if the runaway keeps going a few more weeks. Assuming it is some hiccup causing it not to start back from the bottom of the heap daily, but I only have questions not answers.

[Prime95]

The problem is with the SQL clause that prohibits a user from getting an exponent that was assigned to him previously and had expired within the last 180 days. This was added to help avoid double-checks by the same user (an expired assignment that reports in late plus a new assignment that reports in)

The problem is that Anonymous has SO many exponents and SO many expireds, there aren't a lot of non-churned exponents to assign. I changed the SQL clause for anonymous users to exclude anonymous exponents expired in the last 60 days. Keep an eye on things to see how this works out.

[Madpoo]

Originally Posted by Prime95

The problem is with the SQL clause that prohibits a user from getting an exponent that was assigned to him previously and had expired within the last 180 days. This was added to help avoid double-checks by the same user (an expired assignment that reports in late plus a new assignment that reports in)

The problem is that Anonymous has SO many exponents and SO many expireds, there aren't a lot of non-churned exponents to assign. I changed the SQL clause for anonymous users to exclude anonymous exponents expired in the last 60 days. Keep an eye on things to see how this works out.

That was probably the clause I'd added back when...

The trouble was that anonymous users were getting assignments and then letting them expire but then they'd still check them in eventually, much later. Meanwhile it was assigned to another anonymous user that did finish it. Thus creating a 'self verified" result.

I realize I could be less stringent about my own definition of "self verified" when it comes to anonymous results...my OCD is having a hard time with that though. LOL

[snme2pm1]

Originally Posted by Prime95

The problem is with the SQL clause that prohibits a user from getting an exponent that was assigned to him previously and had expired within the last 180 days. This was added to help avoid double-checks by the same user (an expired assignment that reports in late plus a new assignment that reports in)

The problem is that Anonymous has SO many exponents and SO many expireds, there aren't a lot of non-churned exponents to assign. I changed the SQL clause for anonymous users to exclude anonymous exponents expired in the last 60 days. Keep an eye on things to see how this works out.

Wow, so much worry!
I have uneasy feelings correlated with prior now defunct regimes where extreme attention to compliance was soon after accompanied with demise.

[Siegmund]

@madpoo: seems to me that a restriction that an Anonymous LL test must have a non-anonymous double-check is all that is really necessary (and if the DC doesn't match, a non-anonymous triple-check, but you already harvest a lot of those)...why do we care whether or not Anonymous gets two shots at a doublecheck or not?

[Madpoo]

Originally Posted by Siegmund

@madpoo: seems to me that a restriction that an Anonymous LL test must have a non-anonymous double-check is all that is really necessary (and if the DC doesn't match, a non-anonymous triple-check, but you already harvest a lot of those)...why do we care whether or not Anonymous gets two shots at a doublecheck or not?

It was more an issue with first-time tests since anonymous workers would quite frequently keep working on assignments even after they'd expired. If the new assignment was another anonymous user, then both would often finish resulting in a first/second check by "anonymous".

For double-check assignments, that wasn't as big a deal as long as the first check wasn't an anon user, but even then it wasn't too odd to have cases where the first check was wrong and then the 2nd/3rd checks, both by anonymous users, became the matching pair. Not as common as that first scenario, but still, it happened.

George's solution to limit how exponents are excluded based on past assignment expirations will hopefully be sufficient, but maybe in terms of double-checks in particular it could be loosened up even more.

[chalsall]

Originally Posted by Madpoo

George's solution to limit how exponents are excluded based on past assignment expirations will hopefully be sufficient, but maybe in terms of double-checks in particular it could be loosened up even more.

I would argue that we need to error on the side of caution, to ensure the database is trusted.

At least one of the tests need to be done by a known, trusted, entity.

Two anonymous tests should not be trusted.

[Siegmund]

Yes, requiring one non-anonymous test is very sensible. I think we were only advocating removing the restriction in the case of DC assignments that already had a non-anonymous first test.

I don't actually know how commonly anonymous users request first-time checks, but I'd be fine with not allowing two consecutive anonymous assignments there.

[GP2]

Originally Posted by chalsall

I would argue that we need to error on the side of caution, to ensure the database is trusted.

At least one of the tests need to be done by a known, trusted, entity.

Two anonymous tests should not be trusted.

I always thought that the keepers of the database have additional non-public information at their disposal, like the ComputerGUID. Doesn't any of that help to distinguish among the various Anonymii? And the shift count helps guard against accidental duplications of the same result.

Sometimes MadPoo publishes list of strategic double checks, where some of the exponents have first LL tests that were done by Anonymous. So presumably it's possible to track the stats of how many good results vs. how many bad results were returned by any machine. Regardless of whether a public username was declared, there's an internal ID.

Maybe the internal ID could be spoofed, but that's easy to do with the username too.

[Prime95]

Originally Posted by GP2

Doesn't any of that help to distinguish among the various Anonymii? And the shift count helps guard against accidental duplications of the same result.

The database accepts two results on the same exponent from any user including anonymous as long as the shift count is different. For me, that's good enough to declare an exponent double-checked. Madpoo has a higher standard - he wants a different user id as well.

Madpoo went back and triple-checked all exponents where the matching LL tests were done by the same user. We changed the reservation system to reduce the chance of such occurrences in the future.