![]() |
|
|
#3290 |
|
"Sam Laur"
Dec 2018
Turku, Finland
13E16 Posts |
This may be a simplistic view, but if a poacher returns a result, just give all the credit to the user/machine that had the original assignment. That should discourage at least some of them.
|
|
|
|
|
|
#3291 |
|
Undefined
"The unspeakable one"
Jun 2006
My evil lair
3×5×7×59 Posts |
Which can of course be gamed. Just reserve lots of assignments, never work on them, and wait for someone to complete them for you.
|
|
|
|
|
|
#3292 |
|
"Oliver"
Sep 2017
Porta Westfalica, DE
72×11 Posts |
Another idea: If you turn your result in (in time), which had a valid AID, but was poached, you will get credit as normal and the poacher gets its credit removed in this moment. I know that this is only helpful when the poached did not see that he was poached and ran his assignment 'til the end.
|
|
|
|
|
|
#3293 |
|
Undefined
"The unspeakable one"
Jun 2006
My evil lair
140638 Posts |
... or just stop caring about credit.
|
|
|
|
|
|
#3294 |
|
Oct 2019
5·19 Posts |
Seems the discussion was so active that I have to break silent and make some explanations.
Most times I just clean up the dead assignments which delay the completion of an exponent effectively. As for the last 51M exponent with ongoing progress, it wouldn't cost much time for me to finish it, so I submitted an early result. Of course this is likely a redudant effort, and I should apologize if the user without nickname felt offended. However, this is the private things between me and this user, and I believe that there are no any other harms either. Also, this does not mean when I saw an active assignments I will poach it, this is just a special rare case that hardly happen, and can be treated as single incident that can be mediated easily between users. Even if there exist any user poached many active assignments, this can be treated as special case and can be mediated (or some special actions can be taken) too. So I don't think it makes sense to take measures for "poach", at least I think so. Last fiddled with by Fan Ming on 2020-07-21 at 15:00 |
|
|
|
|
|
#3295 |
|
6809 > 6502
"""""""""""""""""""
Aug 2003
101×103 Posts
263816 Posts |
With the (very early beta) release of v30 (and all that entails), I decided to update the progress chart with extended trendlines.
|
|
|
|
|
|
#3296 |
|
6809 > 6502
"""""""""""""""""""
Aug 2003
101×103 Posts
23·1,223 Posts |
Anyone know who this PrimeNet user is?
Lasers and plasmas in Bordeaux They have a slug of Cat 0-1 assignments not getting done, all on 1 machine. |
|
|
|
|
|
#3297 |
|
Sep 2002
Oeiras, Portugal
26·23 Posts |
They´ve been around for many years (by "many" I mean at least ten, if I remember well). The name suggests a french business.
|
|
|
|
|
|
#3298 |
|
"Bill Staffen"
Jan 2013
Pittsburgh, PA, USA
23·53 Posts |
Probably the University. They have an extensive Laser and Plasma physics lab there.
|
|
|
|
|
|
#3299 |
|
6809 > 6502
"""""""""""""""""""
Aug 2003
101×103 Posts
23·1,223 Posts |
Looking at the current status of exponents at the trailing of the FTC and DC ranges: it looks like we should easily complete 10 milestones (1,000,000 levels) between the 2, by the end of 2020. With a focused effort on the FTC's that could go up to 13.
|
|
|
|
|
|
#3300 |
|
6809 > 6502
"""""""""""""""""""
Aug 2003
101×103 Posts
23·1,223 Posts |
For lack of a better thread...
We can see a dramatic impact of PRP-VDF & Certs already in the progress report. The colourised lines are where most of the PRP results are coming in with VDFs and certs being done. Note the Composite DC column. 58,000,000 is the last range to have >1070 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 | ----------=-----=-- | -----=-----=-----=-----=----- | -----=-----=-----=----- | -----=-----=-----=----- | 90000000 54705 | 35760 279 18666 | 3 37 | 18626 | 91000000 54578 | 35525 256 18626 171 | 9 162 40 | 18586 | 92000000 54444 | 35501 55 18825 63 | 63 18 | 18807 | 93000000 54423 | 35334 58 18479 3 549 | 130 7 | 422 18471 | 94000000 54645 | 35664 66 18644 2 269 | 162 2 | 109 18642 | 95000000 54452 | 35397 29 18816 4 206 | 11 6 | 199 18810 | 96000000 54364 | 35356 42 18928 38 | 11 2 | 27 18926 | 97000000 54431 | 35479 599 17761 592 | 241 314 8 | 37 17751 | 98000000 54127 | 35431 1073 13300 4 4319 | 2419 1246 21 | 659 13226 | 99000000 54332 | 35231 26 7373 1 11701 | 403 418 42 11 | 1 10840 7360 | 100000000 54208 | 34503 21 1893 1 17790 | 3404 233 22 16 | 10925 3207 1877 | 101000000 54316 | 34067 21 3122 4 17102 | 16714 158 3 | 105 130 3118 | 102000000 54304 | 34206 39 3147 1 16911 | 16506 181 6 | 39 188 3139 | 103000000 54206 | 34020 70 2560 1 17555 | 16958 457 10 | 123 18 2550 | 104000000 54207 | 33850 83 1632 5 18637 | 18087 533 3 | 23 1627 | 105000000 54071 | 33861 86 1835 7 18282 | 16920 762 7 | 1 609 1825 | 106000000 54061 | 33708 23 2564 10 17756 | 16520 919 6 | 4 327 2554 | 107000000 54135 | 34048 379 2215 12 17481 | 15332 1886 3 | 11 278 2196 | 108000000 54215 | 33550 5 435 2 20223 | 18842 654 1 | 647 86 430 | 109000000 54131 | 33700 4 507 3 19917 | 18441 908 2 | 450 141 485 | |
|
|
|
![]() |
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Newer X64 build needed | Googulator | Msieve | 73 | 2020-08-30 07:47 |
| Performance of cuda-ecm on newer hardware? | fivemack | GMP-ECM | 14 | 2015-02-12 20:10 |
| Cause this don't belong in the milestone thread | bcp19 | Data | 30 | 2012-09-08 15:09 |
| Newer msieves are slow on Core i7 | mklasson | Msieve | 9 | 2009-02-18 12:58 |
| Use of large memory pages possible with newer linux kernels | Dresdenboy | Software | 3 | 2003-12-08 14:47 |