That's true, the server can be represented as a sole reducer.
The objective, though, is to distribute as much as possible and reduce
sequential work, so if possible, it would be benefitial in some cases to
have a distributed group of reducers.
BOINC only needs an outbound connection to the
Heard from Richard that a fix has now been found for this problem. Thanks
for tracking it down:
The cause has been found. In your client_state.xml file, you'll find a
section like this:
[code]time_stats
on_frac0.998909/on_frac
connected_frac1.00/connected_frac
All the pieces are open source. Re-write the code in the middle so that it
generates a new file with a new hash and reports the new hash along with
the new data. Or, if the hash is coming from the server, have a re-written
client for those in the know that ignores the hash entirely.
OK, we are
For the last ~24 hours I've been testing the default credit system.
I made a logger which keeps track of credits granted, and I'm already observing
weird values there.
mysql select wu_type, MIN(granted_credit), AVG (granted_credit),
MAX(granted_credit) from granted_log group by wu_type;
Gianni reports (see below) that GPU apps run much faster, like 2X,
if their CPU and GPU parts synchronize by busy-waiting instead of interrupts.
(Busy-waiting means using 100% of a CPU,
and this process runs at normal OS scheduling priority.)
E.g. you might get a 100 GFLOPS increase in GPU speed
Where to start. First of all the SWAN_SYNC environment variable referred to
is only CLAIMED to speed the GPUGRID app by 20-30%, not 2x. Users report an
actual speedup of 10-15% on Fermi cards. Other GPUs see little or no
benefit. Using this variable does indeed reserve 1 CPU core. Some users
OK, let's defer this issue until it's well understood
whether GPU apps can run at top speed without busywaiting.
-- David
On 05-Nov-2010 7:04 PM, Ed A wrote:
Where to start. First of all the SWAN_SYNC environment variable referred to
is
only CLAIMED to speed the GPUGRID app by 20-30%, not
