OFFICIAL "SERVER PROBLEMS" THREAD - Page 155

kriesel · 2019-05-09, 18:51

Quote:

Originally Posted by SELROC

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

No, I've been running mfaktc on a dozen gpus for years, and this is a new occurrence. It looks like it may dog those specific exponents for me until they are deeply enough trial factored. (Hopefully not further up in bit level than that!)

2019-05-09, 19:08

Quote:

Originally Posted by kriesel

No, I've been running mfaktc on a dozen gpus for years, and this is a new occurrence. It looks like it may dog those specific exponents for me until they are deeply enough trial factored. (Hopefully not further up in bit level than that!)

Ok

I don't know mfaktc. With mfakto never had an issue, though I fetch/submit via mfloop.py

kriesel · 2019-05-10, 16:23

Quote:

Originally Posted by kriesel

It looks like it may dog those specific exponents for me until they are deeply enough trial factored. (Hopefully not further up in bit level than that!)

First, thanks to masser and SELROC for comments intended to be helpful.
Other manual reporting of tf is working ok for me. It's only specific exponents that show an issue. It appears to be related to a previous tf assignment expiration on them. I think this would be the case for mfaktc or mfakto, manual use of the web result reporting page or misfit or other reporting method.

Quote:

Originally Posted by masser

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.

Master of understatement there, masser.

It turns out the problem persists, even after the exponents have been taken above the bit level gpu72 recommends or primenet should be issuing. I hope someone can find the time to correct the results processing script for this issue to avoid future wasted too-high-bit-level trial factoring for all participants.

The relevant manual assignments before reporting the latest results:

Code:

Factor=1991E1D4EF6A1443E7C46167A966FFBA,93010733,75,76
Factor=A7D40822C6767282FDEE88489C9B8EB7,93010793,75,76
Factor=D243F3FD96E8D0104BA07EC4E54A2F33,93010829,75,76
Factor=3290E96380B548A47C71658E7CB169DE,93010867,75,76
Factor=4A3142F28040A46BE263DC6F002DADF2,93010903,75,76
Factor=D3F64D656CC6683BCF90929201E22C22,93010949,75,76
Factor=EAD2D6EDCCDBE6F661D01529058A0C92,93010991,75,76
Factor=76084F128113E1B8EF066BF5F6D2C0EA,93010993,75,76
Factor=B3914EF7593608104BA805173B318F49,93011111,75,76
Factor=9F88029B2DC0D722C40451210E87C3B5,93011189,75,76
Factor=E61F5C4623AD0B5DACA114FF70B463E5,93011197,75,76
Factor=F290F28CF11C8CF7FF43AD082F695914,93011227,74,75
Factor=307E7A6DB4717487AB1461A70FD0E7D6,93011257,74,75
Factor=A97CAC5D8421CBAA292689DEB25815B6,93011297,74,75
Factor=52C5677A2C035EDF089104646DD53C3F,93011311,74,75
Factor=41900F9267BAC0CF99CFE7AC28867432,93011341,74,75
Factor=1C78EA56966BC0BB7655B365B86D1E3A,93011351,74,75
Factor=2641B4A0F3314C9B94A8E67782BE99B7,93011419,74,75
Factor=EA65F4B08C92FB2FE5A0974E38C21827,93011459,74,75
Factor=556D5A147F268819672EEB14FB59103B,93011507,74,75

Result of reporting those results:

Code:

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 82.2710 GHz-days.
processing: TF no-factor for M93010793 (275-276)
Result type (4) inappropriate for the assignment type (unknown). Processing result but not deleting assignment.
CPU credit is 82.2709 GHz-days.
processing: TF no-factor for M93010829 (2⁷⁵-2⁷⁶)
Result type (4) inappropriate for the assignment type (unknown). Processing result but not deleting assignment.
CPU credit is 82.2709 GHz-days.
processing: TF no-factor for M93010867 (275-276)
Result type (4) inappropriate for the assignment type (unknown). Processing result but not deleting assignment.
CPU credit is 82.2709 GHz-days.
processing: TF no-factor for M93010903 (2⁷⁵-2⁷⁶)
Result type (4) inappropriate for the assignment type (unknown). Processing result but not deleting assignment.
CPU credit is 82.2708 GHz-days.
processing: TF no-factor for M93010949 (2⁷⁵-2⁷⁶)
Result type (4) inappropriate for the assignment type (unknown). Processing result but not deleting assignment.
CPU credit is 82.2708 GHz-days.
processing: TF no-factor for M93010991 (2⁷⁵-2⁷⁶)
Result type (4) inappropriate for the assignment type (unknown). Processing result but not deleting assignment.
CPU credit is 82.2708 GHz-days.
processing: TF no-factor for M93011227 (2⁷⁴-2⁷⁵)
Result type (4) inappropriate for the assignment type (unknown). Processing result but not deleting assignment.
CPU credit is 41.1353 GHz-days.
processing: TF no-factor for M93011257 (2⁷⁴-2⁷⁵)
Result type (4) inappropriate for the assignment type (unknown). Processing result but not deleting assignment.
CPU credit is 41.1353 GHz-days.
processing: TF no-factor for M93011297 (2⁷⁴-2⁷⁵)
Result type (4) inappropriate for the assignment type (unknown). Processing result but not deleting assignment.
CPU credit is 41.1352 GHz-days.
processing: TF no-factor for M93011311 (2⁷⁴-2⁷⁵)
Result type (4) inappropriate for the assignment type (unknown). Processing result but not deleting assignment.
CPU credit is 41.1352 GHz-days.
processing: TF no-factor for M93011341 (2⁷⁴-2⁷⁵)
Result type (4) inappropriate for the assignment type (unknown). Processing result but not deleting assignment.
CPU credit is 41.1352 GHz-days.
processing: TF no-factor for M93011351 (2⁷⁴-2⁷⁵)
Result type (4) inappropriate for the assignment type (unknown). Processing result but not deleting assignment.
CPU credit is 41.1352 GHz-days.
processing: TF no-factor for M93011419 (2⁷⁴-2⁷⁵)
Result type (4) inappropriate for the assignment type (unknown). Processing result but not deleting assignment.
CPU credit is 41.1352 GHz-days.
processing: TF no-factor for M93011459 (2⁷⁴-2⁷⁵)
Result type (4) inappropriate for the assignment type (unknown). Processing result but not deleting assignment.
CPU credit is 41.1352 GHz-days.
processing: TF no-factor for M93011507 (2⁷⁴-2⁷⁵)
Result type (4) inappropriate for the assignment type (unknown). Processing result but not deleting assignment.
CPU credit is 41.1352 GHz-days.

The relevant manual assignments after reporting the latest results, without making any new assignment reservations manually:

Code:

Factor=1991E1D4EF6A1443E7C46167A966FFBA,93010733,76,77
Factor=A7D40822C6767282FDEE88489C9B8EB7,93010793,76,77
Factor=D243F3FD96E8D0104BA07EC4E54A2F33,93010829,76,77
Factor=3290E96380B548A47C71658E7CB169DE,93010867,76,77
Factor=4A3142F28040A46BE263DC6F002DADF2,93010903,76,77
Factor=D3F64D656CC6683BCF90929201E22C22,93010949,76,77
Factor=EAD2D6EDCCDBE6F661D01529058A0C92,93010991,76,77
Factor=76084F128113E1B8EF066BF5F6D2C0EA,93010993,75,76
Factor=B3914EF7593608104BA805173B318F49,93011111,75,76
Factor=9F88029B2DC0D722C40451210E87C3B5,93011189,75,76
Factor=E61F5C4623AD0B5DACA114FF70B463E5,93011197,75,76
Factor=F290F28CF11C8CF7FF43AD082F695914,93011227,75,76
Factor=307E7A6DB4717487AB1461A70FD0E7D6,93011257,75,76
Factor=A97CAC5D8421CBAA292689DEB25815B6,93011297,75,76
Factor=52C5677A2C035EDF089104646DD53C3F,93011311,75,76
Factor=41900F9267BAC0CF99CFE7AC28867432,93011341,75,76
Factor=1C78EA56966BC0BB7655B365B86D1E3A,93011351,75,76
Factor=2641B4A0F3314C9B94A8E67782BE99B7,93011419,75,76
Factor=EA65F4B08C92FB2FE5A0974E38C21827,93011459,75,76
Factor=556D5A147F268819672EEB14FB59103B,93011507,75,76

Note that for each exponent, the AIDs are unchanged, but the bit levels starting and ending got incremented at the server. The mersenne.ca status page for the highest exponent in that list https://www.mersenne.ca/exponent/93011507 hasn't updated yet for today's results, but shows the target bit level is 75. Not 76 or 77.
So:

Code:

Unreserved 93,010,733
Unreserved 93,010,793
Unreserved 93,010,829
Unreserved 93,010,867
Unreserved 93,010,903
Unreserved 93,010,949
Unreserved 93,010,991
Unreserved 93,010,993
Unreserved 93,011,111
Unreserved 93,011,189
Unreserved 93,011,197
Unreserved 93,011,227
Unreserved 93,011,257
Unreserved 93,011,297
Unreserved 93,011,311
Unreserved 93,011,341
Unreserved 93,011,351
Unreserved 93,011,419
Unreserved 93,011,459
Unreserved 93,011,507

None of the listed AIDs are valid any more. They are included for possible use in examining what was happening at the primenet server.

kriesel · 2019-05-20, 14:31

In my logged on primenet workload / assignments pending page https://www.mersenne.org/workload/
under the system name that I set preferences to get PRP DC, and primenet earlier decided to treat a duly assigned PRP DC as a PRP first test until MadPoo intervened, it now lists

Code:

UNKNOWN WORKTYPE "151"

It's also listed that way under "All CPUs"
But in the first, initially sorted-by-exponent tabular section, it's correctly shown as PRP-DC. The exponent so afflicted is https://www.mersenne.org/report_expo...9335979&full=1 which had first tests of differing PRP residue type.
This was assigned per pre-set preference to a prime95 instance via the primenet API. (No manual assignment activity involved on this one.)

GP2 · 2019-05-20, 17:22

Quote:

Originally Posted by kriesel

it now lists

Code:

UNKNOWN WORKTYPE "151"

It's also listed that way under "All CPUs"

This is an old error, not the result of any recent change. PRP-DC assignments have never displayed correctly in the "All CPUs" section of https://www.mersenne.org/workload/ .

PhilF · 2019-05-20, 21:39

I just had a machine send a result to the server for 3 ECM curves completed, followed by a CURL timeout error. When the server was contacted again 70 minutes later, this time the data was resubmitted without error, but now the exponent has been credited with 6 curves instead of 3.

https://www.mersenne.org/report_expo...ll=1&ecmhist=1

Looking at the mprime log file, the resubmitted data was identical, including the AID, so it probably should have been silently rejected.

Madpoo · 2019-05-21, 03:52

Quote:

Originally Posted by PhilF

I just had a machine send a result to the server for 3 ECM curves completed, followed by a CURL timeout error. When the server was contacted again 70 minutes later, this time the data was resubmitted without error, but now the exponent has been credited with 6 curves instead of 3.

https://www.mersenne.org/report_expo...ll=1&ecmhist=1

Looking at the mprime log file, the resubmitted data was identical, including the AID, so it probably should have been silently rejected.

You'd think so, but it's not entirely uncommon for someone to keep running additional curves with the same assignment. Well, maybe it is uncommon, but people do it sometimes. Easier than getting another assignment just to run more.

Madpoo · 2019-05-21, 04:03

Quote:

Originally Posted by GP2

This is an old error, not the result of any recent change. PRP-DC assignments have never displayed correctly in the "All CPUs" section of https://www.mersenne.org/workload/ .

Oh... oversight.

Try it again. I don't know if a PRP doublecheck entry is any different than a first time test in the worktodo file so I just made it the same "PRP=blahblah" as a first-time check.

GP2 · 2019-05-21, 04:14

Quote:

Originally Posted by Madpoo

Oh... oversight.

Try it again. I don't know if a PRP doublecheck entry is any different than a first time test in the worktodo file so I just made it the same "PRP=blahblah" as a first-time check.

It probably ought to be PRPDC=blahblah now.

The same also applies for work type 161 = "Double-check PRP on Mersenne cofactors"

kriesel · 2019-05-21, 04:50

Quote:

Originally Posted by Madpoo

Oh... oversight.

Try it again. I don't know if a PRP doublecheck entry is any different than a first time test in the worktodo file so I just made it the same "PRP=blahblah" as a first-time check.

That's interesting.

This is a PRP DC delivered by the Primenet API;
PRP=(aid),1,2,79335979,-1,75,0,3,1 in the worktodo file,
PRP=(aid),1,2,79335979,-1,75,0,3,4 in the All cpus and system-specific listings on my assignments page

PRP first test assignments do not list a residue type in the worktodo line on the assignments page, ending in a comma.
PRP=(aid),1,2,exponent,-1,75,0,3,

PhilF · 2019-05-21, 12:10

Quote:

Originally Posted by Madpoo

You'd think so, but it's not entirely uncommon for someone to keep running additional curves with the same assignment. Well, maybe it is uncommon, but people do it sometimes. Easier than getting another assignment just to run more.

Well, maybe the date or time should be considered then, because there's a security hole there. People could start reporting curves run that really weren't run, increasing their Ghz/day standings. Not to mention the inaccuracy of the number of curves run per exponent.

2019-05-20, 14:31	#1698
kriesel "TF79LL86GIMPS96gpu17" Mar 2017 US midwest 7×1,051 Posts	In my logged on primenet workload / assignments pending page https://www.mersenne.org/workload/ under the system name that I set preferences to get PRP DC, and primenet earlier decided to treat a duly assigned PRP DC as a PRP first test until MadPoo intervened, it now lists Code: UNKNOWN WORKTYPE "151" It's also listed that way under "All CPUs" But in the first, initially sorted-by-exponent tabular section, it's correctly shown as PRP-DC. The exponent so afflicted is https://www.mersenne.org/report_expo...9335979&full=1 which had first tests of differing PRP residue type. This was assigned per pre-set preference to a prime95 instance via the primenet API. (No manual assignment activity involved on this one.)

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

2019-05-20, 21:39	#1700
PhilF "6800 descendent" Feb 2005 Colorado 1011100000₂ Posts	I just had a machine send a result to the server for 3 ECM curves completed, followed by a CURL timeout error. When the server was contacted again 70 minutes later, this time the data was resubmitted without error, but now the exponent has been credited with 6 curves instead of 3. https://www.mersenne.org/report_expo...ll=1&ecmhist=1 Looking at the mprime log file, the resubmitted data was identical, including the AID, so it probably should have been silently rejected.