My home box is on the web only very intermittently. It finished a LL test
several days ago and did not have another exponent ready to test, so I set
it going on some ECM factoring.
Just now, I started the dial-up connection and tried to upload the LL result
manually, with no discernable effect whatsoever.
Was there a prime.spl file? When you say you tried to upload
manually, do you mean you have "Do not contact PrimeNet server
automatically" checked in Advanced/Manual Communication, and
that you then selected Advanced/Manual Communication/Contact
Now? Was the system actually on line at the time, if not do you
have auto-dial enabled in Windows Dial-Up Networking?
I then stopped the ECM curve and tried again.
When Prime95 is running a LL test or factoring assignment, it
doesn't respond instantly to a "connect now" request. I think it waits
till it gets to a point where it can write a checkpoint file. This
sometimes takes up to a minute. Now, ECM does not use
checkpoint files (at present), so maybe it doesn't know how to
interrupt itself to make the PrimeNet connection, unless you leave
it long enough for the current curve to complete. :-(
Perhaps this "buglet" (or unwanted feature) is another reason why
a small change to Prime95 might be indicated. What I'm thinking of
is that, when the (low priority) computing task detects that a
connection to PrimeNet is neccessary, it forks off a new task
(which should run at normal priority) to handle the connection. The
new task can die as soon as its job is done. The point here is that
there would be no need to interrupt the computing task, and, in the
event that a deadlock occurred in the PrimeNet comms, time would
not be lost with the computing task stalled.
This time, the server was "busy" (Error 23 returned)
If the last thing I wrote is wrong, then maybe either there already was a
connection from your machine to the PrimeNet server, and trying to
start another caused it to get confused. Probably confused enough
to reset the connection i.e. terminate it, unless special recovery
handling is built in. So it works next try...?
and Prime95 V16.4.1 started a new ECM curve; the effect was
reproducible. I
know the server was ok, because I was looking at various status pages.
Well, it *would* start a new curve - this is normal behaviour...
The workaround is to rename the worktodo.ini file in the Prime95 folder and
to re-run the manual communication. My LL result is now on the server and
I've been allocated a new exponent.
You could also exit Prime95, stick a line at the top like
DoubleCheck=11213,40
which executes very fast but causes some LL testing work to be
done when you restart Prime95. Thus giving the manual
communication a chance to bite (and your computer a chance to
"discover" a Mersenne prime!). The spurious result won't hurt the
PrimeNet server. If you look at lucas_v.txt (from the database - see
http://www.mersenne.org/status.htm) you can even turn this into
(more or less) useful work. There are lots of very small exponents
which have been double-checked, but one of the residuals is very
short, IMHO it would do no harm to have a few of these rechecked
with Prime95 v17.
A better "workaround" is to set your "days work" (in Test/PrimeNet)
to about twice the time between your machine's "very intermittent"
connection to the Net. Then, look for a prime.spl file, if there is one
(probably only 1 byte long) Prime95 wants to interact with the
PrimeNet server - maybe it wants more work - let it contact the
server get some. That way, you shouldn't get into "emergency"
(run ECM for a while) operation modes.
Not that there's anything wrong with running ECM...
Regards
Brian Beesley
