Successful sneakernetting

[ihrsetrdr]

Transferring Linux SMP WU's from one machine to another has been hit-and-miss for me, but I think I may have found the answer. Before, I'd just copy the entire directory(after killing the client processes) to a pendrive, then copy onto the recipient machine the directory from the pendrive. More often than not, the WU would start, but at 0 frames completed instead of where it had left off, on the original machine. This evening I was decommissioning a rig, but didn't want to wait for the WU to complete(another 10 hours) so I tried something different, I deleted the machine dependent .dat file, figuring that this must be what's causing the transplanted client's confusion...started up the WU on the recipient machine, and the WU picked up right where it left off. :clap: I'm probably the last one to know about this, but I thought that I'd share. ;)

[dfonda]

That will come in useful.:)

I lost a HD a couple weeks ago when the power flickered, so I have been running offf Ubuntu's CD.
At some point I need to put a HD in and transfer the WU (Or do a -oneunit) seems to run just as well off the CD but I can't turn the machine off.

[pscout]

I haven't resurrected my old practice with the standard client of occasionally sneakernetting wu's to optimize things a bit, usually around cache.

It was always very reliable on standard client, but like your experience I have been reluctant to do it with smp except when necessary due to corrupted linuxes (unstable oc probably) or switching between win smp and linux.

Although with the standard client, there were all the usual official warnings that it was not supported, it always seemed to work fine.

One aspect that I am less confident about with smp wu's is the assignment server behavior that will reassign the same wu to an instance that has had its wu deleted (ie work and queue.dat) 3 times before assigning a new one. I have has this happen a lot through the beta's especially on linux.

This behavior may have been present with the standard clients too, but i never experienced or noticed it - possibly because of the reliability of the standard client.


So, for example, instance A has wu #1, instance B has wu #2. If I swap the wu's (and not machinedependant.dat which contains the instance's unique id) and A turns in #2 before B turns in #1, will the assignment server feed A a new wu? or will it reassign wu#1 since it hasn't been returned by B yet?

Since things have been a bit more stable on the farm lately, i will probably test this out. One advantage of running several quads is that it is reasonably practical, and in many cases advantageous points wise, to run 2 smp instances in linux. However, if the 2 instances both get 2609's, total throughput goes down. It doesn't happen very often since the quads tend to get 304x/5x wu's which only run at ~70%. In the past when i did get 2 2609's, I would just stop one instance till the first one completed and then restart the second one. So some sneakernetting would probably be worthwhile as long as it is reliable. If the restarts are usually from 0% then any advantage would be lost in most cases.

[harlam357]

On WinSMP I've been swapping some WUs around from my 2x1mb cpus and my 2x512k Brisbane. Just been doing the old stand-by... work folder and queue.dat. Haven't had a problem yet.

Although I'll have to keep an eye on what WU comes next after I do a swap and make sure they aren't being reassigned the same WU.

Thanks for the heads up on that one pete. :thup:

[ihrsetrdr]

I'm curious as to what the difference is between the SMP client and the "regular" clients is, in regards to the machine .dat file; the regular WU's have always transplanted fine for me. I'm guessing that there exists some extra parameters involved to identify the machine as being multiple processor....? I remember one occasion where I had just setup a Linux box, and tried to start a SMP client, but got some terminal output telling me that the box wasn't SMP compliant. Turns out that for reasons unknown, the SMP kernal had not been loaded during the o/s install.


Speaking of quads(Q6600), will they in fact be the "shnizzel" and knock out WU's twice as fast as a comparably clock E6600? July 22nd price drop is the date I've been holding my breath for...:D From my recent sales of the farm components, I've got enough saved in my paypal account for 3 Q's. :burn:

[pscout]

Speaking of quads(Q6600), will they in fact be the "shnizzel" and knock out WU's twice as fast as a comparably clock E6600? July 22nd price drop is the date I've been holding my breath for...:D From my recent sales of the farm components, I've got enough saved in my paypal account for 3 Q's. :burn:

It depends on the oc ... since mine are all ~ 3 ghz vs my 6600 average ~ 3.3 the average thoughput is less than double, but close.

I am running all of my quads under 1.4 V now ... mostly ~ 1.35 V so that limits the oc somewhat. The q6600's need a bit more V than the x3210's, but they have the 9 multi vs 8 so the clocks end up about the same.