[QUOTE=GP2;474038]It is mathematically impossible for two Mersenne numbers with prime exponents to share the same factor, so this would be the easiest way to prevent the problem from recurring.[/QUOTE]

Of course, it is not impossible (as far as we know) for a Mersenne number with prime exponent to have the same factor twice. However, finding any such non-square-free Mersenne number would generate headlines worldwide, because then we'd automatically have the third known Wieferich prime. The odds of this are surely astronomically low.

It's simple enough to test for non-squarefree-ness separately, over the entire database of factors, or at the time any factor is submitted, using standard modular exponentiation library functions, so this unlikely eventuality isn't a reason not to put a unique constraint or unique index on the factors column.

[QUOTE=GP2;473675]The Exponent Status report in text-only format is a bit garbled. It's missing a semicolon to separate the shift count from the residue type, and there is an extra semicolon at the end.

This is a recent change that seems to coincide with the switch from "CofactorPRP" to "PRPCofactor".[/QUOTE]

That's entirely my fault. I was moving some stuff around and got a little sloppy with cut/paste.

Plus, I'm noticing that the order of things isn't the same between PRP and PRP-cofactor and I feel like they should be consistent...

Right now, PRP has:
exponent, type, status, date, user, residue, residue-type, base, shift

However, for whatever reason I set PRP-CF to be:
exponent, type, status, date, user, residue, # of factors, shift, residue-type, base

In short, what was I thinking? I made PRP-CF match the way they're shown in the table, but I didn't update PRP at the same time I guess? I've been dealing with a bad bout of the flu and I probably did that during a feverish period. :smile:

I'll try to get that fixed and make more sense... hope it doesn't mess the parsing anyone already has but better to do it now.

[QUOTE=GP2;474047]One more thing related to [M]M2207441[/M], [M]M2233183[/M], [M]M2233019[/M] and any similar cases:[/QUOTE]

Yeah, those "bad" results with missing known_factors still need cleaning. I think I've fixed up what I could from the results data sent to me and now it's a matter of what to do with what's left.

I think I left off the PM threads with the idea of generating a list of the affected exponents with weird PRP-CF results and redo them while tossing the unusable results.

It's just one of those back-burnered things.

I am actually doing PRP-CF and PRP-CF-D.

Do you think I should stop until things are settled?

Luigi

[QUOTE=ET_;474088]I am actually doing PRP-CF and PRP-CF-D.

Do you think I should stop until things are settled?[/QUOTE]

As long as you are using prime95 29.4 build 5 you are in good shape.

[QUOTE=Prime95;474089]As long as you are using prime95 29.4 build 5 you are in good shape.[/QUOTE]

I am, of course :smile:

[QUOTE=ET_;474088]I am actually doing PRP-CF and PRP-CF-D.

Do you think I should stop until things are settled?

Luigi[/QUOTE]

Yeah, it was only an issue with older Prime95 versions that sent their PRP results to the server in a way that resulted in (sometimes) a missing list of known factors used during the test.

New versions (as George mentioned) will send the results fine.

I uploaded two results.txt files through the manual testing page. Among them there is the twin result from this exponent:

[CODE]Manual testing 22268579 F-PM1 2017-12-23 19:32 0.0 Factor: 752894280511036848897308855040509839552636123889 / (P-1, B1=350000, B2=7000000, E=6) 0.8378
Manual testing 22268579 F-PM1 2017-12-23 19:32 0.0 Factor: 752894280511036848897308855040509839552636123889 / (P-1, B1=350000, B2=7000000, E=6)[/CODE]

unlike the other three factors that were uploaded in the same batch this twin result does not show up in the 'Current Progress | Recent Cleared' list, not when sorted on date/time stamp and not when sorted on exponent.
They do however show up correctly in the 'My Account | Results' page and therefore are correctly inserted into the database. Seems to be a report problem.

Probably an artifact of the way composite factors are handled.

Composite factors will be broken into their prime component, but a side effect is that while the prime factors are recorded, the result log shows the original result text with the composite factor so the [url=https://www.mersenne.org/report_exponent/?exp_lo=22268579&full=1]exponent detail page[/url] apparently shows the composite factor recorded twice. This is just a display artifact.

What I can't readily explain is why neither the prime nor composite factors, nor indeed that exponent at all, are shown on the [url=https://www.mersenne.org/report_recent_cleared/]recent cleared report[/url].

I have an automatic PRP assignment that seems to have expired in error. The CPU is set to get PRP-100M automatically for one worker, which it did.

[URL="https://www.mersenne.org/report_exponent/?exp_lo=332291569&full=1"]https://www.mersenne.org/report_exponent/?exp_lo=332291569&full=1[/URL]

2017-12-28 Assigned
2018-01-10 P1 results returned
2018-01-10 Expired

It is still in my local work-to-do for the remaining PRP work.

[QUOTE=potonono;477195]I have an automatic PRP assignment that seems to have expired in error. The CPU is set to get PRP-100M automatically for one worker, which it did.

[URL="https://www.mersenne.org/report_exponent/?exp_lo=332291569&full=1"]https://www.mersenne.org/report_exponent/?exp_lo=332291569&full=1[/URL]

2017-12-28 Assigned
2018-01-10 P1 results returned
2018-01-10 Expired

It is still in my local work-to-do for the remaining PRP work.[/QUOTE]

Fixed. The P-1 result erroneously unassigned the exponent.

You should have the assignment back now.

It seems the first time checks category 0 threshold is stuck at 76737764 on the Assignment Rules page. This means there are only 10 category 0 LL assignments instead of 200.

Jacob

[QUOTE=S485122;477426]It seems the first time checks category 0 threshold is stuck at 76737764 on the Assignment Rules page. This means there are only 10 category 0 LL assignments instead of 200.

Jacob[/QUOTE]

I count 11. You are probably not counting my "hidden" cat 0 ([url=https://www.mersenne.org/M76722991]M76722991[/url])

[QUOTE=S485122;477426]It seems the first time checks category 0 threshold is stuck at 76737764 on the Assignment Rules page. This means there are only 10 category 0 LL assignments instead of 200.

Jacob[/QUOTE]

Fixed. The stored procedure was not recognizing exponents where a PRP result had been turned in.

I'm not sure why, but a user recently ran a PRP test (not a PRP cofactor test) on an already-factored small exponent: [M]M3,859,447[/M].

I think the server rejects LL residue results for already-factored exponents? If so, then probably the behavior should be consistent between LL results and PRP results.

PS,
The same user also ran a PRP test for a very similar exponent ([M]M3,859,477[/M]) which doesn't have known factors, but did already have two matching LL tests. Probably this type of result should be accepted by the server, as it was, but it's an unverified result that doesn't need verification, similar to those few exponents in the 75M range (like [M]M75,512,069[/M]) where we inadvertently ended up with two matching PRP tests and an unverified LL test. I presume the server already handles this situation and won't automatically assign a double-check on the superfluous test type?

On the page [URL="https://www.mersenne.org/report_recent_cleared/"]https://www.mersenne.org/report_recent_cleared/[/URL] the column 'Result' has been changed to include not just the result itself but also the method how it was obtained.

I have two suggestions.

A. Make the page wider, we now have only half the width of the screen in use and double lines because of the extra information not fitting in the cell.
B. Put the additional info on the method used in a separate cell so that automated use in spreadsheets and programs can use the results without having to undo the cell of the additional info.

In the [URL="https://www.mersenne.org/workload/"]Account Assignment Details page[/URL], in the bottom part where the worktodo.txt lines are displayed, the [c]ECM2=[/c] lines don't show the quoted list of comma-separated factors anymore.

Instead it just displays "1410" for ECM, and "1000" for Fermat exponents.

[QUOTE=GP2;477685]In the [URL="https://www.mersenne.org/workload/"]Account Assignment Details page[/URL], in the bottom part where the worktodo.txt lines are displayed, the [c]ECM2=[/c] lines don't show the quoted list of comma-separated factors anymore.

Instead it just displays "1410" for ECM, and "1000" for Fermat exponents.[/QUOTE]

Weird. I did adjust that page the other day to try and better list the PRP assignments. Not sure I got those quite right though, and you're really better off using the line from when you got the assignment originally.

I didn't do anything with any other assignment types though, so that's strange. I'll have to look back at previous versions of that page to see what else might have changed recently.

Actually, I just looked back at the past couple iterations of that page, going back quite a bit, and I don't see that it would have ever included known factors for ECM2. If it ever did, that would have been nice because I had to work a comma separated list of factors into a SQL query as a text string (a little FOR XML magic there).

On ecm_report page the number of curves are "already done", (it's going up as i observed). It would suggest, that the number of curves (280, 640, 1580...) are the maximum(optimal) for the current ECM "level". But e.g. at [URL="https://www.mersenne.org/report_ecm/?txt=0&ecm_lo=818339&ecm_hi=818339"]818339[/URL], it is still not flipped over to Done, and when requesting an assigment it still assigns one with lower bounds (250k).
So it's either the minimum requiment for stepping on to next level, or it should be count as completed (on that bound).

[QUOTE=thyw;477882]On ecm_report page the number of curves are "already done", (it's going up as i observed). It would suggest, that the number of curves (280, 640, 1580...) are the maximum(optimal) for the current ECM "level". But e.g. at [URL="https://www.mersenne.org/report_ecm/?txt=0&ecm_lo=818339&ecm_hi=818339"]818339[/URL], it is still not flipped over to Done, and when requesting an assigment it still assigns one with lower bounds (250k).
So it's either the minimum requiment for stepping on to next level, or it should be count as completed (on that bound).[/QUOTE]

My guess is a floating point roundoff issue. ECM curves done is stored as a float and converted to an integer for display. So, 639.7 might round up to display as 640 yet not satisfy the "if >= 640" to display "Done". Please watch as the next ECM curve completes.

Just today, LL residues were submitted for [M]M11[/M], [M]M23[/M] and various other tiny exponents.

These should have been rejected by the server, because these exponents are already factored, not to mention they're under 1 million.

To make matters worse, the residues submitted aren't even correct. For M11 it should be 00000000000006C8 and for M23 it should be 00000000005D32F7.

Independently of that, some other user also submitted PRP cofactor test results for these exponents, which are at least sort of useful, although kind of obvious.

[QUOTE=GP2;478289]Just today, LL residues were submitted for [M]M11[/M], [M]M23[/M] and various other tiny exponents.[/QUOTE]

Obviously, those were PRP residues rather than LL residues. Not sure how I failed to see that. So it's the same problem that was reported earlier.

I know it's slightly off topic, but how come the matching factors aren't shown on the results pages (i.e. 89 for M11 and178481for M23)?

[QUOTE=0PolarBearsHere;478319]I know it's slightly off topic, but how come the matching factors aren't shown on the results pages (i.e. 89 for M11 and178481for M23)?[/QUOTE]Because the mathematical convention to not show the largest factor outweighs all other practical and sensible alternatives? Because people are scared to go against conventions out of fear? Because we can't expect to be too lazy and should expect to compute the final factor ourselves?

[QUOTE=0PolarBearsHere;478319]I know it's slightly off topic, but how come the matching factors aren't shown on the results pages (i.e. 89 for M11 and178481for M23)?[/QUOTE]

Here's the [URL="http://www.mersenne.ca/prp.php"]list of all known Mersenne PRPs[/URL] (i.e., Mersenne numbers with prime exponent and either fully-factored or with a PRP cofactor).

There are 320 of them, and once you get past the small exponents, the cofactors rapidly get too large to display. For instance [M]M7080247[/M] has a 2,131,318-digit PRP cofactor.

So one way or another, there would have to be some cutoff point after which you don't display that cofactor. So the convention is simply to not display any of them, even the trivially small ones, because they are after all easily calculable.

[QUOTE=GP2;478333]Here's the [URL="http://www.mersenne.ca/prp.php"]list of all known Mersenne PRPs[/URL] ...
So the convention is simply to not display any of them, even the trivially small ones, because they are after all easily calculable.[/QUOTE]And on the above page, if you click the last-factor placeholder (e.g. "P-105") it will display the decimal representation of the actual factor, should you be so inclined.

[QUOTE=James Heinrich;478335]And on the above page, if you click the last-factor placeholder (e.g. "P-105") it will display the decimal representation of the actual factor, should you be so inclined.[/QUOTE]Only if JS is enabled.

I also don't understand that if the data is downloaded with the page anyway why not just display it without the extra steps of navigating the mouse cursor and pressing a button?

[QUOTE=retina;478336]Only if JS is enabled...[/QUOTE]

LOL... not that again. I mean, you also need a computer and power to run it, but you don't hear the Luddites complaining. :smile:

[QUOTE=Madpoo;478354]LOL... not that again. I mean, you also need a computer and power to run it, but you don't hear the Luddites complaining. :smile:[/QUOTE]Yup.[list][*]Electricity: Good[*]Computers: Good[*]Random code from random people: Not so good.[/list]

Actually there is nothing wrong with retinas's suggestion, to direct display of the cofactors if they meet some condition, for example if they "fit the screen" - I just checked and a c90 fits, but a c101 does not (it inserts an additional line, with a single digit on it, when clicked) - so most probably the field size will accommodate a c100. So, the cofactors smaller than a c100 should be displayed without the need of the additional mouse move and click, and the larger one still can be shown like Pxxx (please note there is no dash in the middle, I hate the dash, P-33 looks extremely strange for me, is that a prime with a negative number of digits, or what? And why you don't use dash for Mxxx, if the logic is so? Like say M-757 instead of M757...Grrr... Be constant man, NO DASHES! :rant:) possibly followed by a comment (like "click me!"), as long as there is no indication that the Pxxxx can be clicked...

And of course, if I was silly enough to click a Pxxxxxxxxxxxxx and my screen is filled with billions of meaningless numbers, needing hours of scroll up and down, there is no way to go back, without reloading the page, which takes time... Put a link to the expanded number too, to contract back when clicked... This way, it should be easier, cofactors smaller than c100 start expanded, larger start contracted. The user can flip each of them by clicking it.

hehe... (I know, we always want too much...)
(and don't tell me I can press the "end" and "home" keys on the keyboard, I know :razz:)

[QUOTE=LaurV;478397]* cofactors smaller than a c100 should be displayed
* NO DASHES! :rant:
* The user can flip each of them by clicking it
* if I was silly enough to click a Pxxxxxxxxxxxxx and my screen is filled[/QUOTE]These specific point have been addressed.

You are my man, I knew it!

It really looks much better now.

(Except for retina who can not run JS, hehe... in fact, I don't know if I am running JS either, I think newer browsers have newer tools, covering the same stuff, but more secure, but well, it is not my domain... I am happy with my Firefox).

A small observation tho: (you didn't believe you get out of it so easy, did you?)

When I hover the mouse over the "Pxxx", there is a small question mark getting attached to the tail of the mouse, making my mouse terrible shocked, he scratches itself with the left leg behind right ear, but to no avail, because neither the right click nor the left click does something with that question mark. We expected to click and/or see a help or a tool-tip, or something. It seems just a relic from some older design of the page?

The help-icon-cursor indicates that there's a tooltip available, if you hover over "Pxxx" for a second you should see the tooltip that says "definitely-prime cofactor with xxx decimal digits" (for "PRPyyy" it would replace "definitely" with "probably"). If you think it more annoying than intuitive I can remove the special cursor.

No, do not remove anything. It is totally fine, after a "hard refresh" of the page, the tooltips appear properly. There was no tooltip before, and I remembered I had troubles in the past with hard-refreshing your page. You told me in the past about it. After the right keys pressed, it works well.

We are good here. Thanks a lot.

The manual result interpreter is acting weird:
I reported 16 factors today, in the form of:

[code]
[Fri Feb 02 18:41:11 2018]
M24168631 has a factor: 410953947929229858623 [TF:68:69:mfaktc 0.21 barrett76_mul32_gs]
[Fri Feb 02 18:41:31 2018]
found 1 factor for M24168631 from 2^68 to 2^69 [mfaktc 0.21 barrett76_mul32_gs][/code]And it interprets the factor correctly, but the second line as no factor found :confused2:
Like [URL]https://www.mersenne.org/report_exponent/?exp_lo=24168631&exp_hi=&full=1[/URL]

These are the 16 exponents/factors that were affected:
[code]Manual testing 24203141 F 2018-02-03 22:48 0.0 Factor: 322306365944920950847 / TF: 68-69 0.3137
Manual testing 24199327 F 2018-02-03 22:48 0.0 Factor: 389340722021165530103 / TF: 68-69 0.9872
Manual testing 24196499 F 2018-02-03 22:48 0.0 Factor: 365270435103350185529 / TF: 68-69 0.7598
Manual testing 24196429 F 2018-02-03 22:48 0.0 Factor: 353847077266678602703 / TF: 68-69 0.6466
Manual testing 24194333 F 2018-02-03 22:48 0.0 Factor: 458347279139712572209 / TF: 68-69 1.5690
Manual testing 24193019 F 2018-02-03 22:48 0.0 Factor: 458990510147497392481 / TF: 68-69 1.5741
Manual testing 24191471 F 2018-02-03 22:48 0.0 Factor: 399696812142252603617 / TF: 68-69 1.0811
Manual testing 24190429 F 2018-02-03 22:48 0.0 Factor: 559897299892738650617 / TF: 68-69 2.2828
Manual testing 24186199 F 2018-02-03 22:48 0.0 Factor: 321309301728183128383 / TF: 68-69 0.3028
Manual testing 24184759 F 2018-02-03 22:48 0.0 Factor: 483223333502840065897 / TF: 68-69 1.7581
Manual testing 24183919 F 2018-02-03 22:48 0.0 Factor: 402050127300519458249 / TF: 68-69 1.1023
Manual testing 24181133 F 2018-02-03 22:48 0.0 Factor: 353824296758800018033 / TF: 68-69 0.6467
Manual testing 24171377 F 2018-02-03 22:48 0.0 Factor: 322419644723461498583 / TF: 68-69 0.3153
Manual testing 24170161 F 2018-02-03 22:48 0.0 Factor: 366937867134385016191 / TF: 68-69 0.7769
Manual testing 24169183 F 2018-02-03 22:47 0.0 Factor: 448904488441510170193 / TF: 68-69 1.4964
Manual testing 24168631 F 2018-02-03 22:47 0.0 Factor: 410953947929229858623 / TF: 68-69 1.1812[/code]

[QUOTE=VictordeHolland;479203]The manual result interpreter is acting weird:
I reported 16 factors today, in the form of:

[code]
[Fri Feb 02 18:41:11 2018]
M24168631 has a factor: 410953947929229858623 [TF:68:69:mfaktc 0.21 barrett76_mul32_gs]
[Fri Feb 02 18:41:31 2018]
found 1 factor for M24168631 from 2^68 to 2^69 [mfaktc 0.21 barrett76_mul32_gs][/code]And it interprets the factor correctly, but the second line as no factor found :confused2:
[/QUOTE]

What were your expectations? The manual results will parse each line as one result for one test (it ignores the date stamp lines).

The first line has an exponent, a factor, the other info about the bit range and program, all in a format that is parseable.

The 2nd line is meaningless... "found 1 factor for exponent ###" means nothing on it's own. What's the factor? Why are you telling me this? :smile: It sounds like whatever program generated that output decided to generate an extra line of useless text. Oh well.

[QUOTE=Madpoo;479222]The 2nd line is meaningless... "found 1 factor for exponent ###" means nothing on it's own. What's the factor? Why are you telling me this? :smile: It sounds like whatever program generated that output decided to generate an extra line of useless text. Oh well.[/QUOTE]It does tell you that the range from 2^68 to 2^69 was completed, so it is not entirely useless.

[QUOTE=Madpoo;479222]What were your expectations? The manual results will parse each line as one result for one test (it ignores the date stamp lines).

The first line has an exponent, a factor, the other info about the bit range and program, all in a format that is parseable.

The 2nd line is meaningless... "found 1 factor for exponent ###" means nothing on it's own. What's the factor? Why are you telling me this? :smile: It sounds like whatever program generated that output decided to generate an extra line of useless text. Oh well.[/QUOTE]

[QUOTE=retina;479223]It does tell you that the range from 2^68 to 2^69 was completed, so it is not entirely useless.[/QUOTE]

In particular: not only was this factor found, but it is definitively the [i]only[/i] factor in the range.

PrimeNet does track the distinction, or at least from my years-old memories of TFing it did...

[QUOTE=Madpoo;479222]It sounds like whatever program generated that output decided to generate an extra line of useless text.[/QUOTE]
If it creates problems with parsing (I haven't noticed this behaviour before), I'd better delete them.

Anybody know how I can stop MFAKTC v0.21 CUDA8.0 from writing the line:
"1 factor in range 2^x to 2^y" to the results.txt?

[QUOTE=Madpoo;479222]What were your expectations? The manual results will parse each line as one result for one test (it ignores the date stamp lines).[/QUOTE]Mostly true, but not entirely. For historical reasons, Prime95 output is full of multi-line output like this (factor on one line, summary on the next), and even worse with things like P-1 where it would list the bounds used on one line and then then factor by itself on the next line. ECM is even worse, splitting the details across three lines (curve/stage; sigma/b1/b2; factor). More recent versions of Prime95 have amended the has-a-factor line to include the relevant details on one line (at least for P-1).

[QUOTE=Madpoo;479222]The 2nd line is meaningless... "found 1 factor for exponent ###" means nothing on it's own. What's the factor? Why are you telling me this? :smile: It sounds like whatever program generated that output decided to generate an extra line of useless text. Oh well.[/QUOTE]This output is fairly universal, originally from Prime95 and later copied by mfakt*

I did make a change recently to the manual form to try and fix an issue where submitting a composite factor in a TF range would prevent it recognizing that TF had been completed across that range, but I have now reverted the change and will investigate further how to implement it better.

[QUOTE=VictordeHolland;479237]If it creates problems with parsing (I haven't noticed this behaviour before), I'd better delete them.
Anybody know how I can stop MFAKTC v0.21 CUDA8.0 from writing the line:
"1 factor in range 2^x to 2^y" to the results.txt?[/QUOTE]Please don't change anything, keep submitting your results as you always have, including those lines.

[QUOTE=James Heinrich;479268]but I have now reverted the change and will investigate further how to implement it better.[/QUOTE]I have updated the manual form to be more precise in what I was trying to accomplish: if a has-a-factor line is submitted where the range was completely tested (not just up to the point where the factor was found) then the bitlevel should be updated on the server (in case someone wants to continue checking for further factors at higher bitlevels). It should no longer give false no-factor-found warnings. Let me know if you run into any problems.

[QUOTE=James Heinrich;479283]I have updated the manual form to be more precise in what I was trying to accomplish: if a has-a-factor line is submitted where the range was completely tested (not just up to the point where the factor was found) then the bitlevel should be updated on the server (in case someone wants to continue checking for further factors at higher bitlevels). It should no longer give false no-factor-found warnings. Let me know if you run into any problems.[/QUOTE]

Thanks James. I guess it wasn't entirely useless in that greater context. I thought there was something like an asterisk on the main result line that indicated if factoring in the range continued even after the first factor was found. Maybe that's specific to a certain GPU program though.

[QUOTE=Madpoo;479303]Thanks James. I guess it wasn't entirely useless in that greater context. I thought there was something like an asterisk on the main result line that indicated if factoring in the range continued even after the first factor was found. Maybe that's specific to a certain GPU program though.[/QUOTE]

The asterisk indicates the TFing was ceased at the factor -- the range in which the factor exists is incomplete, when the asterisk exists. Otherwise, if the asterisk doesn't exist with the complete bit level result line, then the entire bit level was TFed (and didn't stop at the factor found).

[QUOTE=VictordeHolland;479237]If it creates problems with parsing (I haven't noticed this behaviour before), I'd better delete them.

Anybody know how I can stop MFAKTC v0.21 CUDA8.0 from writing the line:
"1 factor in range 2^x to 2^y" to the results.txt?[/QUOTE]

Please don't try to stop that. It's what communicates to the primenet server that a bit range for an exponent has been fully trial factored. There are many exponents that have recorded factoring efforts by several people. It's how the server limits wasteful duplication of effort. Take a look at [URL]https://www.mersenne.org/report_exponent/?exp_lo=77232917&exp_hi=&full=1[/URL] for an example. Although that example did not have a factor., some people find it useful or interesting to search for additional factors. See [URL]http://www.mersenne.ca/manyfactors.php[/URL]

However, if you are determined to suppress that line or stop immediately upon finding one factor, see StopAfterFactor in the ini file.

When submitting a factor in the result form of mersenne.org, it gives:
[CODE]Notice: Undefined variable: mfaktco in C:\inetpub\www\manual_result\default.php on line 285 Notice: Undefined variable: mfaktco in C:\inetpub\www\manual_result\default.php on line 286[/CODE]

[QUOTE=kruoli;479321]When submitting a factor in the result form of mersenne.org, it gives: "Undefined variable: mfaktco"[/QUOTE]Thanks, fixed.

[QUOTE=Madpoo;479303]I thought there was something like an asterisk on the main result line that indicated if factoring in the range continued even after the first factor was found. Maybe that's specific to a certain GPU program though.[/QUOTE]As Dubslow said, the asterisk indicates TF was stopped after finding the factor, absence of asterisk implies the bitrange was completed. This applies to mfaktc and mfakto since about 2011. The result line format was discussed on the forum somewhere, but I can't find the thread right now.

[QUOTE=James Heinrich;479337]As Dubslow said, the asterisk indicates TF was stopped after finding the factor, absence of asterisk implies the bitrange was completed. This applies to mfaktc and mfakto since about 2011. The result line format was discussed on the forum somewhere, but I can't find the thread right now.[/QUOTE]

Hmm... it's unfortunate that it's not the other way around, since a missing asterisk in any other program probably means it stopped after finding a factor (or the behavior is unknown). Oh well. :smile: Too late now. LOL

Ideally perhaps it should have been some flag to say that factoring stopped after the factor, and a different flag to say that the bitlevel was completed (and a lack of either flag would indicate status unknown), but it's not really a big problem since the new result line format was introduced with a certain version of mfaktc and mfakto, and only those programs use that particular result format, and so we can still be certain as to whether the bitlevel was completed or not. TF results from non-mfakt* programs (Prime95, etc) may be ambiguous as to whether the bitlevel was completed or not so we have to assume that it wasn't. These days I don't think it's a big deal since I presume the vast majority of TF is done with mfakt*

list of all known Mersenne PRPs - Quirk
 

[QUOTE=James Heinrich;478335]And on the above page, if you click the last-factor placeholder (e.g. "P-105") it will display the decimal representation of the actual factor, should you be so inclined.[/QUOTE]

A quirk - the 'hide decimal representation' seems to be displayed only up to [URL="http://www.mersenne.ca/exponent/3464473"]M3,464,473[/URL], but beyond that ([URL="http://www.mersenne.ca/exponent/4187251"]M4,187,251[/URL] and up), the 'hide decimal representation' link disappears once the decimal representation appears...

(In Firefox 57.0.3 64-bit at least)

[QUOTE=Syntony;479403]A quirk - the 'hide decimal representation' seems to be displayed only up to [URL="http://www.mersenne.ca/exponent/3464473"]M3,464,473[/URL], but beyond that ([URL="http://www.mersenne.ca/exponent/4187251"]M4,187,251[/URL] and up), the 'hide decimal representation' link disappears once the decimal representation appears... (In Firefox 57.0.3 64-bit at least)[/QUOTE]My Firefox is v58.0.1 64-bit (on Windows 7) and everything appears to be working as expected.

[QUOTE=James Heinrich;479413]My Firefox is v58.0.1 64-bit (on Windows 7) and everything appears to be working as expected.[/QUOTE]

You're right James, seems to be a Firefox glitch - I should have checked for that :rolleyes:

The [url=https://www.mersenne.org/primenet/]hourly report[/url] shows two untested numbers in 49M range.

PrimeNet Activity Summary 2018-02-08 09:00 UTC[code] Exponent Range | Composite | Status Unproven | Assigned | Available |
Start Count P | F LL-D | LL LLERR NO-LL | TF P-1 LL LL-D | TF P-1 LL LL-D |
----------=-----=-- | -----=-----=-----=-----=----- | -----=-----=-----=----- | -----=-----=-----=----- |
49000000 56603 | 36470 4221 15910 [color=red][b]2[/b][/color] | 400 11094 | 4416 |[/code]How did that happen?

[QUOTE=retina;479607]The [url=https://www.mersenne.org/primenet/]hourly report[/url] shows two untested numbers in 49M range.

PrimeNet Activity Summary 2018-02-08 09:00 UTC[code] Exponent Range | Composite | Status Unproven | Assigned | Available |
Start Count P | F LL-D | LL LLERR NO-LL | TF P-1 LL LL-D | TF P-1 LL LL-D |
----------=-----=-- | -----=-----=-----=-----=----- | -----=-----=-----=----- | -----=-----=-----=----- |
49000000 56603 | 36470 4221 15910 [color=red][b]2[/b][/color] | 400 11094 | 4416 |[/code]How did that happen?[/QUOTE]

That's weird. They're not there now... I wonder which 2 they were. Anything in that range that would have been marked "suspect" would have been re-tested long ago and that's the only thing I could think of off the top of my head.

Well, I guess put a pin in that and if it happens again we'll see what we can see.

The active assignment page has a problem : if one excludes double-check assignments the other type of assignments are excluded as well (TF, P-1...) See f.i. [url]https://www.mersenne.org/assignments/?exp_lo=46000000&exp_hi=47000000&exdchk=1[/url], 76 P-1 assignments should be shown and you see them if you uncheck the exclude double-checks..

Perhaps the PRP checks and double-checks could be made separate exclusion categories ?

Jacob

[QUOTE=Madpoo;479639]That's weird. They're not there now... I wonder which 2 they were.[/QUOTE]I don't know which two. I don't know of any way us mere mortals can find which exponents don't have any current assignment combined with no LL so I couldn't find which exponents they were.

[QUOTE=retina;479652]I don't know which two. I don't know of any way us mere mortals can find which exponents don't have any current assignment combined with no LL so I couldn't find which exponents they were.[/QUOTE]

I think it might be PRP assignments in those ranges being *prp* tested for the first time. I saw an unusual thing with the 49M range showing a first-time check, and I think that's what it was, someone doing a PRP check in there.

Yeah... the PRP tests are definitely causing some funny reporting results and it's more complicated when you consider that an exponent can be LL and PRP tested without any verification of either (which is a waste), or someone doing unnecessary PRP tests on verified exponents (?) or other funny situations. All of those are probably going to cause strange results.

The only option for any kind of quick fix is to have separate reports... one for LL, one for PRP, but that's not really going to be useful since we care about exponents and which are composite or prime. The method by which that is done shouldn't be important, but there's just a lot of work to get a new thing added to reports in some useful way that doesn't break things.

Bear with us... it'll be sorted out eventually but I know for me it's kind of a "spare time" thing since it's a non-critical thing. :smile:

[QUOTE=S485122;479648]The active assignment page has a problem : if one excludes double-check assignments the other type of assignments are excluded as well (TF, P-1...) See f.i. [url]https://www.mersenne.org/assignments/?exp_lo=46000000&exp_hi=47000000&exdchk=1[/url], 76 P-1 assignments should be shown and you see them if you uncheck the exclude double-checks..
...[/QUOTE]Funny thing is that the problem seems to occur only in the 40M to 50M range.

Jacob

[QUOTE=S485122;480168]Funny thing is that the problem seems to occur only in the 40M to 50M range.

Jacob[/QUOTE]

I dunno... right now it's showing an "LL" assignment in the 60e6 - 61e6 range, and that's because of this PRP assignment someone decided to do:
[URL="www.mersenne.org/M60004433"]M60004433[/URL]

I don't know why someone did a first PRP check and then someone doing a second one, when there was already a first-time LL done and waiting to be verified, but... whatever. :smile:

In a sense, it could be argued that, yes, that exponent is currently assigned for a first-time check. A first time *PRP* check. So the report is correct.

[QUOTE=S485122;480168]Funny thing is that the problem seems to occur only in the 40M to 50M range.
Jacob[/QUOTE][QUOTE=Madpoo;480248]...
In a sense, it could be argued that, yes, that exponent is currently assigned for a first-time check. A first time *PRP* check. So the report is correct.[/QUOTE]I was speaking about another problem : when one looks at the active assignments in 40M range, the TF, PM-1 assignments will only be shown if one does NOT exclude the double-checks.
[url]https://www.mersenne.org/assignments/?exp_lo=46751053&exp_hi=47000000&exdchk=1[/url] : about 150 P-1 assignments (at the time of writing) should be shown, but you see them only if you uncheck the exclude double-checks [url]https://www.mersenne.org/assignments/?exp_lo=46751053&exp_hi=47000000[/url].

Jacob

[QUOTE=Madpoo;480248]I don't know why someone did a first PRP check and then someone doing a second one, when there was already a first-time LL done and waiting to be verified, but... whatever. :smile:[/QUOTE]

I don't know why someone did the first PRP test, but the double check is assigned automatically if you have the PRP-DC work type ([c]WorkPreference=151[/c]) set in prime.txt

The wavefront of PRP double checks is in the 76M range, so anything smaller will get automatically assigned right away.

PrimeNet Activity Summary 2018-03-01 23:00 UTC
 

And again:

[code] Exponent Range | Composite | Status Unproven | Assigned | Available |
Start Count P | F LL-D | LL LLERR NO-LL | ECM P-1 LL LL-D | ECM P-1 LL LL-D |
----------=-----=-- | -----=-----=-----=-----=----- | -----=-----=-----=----- | -----=-----=-----=----- |
8000000 62712 | 41151 21560 [color=red][b]1[/b][/color] | | 21560 |[/code]

Just for fun I did P-1 work on an exponent that apparently had no previous p-1 work being done on. A number of factors had been found during trial factoring in an early stage. The server does seem to ignore any P-1 work having been done and reported because no new factor was reported.

Can it be changed so that if any P-1 work (higher B1/B2 limits) are reported they are stored on the server?


[CODE]
[Work thread Mar 17 21:15] P-1 found a factor in stage #2, B1=400000, B2=8000000, E=6.
[Work thread Mar 17 21:15] M22351237 has a factor: 288476702225081262023002950746197048091558084285203081 (P-1, B1=400000, B2=8000000, E=6)
[Comm thread Mar 17 21:15] Sending result to server: UID: Tha/Riet-Ubuntu, M22351237 has a factor: 288476702225081262023002950746197048091558084285203081 (P-1, B1=400000, B2=8000000, E=6)

[Comm thread Mar 17 21:15] PrimeNet error 40: No assignment
[Comm thread Mar 17 21:15] Factoring result for M22351237 was not needed
[/CODE]

I thought P-1 bounds were recorded in the full history: [url]https://www.mersenne.org/report_exponent/?exp_lo=22351237&exp_hi=&full=1[/url]
but apparently not.

If you put the known factors in the worktodo.txt entry and then submit a no-factors-found result, do the bounds then get recorded in the history?

I downloaded the latest version of mprime to do that test. I used the same installation as on all previous versions of mprime on a Ubuntu-stable OS
This is what came back:

[CODE]
P5K:~/Mersenne$ ls -l
totaal 34120
lrwxrwxrwx 1 riet riet 16 mrt 19 09:32 libgmp.so -> libgmp.so.10.3.2
lrwxrwxrwx 1 riet riet 16 mrt 19 09:32 libgmp.so.10 -> libgmp.so.10.3.2
-rwxr-xr-x 1 riet riet 545695 feb 9 23:40 libgmp.so.10.3.2
-rw-r--r-- 1 riet riet 2110 feb 9 23:40 license.txt
-rwxrwxr-x 1 riet riet 34259741 feb 9 23:40 mprime
-rw-r--r-- 1 riet riet 20019 feb 9 23:40 readme.txt
-rw-r--r-- 1 riet riet 6860 feb 9 23:40 stress.txt
-rw-r--r-- 1 riet riet 36601 feb 9 23:40 undoc.txt
-rw-r--r-- 1 riet riet 55153 feb 9 23:40 whatsnew.txt
P5K:~/Mersenne$
P5K:~/Mersenne$ ./mprime -m
bash: ./mprime: kan binair bestand [I][U]Verkeerd uitvoerbaar bestand[/U][/I] niet uitvoeren
P5K:~/Mersenne$

[/CODE]

The last line can be translated as:

bash: ./mprime: cannot execute binary file [I][U]Wrong executable file[/U][/I]

Please post output from: [code]
file mprime
file libgmp.so.10.3.2
uname -a
[/code]
It sounds as if you have a version of mprime compiled for a different CPU to the one in your system. The above commands will check if that's the problem.

Chris

What is the output of [CODE]lscpu | grep Arch[/CODE]?

I downloaded mprime for Linux 64 bit as were all previous versions on this machine.

[CODE]
P5K:~/Mersenne$ ls -l
totaal 34120
lrwxrwxrwx 1 riet riet 16 mrt 19 09:32 libgmp.so -> libgmp.so.10.3.2
lrwxrwxrwx 1 riet riet 16 mrt 19 09:32 libgmp.so.10 -> libgmp.so.10.3.2
-rwxr-xr-x 1 riet riet 545695 feb 9 23:40 libgmp.so.10.3.2
-rw-r--r-- 1 riet riet 2110 feb 9 23:40 license.txt
-rwxrwxr-x 1 riet riet 34259741 feb 9 23:40 mprime
-rw-r--r-- 1 riet riet 20019 feb 9 23:40 readme.txt
-rw-r--r-- 1 riet riet 6860 feb 9 23:40 stress.txt
-rw-r--r-- 1 riet riet 36601 feb 9 23:40 undoc.txt
-rw-r--r-- 1 riet riet 55153 feb 9 23:40 whatsnew.txt
P5K:~/Mersenne$ file mprime
mprime: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.9, not stripped
P5K:~/Mersenne$ file libgmp.so.10.3.2
libgmp.so.10.3.2: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
P5K:~/Mersenne$ uname -a
Linux P5K 4.4.0-116-generic #140-Ubuntu SMP Mon Feb 12 21:22:43 UTC 2018 i686 i686 i686 GNU/Linux
riet@Merlijn-P5K:~/Mersenne$

P5K:~/Mersenne$ lscpu | grep Arch
Architecture: i686



[/CODE]

You're running a 32-bit Linux installation, so the 64-bit binary won't work.

Looks like a 64 bit system to me, all previous mprime versions were also 64 bit on this machine:

[CODE]
P5K:~/Mersenne-oud$ lscpu
Architecture: i686
CPU-modus(sen): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Draden per kern: 1
Kern(en) per voet: 4
Socket(s): 1
Producent-ID: GenuineIntel
CPU-familie: 6
Model: 15
Model name: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
Stepping: 11
CPU-frequentie (MHz): 1596.000
CPU max MHz: 2394,0000
CPU min MHz: 1596,0000
BogoMIPS: 4811.10
Virtualisatie: VT-x
L1d-cache: 32K
L1i-cache: 32K
L2-cache: 4096K
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm retpoline tpr_shadow vnmi flexpriority dtherm

[/CODE]

[QUOTE=tha;482926]Looks like a 64 bit system to me, all previous mprime versions were also 64 bit on this machine:

[CODE]
P5K:~/Mersenne-oud$ lscpu
Architecture: i686
CPU-modus(sen): 32-bit, 64-bit
[/CODE][/QUOTE]

Your CPU is 64 bit, but your operating system (kernel, more specifically) is 32 bit. i686 is a 32 bit architecture. You can see "i686" in your previous console output as well.

For reference, a 64-bit installation will look like this:

[code]
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
[/code]

OK, thanks, this machine indeed did have a 32 bit OS installed.

So I added this line to worktodo.txt:

[CODE]Pminus1=N/A,1,2,22351237,-1,400000,9000000,134107423,1564586591,3889115239,6403852912871,55203442762393[/CODE]

Which results in:
[CODE]
[Work thread Mar 21 19:47] Insufficient memory to ever run stage 2.[/CODE]

Immediately followed by the same result it produced the previous time it worked on this exponent, including the previous B1,B2 settings.

There is plenty of memory to run P-1 on this exponent with this B1/B2 setting.

Any comments?

[QUOTE=tha;482995]Any comments?[/QUOTE]

How much memory can be addressed by a 32 bit OS?

Anywhere from <2GB to <4GB depending on the OS and application.

In Options/CPU you tell prime95 how much memory it can use

[QUOTE=Prime95;483001]In Options/CPU you tell prime95 how much memory it can use[/QUOTE]

Does Prime95 detect how much memory is available?

Thrashing is a pain.

[QUOTE=chalsall;483003]Does Prime95 detect how much memory is available?.[/QUOTE]

Yes. Setting available memory to more than 90% (I think, I need to look at the code) of physical memory cannot be done from the Windows GUI or mprime menus.

[QUOTE=Prime95;483005]Setting available memory to more than 90% (I think, I need to look at the code) of physical memory cannot be done from the Windows GUI or mprime menus.[/QUOTE]

Fuck me.

[QUOTE=chalsall;483006]Fuck me.[/QUOTE]
What is the problem?

[QUOTE=kladner;483010]What is the problem?[/QUOTE]

Perhaps a lack of medication?

[QUOTE=VBCurtis;483012]Perhaps a lack of medication?[/QUOTE]

You guys have no sense of homour.

mprime was set to use 2,5 GB of ram which is more than sufficient to run this exponent with this B1/B2 setting. Can someone try this on his/ her machine? Could it be that the known factors are used as settings that don't make sense? Or that the line in worktodo should be constructed differently?

[QUOTE=chalsall;483006]Fuck me.[/QUOTE]

That's what you get for using a text editor instead of those fancy new fangled "user interfaces" :razz:

[QUOTE=tha;483014]mprime was set to use 2,5 GB of ram which is more than sufficient to run this exponent with this B1/B2 setting. Can someone try this on his/ her machine? Could it be that the known factors are used as settings that don't make sense? Or that the line in worktodo should be constructed differently?[/QUOTE]
Your worktodo line looks fine. I didn't let it run to stage2 to see how much RAM it actually used. My [url=http://www.mersenne.ca/prob.php?exponent=22351237&b1=400000&b2=9000000]P-1 probably calculator said[/url] it [i]needs[/i] 186MB, [i]would like[/i] 555MB, and wouldn't use more than 4536MB even if it was available.

Running your worktodo as-is seemed to start fine:[code]Setting affinity to run worker on logical CPUs 2 (zero-based)
P-1 on M22351237 with B1=400000, B2=9000000
Using AVX FFT length 1152K, Pass1=384, Pass2=3K, clm=1
M22351237 stage 1 is 0.557385% complete.[/code]and restructured to a normal pick-its-own-bounds P-1 it picked:[code]Optimal P-1 factoring of M22351237 using up to 10000MB of memory.
Assuming no factors below 2^69 and 2 primality tests saved if a factor is found.
Optimal bounds are B1=215000, B2=3923750
Chance of finding a factor is an estimated 3.45%
Using AVX FFT length 1152K, Pass1=384, Pass2=3K, clm=1[/code]

[QUOTE=tha;483014]mprime was set to use 2,5 GB of ram which is more than sufficient to run this exponent with this B1/B2 setting. [/QUOTE]

Do you have different day and nighttime settings? Do you have a memory setting for that particular worker?

I had copied the file
[CODE]mM351237[/CODE]
to the new directory. That file contained the data from the previous run on that exponent with the B1=400000 and B2=8000000 setting and done with
[CODE]Linux,Prime95,v28.9,build 2[/CODE]

I renamed that file now so it will not be used in a new run. It started stage 1 correctly an I will watch it over the next hours.

Same result. It first found the existing factors in stage1. I then restarted the assignment with Stage1GCD=0 added to prime.txt file. It still comes back with [CODE]Insufficient memory to ever run stage 2.
Stage 2 GCD complete. Time: 40.764 sec.
[Work thread Mar 22 12:39] P-1 found a factor in stage #2, B1=400000, B2=400000.
[Work thread Mar 22 12:39] M22351237 has a factor: 288476702225081262023002950746197048091558084285203081 (P-1, B1=400000, B2=400000)
[/CODE]

These last setting B1=B2=400000 it generates itself every time.

So I now renamed the file mM351237 again and restarted the assignment with the Stage1GCD=0 setting before embarking on stage 1.

I have daytime and nighttime both set to 2560MB.

If setting a memory for a worker involves some kind of tweaking through the menu or in prime.txt than I would have remembered since this download and install took place yesterday.

Also does not result in a start of stage2. Removing the known factors is the only way to start stage2, even with B2=12000000. However, we wanted to start the line with the known factors in place, to test if the server will accept the higher B1/B2 bounds for inclusion in the data available on the exponent.

Known factors should be put in between quotation marks: ...,"known,factors"

[QUOTE=error;483061]Known factors should be put in between quotation marks: ...,"known,factors"[/QUOTE]

Yep, that works!

Now wait and see what the server will store once the client makes the report.

[QUOTE=James Heinrich;483018]Your worktodo line looks fine. I didn't let it run to stage2 to see how much RAM it actually used. My [url=http://www.mersenne.ca/prob.php?exponent=22351237&b1=400000&b2=9000000]P-1 probably calculator said[/url] it [i]needs[/i] 186MB, [i]would like[/i] 555MB, and wouldn't use more than 4536MB even if it was available.][/QUOTE]

I ran it on one of my machines, with 12GB of RAM available, with the requested parameters.

Found a factor after stage 1. Interestingly, these results we're reported by Primenet. I suspect this is because they are already known.

[CODE][Main thread Mar 21 19:40] Mersenne number primality test program version 29.4
[Main thread Mar 21 19:40] Optimizing for CPU architecture: Core i3/i5/i7, L2 cache size: 256 KB, L3 cache size: 6 MB
[Main thread Mar 21 19:40] Starting worker.
[Work thread Mar 21 19:40] Worker starting
[Work thread Mar 21 19:40] Setting affinity to run worker on CPU core #1
[Work thread Mar 21 19:40] P-1 on M22351237 with B1=400000, B2=9000000
[Work thread Mar 21 19:40] Using AVX FFT length 1152K, Pass1=384, Pass2=3K, clm=1, 4 threads
[Work thread Mar 21 19:40] Setting affinity to run helper thread 3 on CPU core #4
[Work thread Mar 21 19:40] Setting affinity to run helper thread 2 on CPU core #3
[Work thread Mar 21 19:40] Setting affinity to run helper thread 1 on CPU core #2
[Work thread Mar 21 19:41] M22351237 stage 1 is 1.73% complete. Time: 38.006 sec.
[Work thread Mar 21 19:41] M22351237 stage 1 is 3.46% complete. Time: 28.800 sec.
[Work thread Mar 21 19:42] M22351237 stage 1 is 5.19% complete. Time: 27.955 sec.
[Work thread Mar 21 19:42] M22351237 stage 1 is 6.92% complete. Time: 28.137 sec.
[Work thread Mar 21 19:43] M22351237 stage 1 is 8.66% complete. Time: 29.200 sec.
[Work thread Mar 21 19:43] M22351237 stage 1 is 10.39% complete. Time: 29.818 sec.
[Work thread Mar 21 19:44] M22351237 stage 1 is 12.12% complete. Time: 28.841 sec.
[Work thread Mar 21 19:44] M22351237 stage 1 is 13.85% complete. Time: 28.288 sec.
[Work thread Mar 21 19:45] M22351237 stage 1 is 15.59% complete. Time: 27.570 sec.
[Work thread Mar 21 19:45] M22351237 stage 1 is 17.32% complete. Time: 27.334 sec.
[Work thread Mar 21 19:45] M22351237 stage 1 is 19.05% complete. Time: 26.511 sec.
[Work thread Mar 21 19:46] M22351237 stage 1 is 20.78% complete. Time: 26.816 sec.
[Work thread Mar 21 19:46] M22351237 stage 1 is 22.52% complete. Time: 27.140 sec.
[Work thread Mar 21 19:47] M22351237 stage 1 is 24.25% complete. Time: 26.725 sec.
[Work thread Mar 21 19:47] M22351237 stage 1 is 25.98% complete. Time: 26.483 sec.
[Work thread Mar 21 19:48] M22351237 stage 1 is 27.71% complete. Time: 27.906 sec.
[Work thread Mar 21 19:48] M22351237 stage 1 is 29.44% complete. Time: 26.641 sec.
[Work thread Mar 21 19:49] M22351237 stage 1 is 31.18% complete. Time: 27.229 sec.
[Work thread Mar 21 19:49] M22351237 stage 1 is 32.91% complete. Time: 27.801 sec.
[Work thread Mar 21 19:50] M22351237 stage 1 is 34.64% complete. Time: 30.414 sec.
[Work thread Mar 21 19:50] M22351237 stage 1 is 36.37% complete. Time: 29.186 sec.
[Work thread Mar 21 19:50] M22351237 stage 1 is 38.11% complete. Time: 28.209 sec.
[Work thread Mar 21 19:51] M22351237 stage 1 is 39.84% complete. Time: 27.703 sec.
[Work thread Mar 21 19:51] M22351237 stage 1 is 41.57% complete. Time: 27.121 sec.
[Work thread Mar 21 19:52] M22351237 stage 1 is 43.30% complete. Time: 26.914 sec.
[Work thread Mar 21 19:52] M22351237 stage 1 is 45.04% complete. Time: 27.352 sec.
[Work thread Mar 21 19:53] M22351237 stage 1 is 46.77% complete. Time: 28.310 sec.
[Work thread Mar 21 19:53] M22351237 stage 1 is 48.50% complete. Time: 27.263 sec.
[Work thread Mar 21 19:54] M22351237 stage 1 is 50.23% complete. Time: 26.834 sec.
[Work thread Mar 21 19:54] M22351237 stage 1 is 51.96% complete. Time: 30.217 sec.
[Work thread Mar 21 19:55] M22351237 stage 1 is 53.70% complete. Time: 26.946 sec.
[Work thread Mar 21 19:55] M22351237 stage 1 is 55.43% complete. Time: 28.055 sec.
[Work thread Mar 21 19:56] M22351237 stage 1 is 57.16% complete. Time: 34.969 sec.
[Work thread Mar 21 19:56] M22351237 stage 1 is 58.89% complete. Time: 26.830 sec.
[Work thread Mar 21 19:57] M22351237 stage 1 is 60.63% complete. Time: 26.890 sec.
[Work thread Mar 21 19:57] M22351237 stage 1 is 62.36% complete. Time: 27.189 sec.
[Work thread Mar 21 19:58] M22351237 stage 1 is 64.09% complete. Time: 34.326 sec.
[Work thread Mar 21 19:58] M22351237 stage 1 is 65.82% complete. Time: 28.445 sec.
[Work thread Mar 21 19:59] M22351237 stage 1 is 67.56% complete. Time: 26.598 sec.
[Work thread Mar 21 19:59] M22351237 stage 1 is 69.29% complete. Time: 30.539 sec.
[Work thread Mar 21 20:00] M22351237 stage 1 is 71.02% complete. Time: 32.876 sec.
[Work thread Mar 21 20:00] M22351237 stage 1 is 72.75% complete. Time: 30.036 sec.
[Work thread Mar 21 20:01] M22351237 stage 1 is 74.49% complete. Time: 26.737 sec.
[Work thread Mar 21 20:01] M22351237 stage 1 is 76.22% complete. Time: 26.565 sec.
[Work thread Mar 21 20:01] M22351237 stage 1 is 77.95% complete. Time: 27.443 sec.
[Work thread Mar 21 20:02] M22351237 stage 1 is 79.68% complete. Time: 26.631 sec.
[Work thread Mar 21 20:02] M22351237 stage 1 is 81.41% complete. Time: 28.904 sec.
[Work thread Mar 21 20:03] M22351237 stage 1 is 83.15% complete. Time: 26.724 sec.
[Work thread Mar 21 20:03] M22351237 stage 1 is 84.88% complete. Time: 27.368 sec.
[Work thread Mar 21 20:04] M22351237 stage 1 is 86.61% complete. Time: 27.381 sec.
[Work thread Mar 21 20:04] M22351237 stage 1 is 88.34% complete. Time: 27.092 sec.
[Work thread Mar 21 20:05] M22351237 stage 1 is 90.08% complete. Time: 26.649 sec.
[Work thread Mar 21 20:05] M22351237 stage 1 is 91.81% complete. Time: 26.547 sec.
[Work thread Mar 21 20:05] M22351237 stage 1 is 93.54% complete. Time: 26.653 sec.
[Work thread Mar 21 20:06] M22351237 stage 1 is 95.27% complete. Time: 26.456 sec.
[Work thread Mar 21 20:06] M22351237 stage 1 is 97.01% complete. Time: 26.728 sec.
[Work thread Mar 21 20:07] M22351237 stage 1 is 98.74% complete. Time: 26.603 sec.
[Work thread Mar 21 20:07] M22351237 stage 1 complete. 1154518 transforms. Time: 1624.137 sec.
[Work thread Mar 21 20:07] Stage 1 GCD complete. Time: 7.497 sec.
[Work thread Mar 21 20:07] P-1 found a factor in stage #1, B1=400000.
[Work thread Mar 21 20:07] M22351237 has a factor: 288476702225081262023002950746197048091558084285203081 (P-1, B1=400000)
[Comm thread Mar 21 20:07] Sending result to server: UID: wabbit/burrow, M22351237 has a factor: 288476702225081262023002950746197048091558084285203081 (P-1, B1=400000)
[Comm thread Mar 21 20:07][/CODE]

The test completed without any new factors found. As far as I can see the new B1/B2 limits were not accepted by the server, either because the exponent was not reserved or for any other reason. What would be desired is the server accepting the new B1/B2 limits.

[CODE]
[Work thread Mar 22 20:44] Stage 2 GCD complete. Time: 41.600 sec.
[Work thread Mar 22 20:44] M22351237 completed P-1, B1=400000, B2=12000000, E=6, Wg2: 42FE55FE
[Comm thread Mar 22 20:44] Sending result to server: UID: Tha/Riet-Ubuntu, M22351237 completed P-1, B1=400000, B2=12000000, E=6, Wg2: 42FE55FE
[Comm thread Mar 22 20:44]
[Comm thread Mar 22 20:44] PrimeNet error 40: No assignment
[Comm thread Mar 22 20:44] P-1 result for M22351237 was not needed
[/CODE]

[QUOTE=tha;483083]What would be desired is the server accepting the new B1/B2 limits.[/QUOTE]

I suspect that if you had done the test with known factors in quotation marks, and it reported no factor, then the B1,B2 would at least show up in the history, even though Primenet gives no credit due to "result not needed".

Or at least that's the way I recall it used to work.

[QUOTE=GP2;483098]I suspect that if you had done the test with known factors in quotation marks,...[/QUOTE]

That is exactly what I was able to do during the last run.

[QUOTE=tha;483104]That is exactly what I was able to do during the last run.[/QUOTE]

The exact job I asked one of my machines to do was: [code]Pminus1=N/A,1,2,22351237,-1,400000,9000000,134107423,1564586591,3889115239,6403852912871,55203442762393[/code]

And it diligently refound some factors already known.