Welcome Ben Delo
 

He's been completing DC and LL by the bucket loads the last few months.

WOW!!!

Are the DC's on the same exponents as the LL?
Not suggesting that there is anything untoward going on, just saying "доверяй, но проверяй" (doveryay, no proveryay) ["Trust, but verify"].

They seem to be genuine DCs, at least the few that I manually looked through. The computer names remind me a lot of Amazon instance names, though... C4_8XL, C5_24XL, C5_METAL :smile:

This user appears to be [I]the[/I] Ben Delo: [url]https://en.wikipedia.org/wiki/Ben_Delo[/url]

Assuming that's him, then we've got a billionaire in our ranks!

Thank you for the welcome. I have some spare AWS credit that I thought I would put towards GIMPS. Please do verify my results as I am still experimenting with different instance types and configurations.

[QUOTE=Ben Delo;527576]Please do verify my results as I am still experimenting with different instance types and configurations.[/QUOTE]

AWS instance use ECC memory. Based on past experience it's extremely unlikely that you'll get any incorrect results.

The c5 instances use AVX-512 and have more cache, so they run mprime considerably faster than c4 instances. The c5n and c5d can also be used.

It's better to run multiple instances of the one-core c5.large, or at most the two-core c5.xlarge, rather than fewer many-core instances, because then the multiple cores on the same physical machine will contend with each other for memory access and bring your throughput way down.

Note that in AWS terminology, "two vCPUs" means a single core with hyperthreading. The mprime program is highly optimized and gets no benefit from hyperthreading.

The C5 instances work very well. I always have some spot instances running. Those c5.metal instances are kinda pricey for me though. :smile: They must have a lot of memory channels since even the c5.9xlarge show no signs (that I could see) of any contention for memory.

[QUOTE=mrh;527613]They must have a lot of memory channels since even the c5.9xlarge show no signs (that I could see) of any contention for memory.[/QUOTE]

Hmmm... it was true of the c4's, but I didn't really benchmark the c5's carefully.

One issue is that if you run separate one-core c5.large instances, then AWS might still end up running them on the same physical hardware, especially if you start them all at the same time. I'm not sure if there's any way you can tell.

Maybe staggered starts help, but you might need to use a pretty long interval to be on the safe side.

[QUOTE=Ben Delo;527576]Thank you for the welcome. I have some spare AWS credit that I thought I would put towards GIMPS. Please do verify my results as I am still experimenting with different instance types and configurations.[/QUOTE]

Ah, the lights just went on - I figured the name "Delo Ben", the rendering of your name in the Paypal e-mail I got, was some kind of semi-anglicized Asian name. Thanks again for the generous donation, and for the compute cycles! IIRC the last time GIMPS saw a rough doubling of daily throughput it was due to a bunch of LL results from a fellow using my Mlucas code to stress test a bunch of ARM-based servers, but that was a 1-day deal. How many LL tests do you estimate your AWS credits to amount to?

[QUOTE=petrw1;527499]He's been completing DC and LL by the bucket loads the last few months.

WOW!!![/QUOTE]

The statistics from the Primenet reports page are AWESOME:

211 DCs and 818 1st time LLs in the past 90 days; 90% of this work was done in the last 30 days !!!!!

Thanks, indeed Ben.

[QUOTE=GP2;527617]Hmmm... it was true of the c4's, but I didn't really benchmark the c5's carefully.

One issue is that if you run separate one-core c5.large instances, then AWS might still end up running them on the same physical hardware, especially if you start them all at the same time. I'm not sure if there's any way you can tell.

Maybe staggered starts help, but you might need to use a pretty long interval to be on the safe side.[/QUOTE]

Yes I found that running 50x c5.metal was better than 2400x c5.large, but I will keep experimenting.

fack you might unseat me from the 2nd or 3rd place I've had for a few years (depending if you count anonymous results). Too bad my company is getting better at not letting hardware sit on the shelf for stuff like gimps to use.....

[QUOTE=aurashift;528002]fack you might unseat me from the 2nd or 3rd place I've had for a few years (depending if you count anonymous results). Too bad my company is getting better at not letting hardware sit on the shelf for stuff like gimps to use.....[/QUOTE]

Could we ask Ben to please switch to PRP first-time tests to reduce the eventual number of LL DC checks in the future?

[QUOTE=Chuck;528025]Could we ask Ben to please switch to PRP first-time tests to reduce the eventual number of LL DC checks in the future?[/QUOTE]

Honestly just everyone in general :)

[QUOTE=Chuck;528025]Could we ask Ben to please switch to PRP first-time tests to reduce the eventual number of LL DC checks in the future?[/QUOTE]

Yes I am looking into it

[QUOTE=Ben Delo;527576]Thank you for the welcome. I have some spare AWS credit that I thought I would put towards GIMPS. Please do verify my results as I am still experimenting with different instance types and configurations.[/QUOTE]

No worries, the results are being accepted. :smile: Thanks for participating.

As others have said, the previous results turned in by users using Amazon EC instances have been very reliable. I don't think I've ever seen a bad result.

Same goes for just about any other server with ECC memory. The only time I remember seeing bad results from those were due to very specific circumstances (the false positives that one user was turning in from one of his servers).

[QUOTE=Ben Delo;527643]Yes I found that running 50x c5.metal was better than 2400x c5.large, but I will keep experimenting.[/QUOTE]

Do you have some magic for managing so many machines and assignments? I just have a few spot instances that come and go, so I keep all the state in EFS. But I think that would get messy with 2400 instances.

[QUOTE=mrh;528111]Do you have some magic for managing so many machines and assignments? I just have a few spot instances that come and go, so I keep all the state in EFS. But I think that would get messy with 2400 instances.[/QUOTE]


cssh/csshx

Welcome aboard Ben, any prime yet?!

Ben now has more GHz-days than Curtis Cooper!

I'd be surprised if we [I]don't[/I] find a new Mersenne prime by the end of the year.

[QUOTE=ixfd64;530736]I'd be surprised if we [I]don't[/I] find a new Mersenne prime by the end of the year.[/QUOTE]

Now there's an optimist!

[QUOTE=Prime95;530763]Now there's an optimist![/QUOTE]When's your holiday vacation this year? :)

[QUOTE=kriesel;530771]When's your holiday vacation this year? :)[/QUOTE]
[url]https://wb.md/2OgJif3[/url]

[QUOTE=Batalov;530773][url]https://wb.md/2OgJif3[/url][/QUOTE]That pages fails to mention the most prevalent example of the behaviour. [spoiler]Praying to and/or believing in a god or gods.[/spoiler]

[QUOTE=retina;530774]That pages fails to mention the most prevalent example of the behaviour. [spoiler]Praying to and/or believing in a god or gods.[/spoiler][/QUOTE]

[SPOILER]
Or Wikipedia for that matter.
[/SPOILER]:smile:

Some people have no sense of humor.

Ben's future plans
 

I am wondering if Ben plans to stay with GIMPS for the foreseeable future, or just until the next Mersenne prime is found (OR until he finds a Mersenne prime).

duplicate first-PRP assignment by primenet, or poached by Ben Delo?
 

These take of order 18 days on an RX550. Will upgrade gpuowl version soon which will help.

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

[CODE]2019-12-31 08:56:53 condorella/rx550 90709987 FFT 5120K: Width 256x4, Height 64x4, Middle 10; 17.30 bits/word
2019-12-31 08:56:55 condorella/rx550 OpenCL args "-DEXP=90709987u -DWIDTH=1024u -DSMALL_HEIGHT=256u -DMIDDLE=10u -DWEIGHT_STEP=0xc.fb65b19625858p-3 -DIWEIGHT_STEP=0x9.dc1b382f1df1p-4 -DWEIGHT_BIGSTEP=0x9.837f0518db8a8p-3 -DIWEIGHT_BIGSTEP=0xd.744fccad69d68p-4 -DAMDGPU=1 -DNO_ASM=1 -DMERGED_MIDDLE=1 -DWORKINGIN5=1 -DWORKINGOUT2=1 -DT2_SHUFFLE_HEIGHT=1 -DT2_SHUFFLE_MIDDLE=1 -DT2_SHUFFLE_REVERSELINE=1 -I. -cl-fast-relaxed-math -cl-std=CL2.0"
2019-12-31 08:56:58 condorella/rx550 OpenCL compilation in 3.28 s
2019-12-31 08:57:05 condorella/rx550 90709987 OK 0 loaded: blockSize 400, 0000000000000003
2019-12-31 08:57:24 condorella/rx550 90709987 OK 800 0.00%; 15466 us/it; ETA 16d 05:42; 2acdc628cc78e4b9 (check 6.36s)
[/CODE] [CODE]2020-01-18 06:40:00 condorella/rx550 {"exponent":"90709987", "worktype":"PRP-3", "status":"C", "program":{"name":"gpuowl", "version":"v6.11-104-g91ef9a8"}, "timestamp":"2020-01-18 12:40:00 UTC", "user":"kriesel", "computer":"condorella/rx550", "aid":"[B]8C8249448DB3893C26ADE7005061____[/B]", "fft-length":5242880, "res64":"2cf903f323be13a0", "residue-type":1, "errors":{"gerbicz":0}}
[/CODE]Welcome Ben Delo, yes. Poaching, not welcome. Issuing errors, not welcome.
For me, this was, as far as I know, a legit unexpired first-test PRP assignment. But I suppose it's possible my assignment expired along the way.

That's a PRP DC right there, and across different software no less :)
I find it most likely that the exponent expired and was reassigned by primenet. This may have been caused by the exponent changing category along the way.

[QUOTE=kriesel;535428]These take of order 18 days on an RX550. Will upgrade gpuowl version soon which will help.

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

[CODE]2019-12-31 08:56:53 condorella/rx550 90709987 FFT 5120K: Width 256x4, Height 64x4, Middle 10; 17.30 bits/word
2019-12-31 08:56:55 condorella/rx550 OpenCL args "-DEXP=90709987u -DWIDTH=1024u -DSMALL_HEIGHT=256u -DMIDDLE=10u -DWEIGHT_STEP=0xc.fb65b19625858p-3 -DIWEIGHT_STEP=0x9.dc1b382f1df1p-4 -DWEIGHT_BIGSTEP=0x9.837f0518db8a8p-3 -DIWEIGHT_BIGSTEP=0xd.744fccad69d68p-4 -DAMDGPU=1 -DNO_ASM=1 -DMERGED_MIDDLE=1 -DWORKINGIN5=1 -DWORKINGOUT2=1 -DT2_SHUFFLE_HEIGHT=1 -DT2_SHUFFLE_MIDDLE=1 -DT2_SHUFFLE_REVERSELINE=1 -I. -cl-fast-relaxed-math -cl-std=CL2.0"
2019-12-31 08:56:58 condorella/rx550 OpenCL compilation in 3.28 s
2019-12-31 08:57:05 condorella/rx550 90709987 OK 0 loaded: blockSize 400, 0000000000000003
2019-12-31 08:57:24 condorella/rx550 90709987 OK 800 0.00%; 15466 us/it; ETA 16d 05:42; 2acdc628cc78e4b9 (check 6.36s)
[/CODE] [CODE]2020-01-18 06:40:00 condorella/rx550 {"exponent":"90709987", "worktype":"PRP-3", "status":"C", "program":{"name":"gpuowl", "version":"v6.11-104-g91ef9a8"}, "timestamp":"2020-01-18 12:40:00 UTC", "user":"kriesel", "computer":"condorella/rx550", "aid":"[B]8C8249448DB3893C26ADE7005061____[/B]", "fft-length":5242880, "res64":"2cf903f323be13a0", "residue-type":1, "errors":{"gerbicz":0}}
[/CODE]Welcome Ben Delo, yes. Poaching, not welcome. Issuing errors, not welcome.
For me, this was, as far as I know, a legit unexpired first-test PRP assignment. But I suppose it's possible my assignment expired along the way.[/QUOTE]

[QUOTE=preda;535436]That's a PRP DC right there, and across different software no less :)
I find it most likely that the exponent expired and was reassigned by primenet. This may have been caused by the exponent changing category along the way.[/QUOTE]Assignments are supposed to not get recategorized to a lower Cat# and thereby expired, while pending. (User standing on rug; YANK!)

The PRP DC was added to the stale list at [URL]https://www.mersenneforum.org/showpost.php?p=501181&postcount=6[/URL]

Mine was a manual assignment, for gpuowl on AMD RX550, so by assignment rules it should have been a Cat 2 when issued, and was age 21.9 days when I manually submitted the result. Cat 2 is supposed to have 30 days before expiration for no progress reported.
The most favorable interpretation is that Cat1 rules got applied and Delo ran it on very fast gear.

If it was possible to do progress reporting for manual assignments, this perhaps could be avoided.

Manual testing[URL="https://www.mersenne.org/report_exponent/?exp_lo=90709987&full=1"] 90709987[/URL] C-PRP 2020-01-18 15:1221.92CF903F323BE13A0 21.9 days 328.5717

Oh well, it dinged my PRP but boosted my PRP-DC standing.

And there was only ~1ppm chance of finding a prime as a first-test PRP.

I will check the logs but it is possible this may have been due to me using AWS spot instances that can come and go, leaving assignments neglected for weeks. Sometimes an assignment expires (and it is reassigned) but PrimeNet does not tell mprime to stop working on it!

[QUOTE=Ben Delo;535507]I will check the logs but it is possible this may have been due to me using AWS spot instances that can come and go, leaving assignments neglected for weeks. Sometimes an assignment expires (and it is reassigned) but PrimeNet does not tell mprime to stop working on it![/QUOTE]Thanks for responding. I've checked my own assignment lists and logs.

It looks like I owe you and the PrimeNet authors and operators an apology.
(Do 10 LL DC and 5 PRP DC as penance. (Any Catholics will get that line.))

It seems I'm getting Cat 1 manual assignments occasionally. It turns out I've been a bit sloppy lately about checking they'll complete before expiration. Even though that is simple to do; [URL]https://www.mersenne.org/workload/[/URL], click on "Expires (days)" to sort by expiration order. There's one now that you're legitimately running as a reassignment and will likely finish before I do. 90710093 [URL]https://www.mersenne.org/report_exponent/?exp_lo=90710093&exp_hi=&full=1[/URL]
Another I've shifted to a Radeon VII to finish today before expiration. 90895003 [URL]https://www.mersenne.org/report_exponent/?exp_lo=90895003&full=1[/URL] will be close, with 8 hours to run and 1 day indicated to expiration.

All of this would become moot if we could do manual assignment progress reporting, perhaps on the manual submission page. But I assume the folks that could make that happen are busy with other things. (Including things I've added to the queue, such as sorting out the PRP first vs PRP DC handling.)

[QUOTE=kriesel;535523]It seems I'm getting Cat 1 manual assignments occasionally. It turns out I've been a bit sloppy lately about checking they'll complete before expiration. Even though that is simple to do; [URL]https://www.mersenne.org/workload/[/URL], click on "Expires (days)" to sort by expiration order. There's one now that you're legitimately running as a reassignment and will likely finish before I do. 90710093 [URL]https://www.mersenne.org/report_exponent/?exp_lo=90710093&exp_hi=&full=1[/URL]
Another I've shifted to a Radeon VII to finish today before expiration. 90895003 [URL]https://www.mersenne.org/report_exponent/?exp_lo=90895003&full=1[/URL] will be close, with 8 hours to run and 1 day indicated to expiration.

All of this would become moot if we could do manual assignment progress reporting, perhaps on the manual submission page. But I assume the folks that could make that happen are busy with other things. (Including things I've added to the queue, such as sorting out the PRP first vs PRP DC handling.)[/QUOTE]

Ken, I regulalrly use the time-extensions since I have a significant number of slow devices, notably my Galaxy S7 Adroid phone cluster running Mlucas. Here is the method I use to manage things - the workload page is handy, but going straight to the Manual Tests -> Extensions page shows more or less the same info, only drawback is in a non-sortable table format, so you have to scan the days-to-expiry column. (Perhaps adding sortability to this table would not be difficult, we'd need to ask Aaron.) Any that are less than a week from expiry, click the checkbox for and then extend them all via the main widget. At the same time I make note of the soonest-to-expire remaining in the resulting updated table, and mark my calendar app with an "extend assignments" alert for the day corresponding to the next-to-expire having 1 day left. Since I tend to reserve new work in batches I only need to do this every few weeks. Each renewal I simply edit the calendar reminder to update the date.

Rre. your note on manual assignment progress reporting, I actually worked with Aaron over a few weeks last year to add this functionality to the primenet.py script I ship with Mlucas. (It's there in the v19 py-script, it's just not called). The remaining sticking point was that assignment-progress-update calls to the Primenet server require update-computer (also in the v5 API) to have been called in the past 30 days (IIRC), and that currently only works for "trusted clients", i.e. for Prime95/mprime. The way I was able to test it for my py-script was that Aaron went in and manually did an update-computer for my UID on the server.

[QUOTE=ewmayer;535595]The remaining sticking point was that assignment-progress-update calls to the Primenet server require update-computer (also in the v5 API) to have been called in the past 30 days (IIRC), and that currently only works for "trusted clients", i.e. for Prime95/mprime.[/QUOTE]

If it's of any help ewmayer, GPU72 has a similar issue with one of it's spiders. My hack is to have a slaved mprime with the same CID contact Primenet once a day saying "Hi. I'm still here."

Not sure if this could be easily implemented in a wider deployment scenario. Probably better to figure out how to talk to the API with untrusted code. Perhaps limit any database deltas possible to be solely the last contact date -- no security exposure, and would solve your problem more gracefully.

[QUOTE=chalsall;535596]If it's of any help ewmayer, GPU72 has a similar issue with one of it's spiders. My hack is to have a slaved mprime with the same CID contact Primenet once a day saying "Hi. I'm still here."

Not sure if this could be easily implemented in a wider deployment scenario. Probably better to figure out how to talk to the API with untrusted code. Perhaps limit any database deltas possible to be solely the last contact date -- no security exposure, and would solve your problem more gracefully.[/QUOTE]
I have a largish perl script in development and daily use, that among other actions, gathers new results from however many gpu app instances it's configured for, on a system, into one file. Currently that is manually submitted by me. It handles the most common versions of the BIG SIX gpu apps: cllucas cudalucas cudapm1 gpuowl mfaktc mfakto. Each app instance's results may have configured in its ini files or batch file a different compound UID/CID combo, unique per system/gpu/app-instancecount, for full traceability back to the result's origin. So for example, Kriesel/condor-gtx1060-2 identifies the TF result as coming from the second instance/folder for the gtx1060 on system condor. TF throughput is higher with multiple instances, so on some gpus where the percentage gain is sufficient in my opinion, which tends to be cards gtx 480 or 1060 and faster, I run 2 or sometimes 3 instances in parallel. Now multiply that by several systems equipped with gpus (mostly multiple) and with multiple app types. Manual reporting lumps them all into a single manual bin which has no corresponding cpu or mprime/prime95 instance or CID. That bin contains the great majority of all my results, at 72% of the total currently.
I would like to be able to interface the script to PrimeNet eventually, and make it available to others to use, including with precompiled executables (which I have working now for my own local distribution for test to multiple systems some of which do not have perl installed).

It sounds like the PrimeNet API is not currently well suited to gpu support or to untrusted-app support.
Both EWMayer and Preda have grappled with it and turned back.

[QUOTE=kriesel;535428]Welcome Ben Delo, yes. Poaching, not welcome. Issuing errors, not welcome.
For me, this was, as far as I know, a legit unexpired first-test PRP assignment. But I suppose it's possible my assignment expired along the way.[/QUOTE]

The same as with me, no poaching, only early double check, but my old hardware still seems to be working fine.:smile:

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

Ben is doing over 10x the [URL="https://www.mersenne.org/report_top_500_ll/"]first time tests[/URL] of Curtis "Chuck Norris" Cooper atm :flex:

[QUOTE=paulunderwood;551439]Ben is doing over 10x the [URL="https://www.mersenne.org/report_top_500_ll/"]first time tests[/URL] of Curtis "Chuck Norris" Cooper atm :flex:[/QUOTE]

Yup. We're going to see the next MP much sooner than originally guessed... :tu:

[QUOTE=chalsall;551443]Yup. We're going to see the next MP much sooner than originally guessed... :tu:[/QUOTE]
We all have the same success count over the past year.
We could be in a barren stretch of the number line. The presumed Poisson distribution has already had ratios of successive exponents of Mersenne primes of ~4:1.. Even the mean expectation, of ~1.47:1 on exponent, implies ~121M, or tens of millions of exponent range to go. A 4:1 puts us near 100Mdigit range. GIMPS has had a very lucky run. Play long enough, and the house wins. The best conjectures indicate there are about 6 more Mersenne primes to find in the range below p=10[SUP]9[/SUP], which under reasonable assumptions will take generations to fully first-time test.

[QUOTE=kriesel;551447]We could be in a barren stretch of the number line.[/QUOTE]

Welcome to statistics. It has no memory... :wink:

And, this doesn't counter my argument. Thanks to Ben, we're going to find the next MP much sooner than originally projected.

[QUOTE=chalsall;551448]Welcome to statistics. It has no memory... :wink:

And, this doesn't counter my argument. Thanks to Ben, we're going to find the next MP much sooner than originally projected.[/QUOTE]
Soon or sooner seem misused, in a context that may involve a desired event per generation. Less unbearably slow perhaps.
The work to primality test up to a given exponent p from 2 is with the best available algorithms, around p[SUP]3[/SUP] to p[SUP]3.1[/SUP]. That eats up powers of 2 or ten on throughput quite readily. LL/LLDC phaseout and PRP DC replacement with the much more economical proof and verification provides nearly 2:1. There are some small gains possible in TF and P-1.
(For a while I'd post such pessimistic comments, and shortly seem to be shown wrong by a new prime find. No such luck lately.)

I wonder how long Ben will continue what is probably a massive financial donation to the cause.

At my current rate I predict a 10-20% chance per year of finding a MP.

[QUOTE=chalsall;551448]And, this doesn't counter my argument. Thanks to Ben, we're going to find the next MP much sooner than originally projected.[/QUOTE]There may be no more Mp's to be had. So it is possible that he hasn't helped at all.

[QUOTE=Uncwilly;551454]There may be no more Mp's to be had. So it is possible that he hasn't helped at all.[/QUOTE]
I have a vague recollection of someone expressing in the mailing list, pre-forum, that no more than 37 Mersenne primes would ever be found, since that was how many existed. It seemed to be some sort of religious belief, or an artful troll pretending to be such. One hopes he changed his mind based on evidence. And not to the belief that no more than 51 or perhaps 53 will ever be found.
Contrast with the [URL="https://en.wikipedia.org/wiki/Mersenne_conjectures"]Lenstra-Pomerance-Wagstaff conjecture[/URL].

[QUOTE=Ben Delo;551450]At my current rate I predict a 10-20% chance per year of finding a MP.[/QUOTE]

Over time, if you add to or upgrade the hardware you're using (the forum shudders), that rate could conceivably increase.

[URL="https://www.mersenneforum.org/showpost.php?p=501173&postcount=2"]Recent past progress and rate[/URL]
[URL="https://www.mersenneforum.org/showpost.php?p=502995&postcount=11"]An extrapolation with big assumptions[/URL], made in December 2018 (IIRC, before Ben Delo ramped up primality testing rate)
Note, multiplying testing effort by n does not make exponents complete n times faster for long, since it speeds reaching the point in exponent where a test is n times more costly. Effort to do a % range in p is ~(O)p[SUP]3[/SUP]. 10[SUP](1/3)[/SUP] is ~2.15.
The PRP proof / verification change is worth 2[SUP](1/3)[/SUP] ~1.26. The combination is 2.71:1 for a 20fold throughput increase. 91M milestone x 2.71 ~247M.
We'll take it. And will keep looking for any algorithm or code improvements, hardware improvements, new recruits, etc. It's a stiff problem.

Yesterday I did a little number-crunch based on Friday's Top500 data ... Ben's accumulated GHz-yrs for the past year amount to ~1.6x the sum of the remaining Top500 totals. This is of course a colossal amount of throughput, but what interests me is the trend. ISTR the tests-per-day count was running ~1000 for a few months earlier this year, but that has slowly trended back down to the 600-700 tests/day range, at the same time the average throughput of the general membership has been continually increasing, as people upgrade their gear and add more GPUs to the mix. Has anyone been tracking the tests/day over time?

[B]Edit : I think you can have an accurate reporting in mersenne.ca (GIMPS Progress vizualization)[/B]

[QUOTE=ewmayer;553906]Yesterday I did a little number-crunch based on Friday's Top500 data ... Ben's accumulated GHz-yrs for the past year amount to ~1.6x the sum of the remaining Top500 totals. This is of course a colossal amount of throughput, but what interests me is the trend. ISTR the tests-per-day count was running ~1000 for a few months earlier this year, but that has slowly trended back down to the 600-700 tests/day range, at the same time the average throughput of the general membership has been continually increasing, as people upgrade their gear and add more GPUs to the mix. Has anyone been tracking the tests/day over time?[/QUOTE]

I found some data in my backups of [url]https://www.mersenne.org/primenet/[/url] which is used to generate this hourly automatic report: [URL="http://hoegge.dk/mersenne/GIMPSstats.html"]GIMPSstats.html[/URL]

Attached is the data and chart from Jan 1st 2019 to now. It is the number of LL+PRP tests combined per day in the complete range up to 1B, where each day goes from midnight to midnight UTC time.

Thanks, Andreas - so sustained peak over 800/day for ~3 weeks early this year, since then rolling 7-day average looks to have been holding more or less steady ~600/day.

I wonder what that huge plunge-followed-by-even-huger spike roughly 1 month ago was about. Maybe a server-offline issue?

[QUOTE=ewmayer;554416]I wonder what that huge plunge-followed-by-even-huger spike roughly 1 month ago was about. Maybe a server-offline issue?[/QUOTE]

Yes, the primenet server refused PRP results for about 18 hours. I manually applied the dropped results the next day.

Ben, PRP, CERTs and version 30
 

I see that Ben Delo is doing CERTs so he must have version 30 installed. But I don't see a wave of his completed PRPs requesting CERTs.

I really don't understand how Amazon Web Services works. Will he have do do a bunch of changes to install version 30 on each of his virtual machines, or is everything driven from some central point?

I have run a Cert on an exponent that Ben has run and vice versa.
Some of his are self certs: [M]98550509[/M], [M]98533321[/M], [M]98540083[/M]

I just now got one of Ben's CERTs to run.

Pardon my ignorance but what are these CERTs?
Certificates of compositeness?

They are the second part of the PRP-VDF run. They prove that the PRP was run without errors and that the number is composite.

[QUOTE=Uncwilly;554559]They prove that the PRP was run without errors and that the number is composite ...[/QUOTE]... or a suspected prime, as the case may be.

Thanks.

Just as an aside, maybe it is a bit of a misnomer. It is like giving 99.9% of population "a certificate" of [I]NOT [/I]being an MD or PhD :-)
Maybe these tests should be called "CONF", or "VAL", or "VER".

[QUOTE=Batalov;554561]Thanks.

Just as an aside, maybe it is a bit of a misnomer. It is like giving 99.9% of population "a certificate" of [I]NOT [/I]being an MD or PhD :-)
Maybe these tests should be called "CONF", or "VAL", or "VER".[/QUOTE]It's actually a certificate of proof of work. Not the end results of prime/composite.

I think of CERT as short for certification. You are certifying the validity of the proof file (which showed the Mersenne number to be prime or composite).

[QUOTE=retina;554562]It's actually a certificate of proof of work. Not the end results of prime/composite.[/QUOTE]

It should also be a proof that the result is correct, so it should catch incorrect results due to hardware errors. That is the claim of those that understand the proof in the paper.

If it was "only" a proof of work, it would not be enough to count as a double check.


It would be nice to test that, if we had a known faulty machine and disabled Gerbicz error checking and see if the proof failed.

Another Ben Delo Cert sighting: [URL]https://www.mersenne.org/report_exponent/?exp_lo=176000023&exp_hi=&full=1[/URL]

[QUOTE=kriesel;554913]Another Ben Delo Cert sighting: [URL]https://www.mersenne.org/report_exponent/?exp_lo=176000023&exp_hi=&full=1[/URL][/QUOTE]

Some funky P-1 on that exponent in March 2019. Why?

2019-03-30 Kriesel NF-PM1 B1=1340000, B2=6700000, e=2
2019-01-24 Kriesel NF-PM1 B1=1205000, B2=39655000, e=2

(the second round of P-1 brought almost zero benefit)

[QUOTE=preda;554954]Some funky P-1 on that exponent in March 2019. Why?

2019-03-30 Kriesel NF-PM1 B1=1340000, B2=6700000, e=2
2019-01-24 Kriesel NF-PM1 B1=1205000, B2=39655000, e=2

(the second round of P-1 brought almost zero benefit)[/QUOTE]
After this long, I can't be sure. Maybe it was intended to be B2=67M.

Uh-oh...

[url]https://news.bitcoin.com/bitmex-cofounder-ben-delo-surrenders-to-us-authorities-arthur-hayes-to-follow-in-april[/url]

[QUOTE=ixfd64;574247]Uh-oh...[/QUOTE]

Big boys play big boy games.

Don't believe everything you read

[QUOTE=Ben Delo;574251]Don't believe everything you read[/QUOTE]

If you tell us the next Mersenne prime, we'll believe it!

Has Mr. Delo reduced his computing power? Today only 9 first-time tests have been received.

Today there was a significant internet outage. This might be the reason.

[QUOTE=moebius;580403]Has Mr. Delo reduced his computing power? Today only 9 first-time tests have been received.[/QUOTE]

Adjusting my configuration, bear with me.

[QUOTE=tuckerkao;580420]Everybody including ViliamF and you told me Ben Delo is not active in the forum, but here comes the big guy, what happened?[/QUOTE]
He talks to crackpots only Sundays, if it is raining and the date is even.

[QUOTE=LaurV;580434]He talks to crackpots only Sundays, if it is raining and the date is even.[/QUOTE]

Cool. I'll get at the back of the line.

[QUOTE=mathwiz;574252]If you tell us the next Mersenne prime, we'll believe it![/QUOTE]
Only if someone has finished the PRP test of it.

[QUOTE=LaurV;580434]He talks to crackpots only Sundays, if it is raining and the date is even.[/QUOTE]
If not, will he reveal the next Mersenne prime to 1 of the crackpots?

Finally found a look-alike. Ben Delo looks like Russian Ambassador to the United States - Anatoly Antonov.

[URL="https://www.aljazeera.com/wp-content/uploads/2021/06/063_1188494391.jpg?resize=770%2C513"]https://www.aljazeera.com/wp-content/uploads/2021/06/063_1188494391.jpg?resize=770%2C513[/URL]

[QUOTE=tuckerkao;585282]Finally found a look-alike. Ben Delo looks like Russian Ambassador to the United States - Anatoly Antonov.

[URL="https://www.aljazeera.com/wp-content/uploads/2021/06/063_1188494391.jpg?resize=770%2C513"]https://www.aljazeera.com/wp-content/uploads/2021/06/063_1188494391.jpg?resize=770%2C513[/URL][/QUOTE]

:oolong:

Honestly, I don't find any similitude. Hopefully he will take it like a good joke and won't complain, or won't care.
[COLOR=White](otherwise my fingers are etching for a while, already looking for the ban button)[/COLOR]

I was comparing the 2 people when they are facing the same angle, the nose shape, the eyes and the lips -

Anatoly Antonov -
[URL="https://www.aljazeera.com/wp-content/uploads/2021/06/063_1188494391.jpg?resize=770%2C513"]https://www.aljazeera.com/wp-content/uploads/2021/06/063_1188494391.jpg?resize=770%2C513[/URL]

Ben Delo -
[URL="https://en.wikipedia.org/wiki/Ben_Delo#/media/File:Ben_Delo_on_stage_at_The_Spectator's_%22Who's_afraid_of_Bitcoin?%22_conference.jpg"]https://en.wikipedia.org/wiki/Ben_Delo#/media/File:Ben_Delo_on_stage_at_The_Spectator's_%22Who's_afraid_of_Bitcoin?%22_conference.jpg[/URL]

[QUOTE=tuckerkao;585362]I was comparing the 2 people when they are facing the same angle, the nose shape, the eyes and the lips [/QUOTE]

Have you done any Computer Vision work?

A very interesting problem space.

I have no idea why anyone would be seeking a lookalike for Ben Delo.

I am very poor at distinguishing faces, but Ben Delo's avatar and the proffered pic of Anatoly Antonov don't look at all alike to me.

[looks at a number of pics of Ben Delo and Ambassador Antonov]

Well, they're both adult males. They both have fairly heavy eyebrows. Their heads appear to be roughly the same shape.

One of them is 37 years old, with a full head of very dark hair, the other is 66 with thinning, graying, medium-brown hair and a receding hairline.

Their complexions are different.

IMO their ears and noses are differently shaped.

Their eye colors appear to be different.

I don't know why Mr. Delo snap my First time PRP assignments after I did P-1 before, but this is poaching and waste of energy and computing power. His amazon instance isn't much faster than my gpu and it isn't funny for me. [URL="https://www.mersenne.org/report_exponent/?exp_lo=106325413&full=1"]106325413[/URL]

[QUOTE=moebius;588245]I don't know why Mr. Delo snap my First time PRP assignments after I did P-1 before, but this is poaching and waste of energy and computing power. His amazon instance isn't much faster than my gpu and it isn't funny for me. [URL="https://www.mersenne.org/report_exponent/?exp_lo=106325413&full=1"]106325413[/URL][/QUOTE]

I believe he is truly sorry for that, and it probably happened because his assignment expired, but kept running. No need to get angry.

[QUOTE=moebius;588245]I don't know why Mr. Delo snap my First time PRP assignments after I did P-1 before, but this is poaching and waste of energy and computing power.[/QUOTE]

Possibly because one of his various instances was assigned the candidate by the Primenet server.

I don't know Ben. But I know he runs a swarm of automated AWS instances which simply communicates with Primenet for its work assignments.

You completed the P-1 work. Was this part of an FTC assignment? Or a discrete P-1 assignment?

[QUOTE=chalsall;588248]
You completed the P-1 work. Was this part of an FTC assignment? Or a discrete P-1 assignment?[/QUOTE]
It was a PRP assignment with P-1 work to do, gpuOwl v6.11-364 splited it into a P-1 and a PRP assignment.

[QUOTE=moebius;588249]It was a PRP assignment with P-1 work to do, gpuOwl v6.11-364 splited it into a P-1 and a PRP assignment.[/QUOTE]

Ah... So this might actually be an error caused by gpuOwl. And/or whatever system you used to get the assignment, and then report the results.

The [URL="http://v5.mersenne.org/v5design/v5webAPI_0.97.html"]Primenet API[/URL] is a /little/ complicated.

There is a non-zero probability the submission of the P-1 result lead Primenet to think the Candidate was "released" to assign to someone else for the PRP.

TL;DR: Your workflow is non-nominal. Perhaps some debugging needs to be done there.

[QUOTE=moebius;588249]It was a PRP assignment with P-1 work to do, gpuOwl v6.11-364 split it into a P-1 and a PRP assignment.[/QUOTE]Did you report the p-1 result before the PRP result? (Manually, or by Preda's primenet.py doing automatic result reporting and work fetch, etc.?) It SHOULD be ok to do so.
But it seems recently the server may be mishandling that. See [URL]https://mersenneforum.org/showpost.php?p=588032&postcount=2329[/URL] That's in the thread for server issues. The server may have expired your PRP assignment upon receiving the P-1 result, and given it out to the next taker, which about half the time will be Ben because of his high volume.

[QUOTE=kriesel;588252]Did you report the p-1 result before the PRP result? [/QUOTE]
sure, always submitted manually before the PRP result to mersenne.org.

[QUOTE=moebius;588253]sure, always submitted manually before the PRP result to mersenne.org.[/QUOTE]

As I understand it, Mersenne.org manual submissions implicitly include the "DONE" flag.

Thus, Primenet correctly then assigned the Candidate to Mr. Delo's cluster to work (based on its understanding of the situation).

We try to minimize "toe stepping" here. A compute cycle is a horrible thing to waste (that whole entropy thing, to start with).

[QUOTE=chalsall;588255]As I understand it, Mersenne.org manual submissions implicitly include the "DONE" flag.
[/QUOTE]Well, if that is so, and causing premature assignment termination, that occurs to me as a server script design error incompatible with Gpuowl 7.x and a departure from previous practice.
It's tripping up other users too (see Uncwilly's post about Jan S work in the server problems thread)
The rule has long been, that one can report without expiration or termination of an assignment, any lesser / earlier result without expiring an assignment for a later result, except TF at lower bit levels than a TF high bit level assignment.
That is, hold an LL or PRP assignment? Report as much TF or P-1 as you like before the primality test result, on the same exponent, without causing expiration of the assignment. Hold a P-1 assignment? Report as much TF as you like on the same exponent. Only a found factor would expire the assignment.
There seems to be issues with processing P-1 no-factor results in particular; I've seen it cause the P-1 ASSIGNMENT get marked expired. The issue goes back at least to February. "DONE" on P-1 is not "DONE" on PRP.

The server provides no notification to the user that reporting the P-1 just revoked the PRP assignment. That's a problem.
V7.x gpuowl completes part of the PRP WHILE DOING P-1 stage 1 AS A BYPRODUCT at reduced combined cost. Revoking the PRP assignment is a certain waste of cycles.
Mihai's primenet.py would report the P-1 result at its next iteration. I don't believe it has any mechanism for getting the PRP reassigned after the server mishandles it.
It would be better to deal with this issue now, before v30.7? prime95 / mprime also adopts the lower-cost P-1 stage method already present in gpuowl v7.x, and it becomes an issue in the broader user community and wastes many more cycles.

Had this manual assignment issued long ago:
PRP=E9A657A1EFE64E2F082CB753C99AF7C0,1,2,926972593,-1,85,2

Manually prepended GPU72 row bounds for it, then ran it, completed the P-1 part.
B1=5000000,B2=260000000;PRP=E9A657A1EFE64E2F082CB753C99AF7C0,1,2,926972593,-1,85,2

Manually reported this result 2021-02-21:
{"status":"NF", "exponent":"926972593", "worktype":"PM1", "B1":"5000000", "B2":"260000000", "fft-length":"54525952", "program":{"name":"gpuowl", "version":"v7.2-21-g28dbf88"}, "user":"kriesel", "computer":"asr2/radeonvii3", "aid":"E9A657A1EFE64E2F082CB753C99AF7C0", "timestamp":"2021-02-21 17:38:46 UTC"}

Checked today, actually tried to report PRP progress using CURL, and it replies there's no such assignment.
[CODE]pnErrorResult=43
pnErrorDetail=ap: no such assignment key, GUID: ...[/CODE] Apparently the server cleared the PRP assignment when processing the P-1 NF result, back in February.

(And I note Gpuowl V7.2-21 left the bounds and 2 tests saved by P-1 factor found on the worktodo item after P-1 complete, so it would have done P-1 again. Manually edited to 0 now.)

Obtained a new assignment for that PRP today.

[QUOTE=kriesel;588256]There seems to be issues with processing P-1 no-factor results in particular; I've seen it cause the P-1 ASSIGNMENT get marked expired. The issue goes back at least to February. "DONE" on P-1 is not "DONE" on PRP.[/QUOTE]

OK. So we now have a very well-documented bug report / change request. Excellent.

Programmers appreciate detailed "tech debt" reports. It helps focus the refactoring work.

As I understand it, there are three very talented (but ***very*** busy) people involved with Primenet.

Thoughts?

P.S. Only today I received two separate "It doesn't work." reports from "real" clients. Sigh...

I'm not sure, if it is only a problem with manual submissions. LaurV did the p-1 short before. I don't know if his p-1 result was submitted manually or with prime95. [URL="https://www.mersenne.org/report_exponent/?exp_lo=106707187&full=1"]106707187[/URL]

Such reports should normally go in the [URL="https://mersenneforum.org/showthread.php?t=5758"]official server problems thread[/URL].

[QUOTE=chalsall;588257]OK. So we now have a very well-documented bug report / change request. Excellent.[/QUOTE]

I have an attempted fix in place. The done flag will be ignored for no-factor-TF and no-factor-P-1 results if the assignment is for first-time LL or first-time PRP.

[QUOTE=Prime95;588267]I have an attempted fix in place. The done flag will be ignored for no-factor-TF and no-factor-P-1 results if the assignment is for first-time LL or first-time PRP.[/QUOTE]

Excellent. Thanks, George.

Ken... Would you be able to bring resources to bear, to test if this fix works for the cases being reported?

I'll trade you a bit of [URL="https://www.youtube.com/watch?v=083F2oWtMuQ"]Canadian humour[/URL] for your efforts. It gets really funny at about 11:30...

[url]https://mersenneforum.org/showpost.php?p=588271&postcount=2342[/url]

[QUOTE=Prime95;588267]I have an attempted fix in place. The done flag will be ignored for no-factor-TF and no-factor-P-1 results if the assignment is for first-time LL or first-time PRP.[/QUOTE]
THX!

[QUOTE=Prime95;588267]I have an attempted fix in place. The done flag will be ignored for no-factor-TF and no-factor-P-1 results if the assignment is for first-time LL or first-time PRP.[/QUOTE]Great!
Have you considered also for when the reported bit level is lower than the assigned bit level of TF, letting the multi-bit-level assignment persist until its expiration date? Then successive bit levels could be reported showing progress, and the user would not need to get as many assignments or collide with reassignment to someone else after the first bit level result is reported.