Prime95 version 25.7

[markr]

Originally Posted by jinydu

Why even add such an instruction (unreserving) to the client? Wasn't the previous system of the server and manual communications doing all the unreserving good enough?

Nothing has changed in the client (or rather, what it is supposed to do). The client has been able to unreserve an assignment in its own worktodo as far back as I can remember, and more. So if the completion dates were too far in the future - eg if you reduced the "days of work" setting, or progress slowed - it would unreserve some.

[Prime95]

Originally Posted by starrynte

I got one random unreserve too

In Garo's and your case. is there any chance that rolling average moved the expected completion date so far in the future that prime95 decided to do an unreserve?? I can't think of any other good reason prime95 would initiate an unreserve.

[garo]

No, because an hour before the unreserve the expected completion dates were sent out and they were 10-15 days out. Plus I have UnreserveDays=900 in my prime.txt so it should never unreserve. I know this is probably a hard bug to track down. I'll supply as much info as I can and let you know if it happens again.

Also, this is a dual core machine and there were 4 exponents assigned to both cores. Only one had three exponents unreserved. Plus as you can see from the log, immediately after the unreserve, two new exponents were fetched from the server.

[starrynte]

rolling average is a slim possibility for me, but not sure completely

[James Heinrich]

Originally Posted by James Heinrich

I just ran a benchmark (v25.7b4,x64) and the server returned an error:

Sending benchmark data to server
...
pnErrorResult=7
pnErrorDetail=parameter FFT4K: Invalid float value: '5.40571e-005'

I just happened to run another full benchmark and notice this error is still present; hopefully it's on a to-do list to be fixed sometime (where's that public to-do list thread that was talked about?... )

I suspect the above error should be a relatively-trivial fix (at least to let the benchmark submit while ignoring the unhandled value). My personal biggest wishlist priority item is that the x64 client gets fixed so that it doesn't freak out when more than 1800MB RAM is assigned (I'm trying to P-1 M332203901 this month and letting it use 2500MB would be most useful, for example).

[Prime95]

Originally Posted by James Heinrich

I suspect the above error should be a relatively-trivial fix (at least to let the benchmark submit while ignoring the unhandled value).

Already fixed in 25.8.

No luck so far in fixing any memory bugs. Though I will compile 25.8 with the 3GB option for win32 and I guess more fox x64.

[garo]

Is the priority issue fixed in 25.8? Do you want me to test it?

[Prime95]

Originally Posted by garo

Is the priority issue fixed in 25.8? Do you want me to test it?

Yes. Please test it if it is convenient for you.

[garo]

Fixed! Brilliant.

[James Heinrich]

Originally Posted by Prime95

[fullbench benchmark submission] Already fixed in 25.8.

Just tested it and yes, it works fine now -- thanks.

Originally Posted by Prime95

No luck so far in fixing and memory bugs. Though I will compile 25.8 with the 3GB option for win32 and I guess more fox x64.

I'll be starting P-1,stage2 on M332203901 in a day or so; I'll be very happy to test whatever your latest 25.8 build, x64 version if you have one, to see if it'll cooperate with 2500MB allocated. The latest (GUI) version I see right now is the 32bit build from 23nov2008.

[Axel1]

Hi,

is the server down at the moment? Get an unexpected CURL Lib Error?

best wishes
Axel