answered, but you can add more if you like (was -> rc5: will this cheat the stats?)

[stndn]

i did some cracking at home pc plus some at work.
the home cracking is almost done, about 1 day + several hours left (after about a week 🙁 ).

tomorrow i'm going to bring my home's buffer out on a floppy, transfer it to my work machine, update the buffer, get new work units, and move it back to my home machine.

1. if after i do that (update my home's units from my work machine), and then i go home and update the same units from my home machine, will anything bad happen either to my dnet client, my machine, tacube, or the world as we know it? what about everything else?

more questions:
2. since the two machines are different speed (MHz), will anything bad happen if i run the remaining units on different machine speed?
3. is it possible to run two clients on one machine?
4. if yes, when i do work unit update, will one client mess the other's units?

thanks a lot for the help 🙂
and no, i don't plan to cheat. that's why i'm asking these questions

-sutan.

 

[networkman]

You needn't worry about submitting duplicate blocks.. Dnet will sort this out just fine. I had a similar occurence a while back when I imaged a drive for another system and both systems later flushed their duplicate blocks.

I cannot forsee any problems with running blocks at different speeds, such as in a case where you download a whole bunch of blocks on a p2-350, then a couple hours later upgrade the cpu to a p3-550.. the blocks don't care which processor cracks them, though some processors have an advantage over others. Refer here for more info on that.

As far as running two clients on one machine... not sure. The RC5 client is SMP aware meaning that it will identify both CPUs in a dual processor system and use them both - you can configure the client not to, but given this information, I can't see why you'd want to run more than one RC5 client on a machine. If a dual system(or more) you could configure the SETI@Home client to run on one processor and have the RC5 client run on the other processor if you wanted.

Does that help?

 

[stndn]

thanks for the info. yup it does help.

no i don't have dual processor... i only have one. i was just thinking if after i update my dnet blocks tomorrow, while the client is still hanging around and my work client kicks back again, i will have two clients running.... but i guess i'll just make sure it doesn't happen

after i re-read my own question, i have the feeling i didn't make much sense... but oh well, i guess i know what i need to know, so that's settled.....

thanks again.

 

[ZapZilla]

1) pproxies are not smart enough to filter duplicate blocks, only the DNet servers can do that, thus, duplicate blocks will count on pproxies. It has happened that buff.out files have been copied and submitted several times giving an artificially high number of pproxy blocks. Crunching random blocks may result in duplicate block submission too. DNet's stats will only list true blocks and not duplicate blocks.

2) No. When a block is done it gets assigned to it the email address from the DNet configuation of the machine it is run on. Speed of doing the block is not a factor. You could crack a block for a while, reboot your machine at a different clock/bus speed, and then resume cracking that same block without any problems.

3) Two or more clients can be run, but if there are more running clients than CPUs running, then there is a loss of efficiency and keyrate due to system resource overhead. The DNet client will automatically find each CPU on a multi-CPU system and launch a client for each one. The different client processes will be designated with a letter of the alphabet starting with "a".

Running different projects on the same machine such as SETI and RC5 at the same time will depend on the priority settings of the projects to determine how much CPU time each process gets. I only run one project per machine.

4) Unless you do something strange to alter the normal process, each instance of the client will get their blocks from the same buff.in file and send finished blocks to the same buff.out file.
I guess if you installed, configured, and ran different clients from different directories, then each client would fetch and flush from their own set of buff.in and buff.out files, but this would add a lot of unneeded overhead.

Go Team AnandTech!