PrimeNet error 7
 

What is this error?
[code]
Sending expected completion date for M79299421: Nov 22 2009
URL: http://v5.mersenne.org/v5server/?v=0.95&px=GIMPS&t=ap&g=53adfe7f793ad75ed72
b6f5618763582&k=FFAF8FBF3EF1BAE37DC58554938A503D&c=0&p=0.000000&d=86400&e=461777
03&ss=27927&sh=DEE56EA271127ED5B29BDDA0AAC5533F
RESPONSE:
pnErrorResult=7
pnErrorDetail=parameter e: Invalid int value/precision '46177703'
==END==

PrimeNet error 7: Invalid parameter
parameter e: Invalid int value/precision '46177703'
[/code]The message repeats, but the number e changes every time. The first occurence is here:
[code]
Getting assignment from server
URL: http://v5.mersenne.org/v5server/?v=0.95&px=GIMPS&t=ga&g=53adfe7f793ad75ed72
b6f5618763582&c=0&ss=21557&sh=A0365CD07CBDEF4FDB6A997F04A85DAE
RESPONSE:
pnErrorResult=0
pnErrorDetail=Server assigned Lucas Lehmer primality test work.
g=53adfe7f793ad75ed72b6f5618763582
k=FFAF8FBF3EF1BAE37DC58554938A503D
A=1
b=2
n=79299421
c=-1
w=100
sf=72
p1=1
==END==

PrimeNet success code with additional info:
Server assigned Lucas Lehmer primality test work.
Got assignment FFAF8FBF3EF1BAE37DC58554938A503D: LL M79299421
Sending expected completion date for M79299421: Dec 8 2009
URL: http://v5.mersenne.org/v5server/?v=0.95&px=GIMPS&t=ap&g=53adfe7f793ad75ed72
b6f5618763582&k=FFAF8FBF3EF1BAE37DC58554938A503D&c=0&p=0.000000&d=86400&e=476552
53&ss=64304&sh=4B77EE52AC54FCCAC87C73B041640F93
RESPONSE:
pnErrorResult=7
pnErrorDetail=parameter e: Invalid int value/precision '47655253'
==END==

PrimeNet error 7: Invalid parameter
parameter e: Invalid int value/precision '47655253'
[/code]

The server is rejecting the expected completion date because it is more than two years out.

Obviously, this needs work. Scott and I (and forum members) felt that users should not attempt assignments that last a long long time. IIRC, we talked about recycling reservations more than a year old.

Perhaps we could modify the maximum completion date based on the size of the exponent? Something like min(1yr, exponent_size/40M)??

[quote=Prime95;135311]The server is rejecting the expected completion date because it is more than two years out.

Obviously, this needs work. Scott and I (and forum members) felt that users should not attempt assignments that last a long long time. IIRC, we talked about recycling reservations more than a year old.[/quote]
I didn't choose the assignment. The problematic thread is set to the "GIMPS" worktype. The other thread is set to factoring to reduce pressure on the memory bus and cache, and is not getting more work becuase the error blocks further communication.

Btw the time estimate may be way off, because mprime assumes wrong CPU speed. It is about 1 GHz when mprime detects it, but when mprime starts working AMDs Cool'n quiet will detect the ongoing work and increase the clock to 2,2 or 2,4 GHz. (I suspect Cool'n quiet, but it may be something else.)

[QUOTE=S00113;135319]The other thread is set to factoring to reduce pressure on the memory bus and cache, and is not getting more work becuase the error blocks further communication.[/QUOTE]

I think the error is fixed. You should now get a warning response.

[quote=S00113;135319]Btw the time estimate may be way off, because mprime assumes wrong CPU speed. It is about 1 GHz when mprime detects it, but when mprime starts working AMDs Cool'n quiet will detect the ongoing work and increase the clock to 2,2 or 2,4 GHz. (I suspect Cool'n quiet, but it may be something else.)[/quote]

Yes, this happened to me, too, long ago. I've put the following lines in the [B]local.txt[/B], and you can, too:
[code][SIZE=2]CpuOverride=1[/SIZE]
[SIZE=2]CpuType=11[/SIZE]
[SIZE=2]CpuSpeed=2600[/SIZE][/code]
(put 2400 or 2200 here)

On the v5 homepage, the number of exponents available for ECM equals the number of exponents in the LL-D bucket for each range except 0-999999, where there is one more exponent available for ECM than in LL-D. Any idea why there's a discrepency?

[QUOTE=jbristow;135448]On the v5 homepage, the number of exponents available for ECM equals the number of exponents in the LL-D bucket for each range except 0-999999, where there is one more exponent available for ECM than in LL-D. Any idea why there's a discrepency?[/QUOTE]

It looks like the factors reported for 13711 and 16993 did not clear out the available assignments.

It seems these were reported using the manual results web form. Either there is a bug with the form - I cannot find it. Or the bug has been fixed since they were reported (not unlikely).

I'm seeing an 'off by one' error in the display of the status of thread 1.

For instance, I have two threads running right now, both running P-1 factoring because I just installed Prime95 on this machine. At 3:52 pm, the following line appears (note the time stamp):

[Jun 12 15:37]M42676363 stage 1 is 6.79% complete. Time:847.605 sec.

This is buffered data being displayed when presumably the subsequent message should appear (8.15% progress). Thread #2 appears to be about 15 minutes ahead of thread 1 despite the fact that they both started adjacent exponents at exactly the same time.

[QUOTE=drew;135781]I'm seeing an 'off by one' error in the display of the status of thread 1.[/QUOTE]

I'm not seeing that here. Is the scroll bar dragged all the way to the botttom?

[QUOTE=Prime95;135791]I'm not seeing that here. Is the scroll bar dragged all the way to the botttom?[/QUOTE]
Yes it was...that's the first thing I checked.

However, I'm not seeing it now, either. I changed my memory allocation, and after the associated messages appeared, things went back in sync, and it hasn't happened since, even with subsequent reboots.

I wonder if it's something that happens only after a fresh installation.