![]() |
|
|
#375 |
|
"Åke Tilander"
Apr 2011
Sandviken, Sweden
2·283 Posts |
Well as many have pointed out the wait to reach milestones could almost be indefinitely and most of us really want the milestones to be reached as soon as possible.
Therefore I suggest that Primenet should assign the last 100 LL-tests below each milestone as "Triple checks" to anyone who want to do that kind of work. If we do so we would avoid "annoying" persons like myself poaching and we would also reach the milestones much quicker. I am thinking about both first time milestones and double check milestones as well as any other kind of "official" milestone. |
|
|
|
|
|
#376 |
|
Basketry That Evening!
"Bunslow the Bold"
Jun 2011
40<A<43 -89<O<-88
3×29×83 Posts |
Indeed, 22545883 has been double checked. Why would it still be listed there then?
Well, actually, it isn't listed. According to my GIMPS milestone page, it has this: All exponents below 24,052,939 have been tested and double-checked. |
|
|
|
|
|
#377 |
|
Dec 2007
Cleves, Germany
2·5·53 Posts |
There are now less than a million exponents left at less than 65 bits.
|
|
|
|
|
|
#378 | |||
|
"Richard B. Woods"
Aug 2002
Wisconsin USA
22×3×641 Posts |
Quote:
If you disagree -- show us actual examples of milestones that the PrimeNet/GIMPS mechanisms were not able to prevent from stretching "indefinitely". If you cite any milestone that has not yet been reached as an example, I'm going to ask you to show a comparison of the actual length of time that has elapsed since the preceding milestone in that series to the actual lengths of time between past milestones that were achieved. If you can't back up the "indefinite" argument with actual examples, then it's not a real problem, is it? Quote:
Besides, when you say "milestones", are you thinking about the future milestones after the one you're concentrating on? What's the net effect of diverting a system that could have been working on the next milestone, to poach someone who's working on the current milestone? Quote:
We're not ethically entitled to poach anything we happen not to have the patience to wait for. Furthermore, as I've explained before, poaching never speeds up GIMPS progress. Any supposed speedup in one area is offset by at least that much slowdown in another area, something that poaching advocates almost always ignore. If you divert a "fast" system to poach an assignment that was being processed by a "slow" system, that means that whatever work the "fast" system could have been doing instead of the poached assignment is delayed by that much. Then, if the poaching discourages an owner of a "slow" system from further participation, the poaching actually has the net effect of slowing down GIMPS, not speeding it up. Focusing on one milestone runs the risk of failing to see that GIMPS is much more than that particular stream. If one looks only at speeding up one milestone, one might forget that a diversion of resources would slow down the next milestone in the series by the same amount, so that there's no net gain. Last fiddled with by cheesehead on 2012-02-21 at 10:06 |
|||
|
|
|
|
|
#379 | |
|
"Brian"
Jul 2007
The Netherlands
7×467 Posts |
Cheesehead, I for one am in full agreement with what you write about the futility of chasing individual milestones and the negative effect which poaching has on the project as a whole.
However, directing your post at aketilander in this case may possibly be inappropriate. I know his post apparently identifies himself as one of those who want milestones to be achieved as soon as possible and takes part in poaching to do so. But my hunch/guess is that he is using this form of writing merely in order to show empathy with the thought-processes behind milestone-chasing. And my feeling is that the real poaching culprits are less likely to identify themselves so publicly. That piece of speculation on my part can now be debunked if necessary by aketilander himself. I fully agree with you that artificially diverting resources to chase the never-ending series of arbitrary milestones has a negative effect on the project as a whole. However, aketilander is also correct to identify and acknowledge the human instinct to do this and the consequent necessity of dealing with this human phenomenon in the project. And you are of course correct to point out that the project already does take measures to reach milestones quickly to appease these sentiments. As to aketilander's proposal (which should be seen as over and above the other procedures already undertaken by the project to which you rightly refer)... Quote:
|
|
|
|
|
|
|
#380 | |
|
"Åke Tilander"
Apr 2011
Sandviken, Sweden
2×283 Posts |
Quote:
http://www.mersenne.org/assignments/...et+Assignments Surely someone will poach it sooner or later and then the problem will be solved, but it would be better to do it in an official and organized form don't you think? Last fiddled with by aketilander on 2012-02-21 at 14:41 |
|
|
|
|
|
|
#381 | |
|
"Åke Tilander"
Apr 2011
Sandviken, Sweden
10668 Posts |
Quote:
To tell the whole truth I am working on a few exponents in the 50M region where I lost the original assignment and they were reassigned to others. I picked up old backup copies of the half way through exponents and finish them. It won't harm the project since its no loss of capacity on the contrary its a gain. A person actually doing the first time LL-tests could though consider this as poaching if I finish first but I consider it better doing it like this, as a premature double-check work, instead of waste all that work. Last fiddled with by aketilander on 2012-02-21 at 14:42 |
|
|
|
|
|
|
#382 | |
|
Oct 2011
7·97 Posts |
Quote:
I am currently running a 332M exp that is 5% complete and I estimate it to be complete late next year. In other recent posts, it was recommended that EEC memory be used due the the possibility of errors from such a long run. Wouldn't this concern be the same for these DC exponents? |
|
|
|
|
|
|
#383 |
|
Basketry That Evening!
"Bunslow the Bold"
Jun 2011
40<A<43 -89<O<-88
3·29·83 Posts |
Consider that he may have a large assignment queue, and that he's only been working on the assignment the last month or however long.
|
|
|
|
|
|
#384 | |
|
If I May
"Chris Halsall"
Sep 2002
Barbados
100110001101102 Posts |
Quote:
While I agree with the argument that "101 km/h is better than 100 km/h", I question if 100.0000001 km/h is better than 100 km/h. Or, put another way, why should a very slow machine owned by someone who didn't even bother to register hold up a milestone? A trusted user could eliminate this candiate in only a few days. Cheesehead: please argue your position. |
|
|
|
|
|
|
#385 | |
|
"Richard B. Woods"
Aug 2002
Wisconsin USA
1E0C16 Posts |
Quote:
Perhaps you're not yet fully familiar with the "procedures in PrimeNet and GIMPS" to which I referred. One of the less-prominently-documented is that the administrators (usually George) do keep an eye on such assignments, and will intervene when they think it's justified. There already has been, for several years, a warning somewhere that a PrimeNet assignment may be taken away if the work extends past a year. (One forum topic of discussion has been the best way to modify this established policy for the cases of large exponents which can be expected to take more than a year even at full speed on a fast system.) This warning has been and is already enforced by the intervention policy. It's not "automated", but this safeguard does indeed already exist and has already been used in the past. (I'm not expecting that any newcomer would read all past forum threads, but one who did so would discover all this.) I'm polishing it a bit more through each repetition. - - - I know that probably the only way this stuff will become documented to my satisfaction is for me to create and post (in mersennewiki) such documentation so that we can all point newbies to it with a simple link. That's on my to-do list. I'm now in the midst of a documentation project for another forum; when I finish that one, I'll attend more to this one. Last fiddled with by cheesehead on 2012-02-21 at 19:32 |
|
|
|
|
![]() |
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 |