mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   PrimeNet (https://www.mersenneforum.org/forumdisplay.php?f=11)
-   -   Welcome Ben Delo (https://www.mersenneforum.org/showthread.php?t=24819)

Batalov 2019-11-16 18:08

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

retina 2019-11-16 18:11

[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]

a1call 2019-11-16 19:26

[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:

kriesel 2019-11-16 20:10

Some people have no sense of humor.

Chuck 2020-01-17 02:06

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

kriesel 2020-01-18 15:26

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.

preda 2020-01-18 16:54

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]

kriesel 2020-01-18 18:59

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

Ben Delo 2020-01-19 11:39

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!

kriesel 2020-01-19 14:47

[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.)

ewmayer 2020-01-20 20:27

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


All times are UTC. The time now is 08:57.

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