It's very definitely a Firefox v54 issue. At the time it was reported [url=http://mersenneforum.org/showpost.php?p=461329&postcount=560]I was still running FF53 and the page looked fine, updated to FF54 and the issue showed up[/url]. Does not affect any other browsers that I'm aware of. It's possibly the kind of thing that might fix itself in FF55 (because Mozilla broke something), or not (because Mozilla deprecated something).

[QUOTE=James Heinrich;461893]It's very definitely a Firefox v54 issue. At the time it was reported [URL="http://mersenneforum.org/showpost.php?p=461329&postcount=560"]I was still running FF53 and the page looked fine, updated to FF54 and the issue showed up[/URL]. Does not affect any other browsers that I'm aware of. It's possibly the kind of thing that might fix itself in FF55 (because Mozilla broke something), or not (because Mozilla deprecated something).[/QUOTE]

Mozilla likes doing updates. So, there will probably be an update before long. I've not seen it have issues on other web sites, but I only visit a few. Others on the web with different interests may have seen abnormal behavior from it, and reported it, I hope...

[QUOTE=storm5510;461919]Mozilla likes doing updates. So, there will probably be an update before long. I've not seen it have issues on other web sites, but I only visit a few. Others on the web with different interests may have seen abnormal behavior from it, and reported it, I hope...[/QUOTE]Mozilla will only correct this problem if they know about it and if it is indeed a problem with Mozilla, not with the pages themselves.

Jacob

[QUOTE=S485122;461935]Mozilla will only correct this problem if they know about it and if it is indeed a problem with Mozilla, not with the pages themselves.

Jacob[/QUOTE]

I need to get off my butt and get Firefox going and just test it out. Those menus are using a 3rd party set of CSS/js junk. I've tweaked it a bit but unless Firefox did something really strange I would have expected it to just keep on keeping on.

I used apycom.com for it... no particular reason except I didn't know what I was doing at the time and it seemed easy enough to create menus using that which also let non Javascript people (you know who you are) do stuff.

If it was bad enough I could put in the time/effort to do something else. I know, I know, some people will say the fancy menus aren't worth doing at all. They probably prefer text-based websites and still use Lynx, but whatever. :smile:

EDIT: Oooohhh... I just fired up Firefox 54 and the menus looked okay. You guys are talking about the sortable table headers and CSS styling going on there. Okay... that is weird. Now that I see what y'all are seeing, I can see why those colors that are being applied are bleeding to the rest of the page.

[QUOTE=Madpoo;462001]EDIT: Oooohhh... I just fired up Firefox 54 and the menus looked okay. You guys are talking about the sortable table headers and CSS styling going on there. Okay... that is weird. Now that I see what y'all are seeing, I can see why those colors that are being applied are bleeding to the rest of the page.[/QUOTE]

Okay, the problem comes down to a gradient being applied to the table head <thead> element.
[CODE] background:linear-gradient(to right, rgba(179,220,237,1) 0%,rgba(41,184,229,1) 50%,rgba(188,224,238,1) 100%);
background:-moz-linear-gradient(to right, rgba(179,220,237,1) 0%,rgba(41,184,229,1) 50%,rgba(188,224,238,1) 100%);
[/CODE]

Removing that from the CSS (both, including the Mozilla specific variant) fixes it. Firefox seems to ignore the -moz- variant anyway, using the CSS3 version. Oh good. I think when I implemented it (3 years ago?) it didn't? Can't recall.

For some reason the gradient is being applied well beyond the <thead>. How strange. I'm not entirely sure the gradient is applied at all, in any browser. Hmph. That's what I get for trying to be fancy... I wonder when that stopped working.

I guess I'll just remove those gradients... I don't think we'll miss them from the table header row.

So I'll be able to go back to v54 and shut up these frequent update reminders?

[QUOTE=kladner;462022]So I'll be able to go back to v54 and shut up these frequent update reminders?[/QUOTE]Go back to v3.6. You won't regret it. I guarantee it, or your money back..

:truck:

If you use FF, rollback to 53, and stay on 53 for now. There are other pages where 54 makes trouble (ex: sony.com, etc) and 53 works. I reported a couple of them, but it seems like Mozilla team knew about.

[QUOTE=LaurV;462024]If you use FF, rollback to 53, and stay on 53 for now. There are other pages where 54 makes trouble (ex: sony.com, etc) and 53 works. I reported a couple of them, but it seems like Mozilla team knew about.[/QUOTE]
Thanks!

[QUOTE=Madpoo;462012]...
I guess I'll just remove those gradients... I don't think we'll miss them from the table header row.[/QUOTE]Almost perfect now : the Reports / Exponent Status page still has that problem.

Thanks !

Jacob

[QUOTE=S485122;462028]Almost perfect now : the Reports / Exponent Status page still has that problem.

Thanks !

Jacob[/QUOTE]

I may have just fixed that... I had similar linear-gradients applied to <thead> in a different CSS so I removed those as well. I didn't check where / what those apply to so I can't say for sure it's fixed. :smile:

The page in question :
[url]https://www.mersenne.org/report_exponent/[/url]

The references to css on that page :
link href="/scripts/newstyle.css?v=20170625.1"
link type="text/css" href="/scripts/apy5/menu.css?v=20140927.1" rel="stylesheet"
link rel="stylesheet" href="/scripts/tablesorter/css/theme.blue.css?v=20170624.1"

I suppose that it is the last one that gives problems ?

Jacob

[QUOTE=S485122;462071]The page in question :
[url]https://www.mersenne.org/report_exponent/[/url]

The references to css on that page :
link href="/scripts/newstyle.css?v=20170625.1"
link type="text/css" href="/scripts/apy5/menu.css?v=20140927.1" rel="stylesheet"
link rel="stylesheet" href="/scripts/tablesorter/css/theme.blue.css?v=20170624.1"

I suppose that it is the last one that gives problems ?
[/QUOTE]

I finally got around to looking at it again (James had reminded me as well...)

It [I][B]should[/B][/I] be fixed now, fingers crossed.

At first I realized it was a problem with the linear-gradient applied to the table-head. While not strictly necessary, I kind of liked the pleasing shades of blue...personal preference. :smile:

I removed it from other spots but forgot that the exponent report was getting a similar styling from somewhere else... whoops.

So, after looking at it some more just now and inspecting in Firefox, I finally narrowed it down to the "background-attachment: fixed" style also applied to the <thead> element. Forgive the "too much detail" but maybe someone will be interested.

Anyway, everything I could find about how to properly set a linear-gradient on a table head says to set that to "fixed", so I did. However, Firefox 54 decided it would barf if that's set to anything but "local" so that's what I did.

I'd say I'm 60% positive it's a bug in Firefox 54... I can't think of any good reason why it would work in 53 (and all other browsers) and then in 54 it pukes unless the background-attachment is local ... it should be "fixed" to that table header row but somehow FF 54 is letting it "bleed" out to the rest of the page in unpredictable ways. The fact that the colors go entirely bananas when dropping down menus or just moving your mouse around tells me there's something seriously wrong in how FF is handling it, but whatever. LOL

So, like I said it should be fixed but if you continue to see any problems with it, let me know.

Whoops... I managed to mess up the Primenet server just now.

I was testing out setting up a virtual replica, but doing it over a WAN. The physical box didn't have enough space for the interim snapshots while the main vdisk was replicating. Argh. So it put Primenet into standby...

Sigh... I fixed that and now it'll be coming back up shortly. Lesson learned... if space is already low in a situation like that, don't even bother.

Server down?
 

[QUOTE=Madpoo;463889]Whoops... I managed to mess up the Primenet server just now.

I was testing out setting up a virtual replica, but doing it over a WAN. The physical box didn't have enough space for the interim snapshots while the main vdisk was replicating. Argh. So it put Primenet into standby...

Sigh... I fixed that and now it'll be coming back up shortly. Lesson learned... if space is already low in a situation like that, don't even bother.[/QUOTE]

Hi

[URL]https://www.mersenne.org/report_exponent/?exp_lo=43169743&exp_hi=&full=1[/URL] Fatal error: Maximum execution time of 300 seconds exceeded in C:\inetpub\www\report_exponent\default.php on line 250

Other pages are not currently loading. This started several minutes ago. Path to [URL="http://www.mersenne.org"]www.mersenne.org[/URL] traceroutes ok; other sites responsive. Not affecting [URL="http://www.mersenneforum.org"]www.mersenneforum.org[/URL].

That [url=https://www.mersenne.org/report_exponent/?exp_lo=43169743&exp_hi=&full=1=]page[/url] is loading fine (and quickly) here, for what it's worth.

back up
 

Excellent turnaround, appeared to be ~ 20 minutes total down time or less. Outage I saw started ~1150-1155; I sent email about it 1159 CDT, then found this forum thread and posted outage notice here at 1209. Retry showed back up ~1211.

Thanks Madpoo or whomever is responsible for that quick return to service.

Thanks James for checking.

[QUOTE=kriesel;464094]Excellent turnaround, appeared to be ~ 20 minutes total down time or less. Outage I saw started ~1150-1155; I sent email about it 1159 CDT, then found this forum thread and posted outage notice here at 1209. Retry showed back up ~1211.

Thanks Madpoo or whomever is responsible for that quick return to service.

Thanks James for checking.[/QUOTE]

FYI, I use Pingdom to monitor the site. It's a nice service, you get one free monitor or you can pay more to check additional pages.

Anyway, I didn't see any recent outages. It checks the home page though. You noted a problem with an exponent report page and a timeout. That could have been SQL being busy and your request timed out. I've seen that happen from time to time but I've never been able to nail down what other query could be going on at the same time and why it took so long or locked other queries, so we'll just have to keep an eye out for things like that.

Sorry for the brief server interruption. I had to make one final offline tweak to the settings on it. It'll be back up shortly.

Happy Birthday Server! :party:

[QUOTE=LaurV;465907]Happy Birthday Server! :party:[/QUOTE]

Backup server now :smile:

[QUOTE=henryzz;466184]Backup server now :smile:[/QUOTE]
Well.... :blush:

[url]https://mersenne.org/report_exponent/[/url]

[CODE]
Parse error: syntax error, unexpected '$num_known_factors' (T_VARIABLE) in C:\inetpub\v5\v5server\gimps\0.95_ar2_app.php on line 1085
[/CODE]

[QUOTE=GP2;467436][url]https://mersenne.org/report_exponent/[/url]

[CODE]
Parse error: syntax error, unexpected '$num_known_factors' (T_VARIABLE) in C:\inetpub\v5\v5server\gimps\0.95_ar2_app.php on line 1085
[/CODE][/QUOTE]

My bad. Should be fixed now.

Anyone else having trouble getting to mersenne.org
 

or just me?

[QUOTE=petrw1;467815]or just me?[/QUOTE]Okay for me.

[url]http://downforeveryoneorjustme.com/mersenne.org[/url]

Its back

The [url]https://mersenne.org/results[/url] page needs checkboxes for the new work types.

"Exclude PRP test results"
"Exclude PRP cofactor test results"
maybe Fermat too

I just got buried under an avalanche of thousands of those. It also caused the PrimeNet Most Recent Results report to get truncated, I think.

Same with
[url]https://mersenne.org/assignments/[/url]
[url]https://mersenne.org/tresults/[/url]

Maybe some new Detailed Reports are needed.

Wednesday, 3:10 PM UTC
[URL]https://www.mersenne.org/manual_result/[/URL] is displaying a plain white page with no content.

EDIT: Every other page I have tried at mersenne.org comes up normally.

EDIT2: The above is with Firefox. IE11 says [U]http 500 Internal Server Error[/U].

Investigating what I broke
edit: fixed typo, should work now.

[QUOTE=James Heinrich;468188]Investigating what I broke
edit: fixed typo, should work now.[/QUOTE]
All is back to normal. Thanks, James.

The exponent M59999 is one of those that has a two-line "known_factors" PRP output, due to having a long factor string.

If you accidentally manually report to mersenne.org only the second line, namely:

[CODE]
Known factors used for PRP test were: 4430446159,91756922012479,1438108281649159,614609832595742273
[/CODE]

then it will give you an error message about an email failure:

Done processing:
Warning: mail(): Failed to connect to mailserver at "127.0.0.1" port 25, verify your "SMTP" and "smtp_port" setting in php.ini or use ini_set() in C:\inetpub\www\manual_result\to_be_moved.inc.php on line 136 * Parsed 1 lines.

At the bottom, it will say "Did not understand 1 lines." and then echo the above "Known factors" line.


The first line of the two-line PRP output, which was omitted above, is:
[CODE]
UID: GP2/c4.xlarge, M59999/known_factors is not prime. RES64: E2B9C8D770E4A091. Wf8: F5DDFA60,00000000
[/CODE]

Attempting to manually report the two lines together gives the error:

processing: PRP=(false) for M[M]59999[/M]/4430446159/91756922012479/1438108281649159/614609832595742273
Error code: 40, error text: Another computer has already reported this PRP result for M59999

In this case, the other user has indeed self-triple checked the exponent, however all of these are "known_factors" entries without the list of exponents.

On a related note:

There are many cases where the user Oliver Kruse has automatically submitted a "known_factors" result (i.e., without the factor string). In these cases, the user still has an assignment pending for that same exponent.

In these cases, redoing the exponent in question and manually reporting it will often result in a successful double check, an additional entry in the History section with the full factor string, and the other user's pending assignment gets expired (it's now in red). See for instance [M]M1523[/M].

But there is a strange inconsistency, because sometimes Primenet will reject the manual report with a "another computer has already reported" error, even though the circumstances seem identical (the original report was just "known_factors", without the list of factors). In this case, no additional entry gets added to the History second, and the other user's pending assignment remains pending. See for instance [M]M1549[/M].

[QUOTE=GP2;469037]There are many cases where the user Oliver Kruse has automatically submitted a "known_factors" result (i.e., without the factor string). In these cases, the user still has an assignment pending for that same exponent.[/QUOTE]

Yes. I have nearly 33,500 exponents pending and cannot delete them because the server says
[FONT="Courier New"]Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 24 bytes) in C:\inetpub\www\workload\default.php on line 218[/FONT]
All my PRP assignments are getting "stuck".

[QUOTE=kruoli;469068]Yes. I have nearly 33,500 exponents pending and cannot delete them because the server says
[FONT="Courier New"]Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 24 bytes) in C:\inetpub\www\workload\default.php on line 218[/FONT]
All my PRP assignments are getting "stuck".[/QUOTE]

I can handle this.

Have you submitted your results using the manual web pages? If not, please do so.

[QUOTE=Prime95;469071]Have you submitted your results using the manual web pages? If not, please do so.[/QUOTE]

Yes, I did that. It fixed some of the exponents. But it did not fix its assignments, at least it seems like this. I guess I have a backup of most of the result files if this helps.

Oliver's assignments below 1,000,000 are deleted. Once he checks his results in with the manual web pages, I'll make them available again (this time for PRP-DC).

Note: You cannot do PRP-DC without version 29.4. Two PRP results from version 29.3 will look identical and the second one rejected as a duplicate. Version 29.4 implements shift counts, so that prime95 can do both the PRP and PRP-DC.

So, in summary, you can do PRP testing now with version 29.3, but you must also submit your results with the manual web pages. You cannot do PRP-DC at the present time.

[QUOTE=kruoli;469072]Yes, I did that. It fixed some of the exponents. But it did not fix its assignments, at least it seems like this. I guess I have a backup of most of the result files if this helps.[/QUOTE]


There are two kinds of PRP output:

One-line, where it says:

[CODE]
Mnnnnnnn/ffff/fffff/fffffff is not prime
[/CODE]

The program sends this if the length of the factor string "ffff,fffff,fffffff" (including commas) is less than 40.

Two line, where it says:

[CODE]
Mnnnnnnn/known_factors is not prime
Known factors used for PRP test were: fffffffffff/ffffffffffffff/fffffffffffffffff
[/CODE]

The program sends this if the length of the factor string "fffffffffff,ffffffffffffff,fffffffffffffffff" (including commas) is 40 or more.

The one-line version actually works fine, and can be submitted automatically to Primenet.

The two-line version does not transmit the second line automatically, so it has to be reported manually.

So, if you manually send your results files to George, you really only have to send the "known_factors" and "Known factors" lines.

If you manage to sort your worktodo.txt file into two separate files, one with exponents that have longer factor strings and one exponents that have shorter factor strings, then you can put them in separate working directories and make sure that the prime.txt file contains UsePrimenet=0 for the first group (whose results have to be submitted manually) and prime.txt contains UsePrimenet=1 for the second group (whose results can still be submitted automatically).

[QUOTE=Prime95;469073]Note: You cannot do PRP-DC without version 29.4. Two PRP results from version 29.3 will look identical and the second one rejected as a duplicate. Version 29.4 implements shift counts, so that prime95 can do both the PRP and PRP-DC.[/QUOTE]

In some cases, it is actually reporting a successful double check, although obviously it will have to be redone if both shift counts are zero. For example:

processing: PRP=(false) for M[M]1675801[/M]/2932651751/2467992190252774327/26305191321180053684999
PRP test successfully completes double-check of M1675801 -- CPU credit is 0.0909 GHz-days.

Note one small potential problem though, in the history section for that exponent, the order of the factors for the two results is different:

[CODE]
2017-10-03 kkmrkkblmbrbk PRP M1675801/2932651751/2467992190252774327/26305191321180053684999 is not prime. Res64: 1FDDCD18A87084__
2017-09-30 alpertron PRP M1675801/2467992190252774327/26305191321180053684999/2932651751 is not prime. Res64: 1FDDCD18A87084__
[/CODE]

When real double-checking with shift counts is implemented, I hope the program will recognize two factor strings as the same even if the factors are in a different order.

Actually I am more worried about the message indicating that the mail server failed.

We already had two Mersenne primes, I think, whose discovery was delayed by months because no e-mail was sent. And it looks like maybe that's a problem again with the new server?

Aaron, can you check the mail server. I turned off and restarted the SMTP service when James spammed himself. Maybe more needs to be done.

[QUOTE=Prime95;469079]Aaron, can you check the mail server. I turned off and restarted the SMTP service when James spammed himself. Maybe more needs to be done.[/QUOTE]

Oh yeah, how about that. It was still stopped.

No new primes came in while the email notifications were disabled... drat. :smile:

[QUOTE=GP2;469077]In some cases, it is actually reporting a successful double check, although obviously it will have to be redone if both shift counts are zero. For example:

processing: PRP=(false) for M[M]1675801[/M]/2932651751/2467992190252774327/26305191321180053684999
PRP test successfully completes double-check of M1675801 -- CPU credit is 0.0909 GHz-days.
[/QUOTE]

Odd. There were 2 incorrect entries in the app_versions table. I fixed the problem so it shouldn't happen in the future, but I did not go back and mark DC'ed PRPs as not DC'ed.

Can we add PRP work-type to manual assignment selection:
[url]https://www.mersenne.org/manual_assignment/[/url]

[QUOTE=preda;469113]Can we add PRP work-type to manual assignment selection:
[url]https://www.mersenne.org/manual_assignment/[/url][/QUOTE]

I like to experiment and break things. I found something that might be a problem.

The explanation is a bit long, so bear with me.

First of all, I think there are two different kinds of PRP testing, no? One is the PRP-cofactor testing for trying to find fully-factored Mersenne exponents, which has been a capability of mprime for a long time, although mersenne.org did not accept these results until very recently so they had to be manually reported to mersenne.ca instead. The other is the Gerbicz PRP testing, a new way to look for Mersenne primes, currently implemented in gpuOwL, and to be implemented in the upcoming mprime v 29.4

However, when we look at the [URL="https://mersenne.org/worktypes/"]Work Types page[/URL], which is linked from the [URL="https://mersenne.org/assignments/"]Active Assignments page[/URL] column heading, then it shows only work types "PRP" = "PRP test" and "PRP-D" = "PRP double-check", with no additional types for PRP-cofactor testing and PRP-cofactor-doublecheck testing.

Anyway, here's what I did...

In an mprime work directory, I edited the prime.txt file to set WorkPreference=150

I had some reason to think that this would produce assignments of the PRP-cofactor work type. That's because when I reported some PRP-cofactor residues to Primenet for exponents that I was already doing ECM tests on, there was a warning message about returning a different work type than expected, and that message mentioned work types 150 and 5. The numerical value WorkPreference=5 is already known to be for ECM testing (and 0 = "Whatever makes most sense", 2=TF, 100=First time LL tests, 101=Double checking LL tests, etc...)

So I figured that was a strong indication that 150 is the numerical code for the PRP-cofactor work type.


With WorkPreference=150 in prime.txt, I ran mprime, and the worktodo.txt file got some PRP assignments lines from Primenet.

It returned lines that looked like this:

[CODE]
PRP=<<a hex digit string of length 32>>,1,2,[M]82202839[/M],-1
[/CODE]

This looks exactly like the type of worktodo.txt lines generated by mersenne.ca for PRP-cofactor testing, with the same prefix of "PRP=", except it has an actual assignment ID string instead of "N/A". However the exponent is in the 82M range, rather than the single-digit-millions that would be normal for PRP-cofactor testing. And obviously there is no factor string at the end, because there are no known factors for this exponent.

So it looks like the Primenet server actually assigned me a Gerbicz-PRP test instead of a PRP-cofactor test...

The weird thing is that [B]mprime version 29.3 actually started crunching[/B] on this!

There are savefiles, and Primenet says it's 1.90% complete.

The magic number at the start of the p82202839 savefile is 0x87f2a91b, which is the same as for the PRP-cofactor savefiles.

I halted it, of course. But what work was v 29.3 performing on this exponent? I thought Gerbicz PRP testing will only be available in v 29.4

Is Primenet confusing the two different kinds of PRP testing, or am I the one who's confused?


PS,
to answer preda's question, I don't know about manual assignment of Gerbicz PRP work type, but this seems to be a weird way to get automated Gerbicz PRP assignments from the server. Just run mprime to generate the worktodo lines, then halt it, and use gpuOwL on those exponents.

Work preference of 160 is PRP-cofactor, work-preference 161 is PRP-cofactor-DC

A Gerbicz-PRP is just an ordinary PRP with better error checking. Thus, v29.3 (and earlier) can produce an acceptable PRP result for a first-time Mersenne number test -- though there is no good reason to do so.

What's up (or down) with the Manual Results page? Firefox shows a blank page. IE 11 returns 500, Internal Server error.

Please try again

[QUOTE=James Heinrich;469168]Please try again[/QUOTE]
Success! Thanks.

Manual reporting of two-line "known_factors" PRP results is broken right now:

Notice: Undefined index: known_factors in C:\inetpub\www\manual_result\manual_result.inc.php on line 361
processing: PRP=(false) for M[M]3996653[/M]
Notice: Undefined index: known_factors in C:\inetpub\www\manual_result\manual_result.inc.php on line 372 Notice: Undefined index: shift_count in C:\inetpub\www\manual_result\manual_result.inc.php on line 379 Notice: Undefined index: error_code in C:\inetpub\www\manual_result\manual_result.inc.php on line 379
Error code: 40, error text: No CPU credit given for test of already factored M[M]3996653[/M]

Contrary to the error message, no previous PRP result has been reported for this exponent.

Manual reporting of one-line PRP results also seems to be broken the same way, except without the "line 372" error, just line 361 and 379.

Automated reporting to Primenet of one-line PRP results is still working, though.

[QUOTE=GP2;469181]Manual reporting of two-line "known_factors" PRP results is broken right now:
Notice: Undefined index: known_factors in manual_result\manual_result.inc.php on line 361
[/QUOTE]Silly me, I changed two files and only uploaded one of them. :redface:
As a test case I submitted
[url=https://www.mersenne.org/M19571]M19571[/url]/6353725151/2844272257303/44693616409729050616105544862466390529
So that has been (incorrectly) credited to me, sorry. And if you may get an unexpected not-needed result if you try to resubmit it.

But the manual form should be working again for PRP.

[QUOTE=Prime95;469104]Odd. There were 2 incorrect entries in the app_versions table. I fixed the problem so it shouldn't happen in the future, but I did not go back and mark DC'ed PRPs as not DC'ed.[/QUOTE]

I think it would be OK to mark the exponents that were DC'ed with the same shift count of zero as not DC'ed. Probably there are only a relatively small number, and nearly all of them in the smaller exponent ranges like 1.6M and below, where each exponent can be PRP tested in a matter of minutes.

Server - PHP upgrade
 

Hi all... the server got an upgrade to the PHP version last night. Big swap from 5.6 to the latest 7.1 so there were some changes to code to handle a few deprecated things that are now gone, and other quirks.

I chased down some old v4 client problems this morning and hopefully those old clients are checking in smoothly again. Few other minor glitches here and there but I think I'm top of them.

If anyone does encounter *new* strange things (if it was strange before, don't bug me about it, LOL) just let me know. I'm working backwards from any errors PHP is throwing but there could be things happening that aren't an error, just acting different than it used to. Probably not, but just in case...

[QUOTE=Madpoo;469354]Hi all... the server got an upgrade to the PHP version last night. Big swap from 5.6 to the latest 7.1 so there were some changes to code to handle a few deprecated things that are now gone, and other quirks.
[/quote]

You should see a noticeable CPU reduction from that.

[quote]I chased down some old v4 client problems this morning and hopefully those old clients are checking in smoothly again. Few other minor glitches here and there but I think I'm top of them.[/quote]

Wasn't there only that one machine left?

[QUOTE=Mark Rose;469363](re: v4 clients) Wasn't there only that one machine left?[/QUOTE]

There are actually a few. Kinda scratching my head on why they're still running v26 or earlier clients, but oh well. The server has the support for those still so... whatever floats their boat.

I don't know if they'd benefit from newer versions since I don't know what kind of CPUs they're using (or maybe they're still on 32-bit OS?)

[QUOTE=Madpoo;469369]There are actually a few.[/QUOTE]

It seems like there's only one still returning LL results though, maybe the others are factoring?

[QUOTE=GP2;469371]It seems like there's only one still returning LL results though, maybe the others are factoring?[/QUOTE]

Could be. I didn't see what they were reporting, just that they're coming from a few different places.

I did notice some of them are also still trying to hit the old Perl page that I think showed user stats or something (primenet_report.pl or something like that). It no longer exists, they're getting 404's trying to hit it, but still they keep trying.

"Work Results Details" page
 

I do appreciate the new information given by the "Work Results Details" page : having the B1, B2 and E values for PM-1 results on that page is very nice.

I regret one thing though : when some data in the "Result" column is too long the "Result Type" and "Received" columns get wrapped.Which means every single row is two lines high I would prefer to have only the data in the "Result" column to be wrapped : it would only affect those rows that have a long content in "the "Results" column.

Jacob

www.mersenne.org timeout
 

[URL]https://www.mersenne.org/[/URL] -> no longer reachable (timeout) :no::no:

EDIT: seems ok now. Was offline for 10-15 minutes I guess.

Reporting a factor manually gives me this error message at the moment:
[QUOTE]Notice: Undefined variable: current_factor_prime in C:\inetpub\www\manual_result\manual_result.inc.php on line 247 IsAuthenticMersenneFactor(): Unexpected value for factor: [/QUOTE]
All following lines are ignored. Reporting just no-factor-found lines works fine.

Please try again

[QUOTE=James Heinrich;469658]Please try again[/QUOTE]
Submitting a factor seems to work again.
Thanks...

One of my machines was assigned the same exponent [M]2538959[/M] twice in a row for a PRP-CF test, resulting in a self-double-check.

This exponent stood out among the rest because it was out of the usual sequence: it was assigned a PRP-CF test because a new factor was discovered. The other exponents in worktodo were in the 3.1M range and hadn't had a first-time test on Primenet yet.

When the first PRP test completed, the exact same assignment (with same residue type 5) was assigned again, as part of the same communication with the server!

I noticed a few cases like that for Oliver Kruse and others doing PRP-CF tests, but until now I thought maybe they did a self-verify on purpose.



Here is the extract from prime.log, where the result is sent in for the old assignment, and then the new assignment is made at the same time:

[CODE]
[Thu Nov 2 13:19:37 2017 - ver 29.4]
Sending result to server: UID: GP2/c4.xlarge, [M]M2538959[/M]/25110366968391401/26621637266814029887 is not prime. Type-5 RES64: A87DC36CC4F0C31E. Wg8: 5D905E14,1247745,00000000, AID: 7014D24D0BF69D360E9EBE83BFF9888C

PrimeNet success code with additional info:
PRP test successfully completes double-check of [M]M2538959[/M] --
CPU credit is 0.1761 GHz-days.
Getting assignment from server
PrimeNet success code with additional info:
Server assigned PRP work.
Got assignment A6AAED2F0142C4EE83C068749B5D39BB: PRP [M]M2538959[/M]
Sending expected completion date for [M]M2538959[/M]: Nov 3 2017
Sending expected completion date for M3227717: Nov 2 2017
[/CODE]

And results.txt:

Here is results.txt:

[CODE]
c4.xlarge-prp/i-03aa0960019cf8075/results.txt:{"status":"C", "exponent":2538959, "known-factors":"25110366968391401,26621637266814029887", "worktype":"PRP-3", "res64":"A87DC36CC4F0C31E", "residue-type":5, "fft-length":131072, "shift-count":1247745, "error-code":"00000000", "security-code":"5D905E14", "program":{"name":"Prime95", "version":"29.4", "build":2, "port":8}, "timestamp":"2017-11-02 13:19:37", "errors":{"gerbicz":0}, "user":"GP2", "computer":"c4.xlarge", "aid":"7014D24D0BF69D360E9EBE83BFF9888C"}

c4.xlarge-prp/i-03aa0960019cf8075/results.txt:{"status":"C", "exponent":2538959, "known-factors":"25110366968391401,26621637266814029887", "worktype":"PRP-3", "res64":"A87DC36CC4F0C31E", "residue-type":5, "fft-length":131072, "shift-count":2364730, "error-code":"00000000", "security-code":"5D905E14", "program":{"name":"Prime95", "version":"29.4", "build":3, "port":8}, "timestamp":"2017-11-03 15:34:04", "errors":{"gerbicz":0}, "user":"GP2", "computer":"c4.xlarge", "aid":"A6AAED2F0142C4EE83C068749B5D39BB"}
[/CODE]

The same flaw has probably existed all along for LL assignments, it's just much less likely to happen. Right now there are only a handful of us doing PRP-CF tests, with two of us doing the bulk of them, and new assignments for exponents below the wavefront get sent whenever a new factor is discovered, so it's much more likely to happen.

[QUOTE=GP2;470977]One of my machines was assigned the same exponent [M]2538959[/M] twice in a row for a PRP-CF test, resulting in a self-double-check..[/QUOTE]

Actually, there is SQL code in place to prevent assigning double-checks to the same user that did the first test. I believe that code is working.

Your bug was in the SQL code that classifies the next work needed on the exponent. On your first test, you returned a type-5 residue that matched the type-5 residue returned when there was one fewer factor. Your result classified the exponent as double-checked. The SQL code that classifies the next work type for the exponent was not expecting just one row marked as double-checked and classified the exponent as needing a first-time test rather than needing ECM.

Short version: bug fixed.

I recently requested that a [url=http://mersenneforum.org/showthread.php?t=22655]P-1 result be manually added[/url] because PrimeNet keeps complaining that it wasn't needed. However, I still don't see it after almost two weeks. Is there some sort of administrative backlog?

If manually updating the database isn't practical, then I fully understand, but can someone at least let me know instead of never responding to my thread?

[QUOTE=ixfd64;471050]
If manually updating the database isn't practical, then I fully understand, but can someone at least let me know instead of never responding to my thread?[/QUOTE]

Lack of response usually means the 2 or 3 people with access to the server are not real interested in fixing or the effort was too great.

When I looked at it the first time, I found it too tedious to manually generate the needed rows.

Today, I figured out a much easier shortcut. I deleted the factor and re-submitted the result using manual forms. I don't think that will cause any problems, we'll see.....

Thanks, George. This is much appreciated!

Some exponents have a long list of expired assignments in red, which slows down display of the status. Especially the smaller exponents, which can have a lot of expired "factor ECM small" assignments.

These are mostly of historical interest and could be omitted by default.


In other words, how about changing the checkbox from:

Include full ECM history (every "no-factor ECM" result)

to

Include full history (every "no-factor ECM" result, every expired ECM assignment)


By default, we already omit completed NF-ECM assignments from the display, so why do we display uncompleted (expired) ECM assignments? They should be controlled by the same checkbox.

Actually, it might even be desirable to omit all the red lines by default (all expired assignments, whether ECM or not). But at least omitting "factor ECM small" by default would be a good start.

[QUOTE=GP2;471170]Some exponents have a long list of expired assignments in red, which slows down display of the status. Especially the smaller exponents, which can have a lot of expired "factor ECM small" assignments.

These are mostly of historical interest and could be omitted by default
<....>
Actually, it might even be desirable to omit all the red lines by default (all expired assignments, whether ECM or not). But at least omitting "factor ECM small" by default would be a good start.[/QUOTE]

Maybe it could exclude expired assignments by default with a checkbox to enable them if someone were so inclined.

Yeah, I'm not sure how much value is added by showing expired stuff by default, but I can imagine there'd be times when so-and-so would want to look at the full assignment history. Maybe the next prime will be discovered and someone will look back at that and say "oh man, so-and-so had this assignment but never worked on it" and we can all laugh at them. :smile:

(M74207281 has an expired assignment, but it was assigned after we'd made the discovery... not sure how that happened, it shouldn't have gone out as an assignment).

I like to see expired LL/TF assignments so I have a good idea if I'm about to get poached if I'm manually reserving an assignment.

[QUOTE=Madpoo;471188]Maybe it could exclude expired assignments by default with a checkbox to enable them if someone were so inclined.
[/QUOTE]

Not even a checkbox, a more aethestic version (IMO) would be a single line with something like "x expired assignments (click to expand)", which expansion would replace said line.

[QUOTE=Dubslow;471240]Not even a checkbox, a more aethestic version (IMO) would be a single line with something like "x expired assignments (click to expand)", which expansion would replace said line.[/QUOTE]
+1

[QUOTE=Dubslow;471240]Not even a checkbox, a more aethestic version (IMO) would be a single line with something like "x expired assignments (click to expand)", which expansion would replace said line.[/QUOTE]

That's less than ideal, because you are merely hiding the results. You are still spending the time to do the database query. The checkbox would skip the database query entirely.

For small exponents with lots of expired assignments, it can take several seconds to check their status, for instance [M]M1277[/M]. If it is a 10k range of exponents rather than a single exponent, it can take half a minute or so. Whereas exponents without a lot of "baggage" usually display almost instantly.

A lot of time and server effort is spent on retrieving things that clutter the display and will be ignored anyway.

Maybe the default should be to display only "current status": factors, LL residues, PRP and PRP-cofactor residues, and current assignment if any. A lot of the time that's all you want. Anything that's "history" (including expired assignments) would require a checkbox.

[QUOTE=GP2;471257]That's less than ideal, because you are merely hiding the results. You are still spending the time to do the database query.[/QUOTE]Not necessarily. You display the "click to expand" on page load, and use AJAX to load in the actual details iff someone clicks that.

Like on my [url=http://www.mersenne.ca/prp.php]PRP page[/url], if you click "P-<digits>" it expands it to the full decimal representation, but only on demand.

[QUOTE=GP2;471257]That's less than ideal, because you are merely hiding the results. You are still spending the time to do the database query. The checkbox would skip the database query entirely.
[/QUOTE]

The full query is only run when expansion is clicked, as JH says. That might make expansion slow in the large cases, but only when you click it.

(I suppose that might require storing the [i]count[/i] of expired assignments separately in the table, or just leave it out of the "expand" row.)

[QUOTE=James Heinrich;471258]Not necessarily. You display the "click to expand" on page load, and use AJAX to load in the actual details iff someone clicks that.

Like on my [url=http://www.mersenne.ca/prp.php]PRP page[/url], if you click "P-<digits>" it expands it to the full decimal representation, but only on demand.[/QUOTE]No JS please. I also hate the current trend of websites to hide everything behind "click here to ..." things. I like to have all the information there without having to waste time clicking around for hidden things like it is some sort of game for a 5 year old.

I prefer the checkbox option. It can also be stored as a link in the GET query so once someone has got their desired information they can save the link for future visits without needing to "click here" after the page is loaded.

[QUOTE=Mark Rose;471199]I like to see expired LL/TF assignments so I have a good idea if I'm about to get poached if I'm manually reserving an assignment.[/QUOTE]

I do too... so I did think of an alternate idea which is to show [I]recent[/I] expired assignments (in the past XX days), or maybe only show expired assignments if they're still checking in even though expired.

There would still, under that idea, be a checkbox to show *all* of the expired assignments for the truly curious folks who may want to look at something in particular, but for the average use, having all of those show up has little benefit and only clutters things... IMO. :smile:

[QUOTE=Madpoo;471496]I do too... so I did think of an alternate idea which is to show [I]recent[/I] expired assignments (in the past XX days), or maybe only show expired assignments if they're still checking in even though expired.

There would still, under that idea, be a checkbox to show *all* of the expired assignments for the truly curious folks who may want to look at something in particular, but for the average use, having all of those show up has little benefit and only clutters things... IMO. :smile:[/QUOTE]

That's fair. :smile:

The mersenne.org/workload/ page shows UNKNOWN WORKTYPE "150" down in the work-to-do section for PRP tests rather than the expected PRP=xyz,#,#,M#,# that is in an actual work-to-do file.

[QUOTE=potonono;473227]The mersenne.org/workload/ page shows UNKNOWN WORKTYPE "150" down in the work-to-do section for PRP tests rather than the expected PRP=xyz,#,#,M#,# that is in an actual work-to-do file.[/QUOTE]

Can you share an example worktodo entry for a PRP test (XX out the assignment ID). I can try fixing up that page but since I haven't done any PRP tests myself, I don't actually know what such a line should look like. :smile:

[code]PRP=(<assignment_id>,)1,2,<exponent>,-1(,"comma,separated,knownfactors")[/code]

[QUOTE=James Heinrich;473567][code]PRP=(<assignment_id>,)1,2,<exponent>,-1(,"comma,separated,knownfactors")[/code][/QUOTE]

Well, not exactly.

For PRP cofactor double checking:

Between the -1 and the comma-separated list of known factors, there is 99,0,3,1 if it's a double-check of a Type 1 first-time result and 99,0,3,5 if it's a double check of a first-time type 5 result.

For PRP cofactor first-time checking:

It's still a valid line if those four fields are omitted, and I think it just defaults to Type 5. If I'm not mistaken, first-time PRP test assignments do omit those fields, but I don't have any current examples to look at.

For PRP primality double-checking:

Obviously there is no list of known factors, and after the -1 there are the fields "75,0,3,4" (no factors below 2[SUP]75[/SUP], uses base 3 as the work type, and uses residue type 4, to match the first time test that was done by preda using gpuOwL).

For PRP primality first-time checking:

Obviously there is no list of known factors, and the fields just end with the -1

[QUOTE=GP2;473571]
For PRP primality double-checking:

Obviously there is no list of known factors, and after the -1 there are the fields "75,0,3,4" (no factors below 2[SUP]75[/SUP], uses base 3 as the work type, and uses residue type 4, to match the first time test that was done by preda using gpuOwL).[/QUOTE]

Early gpuOwl's did type 4, later versions do type 1.

[QUOTE=GP2;473571]Well, not exactly.

For PRP cofactor double checking:

Between the -1 and the comma-separated list of known factors, there is 99,0,3,1 if it's a double-check of a Type 1 first-time result and 99,0,3,5 if it's a double check of a first-time type 5 result.

For PRP cofactor first-time checking:

It's still a valid line if those four fields are omitted, and I think it just defaults to Type 5. If I'm not mistaken, first-time PRP test assignments do omit those fields, but I don't have any current examples to look at.

For PRP primality double-checking:

Obviously there is no list of known factors, and after the -1 there are the fields "75,0,3,4" (no factors below 2[SUP]75[/SUP], uses base 3 as the work type, and uses residue type 4, to match the first time test that was done by preda using gpuOwL).

For PRP primality first-time checking:

Obviously there is no list of known factors, and the fields just end with the -1[/QUOTE]

Oof. Just when I thought I was getting close to a basic test...

Now my alterations will need to do some additional work to see:
- is this a double-check? If so, set the residue type and base to the same as the first one
- also if it's a double-check, it would need to be using the same # of known factors, although if a new one had been found in the meanwhile, it may or may not be useful to do this double-check anyway (depending on the residue type)

It also depends on the client version since older clients won't support those extra fields (residue type, base, etc).

Well, at any rate I've just about got it worked up to do the basic stuff without the extra parts you mention.

[QUOTE=Madpoo;473574]It also depends on the client version since older clients won't support those extra fields (residue type, base, etc).[/QUOTE]Should you even make an effort to consider such? If the client is old and doesn't support said fields, perhaps we don't want it running PRP tests anyways?

[QUOTE=Prime95;473572]Early gpuOwl's did type 4, later versions do type 1.[/QUOTE]

What's the default type for the latest Prime95? I could omit it and let it do whatever (if this is the first PRP test) or specifically set it to whatever the default ... is it type 5?

I have it sort of mocked up but I really only tested it with a couple of PRP cofactor assignments on myself. I have every reason to believe there are still bugs in it. :) You may even get a 500 error or some crazy debug text...

[URL="https://www.mersenne.org/workload/default.mock.php"]https://www.mersenne.org/workload/default.mock.php[/URL]

That looks good to me, though my Prime95 worktodo file doesn't include the last few delimited items.

mersenne.org/workload/default.mock.php shows:
PRP=xxxyyyzzz,1,2,mmmmmmmm,-1,75,0,3,1
PRP=aaabbbccc,1,2,mmmmmmmm,-1,75,0,3,5

Prime95 v29.4.5.0 worktodo.txt shows:
PRP=xxxyyyzzz,1,2,mmmmmmmm,-1
PRP=aaabbbccc,1,2,mmmmmmmm,-1

[QUOTE=potonono;473597]That looks good to me, though my Prime95 worktodo file doesn't include the last few delimited items.

mersenne.org/workload/default.mock.php shows:
PRP=xxxyyyzzz,1,2,mmmmmmmm,-1,75,0,3,1
PRP=aaabbbccc,1,2,mmmmmmmm,-1,75,0,3,5

Prime95 v29.4.5.0 worktodo.txt shows:
PRP=xxxyyyzzz,1,2,mmmmmmmm,-1
PRP=aaabbbccc,1,2,mmmmmmmm,-1[/QUOTE]

I wonder if those last few bits are only required for double-checks when they need to match the first check.

The "75" is the factored-to-bits (or 99 if that's missing...which is true on some smaller exponents that have factors but were probably done with P-1 or ECM).

I don't know what that second one is... the zero.

"3" is the base... it'll probably always be 3 but I guess someone might have a program that does something different at some point.

And the final "1" or "5" is the residue type. That's important for double-checks because it needs to be the same residue type as the first check otherwise you won't be doing a valid check.

Maybe for first-time checks I should just leave those other parameters out and let Prime95 do its default thing?

Really though, I imagine in most cases you won't need the worktodo lines from this page at all. Only important if you managed to wipe out your txt file and need to add them back in. So... don't do that and you'll be fine no matter what. :smile:

[QUOTE=Madpoo;473600]"3" is the base... it'll probably always be 3 but I guess someone might have a program that does something different at some point.[/QUOTE]Prime95 apparently supports any (int>=3) base for PRP, but defaults to 3 unless specified otherwise. Why you'd want a different base I have no idea, but it's there.

[QUOTE=Madpoo;473600]...
And the final "1" or "5" is the residue type. That's important for double-checks because it needs to be the same residue type as the first check otherwise you won't be doing a valid check.
...[/QUOTE]

Took another look at past results...

PRP cofactor tests are coming in with residue types of 1 or 5, and non-cofactor tests are coming in with types 1 or 4. :confused:

Makes me think I should leave it out for this page (for first-time tests). Double-checks of course should still be set to match the previous test.

I ran a cofactor PRP test without those params and it used a residue type of 1 so that must be the default for those at least. Maybe a regular PRP uses 1 as well if not specified?

[QUOTE=Madpoo;473604]...
I ran a cofactor PRP test without those params and it used a residue type of 1 so that must be the default for those at least. Maybe a regular PRP uses 1 as well if not specified?[/QUOTE]

I take it back. That test was with 29.3 and I realized I should be running 29.4 with the latest build 5. With that one it uses a default residue type of 5.

Which makes sense... that's (I think) the one that uses the Gerbicz error checking, and the residues can still be used to match previous tests when new factors are found. If I got that right.

Anyway, I'm just going to leave that residue type blank if there aren't any unverified tests waiting for a double-check. The default used will depend on the software in use.

[QUOTE=James Heinrich;473601]Prime95 apparently supports any (int>=3) base for PRP, but defaults to 3 unless specified otherwise. Why you'd want a different base I have no idea, but it's there.[/QUOTE]

It might be useful to test PRP cofactors with other bases. I don't think there's been a case where a cofactor was 3-PRP but failed with some other base, but still.

For small exponents less than 64K, the cofactors have all been certified prime by Primo, so nothing further is needed.

For exponents larger than this but smaller than 500K, factordb has done PRP in various bases including at a minimum 3, 5, 7, 11. However, factordb does not test or record PRP-ness for cofactors of Mersenne exponents larger than this, for example M576551.

For exponents larger than 500K, paulunderwood has done some Lucas PRP tests ([URL="http://www.mersenneforum.org/showpost.php?p=435694&postcount=14"]source code[/URL]), including for the ones linked below:
[LIST][*]576551[*][URL="http://mersenneforum.org/showpost.php?p=460881&postcount=309"]611999[/URL][*]675977[*]684127[*]696343[*]750151[*]822971[*]1010623[*]1168183[*]1304983[*][URL="http://www.mersenneforum.org/showpost.php?p=472369&postcount=396"]1629469[/URL][*]1790743[*]2327417[*]3464473[*][URL="http://ftp.mersenneforum.org/showpost.php?p=435655&postcount=42"]4187251[/URL][*][URL="http://mersenneforum.org/showpost.php?p=449050&postcount=278"]4834891[/URL][*][URL="http://ftp.mersenneforum.org/showpost.php?p=439082&postcount=44"]5240707[/URL][*][URL="http://www.mersenneforum.org/showpost.php?p=470457&postcount=389"]7080247[/URL][/LIST]
Also I imagine the [URL="http://www.primenumbers.net/prptop/searchform.php?form=%282^x-1%29%2F%3F&action=Search"]Lifchitz PRP Top website[/URL] probably does some independent testing before adding new entries, and other independent tests must have been carried out without formally recording them.

And of course for non-cofactor PRP testing, a subsequent LL test will certify primality, if and when we find one.

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

For instance, for M17509, here is the HTML format:

[url]https://www.mersenne.org/report_exponent/?exp_lo=17509&exp_hi=[/url]

The columns are: Status, Date, User, Residue, Number of known factors, Shift, Type, Base
[CODE]
Verified 2017-12-10 Oliver Kruse F011B56D2685EC16 3 9334 1 5
Verified 2017-12-10 ATH DF33C34A381E5D0E 3 16014 5 3
Verified 2017-12-10 ATH F011B56D2685EC16 3 3196 1 5
Verified 2017-11-17 Oliver Kruse DF33C34A381E5D0E 3 11413 5 3
Verified (Factored) 2017-11-17 Robin89 3076003BC0CD8C8F 1 0 1 3
Verified (Factored) 2017-11-08 kkmrkkblmbrbk DF33C34A381E5D0E 2 12218 5 3
Verified (Factored) 2017-11-07 Oliver Kruse DF33C34A381E5D0E 2 17291 5 3
Verified (Factored) 2017-10-12 kkmrkkblmbrbk 8255B2EBDE3838E0 1 16575 1 3
Verified (Factored) 2017-09-21 Oliver Kruse 8255B2EBDE3838E0 1 0 1 3
[/CODE]

and the text-only format:

[url]https://www.mersenne.org/report_exponent/?exp_lo=17509&exp_hi=&text=1[/url]

The fields are: Exponent and record type and Status, Date, User, Residue, Number of known factors, [B]Shift + Type concatenated[/B], Base.

So for example, shift = 9334 and type = 1 becomes 93341

[CODE]
17509 PRPCofactor Verified;2017-12-10;Oliver Kruse;F011B56D2685EC16;3;93341;5;
17509 PRPCofactor Verified;2017-12-10;ATH;DF33C34A381E5D0E;3;160145;3;
17509 PRPCofactor Verified;2017-12-10;ATH;F011B56D2685EC16;3;31961;5;
17509 PRPCofactor Verified;2017-11-17;Oliver Kruse;DF33C34A381E5D0E;3;114135;3;
17509 PRPCofactor Verified (Factored);2017-11-17;Robin89;3076003BC0CD8C8F;1;01;3;
17509 PRPCofactor Verified (Factored);2017-11-08;kkmrkkblmbrbk;DF33C34A381E5D0E;2;122185;3;
17509 PRPCofactor Verified (Factored);2017-11-07;Oliver Kruse;DF33C34A381E5D0E;2;172915;3;
17509 PRPCofactor Verified (Factored);2017-10-12;kkmrkkblmbrbk;8255B2EBDE3838E0;1;165751;3;
17509 PRPCofactor Verified (Factored);2017-09-21;Oliver Kruse;8255B2EBDE3838E0;1;01;3;
[/CODE]

[url]https://www.mersenne.org/assignments/?exp_lo=45600000&exp_hi=45700000&exfirst=1[/url]

If I exclude DC it does not show TF assignments.

Same here...

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

It's still doing this, I think it's a fairly quick fix?

[QUOTE=GP2;473167]Prime95 29.4 build 5 is refusing to do PRP-CF on a few exponents:

In my results.txt files:

4456310665879544089 does not divide [M]M2207441[/M]
12415622589540644657 does not divide [M]M2233183[/M]
1219861756779140901119 does not divide [M]M2233019[/M]

All of these statements are false, actually.
[/QUOTE]

This is all fixed now, the above is from [URL="http://mersenneforum.org/showthread.php?t=22683"]the Prime95 version 29.4 thread[/URL], but it was actually a database problem, caused by the same factor being duplicated in the database.

I just realized that [URL="http://www.mersenneforum.org/showpost.php?p=436175&postcount=10"]I had reported this duplication of factors for these same exponents some time earlier[/URL], but I guess it wasn't fixed at the time. In that message, I suggested that the FACTORS column in the database should have an SQL unique index or unique constraint placed on it, which would prevent duplicates.

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.

One more thing related to [M]M2207441[/M], [M]M2233183[/M], [M]M2233019[/M] and any similar cases:

We now seem to be relying on the "Number of known factors" displayed in the PRP Cofactor section. This suggests that any PRP tests done with a bogus factor string should be removed from the PRP Cofactor section at least, and perhaps even from the History. This prevents any confusion about exactly which factors were used.

Currently, this seems to be done in an inconsistent way:

For [M]M2207441[/M] the bogus 2017-10-18 test does not appear in the PRP Cofactor section, although the equally bogus 2017-10-09 test does appear. Both appear in History.

For [M]M2233183[/M], the bogus 2017-10-18 test does not appear in the PRP Cofactor section, but the presumably equally bogus 2017-10-10 test does appear. Hard to say, since it was a "known_factors" result, but it almost certainly used the same factor string. Since Oliver e-mailed you his old results.txt files, it should be possible to check. In any case both of those old results were obsoleted by the discovery of a new factor on 2017-11-09.

For [M]M2233019[/M], the bogus 2017-10-18 test does not appear in the PRP Cofactor section, but the presumably equally bogus 2017-10-10 test does appear. That was also a "known_factors" result, but it almost certainly used the same bogus factor string. Again, Oliver's old results.txt files could be checked if necessary.

There are a handful of other cases:

For [M]M2210209[/M], I submitted a result with a garbled factor string due to a copy-paste mishap, which was noticed by James Heinrich. In a private message from Madpoo dated 2017-10-11, 16:33 from me, James Heinrich and Prime95, he mentioned that he removed it from the results log and also the cofactor PRP table. There is now no trace of this bogus result in the Exponent Status.

In a followup private message from James Heinrich to the same recipients dated 2017-10-11, 16:38, he mentioned two of alperton's old results for [M]37811[/M] and [M]M1132997[/M] with garbled and truncated factors, where the factor string must have been copy-pasted incorrectly.

For [M]37811[/M], this still appears in the History section and in the PRP Cofactor section as a "Bad" result. For consistency with the handling of M2210209, perhaps these should both be removed, or at least in the PRP Cofactor section.

For [M]M1132997[/M], it's the same story.

So there are six cases in all, where the handling ranged from leaving everything as-is to removing all trace of the bogus result. For consistency they should all be handled the same way. I think there is no value in keeping bogus results that originated in garbled input.

PS,
The only genuine Bad result for PRP Cofactor testing that I'm aware of is ATH's result for [M]3167573[/M], which appears to have been done with an older version before the Gerbicz error checking and recovery code was put into the program.