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