from 20 to 10 seconds, this broke things on ultra-slow CPUs.
I think this is because a single loop of the FP
benchmark took so long that the end time of the int
benchmark had already come and gone.
Fixed this (I hope) by reducing the loop length
by a factor of 10.
client/
cs_benchmark.C
dhrystone.C
whetstone.C
svn path=/trunk/boinc/; revision=12908
with multicore machines. I don't know why this happened,
but I fixed it by doing integer benchmarks only on CPU zero.
This is OK since cores have separate integer units
(but not necessarily FP units)
client/
cs_benchmark.C
svn path=/trunk/boinc/; revision=12808
if the initial sched request failed,
the manager would show "communicating" for 60 sec,
then time out and show "failed to attach".
But the project would actually be attached.
This was due to a logic error,
but I fixed it in a more fundamental way:
by considering an attach to be complete immediately,
without waiting for a successful scheduler RPC.
This was originally done to ensure that the URL and account key were valid.
But when using the BOINC Manager, we've already verified
both of these before doing the attach project RPC.
When using boinc_cmd, you now have to check for messages
indicating a bad URL or account key.
I changed things to print these messages on every sched RPC.
Implementation: the notion of "tentative project" no longer exists.
client/
client_state.C,h
client_types.C,h
cs_account.C
cs_benchmarks.C
cs_scheduler.C
gui_rpc_server_ops.C
scheduler_op.C
sim.C
sim_util.C
svn path=/trunk/boinc/; revision=12663
of gcc to try and force them to not complain with -Wall but to always
include this, I decided to take a simpler approach. All these strings
now have global linkage. To prevent namespace conflicts they all
have different names. For the record, the variable extension is a hash made of the first ten characters of the md5sum of the file path, eg:
md5hash=`boinc/api/x_opengl.C | md5sum | cut -c 1-10`
svn path=/trunk/boinc/; revision=4979
the top of all .C files. This means that 'string' or 'ident'
run on an executable will tell you the exact file versions used
in building it, since CVS replaces $Id$ with a complete version ID
string. Declaration is volatile so that the compiler won't remove
it even under agressive optimizations.
svn path=/trunk/boinc/; revision=4610
Frank Thomas