OFFICIAL "SERVER PROBLEMS" THREAD - Page 191

VBCurtis · 2021-01-25, 05:05

Thank you!
One more thing- if you run curves at some B1 not on the Chart, the server converts the curves to whatever level is currently being counted. The conversion doesn't use fancy math: one curve at B1 = 100k is worth two at B1= 50k (supposing both use the same B2 to B1 ratio, like the standard 100x on Prime95 before the brand-new 30.4 version). A curve at B1 = 250k is worth five at B1 = 50k, etc. Simple ratio of B1s.

If you run B1's bigger than what is suggested, this works quite well as an tracker for equivalent work done. Users are discouraged from running B1s smaller than indicated on the ECM factoring page for their input of interest.

B2 values different than 100 * B1 (such as the newest Prime95 uses) are converted using fancier math to the "standard" curves.

lycorn · 2021-01-25, 10:28

This morning I found one of the tasks I ran overnight had been apparently submitted (automatically) twice. Specifically, looking at my Account Results Details page on Primenet server, I found this:

colab_S_1 3141443 NF-ECM 2021-01-25 09:26 0.0 7 curves, B1=50000, B2=6750000 0.9467
colab_S_1 3141443 NF-ECM 2021-01-25 09:10 0.5 7 curves, B1=50000, B2=6750000 0.9467

So, it would seem that the instance Colab_S_1 had done and submitted 7 curves at 09:10, and then another set of 7 curves for the same exponent 16 minutes later. This is obviously not possible, as this task takes ~ 1h50m.
Now what really baffles me is that the task ran between 07:37 and 09:26 AM, as per the mprime output. Then mprime reported it only once, at 09:26..A report of it being finished at 09:10 is absolutely out of whack, as it was still running at that time.
It´s the first time I spot such a thing and I have no clues as to what might have happened. On top of the minor inconvenience of having 7 curves logged that haven´t actually been run, this may indicate some problem in the logging process.
Any ideas?

lycorn · 2021-01-25, 14:53

Follow-up:

I´ve been digging in the results.txt for this particular colab instance, and found that all 6 ECM tasks that started and finished during the session lifetime (i.e. from 23:15 PM yesterday to 11:15 AM today) have had exactly the same behaviour: result sent to the server, and within 15 to 20 minutes another message is sent, with the same data, hence resulting in two results, of which only the first one is meaningful. Upon the session expiration I reconnected to GCE and started a fresh instance of the same notebook. The problem appears to have gone.

That´s something that was somehow connected to that particular combination of notebook / server where it was being run. I have been running this notebook for a long time and never had a single problem.

Funny...

So it´s certainly not a problem on the server side. Any moderator may wish to remove the posts from this thread. Sorry for any inconvenience.

retina · 2021-02-11, 03:30

Quote:

Originally Posted by retina

Quote:

Originally Posted by retina

Code:

----------=-----=-- | -----=-----=-----=-----=----- | -----=-----=-----=----- | -----=-----=-----=----- |
  Exponent Range    | Composite  | Status Unproven  |        Assigned         |        Available        |
   Start   Count  P |   F    DC  |LL/PRP  ERR NO-LL |  ECM   P-1  LL/PRP  DC  |  ECM   P-1  LL/PRP  DC  |
----------=-----=-- | -----=-----=-----=-----=----- | -----=-----=-----=----- | -----=-----=-----=----- |
         0 78498 33 | 63187 15278                   |  6439                   | 15278                   |
   1000000 70435  2 | 52798 17635                   |   750          27       | 17634                   |
   2000000 67883  1 | 48797 19085                   |  1778          14       | 19085                   |
   3000000 66330  1 | 45820 20510                   |   687           6       | 20509                   |
   4000000 65367    | 44709 20659                   |     1           5       | 20658                   |
   5000000 64336    | 43740 20596                   |                18       | 20596                   |
   6000000 63799  1 | 43013 20786                   |     1           7       | 20785                   |
   7000000 63129    | 42279 20851                   |     1         291       | 20850                   |
   8000000 62712    | 41657 21055                   |    28     2   336       | 21053                   |
   9000000 62090    | 40929 21161                   |     4    51   671     9 | 21110                   |
  10000000 61938    | 40933 21007           1       |     2         570       | 21005                   |

Is the DB corrupted?

This problem still exists. It has expanded into other parts of the DB.

Code:

----------=-----=-- | -----=-----=-----=-----=----- | -----=-----=-----=----- | -----=-----=-----=----- |
  Exponent Range    | Composite  | Status Unproven  |        Assigned         |        Available        |
   Start   Count  P |   F    DC  |LL/PRP  ERR NO-LL |  TF    P-1  LL/PRP  DC  |  TF    P-1  LL/PRP  DC  |
----------=-----=-- | -----=-----=-----=-----=----- | -----=-----=-----=----- | -----=-----=-----=----- |
 100000000 54208    | 35166 15704  3338             |                      32 |                    3302 |

Adding the assigned and available 3302 + 32 != 3338

This problem is slowly but surely eating up the DB. Soon there will be no valid figures available.

Code:

----------=-----=-- | -----=-----=-----=-----=----- | -----=-----=-----=----- | -----=-----=-----=----- |
  Exponent Range    | Composite  | Status Unproven  |        Assigned         |        Available        |
   Start   Count  P |   F    DC  |LL/PRP  ERR NO-LL |  TF    P-1  LL/PRP  DC  |  TF    P-1  LL/PRP  DC  |
----------=-----=-- | -----=-----=-----=-----=----- | -----=-----=-----=----- | -----=-----=-----=----- |
  54000000 55997    | 36535 19005   457             |                     439 |                      13 |

457 != 439 + 13

Viliam Furik · 2021-02-11, 11:02

Is it possible that the missing numbers are the exponents which have been completed, but not yet certified (or some other state which is related to the certification process)?

Uncwilly · 2021-02-11, 14:57

Quote:

Originally Posted by Viliam Furik

Is it possible that the missing numbers are the exponents which have been completed, but not yet certified (or some other state which is related to the certification process)?

Nothing is getting a cert down in the 54M range

section31 · 2021-02-11, 15:11

My AMD Athlon 64 3700+ is set to "Whatever makes the most sense" for its assignments, and it recently was assigned a category 4 PRP, which would seem to be way out of its ability to return before the assignment expires; it's over 400 days. The rules say "Assignments are recycled ... when the exponent moves midway into the first category and the assignment is more than 360 days old." I guess I have no way of knowing if that will happen or not.

Should I manually unreserve this exponent?
Should I set this machine to only ask for DDs? This is its first PRP after doing mostly DD and CERTS since I set it to "Whatever makes the most sense".
Is this even worth worrying about?

Prime95 · 2021-02-11, 17:48

Quote:

Originally Posted by section31

Should I manually unreserve this exponent?
Should I set this machine to only ask for DDs?

I would not have the patience to wait 400 days for a result. I would unreserve it and ask for double-checks. You may do whatever makes you happy.

I'll check the assignment code to give double-checks to lesser powered machines

Prime95 · 2021-02-15, 06:44

Quote:

Originally Posted by retina

This problem is slowly but surely eating up the DB. Soon there will be no valid figures available.

So I looked at the off-by-4 in the 100M - 101M range.
The four exponents are awaiting a proof to be uploaded. Thus, they aren't DCed, nor are they available for assignment. They are in limbo. Suggestions? Count them as assigned-for-PRP (though the PRP result was reported, technically the assignment is not complete). Lump them in with assigned DC (it not under active DC). A new column called "stalled"?

Edit: The server is currently configured to wait forever for a proof to be uploaded

retina · 2021-02-15, 06:58

Quote:

Originally Posted by Prime95

Count them as assigned-for-PRP (though the PRP result was reported, technically the assignment is not complete.

Yes, this.

And expire them as usual. No special treatment.

slandrum · 2021-02-15, 08:51

What about the off-by-5 in the 54M to 55M range? There are 5 more needing DC than are assigned DC currently, and none are available for DC.

2021-01-25, 14:53	#2093
lycorn Sep 2002 Oeiras, Portugal 5A8₁₆ Posts	Follow-up: I´ve been digging in the results.txt for this particular colab instance, and found that all 6 ECM tasks that started and finished during the session lifetime (i.e. from 23:15 PM yesterday to 11:15 AM today) have had exactly the same behaviour: result sent to the server, and within 15 to 20 minutes another message is sent, with the same data, hence resulting in two results, of which only the first one is meaningful. Upon the session expiration I reconnected to GCE and started a fresh instance of the same notebook. The problem appears to have gone. That´s something that was somehow connected to that particular combination of notebook / server where it was being run. I have been running this notebook for a long time and never had a single problem. Funny... So it´s certainly not a problem on the server side. Any moderator may wish to remove the posts from this thread. Sorry for any inconvenience. Last fiddled with by lycorn on 2021-01-25 at 14:56

2021-02-11, 15:11	#2097
section31 Dec 2015 Local Group 2³ Posts	My AMD Athlon 64 3700+ is set to "Whatever makes the most sense" for its assignments, and it recently was assigned a category 4 PRP, which would seem to be way out of its ability to return before the assignment expires; it's over 400 days. The rules say "Assignments are recycled ... when the exponent moves midway into the first category and the assignment is more than 360 days old." I guess I have no way of knowing if that will happen or not. Should I manually unreserve this exponent? Should I set this machine to only ask for DDs? This is its first PRP after doing mostly DD and CERTS since I set it to "Whatever makes the most sense". Is this even worth worrying about? Attached Thumbnails Last fiddled with by section31 on 2021-02-11 at 15:21 Reason: removed section of quoted rules not relevant to my question; added screenshot of machine's past results

2021-02-15, 08:51	#2101
slandrum Jan 2021 California 2·7 Posts	What about the off-by-5 in the 54M to 55M range? There are 5 more needing DC than are assigned DC currently, and none are available for DC. Last fiddled with by slandrum on 2021-02-15 at 08:56

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Official "Faits erronés dans de belles-lettres" thread	ewmayer	Lounge	39	2015-05-19 01:08
Official "all-Greek-to-me Fiction Literature and Cinema" Thread	ewmayer	Science & Technology	41	2014-04-16 11:54
Official "Lasciate ogne speranza" whinge-thread	cheesehead	Soap Box	56	2013-06-29 01:42
Official "Ernst is a deceiving bully and George is a meanie" thread	cheesehead	Soap Box	61	2013-06-11 04:30
Official "String copy Statement Considered Harmful" thread	Dubslow	Programming	19	2012-05-31 17:49

2021-01-25, 05:05	#2091
VBCurtis "Curtis" Feb 2005 Riverside, CA 3³×173 Posts	Thank you! One more thing- if you run curves at some B1 not on the Chart, the server converts the curves to whatever level is currently being counted. The conversion doesn't use fancy math: one curve at B1 = 100k is worth two at B1= 50k (supposing both use the same B2 to B1 ratio, like the standard 100x on Prime95 before the brand-new 30.4 version). A curve at B1 = 250k is worth five at B1 = 50k, etc. Simple ratio of B1s. If you run B1's bigger than what is suggested, this works quite well as an tracker for equivalent work done. Users are discouraged from running B1s smaller than indicated on the ECM factoring page for their input of interest. B2 values different than 100 * B1 (such as the newest Prime95 uses) are converted using fancier math to the "standard" curves.

2021-01-25, 10:28	#2092
lycorn Sep 2002 Oeiras, Portugal 2³·181 Posts	This morning I found one of the tasks I ran overnight had been apparently submitted (automatically) twice. Specifically, looking at my Account Results Details page on Primenet server, I found this: colab_S_1 3141443 NF-ECM 2021-01-25 09:26 0.0 7 curves, B1=50000, B2=6750000 0.9467 colab_S_1 3141443 NF-ECM 2021-01-25 09:10 0.5 7 curves, B1=50000, B2=6750000 0.9467 So, it would seem that the instance Colab_S_1 had done and submitted 7 curves at 09:10, and then another set of 7 curves for the same exponent 16 minutes later. This is obviously not possible, as this task takes ~ 1h50m. Now what really baffles me is that the task ran between 07:37 and 09:26 AM, as per the mprime output. Then mprime reported it only once, at 09:26..A report of it being finished at 09:10 is absolutely out of whack, as it was still running at that time. It´s the first time I spot such a thing and I have no clues as to what might have happened. On top of the minor inconvenience of having 7 curves logged that haven´t actually been run, this may indicate some problem in the logging process. Any ideas?

2021-02-11, 11:02	#2095
Viliam Furik "Viliam Furík" Jul 2018 Martin, Slovakia 13×29 Posts	Is it possible that the missing numbers are the exponents which have been completed, but not yet certified (or some other state which is related to the certification process)?