[QUOTE=chalsall;282188]
Ergo, at this point in time all new LL assignments from PrimeNet will have been TFed to at least 72 bits. And many, additionally, will have been P1ed "well" (we have garnered an impressive amount of P-1 "fire power").
[/QUOTE]

Hmmm the logic is flawed... PrimeNet assign for LL testing at least 2-4 time the number of completed test per day. So if 200 test gets completed on a given day, anywhere between 400 and 800 will have been assigned. It's easy to see why when we know that only 25-50% of any assignment ever get completed.

I was actually wandering about this problem.

Is it better to let the wavefront advance or should we release our lowest exponent first?

lets look at 2 different exponent:

45M (our lowest available) and 56M (current wavefront)

If both are factored to 71, witch one is better to hand out first?

Well they require respectively to LL test:

45M - 72.2 Ghz-Days
56M - 118.6 Ghz-Days

The effort required to factor from 2^71 to 2^72:
45M - 10.62 Ghz-Days
56M - 8.54 Ghz-Days

So the respective Bang-for-buck (chance of finding a factor being equal) ratio are:
72.2 / 10.6 = 6.8
118.6 / 8.5 = 13.95

In other word a 56M factor is worth more and cost less than a 45M factor.

Since we know that Prime95 will never further factor exponent factored to 71 in those range, even if it would have been optimal GPU-wise. If the spider could somehow monitor the number of exponent buffered by PrimeNet, so that it didn't have to advance the wavefront and always release the lowest exponent factored to 71. Then, I think the system would be optimal! :cool:

[QUOTE=petrw1;282191]
However, from my perspective I do NOT find it difficult to ensure any assignment I take is NOT already assigned. I don't do 500 a week; closer to 100.

I start with a query like this (ensuring I exclude currently assigned exponents):
[url]http://www.mersenne.org/report_factoring_effort/?exp_lo=400000&exp_hi=499999&bits_lo=0&bits_hi=60&txt=1&exassigned=1&B1=Get+Data[/url]

Then copy and paste the exponents I want into worktodo.add(or txt) and with basic editing massage them into Factor= statements.

I still do it manually because it doesn't take me more than a minute or two but I know it would also be quite easy to automate the entire process (others have).[/QUOTE]

This doesn't reserve the exponent (BTW it's what I use). If I pick a month worth of work in a range, it might not have been assigned when I grabbed it, but that status could have changed in the following month and we are back at square one.

If anything I could save them work by reporting a factor.

[QUOTE=petrw1;282191]
I am one of those people that occasionally does TF in the low ranges knowing I V-E-R-Y likely will NOT find a factor (though I have found several in the 3M range it was a small percentage). I have other reasons of personal interest.
[/QUOTE]

Factors I have found in the low 10M range:
[CODE]10158307 2011/12/10 23165442422693669639
10166789 2011/12/09 30505621781735241263
10177859 2011/12/09 19226522870204743351
10167617 2011/12/09 35400464284608355399
10167589 2011/12/09 19220197856513632009
10151821 2011/12/04 22803421415633075479
10155877 2011/12/01 25221410187895323209
10139453 2011/11/09 29742952181715579481
10130039 2011/11/08 19030509425919904001
10142887 2011/11/06 29386253647515292777
10142603 2011/11/06 25725407691049648513
10144187 2011/11/06 19450708470619689793
10113823 2011/11/01 20633240159215740071
10112413 2011/11/01 35143563607950223351
10117351 2011/11/01 36254438196810113591
10118929 2011/10/27 30922526157342469561
10121257 2011/10/22 30363492001559010857
10099007 2011/10/22 31740104071521452119
10065361 2011/10/20 36225268980519504713
10065203 2011/10/20 35943312394665094271
10064423 2011/10/20 26238270662066701129
10058003 2011/10/20 29744837510404835473
10073599 2011/10/18 22005368889459055223
10072957 2011/10/18 18580180956241537247
10050427 2011/10/11 26662465435662261713
10039879 2011/10/11 21897683265828949169
10031323 2011/10/06 31586511777517672033
10019909 2011/10/06 32423630758344997151
10019197 2011/10/06 21296345329286511871
10017109 2011/10/04 19682494866689261801
10021147 2011/10/03 25504600676039398873
10020613 2011/10/03 19584669608749036703
10016263 2011/10/03 31466213554702484423
10044667 2011/09/29 23885927142945697031
10200781 2011/09/27 33482517911745744913
11001721 2011/09/26 22207016025259277761
11000911 2011/09/26 35147657443478046847
10102007 2011/09/13 22427480224957636601
10006201 2011/09/09 28020776722441384279
[/CODE]

however it looks like there is now P-1 activity in that range since I started

[QUOTE=diamonddave;282192]Hmmm the logic is flawed... PrimeNet reserve at least 2-4 time the number of completed test per day. So if 200 test gets completed on a given day, anywhere between 400 and 800 will have been assigned. It's easy to see why when we know that only 25-50% of any assignment ever get completed.[/QUOTE]

Damn! You're right.

[QUOTE=diamonddave;282192]Since we know that Prime95 will never further factor exponent factored to 71 in those range, even if it would have been optimal GPU-wise. If the spider could somehow monitor the number of exponent buffered by PrimeNet so that it didn't have to advance the wavefront and always release the lowest exponent factored to 71. Then I think the system would be optimal! :cool:[/QUOTE]

Well, right now the system passes back to PrimeNet any candidates above M53 factored to 71 and above, and any above 55M regardless of state. (The two currently "out" in the M55 block were assigned before this change in the heuristics.)

So based on your above analysis (which I agree with), if any GPU Workers want to adapt this strategy all they need to do is adjust the limits on the LLTF Assignment page.

[QUOTE=diamonddave;282194]This doesn't reserve the exponent (BTW it's what I use). If I pick a month worth of work in a range, it might not have been assigned when I grabbed it, but that status could have changed in the following month and we are back at square one.
[/QUOTE]

Admittedly there is a small window. There is a chance that from the time I generate the list until they are added to my worktodo.txt someone may have assigned them. If I notice that some of my assignments show up as N/A I would remove them from my worktodo.txt. However, I tend to work in ranges that don't have a lot of activity. The window will be smaller if you added the new work to worktodo.txt instead of .add.

[QUOTE=petrw1;282203]Admittedly there is a small window. There is a chance that from the time I generate the list until they are added to my worktodo.txt someone may have assigned them. If I notice that some of my assignments show up as N/A I would remove them from my worktodo.txt. However, I tend to work in ranges that don't have a lot of activity. The window will be smaller if you added the new work to worktodo.txt instead of .add.[/QUOTE]

With P-1 the window is small since Prime95 will reserve the exponent. With further TF there is no such thing and no way to mark the exponent as reserved. Or is there an unknown way to reserve lets say range 11.1M to 11.2M for TF 64->65 on PrimeNet that I don't know of?

[QUOTE=cheesehead;282148]That depends rather heavily on the B1 and B2 bounds, doesn't it?[/QUOTE]
cheesehead,

I'm simply trying to get a ballpark estimate on how long it should take to complete a P-1. The ones that get assigned to my not-so-modern CPUs prior to starting an LL test take just a couple of days. Therefore I wonder why it would take nine months for someone to complete a P-1, as in the case under discussion.

Rodrigo

[QUOTE=diamonddave;282192]PrimeNet assign for LL testing at least 2-4 time the number of completed test per day. [/QUOTE]

Makes me wonder if with todays cheap RAM and fast networks there would be merit in ocassionally sending the LL workfile to the server so that if it is abandoned the new assignee does not have to start over.

Ocassionally could be once a day or two
... and maybe only after the test reaches 10 or 25%
... and maybe only if it assigned to a non-trusted tester

[QUOTE=petrw1;282206]Makes me wonder if with todays cheap RAM and fast networks there would be merit in ocassionally sending the LL workfile to the server so that if it is abandoned the new assignee does not have to start over.

Ocassionally could be once a day or two
... and maybe only after the test reaches 10 or 25%
... and maybe only if it assigned to a non-trusted tester[/QUOTE]

In this day and age of P2P network like bittorrent... We could distribute the seeding of backup file (encrypted so the bad poacher wouldn't steal your work), lets say in 1 Ghz-Day increment. Then if an exponent is reclaimed by PrimeNet the latest file would be marked as a DC candidate. When the new worker get to the same point as the previous worker, the residue would be compared and if we have a match the backup file would be marked as DC accepted.

Now when the exponent get assigned as DC or reassigned as LL the known good backup file would be used with the decryption key provided by PrimeNet...

cheesehead, in what way are TF and P-1 assignments overlapping? You said that multiple times, yet I can't see why. They search for very different factors, as markr and ckdo well know. What markr did was not assigned to anybody.

@dd: I think 1 GHz is a bit often. Maybe every 5 or 10 GHz? Either way, a massive increase in throughput I think will be the result. But that does not belong in this thread anyways.

[QUOTE=Rodrigo;282205]I'm simply trying to get a ballpark estimate on how long it should take to complete a P-1.[/QUOTE]At the time it was an untested exponent, given a decent machine to work on, M7,018,901 would've spent about [url=http://mersenne-aries.sili.net/prob.php?guess_saved_tests=2&exponent=7018901]0.06Ghz-days[/url] on P-1. As [i]cheesehead[/i] said, the selected bounds can have a tremendous impact on the time spent. As it happens, [i]ckdo[/i] reports spending roughly 0.366GHz-days on the effort due to [url=http://mersenne-aries.sili.net/prob.php?exponent=7018901&b1=445000&b2=13572500&factorbits=63]higher bounds[/url] (which were [url=http://mersenne-aries.sili.net/7018901]still insufficient[/url] to find the factor that was found by TF).

[QUOTE=petrw1;282206]Makes me wonder if with todays cheap RAM and fast networks there would be merit in ocassionally sending the LL workfile to the server so that if it is abandoned the new assignee does not have to start over.[/QUOTE]There are roughly 150,000 L-L assignments out at any given time. Assuming a nominal savefile size of 5MB, that's not just 750GB of storage (disk space is cheap, that's unlikely to be much of a problem) but a hefty amount of data transfer -- 10+TB/month if all workers report every two days. That's what makes the scheme unworkable. However, narrowing down the criteria to only (for example) [once per month + assignment >25% complete + estimated completion >30days] that would eliminate a large portion of the potential reports. It would still be a lot of storage and data transfer for what might be limited benefit. Is there any data on [i]how far[/i] the 75% assigned-then-dropped assignments ever get? I suspect a bulk of them are registered, then the user sees it'll take a month to complete and never runs Prime95 again. Or were "accidentally" registered when trying to run overclocking stress tests. Or any number of similar never-intend-to-complete assignments on which very little useful work has been done.

[QUOTE=James Heinrich;282213]At the time it was an untested exponent, given a decent machine to work on, M7,018,901 would've spent about [url=http://mersenne-aries.sili.net/prob.php?guess_saved_tests=2&exponent=7018901]0.06Ghz-days[/url] on P-1. As [i]cheesehead[/i] said, the selected bounds can have a tremendous impact on the time spent. As it happens, [i]ckdo[/i] reports spending roughly 0.366GHz-days on the effort due to [url=http://mersenne-aries.sili.net/prob.php?exponent=7018901&b1=445000&b2=13572500&factorbits=63]higher bounds[/url] (which were [url=http://mersenne-aries.sili.net/7018901]still insufficient[/url] to find the factor that was found by TF).

There are roughly 150,000 L-L assignments out at any given time. Assuming a nominal savefile size of 5MB, that's not just 750GB of storage (disk space is cheap, that's unlikely to be much of a problem) but a hefty amount of data transfer -- 10+TB/month if all workers report every two days. That's what makes the scheme unworkable. However, narrowing down the criteria to only (for example) [once per month + assignment >25% complete + estimated completion >30days] that would eliminate a large portion of the potential reports. It would still be a lot of storage and data transfer for what might be limited benefit. Is there any data on [i]how far[/i] the 75% assigned-then-dropped assignments ever get? I suspect a bulk of them are registered, then the user sees it'll take a month to complete and never runs Prime95 again. Or were "accidentally" registered when trying to run overclocking stress tests. Or any number of similar never-intend-to-complete assignments on which very little useful work has been done.[/QUOTE]

In a distributed project you would think that keeping a backup of the file would also be distributed? Think P2P.

So 5000 active user in last 30 days and lets have 10 copies distributed across the network. Also of those 150000 How many actually are being worked on and not just sitting in a queue?

So we get 750 / 5000 * 10 or about 1.5 Gb per user. Numbers could be tweaked, but its definitely doable.

With such a system, no more P-1 work would be wasted and work could be continued in the future.