[RC5] newbie question

Bruce Wilson bwilson at distributed.net
Mon Aug 25 16:12:10 EDT 2003

| After residuals are joined there is no reason
| to split them again. All after all they must have
| origined from the same participant or we would
| not be able to catch who's cheating anyway.
| So if they're from the same participant then
| there's little sense in checking which of the
| blocks is flawed. Again - no splitting.
| Of course I could have missed something, so
| please tell me: why do you want to split them?

You caught the essence of my message.  Blocks are split on their way
downstream, and combined (when possible without losing information)
when travelling upstream.

| > Another factor is that tracking the running
| > XOR/CRC/whatever may have a greater
| > impact on performance on register-starved
| > architectures (X86).
| It can be hold in memory and be cached.
| Of course using cache may or may not be desired.

Hmm... Not exactly.  Reading the CRC out of RAM into CPU registers,
and writing it back to RAM after modification is what would cause the
slowdown.  The caching effects of processors is already accounted for
in the optimization of a core.  Adding more information to be tracked
while processing the work unit would require us to reconsider the
caching effects.

| This words about cache brings another question.
| Where d.net client slows down the system most
| and is it possible to reduce that effect?

The primary bottleneck on a system running dnetc is the CPU.  This is
understandable, since the entire purpose of dnetc is to put as much
CPU power as possible towards the problem.  Since dnetc runs at the
lowest possible priority, any other task on the same computer with a
higher priority should draw CPU away from dnetc, as it should.
Because of the way most operating systems work, dnetc will always
receive some small amount of CPU even if many other tasks are
demanding the CPU at a high priority.

The most obvious ways to make the client faster are to optimize the
core so that it requires less CPU cycles per loop iteration, and to
reduce the latency (delay) of the instructions created by the order in
which they are executed.  I don't know how much more could be done to
make dnetc back off more completely, since it's already running at the
lowest priority.  This is really an operating system issue, not a
dnetc issue - all CPU-intensive tasks are faced with the same issue.
There are some problems encountered occasionally between dnetc and
other idle-priority tasks, but otherwise the impact is not noticeable
to the user (unless they look at Task Manager).

Bruce Wilson <bwilson at distributed.net>
PGP KeyID: 5430B995, http://www.toomuchblue.com/ 

"I want to move to Theory. Everything works in Theory."
    --John Cash, id Software

More information about the rc5 mailing list