Quick Question about assignments
 

[URL="http://www.mersenne.org/report_exponent/?exp_lo=51567343&exp_hi=10000&B1=Get+status"]51567343[/URL]

This exponent last had TF activty in May 2010. I know me and many others have been getting hundreds and thousands of TF assignments up to 71 bits, but usually in the 54M-55M range, at least in my experience. How come this exponent hasn't been assigned for more TF'ing, and even if not, why did it take so long to get an LL assignment to it? I got 53M back in June, when this one was just as far factored as those. Why would this happen?

Maybe it had been picked up by an anon a while back and anon never reported in. Exponent then got reassigned to you.

Possibly, but then why not TF instead of LL?

Since GPUs have successfully got most exponents up to 2^70, I've started handing out some TF to 2^71 to keep the GPUs busy.

But then why was this one sent straight to LL? It's only at 69.

These extra bits of TF are done manually on a rather ad hoc basis.

and I repeat my offer to manually TF any exponent desired to a reasonable level on request.

I had another question:
I've just restarted CUDALucas, and fed it a 25M LL-D. Unlike working for P95, there doesn't seem to be any randomisation of the data passing through the busses, so if there were a data-dependent error, and I were to repeat the test, I would have a good chance of getting the same, erroneous residue.

How does Primenet ensure independence of two LL checks on the same exponent under such circumstances?

[QUOTE=Christenson;273542]
How does Primenet ensure independence of two LL checks on the same exponent under such circumstances?[/QUOTE]

It doesn't. You can't use CudaLUCAS to double-check an exponent that was first-time tested with CudaLUCAS.

[QUOTE=Prime95;273550]It doesn't. You can't use CudaLUCAS to double-check an exponent that was first-time tested with CudaLUCAS.[/QUOTE]

If primenet does not enforce the mathematically required independence, but I can manually asssign the same exponent to my GPU twice, how does that work?

Clearly, the concern is valid, especially since my GT480 is competitive with at least two CPU cores.

[QUOTE=Christenson;273558]If primenet does not enforce the mathematically required independence, but I can manually asssign the same exponent to my GPU twice, how does that work?

Clearly, the concern is valid, especially since my GT480 is competitive with at least two CPU cores.[/QUOTE]
Does CUDALucas employ the "random shift" trick described at the
bottom of "The Math" page?
It is trivial to implement it.

David

[QUOTE=Christenson;273558]If primenet does not enforce the mathematically required independence, but I can manually asssign the same exponent to my GPU twice, how does that work?

Clearly, the concern is valid, especially since my GT480 is competitive with at least two CPU cores.[/QUOTE]

It is enforced when you check in the result. Two matching CudaLucas residues will not result in a change to the verified state.

[QUOTE=Prime95;273540]These extra bits of TF are done manually on a rather ad hoc basis.[/QUOTE]An understatement IMAO.
I would replace "rather" with "extremely":smile:

David

[QUOTE=davieddy;273584]Does CUDALucas employ the "random shift" trick described at the
bottom of "The Math" page?
It is trivial to implement it.

David[/QUOTE]

dunno, I just ordered some books on number theory and expect to be buried there for awhile.

2 things:
A: When I manually get TF assignments, I am now getting 59M from 70 to 71 (which I increase to 72).

B: When I try and set an exponent range to get lower assignments, the page doesn't load/times out. I tried 0-55M, 0-56M, 0-57M, 0-58M, 0-59M, and 0-60M. In each instance the header for mersenne.org loads and nothing else; if I let it set for ten minutes it does the same thing (just the header), but says the page has finished loading. I check my assignments page, and nothing. I also know it's not lack of assignments, because the 0-60M range includes the 59M assignments I get when I don't specify a range. What's up?

Try asking for exponents with a lower bound of 50M or more. I was able to get 400 54Ms this way. Starting with zero may not be ideal depending on the way the Primenet server is coded.

I tried 0 after starting with 50M as the lower bound. I'll try again though.

Nope. Attached a screenshot. The little circle indicating the page was loading was there for about a minute before it went away. No more assignments appeared in my list.

[QUOTE=Dubslow;274760]2 things:
A: When I manually get TF assignments, I am now getting 59M from 70 to 71 (which I increase to 72).
[/QUOTE]
Good on you for going to 72.
I think/hope George intends to make 54M+ available for GPUs to TF
to 72 as soon as expos up to 60M are TFed to 71.
(LLs reaching 60M is ~2 years away).

[QUOTE=garo;274774]Try asking for exponents with a lower bound of 50M or more. I was able to get 400 54Ms this way. Starting with zero may not be ideal depending on the way the Primenet server is coded.[/QUOTE]

Some hard figures for 55M expo:
2.17 GHz days to TF 69 to 70
220 GHz days for 2 LLs.
If 70 bits is worth doing on a CPU, surely 72 bits on a GPU
is a conservative goal.
Note that "P-1 before last bit of TF" is pie in the sky these days:
A. Far too few takers
B. The CPU doing the LL can easily do P-1 where needed.
What it can't do (sensibly) is TF to 72 or more bits.

Finally a radical suggestion:
Since 80% of daily LL assignments are smaller than
54M, and by the nature of being half-chewed have not
been near a GPU in their life, why not make all the newly
rejected LLs available for a couple(*) of extra bits of prompt GPU TF
before assigning them to reliable CPUs for the Coup de Grace?

(*)Eric does 6 or 7 bits on my 45M assignments, Bless Him!

[QUOTE=davieddy;274788]

Some hard figures for 55M expo:
2.17 GHz days to TF 69 to 70
220 GHz days for 2 LLs.
If 70 bits is worth doing on a CPU, surely 72 bits on a GPU
is a conservative goal.
Note that "P-1 before last bit of TF" is pie in the sky these days:
A. Far too few takers
B. The CPU doing the LL can easily do P-1 where needed.
What it can't do (sensibly) is TF to 72 or more bits.
[/QUOTE]

70 bits isn't worth doing on CPU, 26.6 and the math page both list 69 as the max for 53M exponents. Also, there is no guarantee that CPUs doing LL have the memory required for a decent stage 2 P-1. I do, and that's why I might deliberately get P-1 assignments, do that, and then do the LL myself. Otherwise I do agree there's no sense in waiting with the last two bits of TF.

[QUOTE=Dubslow;274834]70 bits isn't worth doing on CPU, 26.6 and the math page both list 69 as the max for 53M exponents.[/QUOTE]

And 70 is the max for exponents >53M, e.g. 55M.

2.17 GHzdays to TF 69-70 has a 1/70 chance of finding a factor.
Say 1/100 if P-1 has been done. Even then it's worth it to try to
save 2 LLs.

BTW P95v26.6 = math page = GHz years forever = George
:smile:

David

Uhh... the math page says
Exponents up to: 58520000 [are] trial factored to 2^69

There is nothing stopping GPUs from taking 54Ms to 72 or 73. Just ask for LL tests and then change the assignment type.

I have started catching expiring LLs and using my GPU to TF them to 71 bits. I was doing 72 but I can't keep up without help.

[QUOTE=davieddy;274788]Good on you for going to 72.
I think/hope George intends to make 54M+ available for GPUs to TF
to 72 as soon as expos up to 60M are TFed to 71.
(LLs reaching 60M is ~2 years away).



Some hard figures for 55M expo:
2.17 GHz days to TF 69 to 70
220 GHz days for 2 LLs.
If 70 bits is worth doing on a CPU, surely 72 bits on a GPU
is a conservative goal.
Note that "P-1 before last bit of TF" is pie in the sky these days:
A. Far too few takers
B. The CPU doing the LL can easily do P-1 where needed.
What it can't do (sensibly) is TF to 72 or more bits.

Finally a radical suggestion:
Since 80% of daily LL assignments are smaller than
54M, and by the nature of being half-chewed have not
been near a GPU in their life, why not make all the newly
rejected LLs available for a couple(*) of extra bits of prompt GPU TF
before assigning them to reliable CPUs for the Coup de Grace?

(*)Eric does 6 or 7 bits on my 45M assignments, Bless Him![/QUOTE]

How do you catch expiring LLs?

There are lots of 50 and 51Ms available until around 1000 UTC. I just ask for LL tests on the manual assignments page. PM me and I can send you some to TF.

so like between 0500-1000? (or so?)

Yup! Like right now.

Expired exponents are made available from about 23:40 UTC each day. 00:40 my local time. If I'm still up I usually try to grab some needing P-1.

Last night I grabbed a whole bunch, in the 45M-49M range. Far more than I need, and including many with P-1 done. Most of the 45Ms and 46Ms and some of the 47Ms have been factored to 68 bits only. Most of the rest to 69.

If anyone want to take any of these on, PM me. Otherwise I will unreserve them.

Your batch to me has just completed 71 bits, just the one factor you know about; I'll do 72 bits in a few days. I'm up for a batch of 50 or 100 to 69 bits.

As Hoc Basis
 

I ask rhetorically:
"Why can't the numerous GPU users get urgent TF work in the
current LL assignment range?"
"Why will your average LL tester not get a nicely TFed expo <50M ?"

This is a "Distributed project".
Grab fewer at a time, and TF to 72 bits, giving other folk a chance to do likewise.

David,
26% through LL testing 45.5M (TFed to 74 bits)

[QUOTE=Dubslow;273518][URL="http://www.mersenne.org/report_exponent/?exp_lo=51567343&exp_hi=10000&B1=Get+status"]51567343[/URL]
This exponent last had TF activty in May 2010. I know me and many others have been getting hundreds and thousands of TF assignments up to 71 bits, but usually in the 54M-55M range, at least in my experience. How come this exponent hasn't been assigned for more TF'ing?[/QUOTE]
[QUOTE=Prime95;273533]Since GPUs have successfully got most exponents up to 2^70, I've started handing out some TF to 2^71 to keep the GPUs busy.[/QUOTE]
[QUOTE=Dubslow;273536]But then why was this one sent straight to LL? It's only at 69.[/QUOTE]
[QUOTE=Prime95;273540]These extra bits of TF are done manually on a rather [B][U]ad hoc basis[/U][/B].[/QUOTE]

[QUOTE=davieddy;273590][B]I would replace "rather" with "extremely"[/B]:smile:David[/QUOTE]
[QUOTE=garo;274774]Try asking for exponents with a lower bound of 50M or more. I was able to get 400 54Ms this way. Starting with zero may not be ideal depending on the way the Primenet server is coded.[/QUOTE]
[QUOTE=Dubslow;274925]How do you catch expiring LLs?[/QUOTE]
[QUOTE=garo;274931]There are lots of 50 and 51Ms available until around 1000 UTC. I just ask for LL tests on the manual assignments page. PM me and I can send you some to TF.[/QUOTE]
[QUOTE=garo;274922]There is nothing stopping GPUs from taking 54Ms to 72 or 73. Just ask for LL tests and then change the assignment type.
I have started catching expiring LLs and using my GPU to TF them to 71 bits. I was doing 72 but I can't keep up without help.[/QUOTE]
[QUOTE=Mr. P-1;274995]Expired exponents are made available from about 23:40 UTC each day. 00:40 my local time. If I'm still up I usually try to grab some needing P-1.
Last night I grabbed a whole bunch, in the 45M-49M range. Far more than I need, and including many with P-1 done. Most of the 45Ms and 46Ms and some of the 47Ms have been factored to 68 bits only. Most of the rest to 69.If anyone want to take any of these on, PM me. Otherwise I will unreserve them.[/QUOTE]
[QUOTE=Christenson;275043]Your batch to me has just completed 71 bits, just the one factor you know about; I'll do 72 bits in a few days. I'm up for a batch of 50 or 100 to 69 bits.[/QUOTE]

[QUOTE=davieddy;275061]I ask rhetorically:
"Why can't the numerous GPU users get urgent TF work in the
current LL assignment range?"
"Why will your average LL tester not get a nicely TFed expo <50M ?"

This is a "Distributed project".
Grab fewer at a time, and TF to 72 bits, giving other folk a chance to do likewise.

David,
26% through LL testing 45.5M (TFed to 74 bits)[/QUOTE]

Speaking for myself,

I'm still waiting on PrimeNet integration into mfaktc. So right now it's a manual process. I grab DC assignment and TF to 69, with a goal of going to 70 (maybe even 71) eventually.

IMO LL candidate at the wavefront receive enough attention, with the PrimeNet infrastructure directly handling it. Although I manually TF to 72 the candidate I get assigned to do LL.

[QUOTE=davieddy;275061]I ask rhetorically:
"Why can't the numerous GPU users get urgent TF work in the
current LL assignment range?"
"Why will your average LL tester not get a nicely TFed expo <50M ?"

This is a "Distributed project".
Grab fewer at a time, and TF to 72 bits, giving other folk a chance to do likewise.[/QUOTE]

Option 1: TF 25 newly-expired assignments from 68 to 72, and find about 1 factor that would not otherwise be found (assuming a 1% chance of finding such a factor per bit level).

Option 2: Using the same resources, TF 375 newly-expired assignments from 68 to 69. amd find about 3.75 new factors.

Option 2 is the clear win here, assuming that the exponents would not otherwise enjoy further TFing. I've been grabbing exponents shortly after expiry for years now, (albeit in much smaller quantities, solely to meet my own need for P-1able assignments), and I've never seen any indication that others are doing likewise. Rather it looks as though they're being taken one-by-one by clients which are probably not doing any more TF.

I've now given away for TFing all of the assignments which I grabbed over the past couple of days, except for the ones I'm keeping for myself. I won't be grabbing any more for a while unless someone asks. If anyone else wants to grab some, have at it. If they're busy (or asleep) when the expiries happen, I'll willing to grab some on their behalf. Otherwise, the most likely outcome is that the expiries will be re-taken up for LLing and never TFed further.

Funny, it looks like ckdo has been grabbing large numbers of exponents and doing one bitlevel (with help from his friends) in the 27M area...doing much the same calculation.
Me, I've just set most of my cores to doing P-1, and they get whatever Primenet hands them...

[QUOTE=diamonddave;275078]Speaking for myself,

I'm still waiting on PrimeNet integration into mfaktc. So right now it's a manual process. I grab DC assignment and TF to 69, with a goal of going to 70 (maybe even 71) eventually.

IMO LL candidate at the wavefront receive enough attention, with the PrimeNet infrastructure directly handling it. Although I manually TF to 72 the candidate I get assigned to do LL.[/QUOTE]
If it is worth TFing a DC to 69, it is worth TFing a first time LL to 73.

[QUOTE=Mr. P-1;275082]Option 1: TF 25 newly-expired assignments from 68 to 72, and find about 1 factor that would not otherwise be found (assuming a 1% chance of finding such a factor per bit level).

Option 2: Using the same resources, TF 375 newly-expired assignments from 68 to 69. amd find about 3.75 new factors.

Option 2 is the clear win here, [B]assuming that the exponents would not otherwise enjoy further TFing[/B]. I've been grabbing exponents shortly after expiry for years now, (albeit in much smaller quantities, solely to meet my own need for P-1able assignments), and I've never seen any indication that others are doing likewise. Rather it looks as though they're being taken one-by-one by clients which are probably not doing any more TF.

I've now given away for TFing all of the assignments which I grabbed over the past couple of days, except for the ones I'm keeping for myself. I won't be grabbing any more for a while unless someone asks. If anyone else wants to grab some, have at it. If they're busy (or asleep) when the expiries happen, I'll willing to grab some on their behalf. Otherwise, the most likely outcome is that the expiries will be re-taken up for LLing and never TFed further.[/QUOTE]

Your "grab" is absolutely fine, in light of what you have done with it.
I just found it ironic that no sooner had Garo pointed out to Dubslow
the time and method of getting expiries, than you grabbed them all!
I hope he (Dubslow) got some.

Note that there is unanimity about 72 bits (mfaktc) being worthwhile.
It is also feasible as long as you have 15 GPUs doing your option 1,
rather than 1 GPU doing your option 2.
Note Garo's admission that he had dropped the level to 71 from 72
for his grab "since one man and his dog can't do it all".

I have suggested that the expired exponents should be made available
for TF (GPU only) instead of LL testing, because I agree with you that
as it is, they will go straight to LL with no further TF.

David

[QUOTE=Mr. P-1;275082]Otherwise, the most likely outcome is that the expiries will be re-taken up for LLing and never TFed further.[/QUOTE]

Bingo!

Mr. P-1, could I ask you to grab some exponents for me in the sub-50M range? I'd prefer to TF those than the 54Ms I have.

[QUOTE=davieddy;275108]Your "grab" is absolutely fine, in light of what you have done with it.
I just found it ironic that no sooner had Garo pointed out to Dubslow
the time and method of getting expiries, than you grabbed them all!
I hope he (Dubslow) got some.[/QUOTE]

Yes he did.

Garo did not, however point out the time and method of getting sub-50M expiries. I did that. Garo suggested up till 10 UTC for getting 50-51Ms

[QUOTE]Note that there is unanimity about 72 bits (mfaktc) being worthwhile.
It is also feasible as long as you have 15 GPUs doing your option 1,
rather than 1 GPU doing your option 2.[/QUOTE]

If we have 15 GPUs each capable of doing 25 exponents from 68 to 72, then we could do that, and discover 25 new factors. Or we could TF 5,625 exponents from 68 to 69, and discover 88 new factors, assuming that 5,625 exponents TFed to 68 are available

The relevant questions are: How many GPUs do we have available for this work? How many exponents are they capable of processing in a day from 68 to 69? To 70? To 71? To 72? How many LL exponents expire each day? How many are assigned each day? Do we have enough GPU power available to bring one full day's worth of LL assignments up to 72 every day? If not, how high could we get one full day's worth of LL assignments up to every day?

One other question: Are we prepared to work together to make this happen? If so, then it would make sense for one person to do the daily grabbing, and farm out the exponents to everyone else.

[QUOTE=garo;275113]Bingo!

Mr. P-1, could I ask you to grab some exponents for me in the sub-50M range? I'd prefer to TF those than the 54Ms I have.[/QUOTE]

OK, I'll grab some for you tonight.

Working together is already happening with ckdo's crew, and it is now starting to happen with "Mr P-1's crew" or whatever we decide to call ourselves. I'd rather be discovering more factors -- there will always be more LL candidates passed out than we can keep up with.

Successive, higher bit levels come when we get a little ways ahead of the LL candidates -- that is, given the choice of hitting 1 exponent from 68 to 72 or 16 exponents from 68 to 69, if all 16 are about to get LL tested, it's better to do the 16 exponents, roughly quadrupling the chance of only needing 15 LL tests.

By the way, I have a present for Mr P-1:
1022665867263659549537 is a factor of M(50496583) by P-1, 2011-10-19 20:56

[QUOTE=Christenson;275123]..."Mr P-1's crew" or whatever we decide to call ourselves.[/QUOTE]

Please not that.

[QUOTE]I'd rather be discovering more factors -- there will always be more LL candidates passed out than we can keep up with.[/QUOTE]

I just gave you about 150 assignments, as you requested, in the expectation that you would be taking them to 72. Would it be better to give you batches of 2,250 (grabbed over several days of course) to take up to 69 only?

[QUOTE]By the way, I have a present for Mr P-1:
1022665867263659549537 is a factor of M(50496583) by P-1, 2011-10-19 20:56[/QUOTE]

70 bits. I'm surprised it wasn't a GPU find.

Speaking of assignments, to get back on topic (relatively speaking) is there a way to reassign an exponent from one user to another without having to release it to the pool for a few seconds, even assuming that two people could get on at the same time.

[QUOTE=davieddy;275108]
Note that there is unanimity about 72 bits (mfaktc) being worthwhile.
[/QUOTE]
Really? News to me.

[QUOTE=Dubslow;275135]Speaking of assignments, to get back on topic (relatively speaking) is there a way to reassign an exponent from one user to another without having to release it to the pool for a few seconds, even assuming that two people could get on at the same time.[/QUOTE]Nope.

Some Stats
 

I just reserved every LL expiry up to 50M to fulfil garo's request.

Total (up to 50M): 204

Of these:

35 were factored to 68 bits
163 were factored to 69 bits of which
->59 have not been P-1ed
->104 have been P-1ed
The rest were factored to 70 bits.

garo didn't say how many he wanted, but assuming these figures are representative of expiries generally, it looks as though a reasonable target might be to TF to 70 bits, all the 68-bits, and the non-P-1ed 69-bits. These I will PM to garo shortly. The rest I have unreserved in order to let the "average LL tester [] get a nicely TFed expo <50M".

[QUOTE=Dubslow;275135]Speaking of assignments, to get back on topic (relatively speaking) is there a way to reassign an exponent from one user to another without having to release it to the pool for a few seconds, even assuming that two people could get on at the same time.[/QUOTE]

The two people don't need to get on at the same time. The current owner can unreserve, log out, then manually re-reserve seconds later. I pretty certain that, with knowledge of the keys, "anonymous" assignments can be claimed.

Who is the right person to check with on the reservation system? P95? And do you have any scripts (Linux64) to assist with manipulating assignments? 20 or 30 assignments at a time is one thing, 150 at a time is another... While I'm at it, what happens if I put an assignment key on my "no factor found" lines on the manual results page?

I'm for beginning by ensuring everything in the assignment pool has 69 bits first, and then if we can keep up with that, we can chase 70 bits.

I'm now going to have my GPU do 2-3 days work on bringing your original list from 71 to 72 bits, with a moderate chance of finding a factor.

[QUOTE=Dubslow;275136]Really? News to me.[/QUOTE]
Everyone (including you) who mentioned a bit level in this
thread said 72.
Two huge threads in the lounge discuss this. 72 is what is
feasible (and comfoortably so) if the assignment was simpler
and organized as I suggested:
Let a larger number of folk each grab fewer expos and take them
to 72 in one go for expos AT, not 2 years AHEAD of, the wavefront.

David

[QUOTE=Mr. P-1;275082]Option 1: TF 25 newly-expired assignments from 68 to 72, and find about 1 factor that would not otherwise be found (assuming a 1% chance of finding such a factor per bit level).

Option 2: Using the same resources, TF 375 newly-expired assignments from 68 to 69. amd find about 3.75 new factors.

Otherwise, the most likely outcome is that the expiries will be re-taken up for LLing and never TFed further.[/QUOTE]
[QUOTE=garo;275113]Bingo![/QUOTE]
[QUOTE=Mr. P-1;275129]Would it be better to give you batches of 2,250 (grabbed over several days of course) to take up to 69 only?
[/QUOTE]
[SIZE=7][COLOR=red]NO [/COLOR][/SIZE]
the most likely outcome is that the expiries will be re-taken up for LLing and never TFed further than 69.


[COLOR=seagreen][/COLOR]

Please read thoughtfully
 

[QUOTE=Mr. P-1;275120]If we have 15 GPUs each capable of doing 25 exponents from 68 to 72, then we could do that, and discover 25 new factors. Or we could TF 5,625 exponents from 68 to 69, and discover 88 new factors, assuming that 5,625 exponents TFed to 68 are available

The relevant questions are: How many GPUs do we have available for this work? How many exponents are they capable of processing in a day from 68 to 69? To 70? To 71? To 72? How many LL exponents expire each day? How many are assigned each day? Do we have enough GPU power available to bring one full day's worth of LL assignments up to 72 every day? If not, how high could we get one full day's worth of LL assignments up to every day?
[/QUOTE]
[URL]http://www.mersenne.info/trial_factored_tabular_delta_180/2/50000000/[/URL]

From ~53.5M to 61M, 130,000 have been TFed 2 more bits in the last
six months. The wave front has advanced by 1.5M which means
~30,000 "status unknown" exponents.
We could have TFed all these 30,000 to 72 bits, with enough to
spare to TF the entire "tail" < 53.5M by 2 or 3 extra bits.

WHY THE HELL HAVEN'T WE?

Because we adopted option 2 up to 61M which won't get assigned
for another two years "to keep the GPUs busy", and find your oh so precious low-hanging fruit factors.

David

Davieddy:
Please remember that GIMPS is like herding cats...and I can only control what I do, not what the big firepower does. I'm not too worried about a 10% or so (assuming we find lots of factors) loss of efficiency on LL testing in the short term.

Also, if we can have GIMPs hand out its last 68-bit TF'ed assignment next week, we will be much further ahead than if it hands out 15 68 bit TF'ed assignments noone has been able to bring up to 69 bits because they were all trying to bring the current exponents to 72 bits. But I'm not going to complain about *any* TF activity in the middle of the LL assignment wavefront. Every factor found saves LL tests, and that's what it's about. Each additional bit level is twice as hard as the last, and in a resource-limited context, doing the easy ones first is most effective.

If you want more productivity, I need a way to restart crashed Windows machines from afar, and about a grand (US$1000) to put together a screamer TF/P-1 machine with a GT580 GPU, a 1KW power supply, and a hot CPU. A UPS wouldn't hurt either, as small power glitches are hard on my high-powered machines. And I need a little less pressure at work, so I get home and work on mfaktc....the primenet side.

[QUOTE=Mr. P-1;275141]The two people don't need to get on at the same time. The current owner can unreserve, log out, then manually re-reserve seconds later. I pretty certain that, with knowledge of the keys, "anonymous" assignments can be claimed.[/QUOTE]

Ah. I'm willing to give it a shot. Let me know when you've done it, and you'd need to send me the new keys. Can anybody else confirm or deny this? (Please reserve the LL's as LL's, not P-1)

[QUOTE=Christenson;275147]Who is the right person to check with on the reservation system? P95?[/QUOTE]

I guess so.

[QUOTE]And do you have any scripts (Linux64) to assist with manipulating assignments?[/QUOTE]

I have scripts to convert Test= assignments to Pfactor=, to make a 2-core worktodo file from an undifferentiated list of assignments, and to convert Test= and Pfactor= assigments to Factor= assignments. I find I can generally whip up a script to do whatever I want in a few minutes. I'm sure you could do the same.

[QUOTE]While I'm at it, what happens if I put an assignment key on my "no factor found" lines on the manual results page?[/QUOTE]

Nothing, I would guess.

I asked both Dubslow and you to unreserve the exponents I gave you when you were finished with them, but this was based upon the assumption that with the keys, you would be able to do this. Since that assumption appears to have been mistaken, I think the easiest thing to do would be for both of you (and garo) to just PM when you're done with them, and I'll unreserve them.

In future, if I'm grabbing on behalf of others, I'll try to make sure I'm logged out at the time, so they won't be assigned to me.

[QUOTE=Dubslow;275158]Ah. I'm willing to give it a shot. Let me know when you've done it, and you'd need to send me the new keys. Can anybody else confirm or deny this? (Please reserve the LL's as LL's, not P-1)[/QUOTE]

This is weird. Of the five exponents I gave you for LL, only 2 are still assigned to me. The other 3 have been reassigned to "ANONYMOUS". Possibilities are 1. I screwed up again somehow. 2. You managed to unreserve them somehow and someone else has them now. 3. You managed to rereserve them somehow. 4. Something else.

I'm not sure, but for now I'm filing this whole "give keys assigned to me to someone else" business in the box marked "unpredicable results", and I don't propose to do it again.

I'll try to do the "unreserve then rereserve anonymously" trick on the two exponents I still have, and on three others. You'll get your five LL exponents, but not necessarily the same ones.

As for the rest, the ones you're just going to TF, I'll check to see if I still have them reserved. If so, I'll just keep them and unreserve them myself when you're done. Expect a PM shortly.

[QUOTE=Mr. P-1;275168]Expect a PM shortly.[/QUOTE]

Or not. The server is somewhat unresponsive just now, and I'm having difficulty in getting any manual assignments at all. I'll try again later.

[QUOTE=davieddy;275152]WHY THE HELL HAVEN'T WE?

Because we adopted option 2 up to 61M which won't get assigned
for another two years "to keep the GPUs busy", and find your oh so precious low-hanging fruit factors.[/QUOTE]

David, we're not talking about those other GPUs which are working in the 61M range, as we have no control over what those GPUS do. We're talking about the GPUs of the people in this thread who have them, and who have expressed an interest in working in the sub 50M range. These people do not appear to include you. The question before us is how [i]we[/i] can optimize [i]our[/i] contribution to GIMPS, not how to fix GIMPS' TF assignment system generally. And of course, by "we" I mean "they". I don't have a GPU either, though I intend to get one within the next few months.

My current best guess is that these people - Dubslow, Christenson, and garo - together have the capacity to TF every 68-bit expiry every day to 70 bits with room to spare, assuming they do nothing else with their GPUs. The question is: what to do with that room to spare. My proposal: use it to factor as many 69-bit expiries to 70 bits as we can, giving priority to those 69-bit assignments which have not had a P-1.

Your proposal appears to be that we TF a smaller number of sub-50M exponents to 72 bits every day, leaving the rest to other people to TF. The problem with this idea is that [i]there don't appear to be any other people TFing in this range[/i]. Instead of being TFed to 72 bits, these other exponents will be left at 68 or 69 bits. Moreover, every exponent we take to 72 bits instead of 70 means six other sub-50M exponents left at 69 bits or twelve at 68 which could otherwise have taken to 70. How is this better?

We could also try to recruit more GPU owners to the effort. With enough, we could maybe take all expiries to 70 bits and then some to 71. Perhaps one of us should post a call for assistance in the GPU forum. However before we do that, I think we need to sort out a system for coordinated assignment "grabbing" and distribution. To get every 68 bit expiry, we will need to "grab" every day. I've volunteered to do some "grabbing", but I'm not sure I want to commit to doing it every day.

Oh, and another thing: Whoever posts the call for assistance, please let it not be you. So far, all you've achieved is to piss everyone off on the subject.

[QUOTE=Mr. P-1;275175]My current best guess is that these people - Dubslow, Christenson, and garo - together have the capacity to TF every 68-bit expiry every day to 70 bits with room to spare, assuming they do nothing else with their GPUs.[/QUOTE]

Could the three of you each give an estimate of just how many exponents you could TF from 68 to 70 bits in a day? I'd like a better figure than my "best" WAG.

I've got a script set up to run tonight that will grab some small LL tests at 0000 UTC. My guess is that it will only get about 6 exponents so you can keep grabbing exponents as and when you can. I'm not sure how long trial factoring a 45M to 70 bits takes on my GPU. My guess is 40 minutes so I could do about 35 of these exponents in a day. I'll have more precise numbers this weekend.

At this point in the discussion, if davieddy continues to refuse to distinguish between TFing of 55-60M and TFing of 42-50M the best we can do is ignore him.

WAG??? My foot!!!! that's at least a SWAG! (Sophisticated WAG). ;)

[QUOTE=garo;275208]I've got a script set up to run tonight that will grab some small LL tests at 0000 UTC. My guess is that it will only get about 6 exponents so you can keep grabbing exponents as and when you can.[/QUOTE]

It's not a good idea to run server related scripts on the hour as the server invariably becomes unresponsive for a few minutes at that time, presumably because it's generating reports.

I intend to grab every exponent to 50M within minutes of expiry, i.e., at about quarter to midnight UTC, then unreserve every one TFed to 70 bits or more, and every one TFed to 69 and P-1ed. I don't know if I'll manage to sift them and do this by midnight UTC, but I'll try to make sure there are a few small ones available to your script by then.

[QUOTE]I'm not sure how long trial factoring a 45M to 70 bits takes on my GPU. My guess is 40 minutes so I could do about 35 of these exponents in a day. I'll have more precise numbers this weekend.[/QUOTE]

Similarly I should have more data on how many exponents at each bit level are expiring each day. At the moment, and bearing in mind that Dubslow and Christenson also have GPUs, it sounds like my WAG was pretty accurate.

[QUOTE=Christenson;275210]WAG??? My foot!!!! that's at least a SWAG! (Sophisticated WAG). ;)[/QUOTE]

It's not a SWAG. If it's at all accurate, then it's a LWAG.

More Stats
 

Today, there were 248 expiries under 50M. Of these:

120 were 68-bit
39 69-bit (no p-1)
61 69-bit (with p-1)
20 70-bit
4 71-bit
4 72 bit

In accordance with previous discussion, I will hold onto the 68s and the no-p-1 69s for the time being and have unreserved the rest.

Benchmark from the GTX440 tonight.
no factor for M44918161 from 2^71 to 2^72 [mfaktc 0.17 barrett79_mul32]
tf(): total time spent: 4h 53m 4.319s

16 more like those remain from your first batch. I'm planning on turning them in to the "manual assignments page". Do you want me to PM you with the results as well?

And what fate the batch of 150? I've passed the part you wanted to P-1 and the part in the continuation to a high-end GT480, but it is significantly less reliable than the GT440 because of the arrangements surrounding the machine, which is shared, and because it runs Windows, which shuts down on its own in the middle of the night despite my best efforts.

For 45M from 68-70, takes 46-47 minutes for me. So that's 29-30 assignments of that sort per day. (Though a pretty decent chunk of TF2 is played per day, so budget 26-27, and I'm also helping ckdo with DC's, so not every day will go to this. Time will be served on a first come first serve basis.)

[QUOTE=Christenson;275210]WAG??? My foot!!!! that's at least a SWAG! (Sophisticated WAG). ;)[/QUOTE]

FWIW, SWAG = _Scientific_ WAG :smile:

[QUOTE=Mr. P-1;275175]

We could also try to recruit more GPU owners to the effort. With enough, we could maybe take all expiries to 70 bits and then some to 71. Perhaps one of us should post a call for assistance in the GPU forum. However before we do that, I think we need to sort out a system for coordinated assignment "grabbing" and distribution. To get every 68 bit expiry, we will need to "grab" every day. I've volunteered to do some "grabbing", but I'm not sure I want to commit to doing it every day.

[/QUOTE]

If you need additional assistance I will forego my TF work in the 600M range and devote one instance of mfaktc on the GTX580 to your project.

Chuck

[QUOTE=Mr. P-1;275215]It's not a good idea to run server related scripts on the hour as the server invariably becomes unresponsive for a few minutes at that time, presumably because it's generating reports.

I intend to grab every exponent to 50M within minutes of expiry, i.e., at about quarter to midnight UTC, then unreserve every one TFed to 70 bits or more, and every one TFed to 69 and P-1ed. I don't know if I'll manage to sift them and do this by midnight UTC, but I'll try to make sure there are a few small ones available to your script by then.
[/QUOTE]


You don't need to bother sifting. Think of my script as a low priority backup for the days you are not able to reserve exponents. And I run it at 5 past the hour.

I think the most useful unit of work here is a TF68-69. Everything else will be in multiples of that.

Based upon what people have said in this thread so far:

Dubslow ??? 15-16 minutes (about 90 per day)
Christenson GTX440 36-37 minutes (about 40 per day)
Christenson GT480 ???
garo ??? 13-14 minutes (est.) (about 100 per day)
Chuck GTX580 ???

[QUOTE=Dubslow;275234]For 45M from 68-70, takes 46-47 minutes for me. So that's 29-30 assignments of that sort per day. (Though a pretty decent chunk of TF2 is played per day, so budget 26-27, and I'm also helping ckdo with DC's, so not every day will go to this. Time will be served on a first come first serve basis.)[/QUOTE]

The rule of thumb here is that a DC of an exponent half the size of an LL assignment should be TFed to four bits lower.

In other words, for DCs in the range 22.5M to 25M, a TF to 66 bits is as valuable to the project as our TFs to 70. TFs higher than that are less valuable.

As I've said on many occasions, the ethos of the project is not "do what makes most sense", but "do whatever floats your own boat". I'm just giving you information here, not telling you what to do. It's all good.

[QUOTE=Christenson;275228]16 more like those remain from your first batch. I'm planning on turning them in to the "manual assignments page". Do you want me to PM you with the results as well?[/QUOTE]

No need. Just let me know when you're finished with them.

[QUOTE]And what fate the batch of 150? I've passed the part you wanted to P-1 and the part in the continuation to a high-end GT480, but it is significantly less reliable than the GT440 because of the arrangements surrounding the machine, which is shared, and because it runs Windows, which shuts down on its own in the middle of the night despite my best efforts.[/QUOTE]

I gave you them on the assumption that you'd be doing them to 72 bits. Given the project goals, it would be sensible to switch to a new batch as soon as all these have been done to 70. Having said that, I'm mindful of the constraints on your own time, and so am reluctant to be continually asking you to furtle around with your worktodos.

Looking forward, I think I should maybe aim to be giving each participant about a weeks worth of assignments at a time, in order to reduce the amount of furtling everyone has to do. (I assume that mfaktc can handle worktodo files of arbitrary length.) I can't do that right now, because I don't have a clear picture of how fast everyone is working, and I don't have a weeks worth to give everyone.

[QUOTE=Mr. P-1;275168]I'm not sure, but for now I'm filing this whole "give keys assigned to me to someone else" business in the box marked "unpredicable results", and I don't propose to do it again.[/QUOTE]

After further discussion with Dubslow I think I've figured out what happened. It appears that the message about the assignment being assigned to another person is a warning only. If you have the key, then you have the assignment, and can unreserve it.

So yes, you can transfer assignments to other people, so long as you have the keys.

That said, moving forward, I think it will be better for me to handle the unreserves myself.

How'd we get 4 bits less for DCs at half the size of LLs? Does it work as, roughly:
1 bit because 1 less LL test is saved
2 bits because the LL on the smaller exponent costs 1/4 of the larger
1 bit because the TF for fixed exponent (say, 69) at the smaller exponent has 2x as many factors

OK, furtling around: The GT480 is at the local university, and I usually visit there 1 or 2 times a week to restart 5 computers when needed and to mentor for First Robotics. Next visit will probably be sunday. I throw in Operation Billion Digits work. I tend to find it shut down, and have been having problems with CudaLucas checkpoints disappearing.

The GT440 is at home, and can be touched nightly if needed. I didn't get as far as programming because I was visiting the 480 last night, and Oliver sent out some mfaktc code that didn't pass a visual inspection.

So we'll let the 480 zork through the second half of mr P-1's list part II, and if it's not done on Sunday, I'll trim the bitlevel back to 70. First half of the list (not the part he specifically wanted to do P-1 on) will get fed to the 440, but it won't start until middle of next week some time. The 440 will finish his first list to 72 bits in a few days.

Meanwhile, my immediate boss is 300 miles away in a steel mill, and the second half of yesterday was spent updating code because we have a "field loss relay" (current detector) that isn't well behaved with high-voltage interference pulses in what amounts to a VFD.

[QUOTE=Christenson;275264]How'd we get 4 bits less for DCs at half the size of LLs? Does it work as, roughly:
1 bit because 1 less LL test is saved
2 bits because the LL on the smaller exponent costs 1/4 of the larger
1 bit because the TF for fixed exponent (say, 69) at the smaller exponent has 2x as many factors.[/QUOTE]

yep :tu:

[QUOTE=Christenson;275264]How'd we get 4 bits less for DCs at half the size of LLs? Does it work as, roughly:
1 bit because 1 less LL test is saved
2 bits because the LL on the smaller exponent costs 1/4 of the larger
1 bit because the TF for fixed exponent (say, 69) at the smaller exponent has 2x as many factors[/QUOTE]

Yes, that's the reasoning. I do, however, find the assumption underlying the last bit rather puzzling. Is it really the case that each candidate at a particular bit level is twice as likely to factor a 50M exponent than a 25M exponent? Because that is what the prob=1/bit-level heuristic implies.

[QUOTE]So we'll let the 480 zork through the second half of mr P-1's list part II, and if it's not done on Sunday, I'll trim the bitlevel back to 70. First half of the list (not the part he specifically wanted to do P-1 on)[/QUOTE]

Don't worry about that. Logically if I have a choice between a P-1 candidate TFed to 70 and another TFed to 72, I should do the former, because the former needs it more. I already have a few candidates TFed to 70 and soon I will have loads of them.

From what you're saying here, you're good till next week at least. I gave Dubslow about 150 units* two days ago and garo 140 units yesterday. I gave Chuck 90 units today, but kept a lot back in case anyone was needing a topup. At a guess, they all look as they they might be done by tomorrow, so I'll split my reserves between the three of them.

*1 unit equivalent to 1 exponent TFed 68-69.

That last bit clearly needs a bit of re-writing::leaving:
[QUOTE]
1 bit because the TF for fixed exponent (say, 69) at the smaller exponent has 2x as many factors
[/QUOTE]
What I should have said was half as many *FACTOR CANDIDATES* at bit level 69, because the factor candidates are all of the form 2kp+1 (or was that 2kp-1?:ermm:), where p is the mersenne exponent involved. Double p, halve the number of k's with 2kp in range. Thus, twice the work for the 25M candidate to 69 bits.

"I know you think you understand what you thought I said, but I don't think you understand that what I said was not what I meant" :smile:

[QUOTE=Christenson;275270]"I know you think you understand what you thought I said, but I don't think you understand that what I said was not what I meant" :smile:[/QUOTE]

This reminds me of a meeting I was at when I expressed my disagreement with the wording of a proposal by saying "I agree with what you meant, but..."

[QUOTE=Mr. P-1;275258]I think the most useful unit of work here is a TF68-69. Everything else will be in multiples of that.

Based upon what people have said in this thread so far:

Dubslow ??? 15-16 minutes (about 90 per day)
Christenson GTX440 36-37 minutes (about 40 per day)
Christenson GT480 ???
garo ??? 13-14 minutes (est.) (about 100 per day)
Chuck GTX580 ???[/QUOTE]

Don't know if this will help you, I have a core2 Duo E4500 with a GTS 450, Prime95 running LL on 1 core, mfaktc on the other.
I did some runs of mfaktc that were in the 55M range:
68-69 took about 30-40 min
69-70 took about 70-80 min
70-71 took about 2.5 hours

Since this is a question about assignments thread, I had a quick one... When I started Prime95 I got 2 LL tests assigned, one for each core, but stopped one core when I was playing with mfaktc and CUDALucas. CUDALucas is currently working on the LL for core 1 since it is 3x the speed of core 1 and I have core 1 stopped. Do I need to drop the core 1 assignment since it is being 'manually tested" or should I keep it since I am still working on it?

No don't drop it. Just edit the worktodo to remove that assignment from it and get core 1 working on something else.

[QUOTE=Christenson;275228]... I've passed the part you wanted to P-1 and the part in the continuation to a high-end GT480, but it is significantly less reliable than the GT440 because of the arrangements surrounding the machine, which is shared, and because it runs Windows, which shuts down on its own in the middle of the night despite my best efforts.[/QUOTE]

Two suggestions, if I may...

1. Have you tried setting the Automatic wakeup in the BIOS? If it the machine turns itself off in the middle of the night, having it wake up at (for example) 0800 is better than nothing.

2. Do you have a Linux box on the same LAN? If so, take a look at the "wol" ("Wake On LAN") command which can easily be run from a CRON job. Usually takes a bit of configuration for each client (again, in the BIOS), and some (very) older machines don't support it, but if the machine in question supports a GT480, it almost certainly will.

2.1. There are similar commands under Windows which you could probably use similarly if you don't have a Linux box there. Can't speak to this directly -- I don't do Windows.

Sort this multiquoting out.
 

I didn't mean to post this. I am too ***king sober, and
so don't think straight.

@P-1 and Garo:
"I thought we were friends; or at least one of us was"
(Iolanthe)

David

PS I suppose I could delete the rest, but I won't.

[QUOTE=Dubslow;273518][URL="http://www.mersenne.org/report_exponent/?exp_lo=51567343&exp_hi=10000&B1=Get+status"]51567343[/URL]

This exponent last had TF activty in May 2010. I know me and many others have been getting hundreds and thousands of TF assignments up to 71 bits, but usually in the 54M-55M range, at least in my experience. How come this exponent hasn't been assigned for more TF'ing, and even if not, why did it take so long to get an LL assignment to it? I got 53M back in June, when this one was just as far factored as those. Why would this happen?[/QUOTE]

[QUOTE=davieddy;274788]Good on you for going to 72.
I think/hope George intends to make 54M+ available for GPUs to TF
to 72 as soon as expos up to 60M are TFed to 71.
(LLs reaching 60M is ~2 years away).



Some hard figures for 55M expo:
2.17 GHz days to TF 69 to 70
220 GHz days for 2 LLs.
If 70 bits is worth doing on a CPU, surely 72 bits on a GPU
is a conservative goal.
Note that "P-1 before last bit of TF" is pie in the sky these days:
A. Far too few takers
B. The CPU doing the LL can easily do P-1 where needed.
What it can't do (sensibly) is TF to 72 or more bits.

Finally a radical suggestion:
Since 80% of daily LL assignments are smaller than
54M, and by the nature of being half-chewed have not
been near a GPU in their life, why not make all the newly
rejected LLs available for a couple(*) of extra bits of prompt GPU TF
before assigning them to reliable CPUs for the Coup de Grace?

(*)Eric does 6 or 7 bits on my 45M assignments, Bless Him![/QUOTE]

[QUOTE=davieddy;275108]If it is worth TFing a DC to 69, it is worth TFing a first time LL to 73.



Your "grab" is absolutely fine, in light of what you have done with it.
I just found it ironic that no sooner had Garo pointed out to Dubslow
the time and method of getting expiries, than you grabbed them all!
I hope he (Dubslow) got some.

Note that there is unanimity about 72 bits (mfaktc) being worthwhile.
It is also feasible as long as you have 15 GPUs doing your option 1,
rather than 1 GPU doing your option 2.
Note Garo's admission that he had dropped the level to 71 from 72
for his grab "since one man and his dog can't do it all".

I have suggested that the expired exponents should be made available
for TF (GPU only) instead of LL testing, because I agree with you that
as it is, they will go straight to LL with no further TF.

David[/QUOTE]

[QUOTE=davieddy;275152][URL]http://www.mersenne.info/trial_factored_tabular_delta_180/2/50000000/[/URL]

From ~53.5M to 61M, 130,000 have been TFed 2 more bits in the last
six months. The wave front has advanced by 1.5M which means
~30,000 "status unknown" exponents.
We could have TFed all these 30,000 to 72 bits, with enough to
spare to TF the entire "tail" < 53.5M by 2 or 3 extra bits.

WHY THE HELL HAVEN'T WE?

Because we adopted option 2 up to 61M which won't get assigned
for another two years "to keep the GPUs busy", and find your oh so precious low-hanging fruit factors.

David[/QUOTE]

[QUOTE=garo;275208]I've got a script set up to run tonight that will grab some small LL tests at 0000 UTC. My guess is that it will only get about 6 exponents so you can keep grabbing exponents as and when you can. I'm not sure how long trial factoring a 45M to 70 bits takes on my GPU. My guess is 40 minutes so I could do about 35 of these exponents in a day. I'll have more precise numbers this weekend.

At this point in the discussion, if davieddy continues to refuse to distinguish between TFing of 55-60M and TFing of 42-50M the best we can do is ignore him.[/QUOTE]

[QUOTE=Mr. P-1;275175]David, we're not talking about those other GPUs which are working in the 61M range, as we have no control over what those GPUS do. We're talking about the GPUs of the people in this thread who have them, and who have expressed an interest in working in the sub 50M range. These people do not appear to include you. The question before us is how [I]we[/I] can optimize [I]our[/I] contribution to GIMPS, not how to fix GIMPS' TF assignment system generally. And of course, by "we" I mean "they". I don't have a GPU either, though I intend to get one within the next few months.

My current best guess is that these people - Dubslow, Christenson, and garo - together have the capacity to TF every 68-bit expiry every day to 70 bits with room to spare, assuming they do nothing else with their GPUs. The question is: what to do with that room to spare. My proposal: use it to factor as many 69-bit expiries to 70 bits as we can, giving priority to those 69-bit assignments which have not had a P-1.

Your proposal appears to be that we TF a smaller number of sub-50M exponents to 72 bits every day, leaving the rest to other people to TF. The problem with this idea is that [I]there don't appear to be any other people TFing in this range[/I]. Instead of being TFed to 72 bits, these other exponents will be left at 68 or 69 bits. Moreover, every exponent we take to 72 bits instead of 70 means six other sub-50M exponents left at 69 bits or twelve at 68 which could otherwise have taken to 70. How is this better?

We could also try to recruit more GPU owners to the effort. With enough, we could maybe take all expiries to 70 bits and then some to 71. Perhaps one of us should post a call for assistance in the GPU forum. However before we do that, I think we need to sort out a system for coordinated assignment "grabbing" and distribution. To get every 68 bit expiry, we will need to "grab" every day. I've volunteered to do some "grabbing", but I'm not sure I want to commit to doing it every day.

Oh, and another thing: Whoever posts the call for assistance, please let it not be you. So far, all you've achieved is to piss everyone off on the subject.[/QUOTE]

[QUOTE=garo;275284]No don't drop it. Just edit the worktodo to remove that assignment from it and get core 1 working on something else.[/QUOTE]

Will he will need to drop it manually, (i.e., via his [url=http://mersenne.org/workload/]assignments page[/url] after he has submitted his cudalucas result to [url]http://mersenne.org/manual_result/?[/url]

[QUOTE=bcp19;275282]Don't know if this will help you, I have a core2 Duo E4500 with a GTS 450, Prime95 running LL on 1 core, mfaktc on the other.
I did some runs of mfaktc that were in the 55M range:
68-69 took about 30-40 min
69-70 took about 70-80 min
70-71 took about 2.5 hours[/QUOTE]

Thank you. Are you just giving me benchmark info, or are you offering to take on some of the work we've been discussing?

[QUOTE=Mr. P-1;275291]Will he will need to drop it manually, (i.e., via his [url=http://mersenne.org/workload/]assignments page[/url] after he has submitted his cudalucas result to [url]http://mersenne.org/manual_result/?[/url][/QUOTE]
I don't think so; if it's an LL assignment and he submits the results manually, I think it will clear regardless of what computer PrimeNet thinks it's on. But we'll see.

To bcp19:
Don't drop the assignment. Wait until you've submitted the CUDALucas results, and then check to see if PrimeNet automatically unreserved it. If not, then do it your self.

[QUOTE=Mr. P-1;275260]
Looking forward, I think I should maybe aim to be giving each participant about a weeks worth of assignments at a time, in order to reduce the amount of furtling everyone has to do. (I assume that mfaktc can handle worktodo files of arbitrary length.) [/QUOTE]
mfaktc has been able to handle a week's worth of 15 minute assignments from ckdo, so whatever you dish out for the week will be fine, 'cause there's less assignments.

[QUOTE=Mr. P-1;275261]After further discussion with Dubslow I think I've figured out what happened. It appears that the message about the assignment being assigned to another person is a warning only. If you have the key, then you have the assignment, and can unreserve it.

So yes, you can transfer assignments to other people, so long as you have the keys.

That said, moving forward, I think it will be better for me to handle the unreserves myself.[/QUOTE]

I think we've both decided that even if the above is possible, it's still safer to make the original reservation ANONYMOUSly, and then send the key to the recipient; they can then claim the assignment without fuss. (Mr. P-1 and I have confirmed this 3 or 4 times already.)

[QUOTE=Mr. P-1;275267]
From what you're saying here, you're good till next week at least. I gave Dubslow about 150 units* two days ago and garo 140 units yesterday. I gave Chuck 90 units today, but kept a lot back in case anyone was needing a topup. At a guess, they all look as they they might be done by tomorrow, so I'll split my reserves between the three of them.
[/QUOTE]
Not for me. The assignments you've given me are currently in a couple day long queue after DC TF.

Could a mod please delete the previous four posts? In the future I won't do anything so silly again.

[QUOTE=Mr. P-1;275291]Will he will need to drop it manually, (i.e., via his [url=http://mersenne.org/workload/]assignments page[/url] after he has submitted his cudalucas result to [url]http://mersenne.org/manual_result/?[/url][/QUOTE]
I don't think so; if it's an LL assignment and he submits the results manually, I think it will clear regardless of what computer PrimeNet thinks it's on. But we'll see.

To bcp19:
Don't drop the assignment. Wait until you've submitted the CUDALucas results, and then check to see if PrimeNet automatically unreserved it. If not, then do it your self.

[QUOTE=Mr. P-1;275260]
Looking forward, I think I should maybe aim to be giving each participant about a weeks worth of assignments at a time, in order to reduce the amount of furtling everyone has to do. (I assume that mfaktc can handle worktodo files of arbitrary length.) [/QUOTE]
mfaktc has been able to handle a week's worth of 15 minute assignments from ckdo, so whatever you dish out for the week will be fine, 'cause there's less assignments.

[QUOTE=Mr. P-1;275261]After further discussion with Dubslow I think I've figured out what happened. It appears that the message about the assignment being assigned to another person is a warning only. If you have the key, then you have the assignment, and can unreserve it.

So yes, you can transfer assignments to other people, so long as you have the keys.

That said, moving forward, I think it will be better for me to handle the unreserves myself.[/QUOTE]

I think we've both decided that even if the above is possible, it's still safer to make the original reservation ANONYMOUSly, and then send the key to the recipient; they can then claim the assignment without fuss. (Mr. P-1 and I have confirmed this 3 or 4 times already.)

[QUOTE=Mr. P-1;275267]
From what you're saying here, you're good till next week at least. I gave Dubslow about 150 units* two days ago and garo 140 units yesterday. I gave Chuck 90 units today, but kept a lot back in case anyone was needing a topup. At a guess, they all look as they they might be done by tomorrow, so I'll split my reserves between the three of them.
[/QUOTE]
Not for me. The assignments you've given me are currently in a couple day long queue after DC TF.

Ignore me
 

[QUOTE=Dubslow;275301]Could a mod please delete the previous four posts? In the future I won't do anything so silly again.


I don't think so; if it's an LL assignment and he submits the results manually, I think it will clear regardless of what computer PrimeNet thinks it's on. But we'll see.

To bcp19:
Don't drop the assignment. Wait until you've submitted the CUDALucas results, and then check to see if PrimeNet automatically unreserved it. If not, then do it your self.


mfaktc has been able to handle a week's worth of 15 minute assignments from ckdo, so whatever you dish out for the week will be fine, 'cause there's less assignments.



I think we've both decided that even if the above is possible, it's still safer to make the original reservation ANONYMOUSly, and then send the key to the recipient; they can then claim the assignment without fuss. (Mr. P-1 and I have confirmed this 3 or 4 times already.)


Not for me. The assignments you've given me are currently in a couple day long queue after DC TF.[/QUOTE]

David

[QUOTE=Dubslow;275301]Could a mod please delete the previous four posts? In the future I won't do anything so silly again.[/QUOTE]

What was silly about them? If there's some rule of netiquette about not posting multiple consecutive replies to the same thread then I'm not aware of it.

[QUOTE=chalsall;275286]Two suggestions, if I may...

1. Have you tried setting the Automatic wakeup in the BIOS? If it the machine turns itself off in the middle of the night, having it wake up at (for example) 0800 is better than nothing.

2. Do you have a Linux box on the same LAN? If so, take a look at the "wol" ("Wake On LAN") command which can easily be run from a CRON job. Usually takes a bit of configuration for each client (again, in the BIOS), and some (very) older machines don't support it, but if the machine in question supports a GT480, it almost certainly will.

2.1. There are similar commands under Windows which you could probably use similarly if you don't have a Linux box there. Can't speak to this directly -- I don't do Windows.[/QUOTE]

I don't *like* to do windows, so I just stop by from time to time...and accept the impact.

Now this might be a good thing for my xubuntu box at home, it crashes every now and then when I'm not there.

The 480 is on a Phenom II x4 CPU, so should have automatic wakeup settings. Time to go look next time I'm there.

Groundhog Day
 

[QUOTE=Mr. P-1;275303]What was silly about them? If there's some rule of netiquette about not posting multiple consecutive replies to the same thread then I'm not aware of it.[/QUOTE]

David

[QUOTE=Mr. P-1;275292]Thank you. Are you just giving me benchmark info, or are you offering to take on some of the work we've been discussing?[/QUOTE]

It was just benchmark info in case anyone else later wanted to know what the 450 could do. With CUDALucas LLing I only have 8% GPU left and if I try to TF it takes 3-4 times as long.

[QUOTE=Mr. P-1;275258]I think the most useful unit of work here is a TF68-69. Everything else will be in multiples of that.

Based upon what people have said in this thread so far:

Dubslow ??? 15-16 minutes (about 90 per day)
Christenson GTX440 36-37 minutes (about 40 per day)
Christenson GT480 ???
garo ??? 13-14 minutes (est.) (about 100 per day)
Chuck GTX580 ???[/QUOTE]

68 to 69 is about 16.5 minutes

Chuck

Day 3 Stats
 

Last night's grab yielded:

40 assignments under 50M TFed to 68 (No P-1)
59 to 68 (P-1 done)
51 to 69 (No P-1)

I also grabbed the 50Ms and 51Ms. This yielded 38 to 69 at 50M (No P-1). There were no assignments in the 51M range meeting our criteria.

Responding here to a remark I made in another thread about the leading edge of the first-time test wave:

[QUOTE=Mr. P-1;275367]Test= assignments are in the low 55Ms. All appear to have been P-1ed. Most are TFed to 71 bits, but a few are only at 69.[/QUOTE]

It would make sense to prioritize these exponents for TF 69-70 over lower P-1ed exponents at the same bit level because it takes less time to do them, and a success saves more LL effort.

Question: Does it make sense to prioritize these over smaller exponents which have [i]not[/i] been P-1ed? If the answer is "no", then we probably don't currently have the resources to do them. If "yes" then we do for at least some of them, and we should.

I've also seen some 55M Test=assignments which were not P-1ed. There were all factored to 71, but it raises the possibility that there are some out there which are TFed to 69 and not P-1ed. We should try to do these to 70 if we find any. Only TF 68-69 is higher priority, and I'm pretty certain we have more than enough capacity to do all of these.

[QUOTE=Mr. P-1;275371]Responding here to a remark I made in another thread about the leading edge of the first-time test wave:



It would make sense to prioritize these exponents for TF 69-70 over lower P-1ed exponents at the same bit level because it takes less time to do them, and a success saves more LL effort.

Question: Does it make sense to prioritize these over smaller exponents which have [i]not[/i] been P-1ed? If the answer is "no", then we probably don't currently have the resources to do them. If "yes" then we do for at least some of them, and we should.

I've also seen some 55M Test=assignments which were not P-1ed. There were all factored to 71, but it raises the possibility that there are some out there which are TFed to 69 and not P-1ed. We should try to do these to 70 if we find any. Only TF 68-69 is higher priority, and I'm pretty certain we have more than enough capacity to do all of these.[/QUOTE]
I think regardless of exponent, those without P-1 should be prioritized first, followed by bit levels. I don't think the exponent itself should matter. (Or, all else being equal, the higher exponent being given priority to due LL cost)

[QUOTE=Dubslow;275381]I think regardless of exponent, those without P-1 should be prioritized first, followed by bit levels. I don't think the exponent itself should matter. (Or, all else being equal, the higher exponent being given priority to due LL cost)[/QUOTE]

No. Consider the following three options which would (on exponents about the same size) all take about the same amount of processing time.

Option 1. Factor two P-1ed exponents from 68-69. We have 2 * about 1% chance of finding a factor that the P-1 failed to find = 2 * about 1% chance of saving 2 LL tests.

Option 2. Factor one P-1ed exponent from 69-70. We have 1 * about 1% chance of finding a factor the the P-1 missed = 1 * about 1% chance of saving 2 LL tests.

Option 3. Factor one non-P-1ed exponent from 69-70. We have 1 * about 1% chance of finding a factor that a P-1 test would miss = 1 * about 1% chance of saving 1 P-1 test + 2 LL tests. We also have 1 * about 0.3% chance of finding a factor that a P-1 test would also find = 1 * about 0.3% chance of saving a P-1 test.

Option 3 is better than option 2, but only marginally. In fact the difference between them is that option 3 gives us an extra 1.3% chance of saving a P-1 test! Option 1 is clearly better than either, and should be prioritised.

Day 4 Stats
 

Last night's grab yielded:

25 assignments under 50M TFed to 68 (No P-1)
18 to 68 (P-1 done)
50 to 69 (No P-1)

Additionally I got 62 assignments in the 50M and 51M ranges TFed to 69 (No P-1)

In view of the preceding analysis, starting from tonight, I will also keep exponents TFed to 69 that have had P-1 done.

Congratulations to Chuck for being the first to report back his completion of the work I had given him.

[QUOTE=Mr. P-1;275442]
Congratulations to Chuck for being the first to report back his completion of the work I had given him.[/QUOTE]

I will start the next batch Monday after I get home and don't have to use remote access software to control my machine. Cutting/pasting/editing is annoying in that mode (using Teamviewer).

Chuck

[QUOTE=Chuck;275443]I will start the next batch Monday after I get home and don't have to use remote access software to control my machine. Cutting/pasting/editing is annoying in that mode (using Teamviewer).[/QUOTE]

I use TightVNC to do, I guess, the same job. I've never tried to cut@paste through it though, instead I pass data via a share on the "remote" machine I have mounted locally. I put "remote" in quotes, because it's physically right next to my main box, and connected via the LAN. Couldn't you do something similar with a genuinely remote system using VPN?