Register FAQ Search Today's Posts Mark Forums Read

2019-05-09, 18:51   #1695
kriesel

"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

7×601 Posts

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   #1696
SELROC

2·5·401 Posts

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

2019-05-10, 16:23   #1697
kriesel

"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

7×601 Posts

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=D3F64D656CC6683BCF90929201E22C22,93010949,75,76
Factor=76084F128113E1B8EF066BF5F6D2C0EA,93010993,75,76
Factor=B3914EF7593608104BA805173B318F49,93011111,75,76
Factor=9F88029B2DC0D722C40451210E87C3B5,93011189,75,76
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 (275-276)
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 (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 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 (275-276)
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 (275-276)
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 (275-276)
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 (274-275)
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 (274-275)
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 (274-275)
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 (274-275)
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 (274-275)
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 (274-275)
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 (274-275)
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 (274-275)
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 (274-275)
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=D3F64D656CC6683BCF90929201E22C22,93010949,76,77
Factor=76084F128113E1B8EF066BF5F6D2C0EA,93010993,75,76
Factor=B3914EF7593608104BA805173B318F49,93011111,75,76
Factor=9F88029B2DC0D722C40451210E87C3B5,93011189,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.

Last fiddled with by kriesel on 2019-05-10 at 16:29

 2019-05-20, 14:31 #1698 kriesel     "TF79LL86GIMPS96gpu17" Mar 2017 US midwest 7·601 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.)
2019-05-20, 17:22   #1699
GP2

Sep 2003

257910 Posts

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/ .

 2019-05-20, 21:39 #1700 PhilF     Feb 2005 Colorado 479 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.
2019-05-21, 03:52   #1701
Serpentine Vermin Jar

Jul 2014

23·409 Posts

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.

2019-05-21, 04:03   #1702
Serpentine Vermin Jar

Jul 2014

23·409 Posts

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.

2019-05-21, 04:14   #1703
GP2

Sep 2003

2,579 Posts

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"

Last fiddled with by GP2 on 2019-05-21 at 04:19

2019-05-21, 04:50   #1704
kriesel

"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

7·601 Posts

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,

2019-05-21, 12:10   #1705
PhilF

Feb 2005

479 Posts

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.

 Similar Threads Thread Thread Starter Forum Replies Last Post ewmayer Lounge 39 2015-05-19 01:08 ewmayer Science & Technology 41 2014-04-16 11:54 cheesehead Soap Box 56 2013-06-29 01:42 cheesehead Soap Box 61 2013-06-11 04:30 Dubslow Programming 19 2012-05-31 17:49

All times are UTC. The time now is 01:01.

Fri Aug 7 01:01:06 UTC 2020 up 20 days, 20:47, 1 user, load averages: 1.21, 1.32, 1.31