Ooh, I hate when that happens!
 

[quote=petrw1;163146]I have a core Duo E6600 with two workers both running LL&DC

Early Feb when the server released all the v4 assignments I grabbed about a 20 28M LL tests for this PC; 10 for each worker; Each worker previously had about 7 18M DC tests and 5 28M LL tests. These assignments would bring each worker up to 240 days.

I have in prime.txt
DaysOfWork=90
UnreserveDays=300

Today at 2009-02-17 14:16 Worker #1 Unreserved all 15 LL assignments (not the DC tests) and then proceeded to get new work. However it only got enough work for 90 days; 6 of the same LL assignments returned for a net loss of 9.[/quote]

Yeah, this has happened to me before, and is quite annoying when it does happen, as I like to hang on to my exponents (how badly would it suck to lose M47 to someone else?!?) even if I pick them up by mistake. I too have DaysOfWork set to 90 and I go really crazy setting the UnreserveDays to something like 1460 (4 years) or even 3650 (10 years). I also make sure that MaxExponents is set to something high like 999. But I have still had instances where I add exponents to my worktodo file, and communicate with the server, only to have a whole bunch of exponents unreserved seemingly for no reason. It's then nigh impossible to get them all back, especially smaller ones, as the server will immediately hand them out to other people.

Since I've upgraded all of my computers to v25.9.3, I haven't seen this bizarre behavior, thankfully, and I too have stocked up my cores with 36 new assignments - 28 28Ms and 8 31Ms, to go with about 50 other assignments in the mid and high 30s, and newer stuff in the 43 and 46M range (for some reason, I've never been given a 44M or 45M exponent). The upshot of this is that I have 13 cores stacked up with enough work for the next 230 days or so (assuming I don't get lucky with P-1), but staggered nicely so that I see a new LL result roughly every 5 days, which is pretty neat.

[QUOTE=NBtarheel_33;163173]Since I've upgraded all of my computers to v25.9.3, I haven't seen this bizarre behavior, thankfully.[/QUOTE]

At least I know I am not crazy now (well maybe not as crazy anyway).

I would upgrade all to 29.3 except that a few tests have shown that it is slightly SLOWER for a PIV. But actually this Duo (and a Quad) were already upgraded to 25.9 Build 3 when this happened.

I am hoping this is a freak occurence. If on the other hand it is a known (dare I say) bug then there may be documentation on how to avoid it because whereas I will NEVER consider myself more worthy than anyone else in getting preferred assignments I don't like losing those I was fortunate enough to acquire.

[quote]
I would upgrade all to 29.3 except that a few tests have shown that it is slightly SLOWER for a PIV.[/quote]

Is this based on your own testing, or on what you have read here? If it's the latter, you might want to run your own tests - I find build 3 to be slightly faster on the Prescott P4s I have borged - last night I saw iteration times of 79ms for a 46M exponent, and before build 3, I had *never* seen the iteration time crack 80ms. 1ms * 46M = 46000 seconds, which is just under a savings of 1/2 day.

[quote]I am hoping this is a freak occurence. If on the other hand it is a known (dare I say) bug then there may be documentation on how to avoid it because whereas I will NEVER consider myself more worthy than anyone else in getting preferred assignments I don't like losing those I was fortunate enough to acquire.[/quote]

If you have UnreserveDays and MaxExponents set high enough, as I have done, to me this has got to be a bug that George may/may not be aware of. If this is a bug that cannot be easily tracked down and fixed, what might be a good idea is to protect released exponents for some interval after their release (e.g. 15 minutes) so that they are not immediately available to be snatched up. Don't know how hard it would be to implement, but I imagine it could be done by keeping an exponent in "limbo", i.e. registered to a user (and able to be registered under the old hex AID) for say 15 minutes, *even after the unreservation of the exponent in question*.

I agree that this is something that does need to be resolved one way or another, as it is very annoying to be in endless cycles of reserving and unreserving and keeping AIDs straight, especially in my case where I keep a pool of over 80 exponents, half of which would be "preferred".

Prime95 once also randomly unreserved an exponent assigned to me. It too was a "first-time test" (there was one suspect result reported before on that exponent), it was manually reserved.

(on my pentium 4 prescott) assuming v25.9.3 is "p95v259.zip", it's about the same as v25.8.5 which I will continue to use

Great work on v5.0! That said, I can't be the only one a tiny bit disappointed that my account no longer have a track of when I first joined GIMPS some 10 years ago.

"Account created 2008-10-29 19:15 UTC" <-- somehow, there's not the same fun to this

TF-LHM Limit suggestion....
 

Can I suggest that the TF-LMH limit be increased to 64 bits since that seems to be a performance dividing line for older artitecture PCs. Going up to 64 would still be efficient for even the slowest PC (my PIII 866 could finish up to 64 in less than 1 hour).

I have two older PC's running TF-LMH (a PIII and an Athlon).
They both perform very good up to 64 bits. 65 bits takes 6 times longer than 64 (not twice as you might expect).

However I am getting assignments on both up to 63 bits in the current 140M ranges. Is everyone getting 63 bits? The PIII takes about 26 minutes for 58-63 bits; the Athlon about 17 minutes.

63 and 64 bits are actually handled best by Athlons running 64-bit OS and clients. But I agree that at 130M, 63 bits goes by too fast even for slow machines. Also, perhaps the 56-62 range should be unified to cut down the amount of server communication required.

[QUOTE=garo;164652]I agree that at 130M, 63 bits goes by too fast even for slow machines.[/quote]

Done. Assignments are now to 2^64 for exponents between 100M and 400M, 2^65 to 800M, and 2^66 to 1B.

[quote] Also, perhaps the 56-62 range should be unified to cut down the amount of server communication required.[/QUOTE]

Improved in 25.9 build 4.

[QUOTE=petrw1;163146]Today at 2009-02-17 14:16 Worker #1 Unreserved all 15 LL assignments (not the DC tests) and then proceeded to get new work.[/QUOTE]

To all sufferers of the unreserve bug:

By any chance was the client doing P-1 when this happened? P-1 sometimes reports percent complete over 100% - I haven't figured out that bug. A side effect, fixed in 25.9, is that estimated completion dates were not calculated properly leading to erroneous unreserves.

For me the assignment didn't start yet...but P-1 was done for that exponent already, it just needed the actual LL test.

The question relates to the exponents that were being tested at the time...not the exponents that were unreserved.