[QUOTE=Prime95;424458] So, I guess we dropped the cat 1 number too much. I'll adjust upward to 4000.[/QUOTE]
:tu:
We don't need more cats. Enforce the one we have. The system is working well. It may look "slow" looked at from the perspective of Aaron and Chris :razz: but we don't all have billions of cores, dogs to whet against one DC, so 10-20 days for us for a DC (including the queue in front of it) is quite ok.

Perhaps it is time to record the actual Category rule applied for an assignment (instead of doing a forensic reconstruction of what would have been the category)?

[QUOTE=Madpoo;424428]

Well, this one is *almost* cat 1... it was assigned back in April 2014 (not grandfathered) so I have no idea why it's not expired already... at least we can say that it wasn't cat 1 (or even cat 3) when it was assigned nearly 2 years ago.
[URL="http://www.mersenne.org/M67729117"]M67729117[/URL][/QUOTE]

Correction. This was not a grandfathered assignment. It was cat 4 at time of assignment.

However, like grandfathered assignments it will not expire until it becomes cat 1.

This will happen real soon now as I just updated cat 1 to the first 4000 exponents.

I don't see the change reflected on the thresholds page... perhaps the 3000 figure there needs to be adjusted separately?

[QUOTE=Prime95;424449]No they should not have expired.

I'm somewhat distressed. The whole point of the "Cat 1/2/3/4" overhaul was to eliminate or at least greatly reduce poaching because milestones would be making steady progress. Instead, it seems to have made people even more impatient.

Let's tweak the "cat" system, rather than embark on more poaching. To that end, I'm studying the cat 0 suggestions and using the number of recently expired assignments to improve our assignment strategy.[/QUOTE]

Mea culpa... I missed the clause where a cat 2 that moves into cat 1 doesn't inherit the native cat 1 expiration date.

[QUOTE=LaurV;424465]:tu:
We don't need more cats. Enforce the one we have. The system is working well. It may look "slow" looked at from the perspective of Aaron and Chris :razz: but we don't all have billions of cores, dogs to whet against one DC, so 10-20 days for us for a DC (including the queue in front of it) is quite ok.[/QUOTE]

Good points. Fortunately the cat 1 stuff also requires having less than 10 days in the work queue, to avoid that problem of getting a cat 1 and having it sit behind a couple weeks of other work before even starting. :smile:

[QUOTE=Mark Rose;424483]I don't see the change reflected on the thresholds page... perhaps the 3000 figure there needs to be adjusted separately?[/QUOTE]

It might not kick in until the next nightly job that changes the thresholds...

Let's say we tried an unofficial DC cat 0 that required a queue depth under 3 days and say 6 LL results per worker in the last 90 days. In other words, serious machines.

Would that really solve the angst exhibited by folks here? When they look at the lowest 100 assignments they will still see it littered with cat 1 assignments waiting for the 90 days to expire. Several will look obviously abandoned as the computer is 10-30 days overdue on a check in -- people will grumble. They will see dozens of exponents where the computer is highly-unlikely / unlikely / possibly-will / should-but-will-be-close chance to get to 100% before the deadline -- people will grumble.

Yes, once the 90-day expiration hits they know that it will be completed by the serious machines in just 10-15 days. But if we start the test without waiting for the 90 day expiration we won't even need to wait those 10-15 days......more grumbling.

The "Cat project" goal was to have steady progression on milestones and reduced incentive for poaching. In my opinion it is a success on the first goal and a failure in the second.

Thoughts? Should we go ahead with cat 0 anyway?

[QUOTE=axn;424474]Perhaps it is time to record the actual Category rule applied for an assignment (instead of doing a forensic reconstruction of what would have been the category)?[/QUOTE]

There is a SQL view that has that info. It shouldn't be hard to add it to the active assignments report.

What about making regular check-ins a requirement to keep an exponent that enters Cat 1? So any exponent in the Cat 1 range that hasn't checked in for a week gets expired.

People who disconnect their machines should probably be working on larger exponents.

I think one reason why a good number of assignments are not being completed on time is a lack of information given in a user's assignments page.

That page:
- gives no indication if an assignment has moved into the first category.
- gives no indication of what category an assignment has (the cat it was in when assigned)
- gives no indication of when it is expected to expire based upon current status

Of course it is possible for a user to figure these things out, but it can be awkward to do so. The page that shows category boundaries for a given date is not even accessible from the menus or have any other GUI support (as far as I know).

I think at a minimum, the assignments page should show the category of each assignment. If it's too time-consuming for the server to provide such information, then I would agree with axn's suggestion to record the cat value in the database directly. (There might be some issues with this if, for example, an assignment is poached. It may need to change from cat 1 LL to cat 4 DC, for instance, I think.)