[QUOTE=SELROC;516220]May be that is what happens when manually wrestling with results.txt[/QUOTE]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!)

[QUOTE=kriesel;516282]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!)[/QUOTE]


Ok

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

[QUOTE=kriesel;516282]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!)[/QUOTE]
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=masser;516238]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. [U]The server doesn't appear to behave well in that case.[/U][/QUOTE]Master of understatement there, masser.

[B]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.[/B]

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[/CODE]Result of reporting those results:[CODE]processing: TF no-factor for M93010733 (2[SUP]75[/SUP]-2[SUP]76[/SUP])
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[SUP]75[/SUP]-2[SUP]76[/SUP])
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[SUP]75[/SUP]-2[SUP]76[/SUP])
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[SUP]75[/SUP]-2[SUP]76[/SUP])
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[SUP]75[/SUP]-2[SUP]76[/SUP])
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[SUP]74[/SUP]-2[SUP]75[/SUP])
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[SUP]74[/SUP]-2[SUP]75[/SUP])
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[SUP]74[/SUP]-2[SUP]75[/SUP])
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[SUP]74[/SUP]-2[SUP]75[/SUP])
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[SUP]74[/SUP]-2[SUP]75[/SUP])
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[SUP]74[/SUP]-2[SUP]75[/SUP])
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[SUP]74[/SUP]-2[SUP]75[/SUP])
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[SUP]74[/SUP]-2[SUP]75[/SUP])
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[SUP]74[/SUP]-2[SUP]75[/SUP])
Result type (4) inappropriate for the assignment type (unknown). Processing result but not deleting assignment.
CPU credit is 41.1352 GHz-days.[/CODE]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[/CODE]Note that for each exponent, [B]the AIDs are unchanged, but the bit levels starting and ending got incremented at the server[/B]. The mersenne.ca status page for the highest exponent in that list [URL]https://www.mersenne.ca/exponent/93011507[/URL] hasn't updated yet for today's results, but shows the target bit level is 75. Not 76 or 77.
So:[CODE]Unreserved [URL="https://www.mersenne.org/report_exponent/?exp_lo=93010733&full=1"]93,010,733[/URL]
Unreserved [URL="https://www.mersenne.org/report_exponent/?exp_lo=93010793&full=1"]93,010,793[/URL]
Unreserved [URL="https://www.mersenne.org/report_exponent/?exp_lo=93010829&full=1"]93,010,829[/URL]
Unreserved [URL="https://www.mersenne.org/report_exponent/?exp_lo=93010867&full=1"]93,010,867[/URL]
Unreserved [URL="https://www.mersenne.org/report_exponent/?exp_lo=93010903&full=1"]93,010,903[/URL]
Unreserved [URL="https://www.mersenne.org/report_exponent/?exp_lo=93010949&full=1"]93,010,949[/URL]
Unreserved [URL="https://www.mersenne.org/report_exponent/?exp_lo=93010991&full=1"]93,010,991[/URL]
Unreserved [URL="https://www.mersenne.org/report_exponent/?exp_lo=93010993&full=1"]93,010,993[/URL]
Unreserved [URL="https://www.mersenne.org/report_exponent/?exp_lo=93011111&full=1"]93,011,111[/URL]
Unreserved [URL="https://www.mersenne.org/report_exponent/?exp_lo=93011189&full=1"]93,011,189[/URL]
Unreserved [URL="https://www.mersenne.org/report_exponent/?exp_lo=93011197&full=1"]93,011,197[/URL]
Unreserved [URL="https://www.mersenne.org/report_exponent/?exp_lo=93011227&full=1"]93,011,227[/URL]
Unreserved [URL="https://www.mersenne.org/report_exponent/?exp_lo=93011257&full=1"]93,011,257[/URL]
Unreserved [URL="https://www.mersenne.org/report_exponent/?exp_lo=93011297&full=1"]93,011,297[/URL]
Unreserved [URL="https://www.mersenne.org/report_exponent/?exp_lo=93011311&full=1"]93,011,311[/URL]
Unreserved [URL="https://www.mersenne.org/report_exponent/?exp_lo=93011341&full=1"]93,011,341[/URL]
Unreserved [URL="https://www.mersenne.org/report_exponent/?exp_lo=93011351&full=1"]93,011,351[/URL]
Unreserved [URL="https://www.mersenne.org/report_exponent/?exp_lo=93011419&full=1"]93,011,419[/URL]
Unreserved [URL="https://www.mersenne.org/report_exponent/?exp_lo=93011459&full=1"]93,011,459[/URL]
Unreserved [URL="https://www.mersenne.org/report_exponent/?exp_lo=93011507&full=1"]93,011,507[/URL][/CODE]None of the listed AIDs are valid any more. They are included for possible use in examining what was happening at the primenet server.

In my logged on primenet workload / assignments pending page [url]https://www.mersenne.org/workload/[/url]
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"[/CODE]
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 [url]https://www.mersenne.org/report_exponent/?exp_lo=79335979&full=1[/url] 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.)

[QUOTE=kriesel;517260]it now lists [CODE]UNKNOWN WORKTYPE "151"[/CODE]
It's also listed that way under "All CPUs"
[/QUOTE]

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 [url]https://www.mersenne.org/workload/[/url] .

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.

[url]https://www.mersenne.org/report_exponent/?exp_lo=3429017&exp_hi=&full=1&ecmhist=1[/url]

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

[QUOTE=PhilF;517291]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.

[url]https://www.mersenne.org/report_exponent/?exp_lo=3429017&exp_hi=&full=1&ecmhist=1[/url]

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

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.

[QUOTE=GP2;517267]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 [url]https://www.mersenne.org/workload/[/url] .[/QUOTE]

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.

[QUOTE=Madpoo;517323]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.[/QUOTE]

It probably ought to be [c]PRPDC=blahblah[/c] now.

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

[QUOTE=Madpoo;517323]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.[/QUOTE]
That's interesting.

This is a PRP DC delivered by the Primenet API;
PRP=(aid),1,2,79335979,-1,75,0,3,[B]1[/B] in the worktodo file,
PRP=(aid),1,2,79335979,-1,75,0,3,[B]4[/B] 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,

[QUOTE=Madpoo;517322]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.[/QUOTE]

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.