[RC5] Help with justification of running Dnet at work

Slawek sgp at telsatgp.com.pl
Fri Mar 17 09:32:47 EST 2006


Hello, Earl!
You wrote to "'D.net Discussion'" <rc5 at lists.distributed.net> on Fri, 17 Mar 
2006 08:30:59 -0500:

 ES> Can anyone provide me with some help. Again, I am putting info together
 ES> on the project and how it runs. What would be great is an explanation
 ES> of the source code showing that is only runs when idle. I have
 ES> benchmarks run on my laptop but as you can see the instructor doesn't
 ES> believe them.


Well, I'd say that it is true that d.net slows down at least some of the 
computers.
That are a few reasons why:

1) Hyperthreaded processors. HT processors can execute more that one logical 
thread at the same time using one processor. Unfortunatelly doing that means 
processor has to divide it's processing power to two processes. This means:
- all of the caches are split: including program memory cache, data memory 
cache and branch prediction cache
- processor has to do some more operations to support multiple processes 
running at the same time
- and most important: processor has to split it's set of virtual registers 
to two processes, which means that code highly optimised for given 
processor - where the processor can optimise it's execution speed when run 
only one process at the time, it may be even slower that 50% of it's 
original speed when two processes are run at the same time.
The main problem here is that (at least when I've taken a look at it) HT 
processors doesn't support processes' priorities when talking about 
hyperthreading and it means that even if process with priority "realtime" is 
run together with a process with priority "idle" those processes would spare 
processor's resources evenly (yes, really, check it if you don't believe).

2) Operating systems frequently does different tasks in the background. On 
some OSs system's "dile" priority is lower that anything user program may 
use. If any process wants to constantly run at "idle" priority, such system 
tasks would not run at all. Such tasks are comonly used to clear freed 
memory, optimise disk cache usage and so on - and it really hurts if those 
tasks are not run at all.

3) Some operating systems doesn't strictly follow the rule "if there's any 
process with higher priority than this one, than skip this one and execute 
process with higher priority". Other scheduling rules (too complicated to 
explain here) can make a difference in good direction in normal 
circumstances, but if d.net client is run... it is run for some time even if 
higher priority tasks wants the processor...

4) Should your system use dynamic speed fans, it would work lauder when you 
launch d.net client. If your fan aren't able to cool the system at 100% 
usage it's possible your processor (or other chips) are working with 
throttled down clock after some time of heating up using d.net client.


Those problems may apply to you or not.
You may quickly set-up a test using d.net client only (it would not catch 
all of mentioned problems):
1) Set up one d.net client to run constantly with normal priority (like 
normal program do) and measure it's performance.
2) Launch second copy of d.net client while first one is still running and 
check if first's client's performance decreased. If it did - you've just 
decreased performance of normal priority program.


With best regards, Slawek.  E-mail: sgp at telsatgp.com.pl 



More information about the rc5 mailing list