OFFICIAL "SERVER PROBLEMS" THREAD

[ric]

This is the second time it happens in a couple of months, so it looks like one of those nasty annoyances quite hard to reproduce and fix (a race condition, maybe?).

• mprime64 v29.6.3 on a fully patched Ubuntu 16.04 derivative (Mint 18.2) - an old laptop used for low-candidates PRP-CF testing
• fully stopped, edited worktodo.txt to insert a few more candidates, all in the form

  PRP=1,2,cand,-1,"factor list"

• restarted, waiting for assignment registration at next communication
  
• 2 out of 3 new candidates get properly assigned as PRP testing
  
• one gets recorded as "factor ECM small" worktype on the server, but has the proper PRP=blahblah line in local worktodo
  
• in addition to being recorded as another worktype, it appears assigned on April 1st, and not today (M12760763) - a delayed April's Fools prank?
  
• relevant prime.log lines releted to the original communication are

  [Sat Apr 27 17:23:40 2019 - ver 29.6] <snip>
  Registering assignment: PRP M12760763
  Assignment registered as: <redacted>
  Sending expected completion date for M12760763: Apr 30 2019

This is just to leave track of an oddity: none of these points is more than a very small nuisance to me - last time I released the candidate and re-registered it a few moments later, with the same procedure, obtaining the expected type of assignment; today I'm inclined towards letting it run the way it is, and see what happens.

[Madpoo]

Originally Posted by ric

This is the second time it happens in a couple of months, so it looks like one of those nasty annoyances quite hard to reproduce and fix (a race condition, maybe?).

• mprime64 v29.6.3 on a fully patched Ubuntu 16.04 derivative (Mint 18.2) - an old laptop used for low-candidates PRP-CF testing
• fully stopped, edited worktodo.txt to insert a few more candidates, all in the form

  PRP=1,2,cand,-1,"factor list"

• restarted, waiting for assignment registration at next communication
  
• 2 out of 3 new candidates get properly assigned as PRP testing
  
• one gets recorded as "factor ECM small" worktype on the server, but has the proper PRP=blahblah line in local worktodo
  
• in addition to being recorded as another worktype, it appears assigned on April 1st, and not today (M12760763) - a delayed April's Fools prank?
  
• relevant prime.log lines releted to the original communication are

  [Sat Apr 27 17:23:40 2019 - ver 29.6] <snip>
  Registering assignment: PRP M12760763
  Assignment registered as: <redacted>
  Sending expected completion date for M12760763: Apr 30 2019

This is just to leave track of an oddity: none of these points is more than a very small nuisance to me - last time I released the candidate and re-registered it a few moments later, with the same procedure, obtaining the expected type of assignment; today I'm inclined towards letting it run the way it is, and see what happens.

Let me make sure I understand your process... when you want new assignments, you don't go to the manual assignments page to get them. Instead, you add the specific ones you want to your worktodo and then let the client connect and it assigns them to you that way? That will work fine in some (most?) cases, so, okay, I guess that's okay.

If I had to guess, the one that got "assigned" as ECM could have been assigned to someone else (either an active assignment, or one that had expired). When you came in saying "I want this assignment" it may have just reassigned an expired one to you, but since it was for ECM and not P-1 like you wanted, that's what shows up on the site. Sure, you went ahead and did P-1 and checked that in, but the assignment was for ECM and until you turn in an ECM result, that assignment will stay open. Or, go on the website and just manually expire that assignment.

Maybe you even had that assigned to you before and didn't know it?

Oh... I just remembered, I still have a backup of the primenet database mounted since I was looking something up. Well, what do you know. There was an ECM assignment for it, made on April 1, to the "anonymous" user account.

Apparently if something is assigned to an anonymous user, the site will happily reassign it to you if you come in and say "I want that particular exponent". It may only do that for ECM/P-1 and not for LL/PRP tests.

It does NOT change the type of assignment: it was an ECM previously and stayed an ECM assignment when it just changed the user to you.

I've seen other strange things with the anonymous user account... you can check in a result that was assigned to the anon user and I think it clears the anonymous assignment. For a first-time check, if you "poach" an assignment that belongs to another user, when you check your result in, that other assignment is auto converted to a double-check. But if it's assigned to the anonymous user, that doesn't happen and the actual assignment disappears.

Bug, or WAD, I'm not sure. The lesson for now is, don't do work on an exponent that's already assigned to someone else, especially if it's assigned to "-Anonymous-".

I'll see if that's a bug we need to fix or just one of the quirks that does it that way for a reason.

[retina]

What do the different anon names indicate? IIRC one is for unknown users, one is for known users who haven't entered a name, and the other is someone with a name they chose. Or is it something else entirely?

-Anonymous-
anonymous
ANONYMOUS

Could the pages be edited to change the colour; so all chosen user names are one colour, and the anon names generated by the server are a different colour?

[Madpoo]

Originally Posted by retina

What do the different anon names indicate? IIRC one is for unknown users, one is for known users who haven't entered a name, and the other is someone with a name they chose. Or is it something else entirely?

-Anonymous-
anonymous
ANONYMOUS

Could the pages be edited to change the colour; so all chosen user names are one colour, and the anon names generated by the server are a different colour?

If the user name shows as "-Anonymous-" that means it's someone who didn't bother creating their own account.

"anonymous" or "ANONYMOUS" or whatever else is when someone created an account but left their display name blank.

The no-account also used to show ANONYMOUS which was really confusing, so when I went through different reports I change that to the -Anonymous- display to help differentiate. It would probably be better to change that to "Unregistered" or something.

There's only one account like that, but there are a lot of users who didn't fill out a display name so it shows as ANONYMOUS. Nearly 1 in 4 accounts.

[ric]

Originally Posted by Madpoo

Apparently if something is assigned to an anonymous user, the site will happily reassign it to you if you come in and say "I want that particular exponent". It may only do that for ECM/P-1 and not for LL/PRP tests.

It does NOT change the type of assignment: it was an ECM previously and stayed an ECM assignment when it just changed the user to you.

Strange thing indeed: since I got an AID as a result of my reservation (and not an 'N/A', noticing me that the specific exponent was already taken), I considered it properly reserved.
Just out of curiosity, my PRP-CF will be finished in half a day - mainly to understand what happens to the original assignment when I return a different worktype.

[Madpoo]

Originally Posted by ric

Strange thing indeed: since I got an AID as a result of my reservation (and not an 'N/A', noticing me that the specific exponent was already taken), I considered it properly reserved.
Just out of curiosity, my PRP-CF will be finished in half a day - mainly to understand what happens to the original assignment when I return a different worktype.

Yeah, your assignment ID was the same one that the system "anonymous" account had. All it really did was change the user from that anonymous account to you, and that was it.

I spent a little more time looking at it, and it does seem like that can only ever happen for assignments to that system anonymous account (people who don't have a logon to the site). I know that certain aspects of that are on purpose, when checking in a result, but when getting assignments in that particular way, I didn't expect it to reassign from anonymous to some other user.

I guess that could be the case if someone starts Prime95 without creating a login, and then later they think "Hey, this is so fun, I'm going to create my own account" and when they reconfigure the client with their login, it takes any of their work and reassigns to their new user id.

I'm pretty sure that was the use case when it was designed, but it should probably match the work *type* and not just the exponent.

[Madpoo]

Thanks upfront to LookAS for being very patient with me while I looked into a problem with logging into the site...

As it turns out, when I modified the hashing method used for passwords on the site, I made a boneheaded mistake with the way case-sensitivity was used when looking at the user name being typed into the login box.

A portion of that login text is involved in the hashing, and of course people don't always maintain the correct case when typing their name into the login box. LOL

So, I fixed it and that should fix the handful of issues people had with logging in once I switched from the old hash to the new one.

[kriesel]

processing: TF no-factor for M93010733 (2⁷³-2⁷⁴)
Result type (4) inappropriate for the assignment type (unknown). Processing result but not deleting assignment.
CPU credit is 20.5677 GHz-days.

https://www.mersenne.org/report_exponent/?exp_lo=93010733&full=1

Expired, completed, and pending, all on the same exponent. possibly a difference in bit level?
There's a 74,75 assignment for the same exponent that did not clear, in my https://www.mersenne.org/workload/ but I have no record of having been assigned that. I have several more in this batch at 73,74 already submitted, and over a dozen to go.
(Primenet says I was assigned 74,75, work needed on the exponent was 73,74, content pasted into my worktodo.txt and separate tracking file says 73,74. Another example, next up, 93011111. Looks like primenet is bumping the bit level during result processing.)

[kriesel]

Originally Posted by kriesel

processing: TF no-factor for M93010733 (2⁷³-2⁷⁴)
Result type (4) inappropriate for the assignment type (unknown). Processing result but not deleting assignment.
CPU credit is 20.5677 GHz-days.

https://www.mersenne.org/report_exponent/?exp_lo=93010733&full=1

Expired, completed, and pending, all on the same exponent. possibly a difference in bit level?
There's a 74,75 assignment for the same exponent that did not clear, in my https://www.mersenne.org/workload/ but I have no record of having been assigned that. I have several more in this batch at 73,74 already submitted, and over a dozen to go.
(Primenet says I was assigned 74,75, work needed on the exponent was 73,74, content pasted into my worktodo.txt and separate tracking file says 73,74. Another example, next up, 93011111. Looks like primenet is bumping the bit level during result processing.)

Same thing happened with same range of exponents when reporting 74,75 results; 75,76 assignments found subsequently in my workload page, that I had no record of having reserved. Queued those up next. Made a note to capture before and after state of manual assignments tomorrow.

Originally Posted by kriesel

Same thing happened with same range of exponents when reporting 74,75 results; 75,76 assignments found subsequently in my workload page, that I had no record of having reserved. Queued those up next. Made a note to capture before and after state of manual assignments tomorrow.

May be that is what happens when manually wrestling with results.txt

[masser]

Originally Posted by kriesel

There's a 74,75 assignment for the same exponent that did not clear, in my https://www.mersenne.org/workload/ but I have no record of having been assigned that. I have several more in this batch at 73,74 already submitted, and over a dozen to go.[/COLOR]

Kriesel,

A similar thing happened to me, see post 1600 of this thread.

It appears that you allowed the exponent to expire and then submitted the result. The server doesn't appear to behave well in that case.