Log in

View Full Version : Moving tests from one machine to another



robvanwijk
02-15-2010, 04:35 PM
Hello everyone,

This paragraph is just context, feel free to skip it
One of my machines has some serious issues (random freezes and bs like that). I'm pretty sure one of those crashes messed up my intermediate save files. The reason for that suspicion is my results.txt file:
It starts logging on March 24, 2009 (when I installed the new client). On October 19th it shows a lonely "ROUND OFF (0.40625) > 0.40" (is a single occurrence like this reason to worry??), then on February 10 it goes berserk, between then and now I've got 254 "ROUND OFF (0.5) > 0.40" errors and 3 "SUM(INPUTS) != SUM(OUTPUTS)".
Not so much because of the errors in SoB, but because of others crashes and issues, that machine is getting a bunch of parts replaced and a fresh install of Windows. Since I'd have to move my tests to a new machine anyway (some new hardware and a new OS install is a new machine in my book) I figured I might as well move them to another machine that's already running SoB, so I can get working on those tests right away (not waiting for the new hardware to arrive).

Real question begins here
So, here's what I did:

Exit (not just to tray, really exit) SoB on old machine.
Open up the worktodo.txt file on the old machine.
Exit (not just to tray, really exit) SoB on new machine.
Open up the worktodo.txt file on the new machine.
Copy over the work units from the old worktodo.txt, adding them to the new worktodo.txt (after the current assignments).
If you skipped the first paragraph: I did NOT move the p?????_????????{""|".bu"|".bu2"} files, since I'm convinced they've been corrupted (besides, I'm not sure if they're compatible between an AMD Phenom 64bit and some Intel CPU running in 32bit mode).
Restarted SoB on the new machine.
In Test\Status the new tests show up correctly.
However, when communicating with the server, it complains about "CPU not registered" (I guess that translates to: the server noticed I moved the workunits to another CPU (machine) and didn't approve).


Question 1: Is there a way to do this move? How do people that use sneakernetting solve this problem?
Question 2: Am I right to assume that a fresh install of SoB (I have to, the OS is getting a fresh install as well) would also trigger this "CPU not registered" error? Or is there a way around this?
Question 3: The only alternative to running these tests on another machine is restarting them from scratch on my current (unstable and buggy) machine. Since that doesn't sound like a good idea, I'd have to manually unreserve the work units, so I'd really prefer running these tests on another machine.

Any help would be really appreciated!
Rob

enderak
02-15-2010, 09:54 PM
I move tests around all the time, although never without copying the p???... files, so I don't really have a definitive answer to your questions. It might have more to do with the server seeing a result come in with negative work done than with a hardware change. Maybe you can prevent it from communicating with the server until it's past the point where you stopped them on the old computer and see if that helps. But of course, that will be a lot of wasted crunching if it doesn't work.

However, since you are restarting the test(s) from scratch anyway, the better solution might be to just cancel them (i.e. expire them on the website and remove them from your worktodo.txt) and then restart Prime95 to start crunching on a brand new test. Then the test will just get assigned to someone else.

robvanwijk
02-15-2010, 11:33 PM
However, since you are restarting the test(s) from scratch anyway, the better solution might be to just cancel them

Argh, how did I not see that...!? :confused: You're right of course; if I'm restarting from scratch anyway it doesn't matter on which tests, I might as well get new ones.

Edit:
Okay, done. Fixed worktodo.txt, forced a manual update, manually expired the tests with an old timestamp (faster and safer than checking exponents). Client and server are happily getting along again. The next time the stats update is gonna hurt though. :( Ah well, looks like it's fixed now, thank you enderak!