![]() |
Primenet Graphs
The following are some observations from the Primenet Graphs page [URL="https://www.mersenne.org/primenet/graphs.php"]https://www.mersenne.org/primenet/graphs.php[/URL]
1) The TFLOP graph y-axis extends into -1000. The values of this should never go below zero so the y-axis min can be set at 0. 2) The Assignments graph has a downward trend happening on the LL values. Is this due to the fact that more people are doing PRP as the first time test vs LL? If so I would recommend either adding PRP to the graph or merge first time LL and PRP and label it as First Time instead of LL. The DC would then be LL-DC + PRP-DC. |
[QUOTE=gjmccrac;523068]
2) The Assignments graph has a downward trend happening on the LL values. Is this due to the fact that more people are doing PRP as the first time test vs LL? If so I would recommend either adding PRP to the graph or merge first time LL and PRP and label it as First Time instead of LL. The DC would then be LL-DC + PRP-DC.[/QUOTE] I changed the stored procedure to count LL+PRP and LLDC+PRPDC. You should see the effect tomorrow. I did not change the graph text or axis. |
[QUOTE=gjmccrac;523068]1) The TFLOP graph y-axis extends into -1000. The values of this should never go below zero so the y-axis min can be set at 0.[/QUOTE]I have set [b]vAxis.viewWindow.min = 0[/b] for the TFLOP/s graph.
|
primenet api vs manual submissions
It looks to me that automatically running and reporting via primenet api, prp results are recorded as unverified (reliable), while manually reported are recorded as unverified; the (reliable) is omitted, for manual results submissions, even though the Gerbicz check errors observed and reported are zero, and all errors counted and reported are zero.
Primenet API example: [URL]https://www.mersenne.org/report_exponent/?exp_lo=85731889&full=1[/URL] manual reporting examples (from prime95 v29.8b5): [URL]https://www.mersenne.org/report_exponent/?exp_lo=97970567&full=1[/URL] [URL]https://www.mersenne.org/report_exponent/?exp_lo=108575167&full=1[/URL] [URL]https://www.mersenne.org/report_exponent/?exp_lo=103404713&full=1[/URL] [URL]https://www.mersenne.org/report_exponent/?exp_lo=87232913&full=1[/URL] Their respective manual report contents (with AID, res2048, full res64 and security code omitted here on the forum but submitted fully on the manual results page): [Mon Aug 05 03:09:36 2019] {"status":"C", "exponent":97970567, [B]"worktype":"PRP-3"[/B], "res64":"1A0D214F3F12C0__", "residue-type":1, "res2048":"omitted here", "fft-length":5505024, "shift-count":32264665, [B]"error-code":"00000000"[/B], "security-code":"omitted here", "program":{"name":"Prime95", "version":"29.8", "build":5, "port":4}, "timestamp":"2019-08-05 08:09:36", [B]"errors":{"gerbicz":0}[/B]} [URL]https://www.mersenneforum.org/showpost.php?p=523095&postcount=239[/URL] [Wed Jul 31 08:19:16 2019] {"status":"C", "exponent":103404713, [B]"worktype":"PRP-3"[/B], "res64":"D5DFE866E919FC__", "residue-type":1, "res2048":"omitted here", "fft-length":5734400, "shift-count":368620, [B]"error-code":"00000000"[/B], "security-code":"omitted here", "program":{"name":"Prime95", "version":"29.8", "build":5, "port":4}, "timestamp":"2019-07-31 13:19:16", [B]"errors":{"gerbicz":0}[/B], "aid":"omitted here"} [URL]https://www.mersenneforum.org/showpost.php?p=522466&postcount=26[/URL] (end) |
[QUOTE=James Heinrich;523082]I have set [b]vAxis.viewWindow.min = 0[/b] for the TFLOP/s graph.[/QUOTE]
Thanks to both of you for fixing those things. I did kind of throw the graphs together on a whim, and while I tried to make sure the floor was set right, I apparently didn't do a good enough job. :smile: |
Here's an odd case for PRP cofactor testing: [M]M2919853[/M]
A new factor was found, and a first PRP cofactor test was done. But then an old, trivially small factor was "rediscovered". And that left this exponent in a kind of limbo: no second PRP cofactor test was ever scheduled. A couple of months later I did one manually, but it still left the exponent in a "Verified (Factored)" state instead of a double-green Verified state, even though there are two matching residues. In general, Primenet is not good at handling the "rediscovery" of trivially small factors that are so old that their discovery predates GIMPS itself. |
[QUOTE=LaurV;465907]Happy Birthday Server! :party:[/QUOTE]
[QUOTE=LaurV;440194](me stressing it out) HAPPY BIRTHDAY SERVER! :party: :razz:[/QUOTE] [QUOTE=LaurV;494352] [URL="http://www.mersenneforum.org/showthread.php?p=440194"]Happy birthday Server![/URL]... hehe... Five years by now? (Edit: [URL="http://www.mersenneforum.org/showthread.php?p=465907"]backup server[/URL], whatever... :razz:) :party:[/QUOTE]Happy Birthday Server ! |
I just got this error from the serve [URL's redacted]:
[CODE][Comm thread Aug 30 11:02] Updating computer information on the server [Comm thread Aug 30 11:02] URL: http://v5.mersenne.org/v5server/?v=0.95&px=GIMPS&t=uc&g.........&a=Wind [Comm thread Aug 30 11:02] RESPONSE: [Comm thread Aug 30 11:02] <!-- IE friendly error message walkround. [Comm thread Aug 30 11:02] if error message from server is less than [Comm thread Aug 30 11:02] 512 bytes IE v5+ will use its own error [Comm thread Aug 30 11:02] message instead of the one returned by [Comm thread Aug 30 11:02] server. --> [Comm thread Aug 30 11:02] [Comm thread Aug 30 11:02] [Comm thread Aug 30 11:02] [Comm thread Aug 30 11:02] [Comm thread Aug 30 11:02] [Comm thread Aug 30 11:02] [Comm thread Aug 30 11:02] <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"> [Comm thread Aug 30 11:02] <html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><style type="text/css">html,body{height:100%;padding:0;margin:0;}.oc{display:table;width:100% [Comm thread Aug 30 11:02] <p> [Comm thread Aug 30 11:02] URL: http://v5.mersenne.org/v5server/?v=0.95&px=GIMPS&t=uc&.........&a= [Comm thread Aug 30 11:02] <br/>User name: [Comm thread Aug 30 11:02] <br/>Group name: [Comm thread Aug 30 11:02] </p></p></div></div></div></body></html> [Comm thread Aug 30 11:02] PnErrorResult value missing. Full response was: [Comm thread Aug 30 11:02] <!-- IE friendly error message walkround. [Comm thread Aug 30 11:02] if error message from server is less than [Comm thread Aug 30 11:02] 512 bytes IE v5+ will use its own error [Comm thread Aug 30 11:02] message instead of the one returned by [Comm thread Aug 30 11:02] server. --> [Comm thread Aug 30 11:02] [Comm thread Aug 30 11:02] [Comm thread Aug 30 11:02] [Comm thread Aug 30 11:02] [Comm thread Aug 30 11:02] [Comm thread Aug 30 11:02] [Comm thread Aug 30 11:02] <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"> [Comm thread Aug 30 11:02] <html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><style type="text/css">html,body{height:100%;padding:0;margin:0;}.oc{display:table;width:100% [Comm thread Aug 30 11:02] <p> [Comm thread Aug 30 11:02] URL: http://v5.mersenne.org/v5server/?v=0.95&px=GIMPS&t=uc&.......&a= [Comm thread Aug 30 11:02] <br/>User name: [Comm thread Aug 30 11:02] <br/>Group name: [Comm thread Aug 30 11:02] </p></p></div></div></div></body></html> [Comm thread Aug 30 11:02] Visit http://mersenneforum.org for help. [Comm thread Aug 30 11:02] Will try contacting server again in 87 minutes.[/CODE] |
This entry suggests a factor that should have been entered in the database long before was not until now.
What could have caused that and are there more missing? [URL="https://www.mersenne.org/report_exponent/?exp_lo=14419&full=1"]https://www.mersenne.org/report_exponent/?exp_lo=14419&full=1[/URL] |
[QUOTE=tha;525212]This entry suggests a factor that should have been entered in the database long before was not until now.
[/QUOTE] Some factors are so small that they were discovered before Primenet. They were in the database all along, but if someone "rediscovers" them and reports them, then they end up in the History log. It's easy to see that the smallest factor of [M]M14419[/M] was known all along, because this exponent never had an LL test even though the second-smallest factor wasn't reported until 2008. |
[QUOTE=tha;525212][URL="https://www.mersenne.org/report_exponent/?exp_lo=14419&full=1"]This entry[/url] suggests a factor that should have been entered in the database long before was not until now.[/QUOTE]Which particular factor are you referring to? (I'm assuming the smallest one, 439058551). Most factors found before mid-2008 do not have specific date-of-discovery details recorded. But clearly it was known before the recent ECM result since three separate cofactor PRPs were performed in 2017 including this factor.
|
| All times are UTC. The time now is 23:02. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.