mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   PrimeNet (https://www.mersenneforum.org/forumdisplay.php?f=11)
-   -   OFFICIAL "SERVER PROBLEMS" THREAD (https://www.mersenneforum.org/showthread.php?t=5758)

petrw1 2020-11-23 02:56

[QUOTE=James Heinrich;564072]Because it wasn't recently "cleared". You may have just recently discovered a factor (or two), but it's been considered "cleared" since the LL-DC was received 2016-07-18.
It does show up (twice, this is a known side-effect of composite factors and is only a display artifact) on [url=https://www.mersenne.org/report_recent_results/]Recent Results[/url].[/QUOTE]

But this one does show up on recent cleared:
[CODE]Sid & Andy Manual testing 43068601 F-PM1 2020-11-23 01:46 0.0 6.7566 Factor: 887259555209600233830649 / (P-1, B1=1500000, B2=30000000)[/CODE]

What am I missing? How are they different other than the other found a composite factor?

Lorenzo 2020-11-28 08:40

Hello! Bug in the report.


[URL]https://www.mersenne.org/report_factors/?end_date=2020-11-20&exp_date=2020-11-20&exp_hi=999999937&exp_lo=332192831&txt=1[/URL]


It does show nothing for any date.


Even more the form on the page is ignoring exp_hi=999999937 parameter.

Viliam Furik 2020-11-28 10:29

[QUOTE=Lorenzo;564654]Hello! Bug in the report.


[URL]https://www.mersenne.org/report_factors/?end_date=2020-11-20&exp_date=2020-11-20&exp_hi=999999937&exp_lo=332192831&txt=1[/URL]


It does show nothing for any date.


Even more the form on the page is ignoring exp_hi=999999937 parameter.[/QUOTE]

There is no bug. That exponent hasn't been factored yet, so it doesn't have any known factors to display.

Lorenzo 2020-11-28 13:38

[QUOTE=Viliam Furik;564660]There is no bug. That exponent hasn't been factored yet, so it doesn't have any known factors to display.[/QUOTE]
Sorry but there is a bug. Please notice that I have requested for the range (332192831-999999937). Not for single exponent!

James Heinrich 2020-11-28 17:31

[QUOTE=Lorenzo;564654]Bug in the report.
[URL]https://www.mersenne.org/report_factors/?end_date=2020-11-20&exp_date=2020-11-20&exp_hi=999999937&exp_lo=332192831&txt=1[/URL]
It does show nothing for any date.
Even more the form on the page is ignoring exp_hi=999999937 parameter.[/QUOTE]Thanks. There were two bugs that affected what you were requesting, one that ignored the exp_hi parameter and the other than didn't correctly return results where start/end date where the same. Both should be fixed now.

Uncwilly 2020-12-04 21:45

Getting a 500 error.

Viliam Furik 2020-12-04 21:47

[QUOTE=Uncwilly;565288]Getting a 500 error.[/QUOTE]

Same here.

lycorn 2020-12-04 21:47

Same here.

James Heinrich 2020-12-04 21:55

Errors started around 20:00h UTC according to the log I can see, I'm not sure why.
I think George or Aaron will need to give the server a reboot. I sent them a note.

Madpoo 2020-12-04 22:01

It seems we fell victim to the recent success at hitting the 100M milestone.

We were getting a TON of traffic to the milestone page. The stats on there are calculated every 15 minutes, but the #'s still have to be pulled using some DB calls that, as it turns out, still have a loading problem with the multiple requests.

For now I've removed all of those real-time stats from the milestone page and I'll have to look at optimizing that section.

I think we got linked to from somewhere, thus the spike in traffic, so, that's not too bad. :smile:

Sorry for the issues... the server should be back to normal except that one page.

EDIT: Yup, I thought I saw traffic coming with these referrals, and that seems to be the reason for the uptick.
[URL="https://news.ycombinator.com/item?id=25306698"]https://news.ycombinator.com/item?id=25306698[/URL]

kriesel 2020-12-06 12:40

Thanks for the link. And there is some unfortunate disinformation there. Including that all prime exponents get triple-checked. And that recent increased emphasis on double-check / triple check caused months of delay between minor first-test milestones. See the barkingcat post there.

kriesel 2020-12-14 12:16

All the listed countdowns to first time check milestones in [URL]https://www.mersenne.org/report_milestones/[/URL] incorrectly have 101M as the low bound in the URL, instead of 100M or [COLOR=blue]100 031 293, [/COLOR]giving page loads that skip the 100M-101M untested exponents. The most dramatic example is returning no results for up to 101M.
[URL="https://www.mersenne.org/assignments/?exp_lo=10"]https://www.mersenne.org/assignments/?exp_lo=101000000&exp_hi=101000000&execm=1&exp1=1&extf=1&exdchk=1[/URL]
[URL]https://www.mersenne.org/assignments/?exp_lo=101000000&exp_hi=102000000&execm=1&exp1=1&extf=1&exdchk=1[/URL]
[URL]https://www.mersenne.org/assignments/?exp_lo=101000000&exp_hi=103000000&execm=1&exp1=1&extf=1&exdchk=1[/URL]
Please fix.

And thank you ViliamF for following up with a post at [url]https://news.ycombinator.com/item?id=25306698[/url] rebutting barkingcat's 100% triplecheck misinformation.

Raydex 2020-12-15 12:58

Unfortunately, normal operations on the "Milestones" page appear to have been upended by the landmark milestone of reaching 100 million, which as we all know by now, has caused a massive wave of traffic to the site. The page is still mostly okay, though.

Madpoo 2020-12-31 22:33

[QUOTE=Raydex;566257]Unfortunately, normal operations on the "Milestones" page appear to have been upended by the landmark milestone of reaching 100 million, which as we all know by now, has caused a massive wave of traffic to the site. The page is still mostly okay, though.[/QUOTE]

After that page got super busy from the hacker news link, I reconfigured how those stats are calculated. In my haste I set a failsafe "low boundary" for the LL checks to 101M instead of 100M ... whoops.

I did eventually fix it once I noticed. :smile:

DW52 2021-01-09 14:03

Am trying to reserve exponents for double-checking slightly below M57885151 (specifically 57878000 to 57879000 - Category 3), and am getting the following error:

[B]Error text: No assignment available meeting CPU, program code and work preference requirements, cpu_id: 574193, cpu # = 0, user_id = 3175[/B]

There appear to be 17 "Unverified" in that range, with only already assigned to someone else.

I've previously reserved many in that general area (as user jg5).

Is this a PrimeNet problem? If not, how do I get around it?

ixfd64 2021-01-14 16:06

[QUOTE=DW52;568828]Am trying to reserve exponents for double-checking slightly below M57885151 (specifically 57878000 to 57879000 - Category 3), and am getting the following error:

[B]Error text: No assignment available meeting CPU, program code and work preference requirements, cpu_id: 574193, cpu # = 0, user_id = 3175[/B]

There appear to be 17 "Unverified" in that range, with only already assigned to someone else.

I've previously reserved many in that general area (as user jg5).

Is this a PrimeNet problem? If not, how do I get around it?[/QUOTE]

You may not have recently submitted results on your account:

[QUOTE]Computer must have enough LL and DC GHz-days over the last 120 days to indicate the assignment will be completed in 90 days.[/QUOTE]

Jwb52z 2021-01-14 21:56

Today, I am getting a "Timed Out" error on port 80 when I try to manually communicate with the server.

tServo 2021-01-16 16:16

I have recently noticed that user SRBase will occasionally flood the server with lots ( over 700 at once this morning ) of results. The server will freeze while trying to digest this. Any thoughts to asking them that they trickle their results in?

tha 2021-01-16 17:46

Usually when a PRP results comes in the assignment for a proof is very shortly afterwards. But quite some results have had no assignment for proofs. I am listing a few of them here as an example. What has caused these exponents with completed PRP work done not to be assigned for proving?

[CODE]
102000071
102000077
102000109
102000161
102000397
102000433
102000463
102000499
[/CODE]

ixfd64 2021-01-16 18:15

Support for proofs was only added to Prime95 last year. There are some people who have not yet upgraded to the latest version.

James Heinrich 2021-01-16 18:36

PRP+proof support came with v30 and that was released Aug/Sep 2020, the quoted examples all had their PRP done in May/Jun 2020.

tServo 2021-01-16 18:59

[QUOTE=tServo;569447]I have recently noticed that user SRBase will occasionally flood the server with lots ( over 700 at once this morning ) of results. The server will freeze while trying to digest this. Any thoughts to asking them that they trickle their results in?[/QUOTE]

I have also noticed that exponents that I submitted are still reserved. This happened saturday, UTC 15:47.

PhilF 2021-01-16 19:20

[QUOTE=tServo;569476]I have also noticed that exponents that I submitted are still reserved. This happened saturday, UTC 15:47.[/QUOTE]

Related thread:

[url]https://www.mersenneforum.org/showthread.php?t=26407[/url]

tServo 2021-01-16 19:38

[QUOTE=PhilF;569478]Related thread:

[url]https://www.mersenneforum.org/showthread.php?t=26407[/url][/QUOTE]

Spot on !
I wonder if this problem is related to the tsunami of SRBase submissions I noticed.

rebirther 2021-01-17 09:26

[QUOTE=tServo;569447]I have recently noticed that user SRBase will occasionally flood the server with lots ( over 700 at once this morning ) of results. The server will freeze while trying to digest this. Any thoughts to asking them that they trickle their results in?[/QUOTE]


You must think bigger ;) The limit is around 10k at once, last time I have reported around 170k results without any problems. At this time I can only report around 1.5k results before the server is running into the ressource error. Its very slow at the moment. I had around 70k results which were already reported but still assigned yesterday. I sent a PM to prime95 to take a look.


If someone has a script which is reporting line by line from a results file that would be great. Thx everyone, looking forward...

ixfd64 2021-01-17 21:39

I noticed that all PRP results for cofactors are now marked as "Factored" regardless of whether or not a factor has been found.

James Heinrich 2021-01-17 22:25

[QUOTE=ixfd64;569541]I noticed that all PRP results for cofactors are now marked as "Factored" regardless of whether or not a factor has been found.[/QUOTE]Can you provide a specific example please?

ixfd64 2021-01-17 22:34

1 Attachment(s)
[QUOTE=James Heinrich;569544]Can you provide a specific example please?[/QUOTE]

Pretty much all of them. Even prime cofactors are marked as "verified." I've attached a screenshot as an example.

James Heinrich 2021-01-17 22:56

Your example ([m]M57131[/m]) is [url=https://www.mersenne.ca/prp.php?show=1&min_exponent=57131&max_exponent=57131]apparently[/url] certified P17152 in addition to those 4 factors, so I'm not sure what part you're objecting to. Perhaps re-explain this for me?


The thing I do find odd with this exponent is the result from [i]Squeeky_Squirrel[/i] on 2017-12-31 as a PRP claimed on only 1 cofactor. Moreover, the history for the exponent doesn't list this test so I can't see that in more detail (and also the result won't show up on mersenne.ca since the export data is from the history log). Perhaps George or Aaron can poke around in the database and make some sense of this? My best guess is that the second run uses the composite of the small known factors as the supplied cofactor and primenet didn't (at the time, it does now) check that the supplied cofactor was prime.

Viliam Furik 2021-01-17 23:30

[QUOTE=James Heinrich;569547]Your example ([m]M57131[/m]) is [url=https://www.mersenne.ca/prp.php?show=1&min_exponent=57131&max_exponent=57131]apparently[/url] certified P17152 in addition to those 4 factors, so I'm not sure what part you're objecting to. Perhaps re-explain this for me?


The thing I do find odd with this exponent is the result from [i]Squeeky_Squirrel[/i] on 2017-12-31 as a PRP claimed on only 1 cofactor. Moreover, the history for the exponent doesn't list this test so I can't see that in more detail (and also the result won't show up on mersenne.ca since the export data is from the history log). Perhaps George or Aaron can poke around in the database and make some sense of this? My best guess is that the second run uses the composite of the small known factors as the supplied cofactor and primenet didn't (at the time, it does now) check that the supplied cofactor was prime.[/QUOTE]

Perhaps the composite 4-factor was used as a whole, not as 4 factors after the assignments.

ixfd64 2021-01-17 23:44

[QUOTE=James Heinrich;569547]Your example ([m]M57131[/m]) is [url=https://www.mersenne.ca/prp.php?show=1&min_exponent=57131&max_exponent=57131]apparently[/url] certified P17152 in addition to those 4 factors, so I'm not sure what part you're objecting to. Perhaps re-explain this for me?


The thing I do find odd with this exponent is the result from [i]Squeeky_Squirrel[/i] on 2017-12-31 as a PRP claimed on only 1 cofactor. Moreover, the history for the exponent doesn't list this test so I can't see that in more detail (and also the result won't show up on mersenne.ca since the export data is from the history log). Perhaps George or Aaron can poke around in the database and make some sense of this? My best guess is that the second run uses the composite of the small known factors as the supplied cofactor and primenet didn't (at the time, it does now) check that the supplied cofactor was prime.[/QUOTE]

It's my understanding that a primality test is marked as "factored" if the a factor is found for the exponent or cofactor. In this particular example, the cofactor is prime and should not have any factors. Yet it's still marked as "factored" even where all other four factors are accounted for. This was not the case until recent months.

James Heinrich 2021-01-17 23:52

[QUOTE=ixfd64;569551]It's my understanding that a primality test is marked as "factored" if the a factor is found for the exponent or cofactor.[/QUOTE]It is my understanding that a PRP test can show one of:[list][*]Unverified (suspect) -- single test but errors were detected in the test[*]Unverified (reliable) -- single test and no errors detected[*]Verified -- PRP confirmed either with multiple tests or proof, no known factors[*]Verified (factored) -- PRP confirmed either with multiple tests or proof, some known factors[/list]PRP tests are always run on the smallest unknown, in most cases that's the entire Mersenne number but when factors are know then it's the remaining cofactor, which is also usually composite but occasionally (as here) you find a large PRP cofactor that is usually (always?) eventually certified-prime.

ixfd64 2021-01-18 05:54

[QUOTE=James Heinrich;569552][list][*]Verified (factored) -- PRP confirmed either with [B]multiple tests[/B] [U]or[/U] proof, some known factors[/list][/QUOTE]

Ah, that explains why these results are marked as "factored." However, this is inconsistent with regular primality test results, which are only marked as "factored" if a factor was actually found.

If I remember correctly, PRP cofactor tests worked the same way until recently. I feel this could be confusing because "factored" implies that further factors were found since the test. For example, the cofactor of [m]10010081[/m] is marked as "factored" even though the exponent has only one known prime factor. The label would imply there are at least two.

Perhaps other members could chime in.

perfectGrease 2021-01-18 15:42

[CODE]PrimeNet success code with additional info:
LL test successfully completes double-check of M59059697 --
CPU credit is 131.2028 GHz-days.
Getting assignment from server
PrimeNet success code with additional info:
Server assigned Lucas Lehmer primality double-check work.
Got assignment ID REDACTED : Double check M63159671 [/CODE]

Linux log says, that my result was accepted and the new assignment given, but none of these is visible in the account information on mersenne.org, for a couple of days already.

Uncwilly 2021-01-18 16:24

[QUOTE=perfectGrease;569596][CODE]PrimeNet success code with additional info:
LL test successfully completes double-check of M59059697 --
CPU credit is 131.2028 GHz-days.[/CODE]

Linux log says, that my result was accepted and the new assignment given, but none of these is visible in the account information on mersenne.org, for a couple of days already.[/QUOTE]
[M]59059697[/M] shows the result turned in yesterday by Anonymous. Are you sure that your machine is set-up to be connected to your PrimeNet account (not your forum account)?
And [m]63159671[/m] is assigned to Anonymous too.

And don't post assignment IDs.

perfectGrease 2021-01-18 17:33

[QUOTE=Uncwilly;569600][M]59059697[/M] shows the result turned in yesterday by Anonymous. Are you sure that your machine is set-up to be connected to your PrimeNet account (not your forum account)?
And [m]63159671[/m] is assigned to Anonymous too.

And don't post assignment IDs.[/QUOTE]

Thank you for removing the assignment ID.

This CPU has already delivered a few results under my name, and its status on the page was green, so I (wrongly) assumed it is connected.
It hasn't been used for a while and lost the connection to my PrimeNet account.
I set the account again, and it is ok now. Thanks for the hint!

perfectGrease 2021-01-18 21:30

[QUOTE=Uncwilly;569600][M]59059697[/M] shows the result turned in yesterday by Anonymous.[/QUOTE]

What is interesting though, my computer was given GHz Days for this one, but my PrimeNet account was not.
So, my PrimeNet account's GHz Days is no longer the sum of all my computers' GHz Days.

LaurV 2021-01-19 03:38

George or James can fix this for you, and assign you the proper credit if the report came from the same system (which is easy to check).

James Heinrich 2021-01-19 04:40

[QUOTE=LaurV;569633]George [STRIKE]or James[/STRIKE] can fix this for you[/QUOTE]Not me, just George.

retina 2021-01-24 09:36

[QUOTE=retina;560104][code]----------=-----=-- | -----=-----=-----=-----=----- | -----=-----=-----=----- | -----=-----=-----=----- |
Exponent Range | Composite | Status Unproven | Assigned | Available |
Start Count P | F DC |LL/PRP ERR NO-LL | ECM P-1 LL/PRP DC | ECM P-1 LL/PRP DC |
----------=-----=-- | -----=-----=-----=-----=----- | -----=-----=-----=----- | -----=-----=-----=----- |
0 78498 33 | 63187 15278 | 6439 | 15278 |
1000000 70435 2 | 52798 17635 | 750 27 | 17634 |
2000000 67883 1 | 48797 19085 | 1778 14 | 19085 |
3000000 [color=red]66330 1 | 45820 20510 [/color]| 687 6 | 20509 |
4000000 [color=red]65367 | 44709 20659 [/color]| 1 5 | 20658 |
5000000 64336 | 43740 20596 | 18 | 20596 |
6000000 [color=red]63799 1 | 43013 20786 [/color]| 1 7 | 20785 |
7000000 [color=red]63129 | 42279 20851 [/color]| 1 291 | 20850 |
8000000 62712 | 41657 21055 | 28 2 336 | 21053 |
9000000 62090 | 40929 21161 | 4 51 671 9 | 21110 |
10000000 [color=red]61938 | 40933 21007 1 [/color]| 2 570 | 21005 |[/code]Is the DB corrupted?[/QUOTE]This problem still exists. It has expanded into other parts of the DB.[code]----------=-----=-- | -----=-----=-----=-----=----- | -----=-----=-----=----- | -----=-----=-----=----- |
Exponent Range | Composite | Status Unproven | Assigned | Available |
Start Count P | F DC |LL/PRP ERR NO-LL | TF P-1 LL/PRP DC | TF P-1 LL/PRP DC |
----------=-----=-- | -----=-----=-----=-----=----- | -----=-----=-----=----- | -----=-----=-----=----- |
100000000 54208 | 35166 15704 [color=red]3338[/color] | [color=red]32[/color] | [color=red]3302[/color] |[/code]Adding the assigned and available 3302 + 32 != 3338

gjmccrac 2021-01-24 13:18

Also in this section the values to do not balance

[CODE] 240000000 52073 | 31277 1 20795 | 3 | 20789 2 1 |
241000000 51674 | 30940 20734 | | 20731 2 1 |
[COLOR="Red"] 242000000 51625 | 31104 20521 | | 15190 3 1 |
243000000 51704 | 30772 20932 | 1 | 2535 |
244000000 52040 | 31187 20853 | | 11963 4 1 |
[/COLOR] 245000000 51723 | 30937 20786 | 15 | 20757 |
246000000 51693 | 31308 20385 | | 20308 76 1 |
247000000 51695 | 31012 20683 | 24 | 20640 18 1 |
248000000 51780 | 31161 20619 | | 20612 6 1 |
249000000 51767 | 30860 20907 | | 20895 11 1 |

----------=-----=-- | -----=-----=-----=-----=----- | -----=-----=-----=----- | -----=-----=-----=----- |
Exponent Range | Composite | Status Unproven | Assigned | Available |
Start Count P | F DC |LL/PRP ERR NO-LL | TF P-1 LL/PRP DC | TF P-1 LL/PRP DC |
----------=-----=-- | -----=-----=-----=-----=----- | -----=-----=-----=----- | -----=-----=-----=----- |[/CODE]

lisanderke 2021-01-24 16:54

Not sure if it's worth mentioning here, but I seem to be able to manually submit my small ECM'ed assignments multiple times and I get credit multiple times for only one iteration of the for example 7 curves I ran. These were assignments I received through Prime95. I decided to submit my Prime95 results file manually due to having ran some unassigned work on small exponents. I'm not sure if me having sent multiple ECM results (that were essentially the same work done) has in some way added on to a tally of these curves being ran on those numbers.

James Heinrich 2021-01-24 17:46

[QUOTE=lisanderke;570010]I seem to be able to manually submit my small ECM'ed assignments multiple times
.. has in some way added on to a tally of these curves being ran on those numbers.[/QUOTE]Yes, it's possible since it's hard to authenticate whether a submitted result is a new set of results or the same result submitted again.
It will affect the number of future curves run at the current bounds (since the server now thinks the exponent has had more ECM factoring applied than it actually has). If you have a definitive list of which exact exponents you duplicate-submitted and how many extra curves you claimed but didn't actually run, you could PM this to George and he may wish to fiddle the database to make the correction (or not, at his discretion).
Please avoid duplicate ECM result submissions. :smile:

Madpoo 2021-01-24 18:01

[QUOTE=gjmccrac;569991]Also in this section the values to do not balance

[CODE] 240000000 52073 | 31277 1 20795 | 3 | 20789 2 1 |
241000000 51674 | 30940 20734 | | 20731 2 1 |
[COLOR="Red"] 242000000 51625 | 31104 20521 | | 15190 3 1 |
243000000 51704 | 30772 20932 | 1 | 2535 |
244000000 52040 | 31187 20853 | | 11963 4 1 |
[/COLOR] 245000000 51723 | 30937 20786 | 15 | 20757 |
246000000 51693 | 31308 20385 | | 20308 76 1 |
247000000 51695 | 31012 20683 | 24 | 20640 18 1 |
248000000 51780 | 31161 20619 | | 20612 6 1 |
249000000 51767 | 30860 20907 | | 20895 11 1 |

----------=-----=-- | -----=-----=-----=-----=----- | -----=-----=-----=----- | -----=-----=-----=----- |
Exponent Range | Composite | Status Unproven | Assigned | Available |
Start Count P | F DC |LL/PRP ERR NO-LL | TF P-1 LL/PRP DC | TF P-1 LL/PRP DC |
----------=-----=-- | -----=-----=-----=-----=----- | -----=-----=-----=----- | -----=-----=-----=----- |[/CODE][/QUOTE]

I haven't checked the forums lately and wasn't aware there was an issue.

I'd guess these instances have something to do with the new certification work types being done, or something like that. It's something to look at when time allows.

Madpoo 2021-01-24 18:40

[QUOTE=Madpoo;570021]I haven't checked the forums lately and wasn't aware there was an issue.

I'd guess these instances have something to do with the new certification work types being done, or something like that. It's something to look at when time allows.[/QUOTE]

Never mind the cert... I see these are for ranges much higher than the current assignment range for first-time checks.

And you're specifically referring to the "Available" counts (since the total-composite-noLL=0)

For example, for 242M there are 20521 with no LL (or PRP) done, so the # available should add up to that. That gives me something to look into... odds are they're probably available but as one of the obscure work types, and the report isn't showing those. :smile:

lisanderke 2021-01-24 18:48

[QUOTE=James Heinrich;570017]Yes, it's possible since it's hard to authenticate whether a submitted result is a new set of results or the same result submitted again.
It will affect the number of future curves run at the current bounds (since the server now thinks the exponent has had more ECM factoring applied than it actually has). If you have a definitive list of which exact exponents you duplicate-submitted and how many extra curves you claimed but didn't actually run, you could PM this to George and he may wish to fiddle the database to make the correction (or not, at his discretion).
Please avoid duplicate ECM result submissions. :smile:[/QUOTE]
Oh dear... I have turned in an awful amount of bogus results...
A small list of some of these exponents I accidentally over-submitted as new ECM curves:
[url]https://www.mersenne.org/report_exponent/?exp_lo=226313&exp_hi=&full=1&ecmhist=1[/url]
[url]https://www.mersenne.org/report_exponent/?exp_lo=230341&exp_hi=&full=1&ecmhist=1[/url]
[url]https://www.mersenne.org/report_exponent/?exp_lo=178397&exp_hi=&full=1&ecmhist=1[/url]
[url]https://www.mersenne.org/report_exponent/?exp_lo=218611&exp_hi=&full=1&ecmhist=1[/url]
[url]https://www.mersenne.org/report_exponent/?exp_lo=233509&exp_hi=&full=1&ecmhist=1[/url]
[url]https://www.mersenne.org/report_exponent/?exp_lo=224443&exp_hi=&full=1&ecmhist=1[/url]

lisanderke 2021-01-24 18:50

It seems in total I have 606 counts of a bogus result submission (as in: any amount of submissions more than just the first time I clocked in the result.)


I'm able to pin-point every one of them in my results tab, sorting by ECM->only manual results. I'm not sure if I should print this page to pdf and attach it in an email or perhaps go through every single exponent and say that only 1 of the results for said exponents should be valid...


Edit: missed a plural form of a word :)

Madpoo 2021-01-24 19:36

[QUOTE=Madpoo;570028]Never mind the cert... I see these are for ranges much higher than the current assignment range for first-time checks.

And you're specifically referring to the "Available" counts (since the total-composite-noLL=0)

For example, for 242M there are 20521 with no LL (or PRP) done, so the # available should add up to that. That gives me something to look into... odds are they're probably available but as one of the obscure work types, and the report isn't showing those. :smile:[/QUOTE]

I think it comes down to some cleanup work George did, removing ancient TF assignments. They didn't seem to get re-added to the list of available exponents.

I'm running some cleanup now - it seems like it was mostly centered around some specific ranges where people had reserved a bunch of TF and then abandoned them, but there are a handful of others here and there. Could take a while to get them all sorted and then we'll see how it looks.

VBCurtis 2021-01-24 20:43

[QUOTE=lisanderke;570031]It seems in total I have 606 counts of a bogus result submission (as in: any amount of submissions more than just the first time I clocked in the result.)


I'm able to pin-point every one of them in my results tab, sorting by ECM->only manual results. I'm not sure if I should print this page to pdf and attach it in an email or perhaps go through every single exponent and say that only 1 of the results for said exponents should be valid...


Edit: missed a plural form of a word :)[/QUOTE]

Sounds like you have a lot of ECM work to do to make your reports accurate! :)

Prime95 2021-01-24 22:22

[QUOTE=lisanderke;570030]Oh dear... I have turned in an awful amount of bogus results...
[/QUOTE]

I'm not overly concerned. The only negatives are 1) we switch to the next B1 bound a little earlier than we would have (and that's not necessarily a bad thing), and 2) you have some unearned CPU credit.

If you feel particularly guilty, you can turn off "Use Primenet" option, fill your worktodo.txt, and only report a factor if you find one.

lisanderke 2021-01-24 23:29

[QUOTE=Prime95;570048]I'm not overly concerned. The only negatives are 1) we switch to the next B1 bound a little earlier than we would have (and that's not necessarily a bad thing), and 2) you have some unearned CPU credit.

If you feel particularly guilty, you can turn off "Use Primenet" option, fill your worktodo.txt, and only report a factor if you find one.[/QUOTE]


But wouldn't switching to the next bound earlier not mean we might (very slight chance I presume) have missed a factor in that bound?

VBCurtis 2021-01-25 01:44

I think your question means you don't understand ECM well. If an ECM curve would find a factor, increased bounds with the same sigma would also find the factor.

There's a slight loss in efficiency in running curves "too big" for a factor hunt, but not much. For example, if an input called for B1=50k curves but you ran curves at B1=100k, you improve your chances to find a bigger factor (say, 27-29 digits) at the expense of taking longer to find a 24-25 digit factor than you would expect to take running curves at B1=50k.

So, your false reports might trigger the next user to run curves at B1=250k sooner, but that's hardly a waste. I skip the 50k level entirely sometimes, such as my current work in 14.01M range.

James Heinrich 2021-01-25 02:06

[QUOTE=VBCurtis;570055]I think your question means you don't understand ECM well.[/QUOTE]Well explained, thank you. I'm sure there's many users here (myself especially included) who run this stuff for some fun without really understanding the math behind it, so simple explanations like that are wonderful. :tu:

VBCurtis 2021-01-25 05:05

Thank you!
One more thing- if you run curves at some B1 not on the Chart, the server converts the curves to whatever level is currently being counted. The conversion doesn't use fancy math: one curve at B1 = 100k is worth two at B1= 50k (supposing both use the same B2 to B1 ratio, like the standard 100x on Prime95 before the brand-new 30.4 version). A curve at B1 = 250k is worth five at B1 = 50k, etc. Simple ratio of B1s.

If you run B1's bigger than what is suggested, this works quite well as an tracker for equivalent work done. Users are discouraged from running B1s smaller than indicated on the ECM factoring page for their input of interest.

B2 values different than 100 * B1 (such as the newest Prime95 uses) are converted using fancier math to the "standard" curves.

lycorn 2021-01-25 10:28

This morning I found one of the tasks I ran overnight had been apparently submitted (automatically) twice. Specifically, looking at my Account Results Details page on Primenet server, I found this:

colab_S_1 [B]3141443[/B] NF-ECM 2021-01-25 [B]09:26[/B] 0.0 7 curves, B1=50000, B2=6750000 0.9467
colab_S_1 [B]3141443[/B] NF-ECM 2021-01-25 [B]09:10[/B] 0.5 7 curves, B1=50000, B2=6750000 0.9467

So, it would seem that the instance Colab_S_1 had done and submitted 7 curves at 09:10, and then another set of 7 curves for the same exponent 16 minutes later. This is obviously not possible, as this task takes ~ 1h50m.
Now what really baffles me is that the task ran between 07:37 and 09:26 AM, as per the mprime output. Then mprime reported it only once, at 09:26..A report of it being finished at 09:10 is absolutely out of whack, as it was still running at that time.
It´s the first time I spot such a thing and I have no clues as to what might have happened. On top of the minor inconvenience of having 7 curves logged that haven´t actually been run, this may indicate some problem in the logging process.
Any ideas?

lycorn 2021-01-25 14:53

Follow-up:

I´ve been digging in the results.txt for this particular colab instance, and found that all 6 ECM tasks that started and finished during the session lifetime (i.e. from 23:15 PM yesterday to 11:15 AM today) have had exactly the same behaviour: result sent to the server, and within 15 to 20 minutes another message is sent, with the same data, hence resulting in two results, of which only the first one is meaningful. Upon the session expiration I reconnected to GCE and started a fresh instance of the same notebook. The problem appears to have gone.

That´s something that was somehow connected to that particular combination of notebook / server where it was being run. I have been running this notebook for a long time and never had a single problem.

Funny...

So it´s certainly not a problem on the server side. Any moderator may wish to remove the posts from this thread. Sorry for any inconvenience.

retina 2021-02-11 03:30

[QUOTE=retina;569982][QUOTE=retina;560104][code]----------=-----=-- | -----=-----=-----=-----=----- | -----=-----=-----=----- | -----=-----=-----=----- |
Exponent Range | Composite | Status Unproven | Assigned | Available |
Start Count P | F DC |LL/PRP ERR NO-LL | ECM P-1 LL/PRP DC | ECM P-1 LL/PRP DC |
----------=-----=-- | -----=-----=-----=-----=----- | -----=-----=-----=----- | -----=-----=-----=----- |
0 78498 33 | 63187 15278 | 6439 | 15278 |
1000000 70435 2 | 52798 17635 | 750 27 | 17634 |
2000000 67883 1 | 48797 19085 | 1778 14 | 19085 |
3000000 [color=red]66330 1 | 45820 20510 [/color]| 687 6 | 20509 |
4000000 [color=red]65367 | 44709 20659 [/color]| 1 5 | 20658 |
5000000 64336 | 43740 20596 | 18 | 20596 |
6000000 [color=red]63799 1 | 43013 20786 [/color]| 1 7 | 20785 |
7000000 [color=red]63129 | 42279 20851 [/color]| 1 291 | 20850 |
8000000 62712 | 41657 21055 | 28 2 336 | 21053 |
9000000 62090 | 40929 21161 | 4 51 671 9 | 21110 |
10000000 [color=red]61938 | 40933 21007 1 [/color]| 2 570 | 21005 |[/code]Is the DB corrupted?[/QUOTE]This problem still exists. It has expanded into other parts of the DB.[code]----------=-----=-- | -----=-----=-----=-----=----- | -----=-----=-----=----- | -----=-----=-----=----- |
Exponent Range | Composite | Status Unproven | Assigned | Available |
Start Count P | F DC |LL/PRP ERR NO-LL | TF P-1 LL/PRP DC | TF P-1 LL/PRP DC |
----------=-----=-- | -----=-----=-----=-----=----- | -----=-----=-----=----- | -----=-----=-----=----- |
100000000 54208 | 35166 15704 [color=red]3338[/color] | [color=red]32[/color] | [color=red]3302[/color] |[/code]Adding the assigned and available 3302 + 32 != 3338[/QUOTE]This problem is slowly but surely eating up the DB. Soon there will be no valid figures available.[code]----------=-----=-- | -----=-----=-----=-----=----- | -----=-----=-----=----- | -----=-----=-----=----- |
Exponent Range | Composite | Status Unproven | Assigned | Available |
Start Count P | F DC |LL/PRP ERR NO-LL | TF P-1 LL/PRP DC | TF P-1 LL/PRP DC |
----------=-----=-- | -----=-----=-----=-----=----- | -----=-----=-----=----- | -----=-----=-----=----- |
54000000 55997 | 36535 19005 [color=red]457 | 439 | 13[/color] |
[/code]457 != 439 + 13

Viliam Furik 2021-02-11 11:02

Is it possible that the missing numbers are the exponents which have been completed, but not yet certified (or some other state which is related to the certification process)?

Uncwilly 2021-02-11 14:57

[QUOTE=Viliam Furik;571309]Is it possible that the missing numbers are the exponents which have been completed, but not yet certified (or some other state which is related to the certification process)?[/QUOTE]
Nothing is getting a cert down in the 54M range

section31 2021-02-11 15:11

2 Attachment(s)
My AMD Athlon 64 3700+ is set to "Whatever makes the most sense" for its assignments, and it recently was assigned a category 4 PRP, which would seem to be way out of its ability to return before the assignment expires; it's over 400 days. The rules say "Assignments are recycled ... when the exponent moves midway into the first category and the assignment is more than 360 days old." I guess I have no way of knowing if that will happen or not.

Should I manually unreserve this exponent?
Should I set this machine to only ask for DDs? This is its first PRP after doing mostly DD and CERTS since I set it to "Whatever makes the most sense".
Is this even worth worrying about?

Prime95 2021-02-11 17:48

[QUOTE=section31;571318]
Should I manually unreserve this exponent?
Should I set this machine to only ask for DDs? [/QUOTE]

I would not have the patience to wait 400 days for a result. I would unreserve it and ask for double-checks. You may do whatever makes you happy.

I'll check the assignment code to give double-checks to lesser powered machines

Prime95 2021-02-15 06:44

[QUOTE=retina;571290]This problem is slowly but surely eating up the DB. Soon there will be no valid figures available.[/QUOTE]


So I looked at the off-by-4 in the 100M - 101M range.
The four exponents are awaiting a proof to be uploaded. Thus, they aren't DCed, nor are they available for assignment. They are in limbo. Suggestions? Count them as assigned-for-PRP (though the PRP result was reported, technically the assignment is not complete). Lump them in with assigned DC (it not under active DC). A new column called "stalled"?

Edit: The server is currently configured to wait forever for a proof to be uploaded

retina 2021-02-15 06:58

[QUOTE=Prime95;571633]Count them as assigned-for-PRP (though the PRP result was reported, technically the assignment is not complete.[/QUOTE]Yes, this.

And expire them as usual. No special treatment.

slandrum 2021-02-15 08:51

What about the off-by-5 in the 54M to 55M range? There are 5 more needing DC than are assigned DC currently, and none are available for DC.

Prime95 2021-02-15 10:19

[QUOTE=slandrum;571637]What about the off-by-5 in the 54M to 55M range? There are 5 more needing DC than are assigned DC currently, and none are available for DC.[/QUOTE]

Those 5 were all unaccounted for -- neither assigned or available. They are now available.

Viliam Furik 2021-02-15 11:34

[QUOTE=retina;571634]Yes, this.

And expire them as usual. No special treatment.[/QUOTE]

Expire, yes. But keep the RES64 for DC.

chalsall 2021-02-15 15:02

[QUOTE=Prime95;571641]Those 5 were all unaccounted for -- neither assigned or available. They are now available.[/QUOTE]

And, another oddity...[CODE]101000000 54316 | 35141 14659 4471 [COLOR="Red"]45[/COLOR] | 135 6 [COLOR="Red"]39 6[/COLOR] | [COLOR="red"]1[/COLOR] 4323 |[/CODE]

kriesel 2021-02-15 15:43

unable to get p-1 manual assignments (unwanted double checks substituted)
 
Are others seeing this issue?

~0730 UTC 2021-02-15, 32 of 32 attempts at manual P-1 assignments (an attempt at a batch of 31 followed by a retest requesting 1), respond like this:
[CODE]
Not enough available memory for P-1 factoring assignments.

DoubleCheck=(AID),58660957,74,1[/CODE]Problem persists now ~1530 UTC 2021-02-15 (a single 11-assignment request)
Can not get any new P-1 assignments for gpuowl v6.11 on gpus.
It takes around 30 per Radeon VII per day at the P-1 for first-test wavefront.

PM to James Heinrich ~0730 UTC but it is outside his realm.
PM to Prime95 ~1531 UTC
I can temporarily busy the gpus going empty, with PRP, or P-1/PRP for high exponents, but that does not help clear the P-1 for others doing wavefront PRP who perhaps have too little ram for an efficient P-1.

(edit:) FWIW, PrimeNet API/prime95 does not appear to be affected, as of 2021-02-15 1130 UTC.
(edit 2:) Assigning LL DC 1:1 in place of requested P-1 is overkill, comprising several times the GhzD per assignment at gpuowl default P-1 bounds. (LL DC 56M ~ 120. GhzD, 102M P-1 at 1M, 30M ~15. GhzD, each; ~8:1 ratio over requested work.)

Zenzoma 2021-02-15 19:09

Happened to me too. I got 13 DC LL's instead of PM1's a few hours ago.

Each manual assignment had this text:

"Not enough available memory for P-1 factoring assignments."

Prime95 2021-02-15 21:03

[QUOTE=MattL;571669]Happened to me too. I got 13 DC LL's instead of PM1's a few hours ago.[/QUOTE]

Please try again.

I increased the CPU power required to get first-time tests. While I was at it I increased the amount of RAM a client must have to get P-1 assignments. In the process, I messed up manual assignments.

Uncwilly 2021-02-15 22:03

[QUOTE=Prime95;571686]While I was at it I increased the amount of RAM a client must have to get P-1 assignments.[/QUOTE]Can you start enforcing expiration on P-1?
There are a bunch here with no progress and are a month old:
[url]https://www.mersenne.org/assignments/?exp_lo=101078797&exp_hi=103000000&execm=1&exdchk=1&exfirst=1&extf=1&excert=1[/url]

slandrum 2021-02-16 05:23

Off by one in the 101M to 102M range
 
2 Attachment(s)
Snapshot at the hour, from the milestones page it shows 33 needing to be cleared, with 2 available. From the work distribution map it shows 32 w/o LL (not 33), but also shows 28 assigned to PRP/LL, 3 assigned to P-1, and 2 available for LL/PRP assignment (which does add to 33).


All times are UTC. The time now is 06:02.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.