Expiration glitch?

PhilF · 2021-01-16, 17:10

I don't know if this is an issue or not. I submitted a manual result today, that the server apparently simultaneously expired then recorded the result:

https://www.mersenne.org/report_expo...5047507&full=1

The exponent was only 10 days old, so I don't understand what happened here or if it is indicative of a problem.

Viliam Furik · 2021-01-16, 17:25

I think that happens when you assign it for a registered CPU (i.e. with Prime95 or other) and turn in as a manual result. Is that your case?

PhilF · 2021-01-16, 17:27

Quote:

Originally Posted by Viliam Furik

I think that happens when you assign it for a registered CPU (i.e. with Prime95 or other) and turn in as a manual result. Is that your case?

No, this one was registered as a manual checkout, 10 days ago. Unless I screwed up somewhere.

EDIT: I did use Prime95 to upload the proof file, but I have been doing that for weeks now without issue.

Zenzoma · 2021-01-16, 18:06

I think something is wrong. I'm getting the same expiration error with manual TF's. I noticed this morning as I began turning manual results in. For me, it seems like if I reserved TF72-74 and a factor was found for 73, it accepts the 73 and records the 74 as an expiration.

Zenzoma · 2021-01-16, 18:41

There's more to it. It is showing me as still assigned to exponents that I uploaded results for:

https://www.mersenne.org/report_expo...0762849&full=1

Here's an example of the expiration problem. I was assigned 72-74. I uploaded a factor for 73 and now it says expired.

https://www.mersenne.org/report_expo...0766061&full=1

ixfd64 · 2021-01-17, 21:47

I'm not sure if this is a related issue, but some PRP results are still marked as unverified even when a matching result has been submitted. Example: https://mersenne.org/m94662011

slandrum · 2021-01-17, 22:37

Quote:

Originally Posted by ixfd64

I'm not sure if this is a related issue, but some PRP results are still marked as unverified even when a matching result has been submitted. Example: https://mersenne.org/m94662011

It looks verified on the link to me (there are two entries, the latest one is marked verified, the earlier one with the same residue is marked unverified). Perhaps someone corrected something.

Edit: If Show Full Details is checked, then it shows verified above the unverified result. If I uncheck that box, then it shows the unverified line above the verified line

LaurV · 2021-01-18, 02:55

Same here.

Prime95 · 2021-01-18, 03:31

Quote:

Originally Posted by ixfd64

I'm not sure if this is a related issue, but some PRP results are still marked as unverified even when a matching result has been submitted. Example: https://mersenne.org/m94662011

ATH's first PRP test did not have a proof. It can only be verified via a matching 64-bit residue. Although the second test provided the matching residue, it was calculated using the same program and thus does not qualify. So the first test remained unverified.

The certification came in marking the second test verified. Now I suppose one could reasonably argue that when the second test was marked verified the server could also mark any results with matching 64-bit residues verified. I must admit I did not envision this case when I wrote the server code.

Prime95 · 2021-01-18, 03:51

I found 23 examples:

1005359
10496897
77979053
94140619
94662011
101101493
108824453
104189453
107132983
139000019
108003647
100598731
101471189
108980089
100535509
108002893
106745269
109229633
106742219
108979987
109867859
100574711
102685769

2021-01-16, 17:10	#1
PhilF Feb 2005 Colorado 2×5×61 Posts	Expiration glitch? I don't know if this is an issue or not. I submitted a manual result today, that the server apparently simultaneously expired then recorded the result: https://www.mersenne.org/report_expo...5047507&full=1 The exponent was only 10 days old, so I don't understand what happened here or if it is indicative of a problem.

2021-01-16, 18:06	#4
Zenzoma Aug 2020 2×7 Posts	I think something is wrong. I'm getting the same expiration error with manual TF's. I noticed this morning as I began turning manual results in. For me, it seems like if I reserved TF72-74 and a factor was found for 73, it accepts the 73 and records the 74 as an expiration. Last fiddled with by Zenzoma on 2021-01-16 at 18:07

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Server Glitch?	Christenson	PrimeNet	2	2011-06-10 12:01
a glitch with the forum, my vision or my PC ?	science_man_88	Forum Feedback	7	2011-01-28 01:40
v5 glitch?	crash893	PrimeNet	0	2008-05-16 04:33
Assignment Glitch	Mr. P-1	PrimeNet	0	2007-09-10 17:43
Manual Check-in glitch	bayanne	Software	2	2003-12-10 13:38

2021-01-16, 17:25	#2
Viliam Furik "Viliam Furík" Jul 2018 Martin, Slovakia 443₁₀ Posts	I think that happens when you assign it for a registered CPU (i.e. with Prime95 or other) and turn in as a manual result. Is that your case?

2021-01-16, 18:41	#5
Zenzoma Aug 2020 1110₂ Posts	There's more to it. It is showing me as still assigned to exponents that I uploaded results for: https://www.mersenne.org/report_expo...0762849&full=1 Here's an example of the expiration problem. I was assigned 72-74. I uploaded a factor for 73 and now it says expired. https://www.mersenne.org/report_expo...0766061&full=1

2021-01-17, 21:47	#6
ixfd64 Bemusing Prompter "Danny" Dec 2002 California 2³·3³·11 Posts	I'm not sure if this is a related issue, but some PRP results are still marked as unverified even when a matching result has been submitted. Example: https://mersenne.org/m94662011

2021-01-18, 02:55	#8
LaurV Romulan Interpreter Jun 2011 Thailand 3³·347 Posts	Same here.

2021-01-18, 03:51	#10
Prime95 P90 years forever! Aug 2002 Yeehaw, FL 3²×823 Posts	I found 23 examples: 1005359 10496897 77979053 94140619 94662011 101101493 108824453 104189453 107132983 139000019 108003647 100598731 101471189 108980089 100535509 108002893 106745269 109229633 106742219 108979987 109867859 100574711 102685769