New Folding member, mostly set up

[Foxery]

Hello, all. I've decided to get back into distributed computing lately, and opted to join AT's Folding@Home team as thanks for all the great info I've read here over the years.

I'm anxiously awaiting the new GPU client for my shiny new Radeon, but decided to play with the CPU client on my P4/2.4ghz office machines in the meantime. Console-6.0b1 is happily crunching away at my desk and Console-5.04 on one next to me, but I have a few quick questions.

-How do I add flags such as -verbosity 9 when running this as a Service? The WinXP Service Manager isn't letting me modify or add arguments, even though there's a text field claiming to do exactly that!

-I accidentally ran v5.04 twice at once from the same directory, and it downloaded two work units. (From different projects.) I stopped one and only want a single instance of the program to run, so how do I either make sure it winds up finishing both WUs, or tell Stanford that one is "dead"? Alternatively, I see two sets of files in the \Work directory numbered 01 and 02... could I perhaps move one set to a new install on another machine?

-Concerning the option to accept "large" WUs, (>5MB in v5, >10MB in v6)
Do these WUs take significantly more time to complete than smaller WUs? i.e. Should I bother with those on less than stellar hardware?

Thanks!

 

[GLeeM]

Hello Foxery and welcome to the TeAm and the DC forum

I'm not sure about how to add flags to service install, but I think it used to be you had to edit the registry. Someone will be along shortly with the answer.

You cannot tell Stanford about a lost WU.
You cannot move one set of files to another directory.
I think it will work out in the end if you just let the one client run.

The large WU option is mostly size of download or upload. With it set you can get WUs that might take days to finish or only hours to finish. I think most run with large WU set to yes.

 

[Insidious]

I edit the registry to add the flags for service installs.

The easiest way I found was to open up the registry editor (run regedit) and then with the top folder selected, I hit cntrl^F to open up the search (find) window. Now I search on the string "-svcstart" (no quotes) to find the folding at home intries. One of them will be "image path" or something like that). double-click it to get the edit wiindow and then I add the flags to the end of the string that is already there.

next time the service starts, you should see (in the fahlog.txt file) that the flags are now in play.

Good Luck (and Welcome aboard!)

-Sid

(edit: I use -local -forceasm -advmethods -verbosity 9)

 

[Foxery]

Whoops... I'm in the wrong mindset at the office to think of RegEdit. That'll be easy enough

Still praying for the new GPU client. I can't wait to see how the stats page explodes when everyone's 3850/3870s come online.

Thanks!

 

[Uppsala9496]

Welcome to the TeAm Foxery.

 

[caferace]

Originally posted by: GLeeM
Hello Foxery and welcome to the TeAm and the DC forum

You cannot move one set of files to another directory.

Howdy, Foxery!

"You cannot move one set of files to another directory. "

I'm not sure that's true. During the race in December my e4500 refused to upload completed WU's, but finished and downloaded them fine. Ultimately, my low-tech solution was to copy files from that box to another, and use that one to upload the results.

What I would do would be to install FAH in a unique directory on the target (uploader) machine.

To do so using CLI client:

1) Stop FAH processes on both machines
2) From the e4500 I would copy the following...
client.cfg
queue.dat
/work
...into (and over) whatever was in the new FAH folder on the target box.
3) Once copied, delete all files in /work folder on e4500 and restart FAH to download and crunch
4) On target machine stop all FAH processes.
5) Start FAH from CLI in new directory with fah.exe -sendall
6) Once complete, stop all FAH processes
7) Double-click install.bat in "real" FAH folder to assure target machine relocked to proper folder
8) Start fah.exe in normal manner on target machine

Yes, it sounds complicated but after a few times it took less than 5 minutes total.
I'm not sure if a variation if this would help moving files to different directories or machines, but it might....

And it might also help someone who ended up in my overlarge shoes. :laugh:

-jim

 

[Foxery]

caferace:
The WU in question didn't finish. The client picked up a second one in the middle of it, and updated the local files to show the new project#. I'll let it run for a few days and see if it works itself out.

GLeeM:
Guess I'll turn Large WUs on next week. My current ones are slated to take 4 days, so I didn't want to feel any slower than that. These machines have vastly underutilized RAM... although, it's ancient DDR-266, so this may yet wind up being slow as @#%.

There are a few other P4s that I could borg without anyone minding, but damn, ~87 PPD for the electricity and heat that come with Pentiums is sad. I'll have to stop some of them in the summer, too, with our crappy air conditioning! Oh well.

 

[GLeeM]

Originally posted by: caferace
"You cannot move one set of files to another directory. "

I'm not sure that's true.

What you are describing is sneakernetting and I do that for half of my points, I just move the entire directory though

Foxery's situation is a little different, with the client run from the same directory twice at the same time somehow (not sure how really the second one should have stopped and said something about a process already running!) they downloaded two WUs.
What I am not sure about is SEPARATING the WUs from queue.dat and making sure to move each WUs unique files along with everything else needed. Possibly, using the -delete # flag after using the -queueinfo flag it would have been possible, but explaining that process was something I didn't have time to do
Double thinking it though, the best advice might have been to delete the entire "work" folder and started over, as I am not too sure things WILL work out. From my experience, when two are run from the same directory, the WU is usually borked.

 

[GLeeM]

Originally posted by: Foxery
GLeeM:
Guess I'll turn Large WUs on next week. My current ones are slated to take 4 days, so I didn't want to feel any slower than that. These machines have vastly underutilized RAM... although, it's ancient DDR-266, so this may yet wind up being slow as @#%.

There are a few other P4s that I could borg without anyone minding, but damn, ~87 PPD for the electricity and heat that come with Pentiums is sad. I'll have to stop some of them in the summer, too, with our crappy air conditioning! Oh well.

When you start doing large WUs make sure you also add the -advmethods flag. Currently, by using this flag you can sometimes get WUs p3906 and p3907 which use double precision floating point and get great PPD. My P4 @ 3.2 gets about 500 PPD Upload is 10 MB though.

 

[Foxery]

I did notice one thing that may help if the program forgets the other WU:
[00:36:59] - Calling 'FahCore_81.exe -dir work/ -suffix 01 -checkpoint 15 -service -forceasm -verbose -lifeline 1692 -version 600'
[/code]

If the Core will let me call it manually, rather than passing through the Console Client, I could pass it the argument "-suffix 02" and pray that the files aren't corrupt in any other way.

The only arg I can't decipher is "lifeline." Can't find any info on its meaning on FahWiki or several forums. I don't think this line displays when running at the default verbosity level, so I may or may not have the old value logged for the WU in question.

I'll see what the machine is doing on Monday, but in the meantime I've added my home machine to the mix. Two cores to toy with at once I knew NetBurst was garbage, but I'm highly amused to see first hand a Core2 chip doing about 2.25X as many operations per clock for a similar protein (FahCore_81).

 

[GLeeM]

I like the way you think!

Looks to me like -suffix ## is indeed the WUs position in the queue.

The client has to be shut down to do this but you can see what is in the queue by using the flag -queueinfo. You can either add the flag to a shortcut or open a command window (cmd.exe) and CD to the folding directory and run the exe with the flag: fah.exe -queueinfo

Now that I have more time I can explain what I was thinking before to maybe salvage the other WU if it is there.
Copy and rename the entire directory
If running on same computer - change the MachineID with -configonly
Use -queueinfo to get info
Check which unit first computer is crunching, (suffix number)
Use -delete ## to delete that WU from this copied directory
Add -oneunit flag to stop client from getting new WU when this one is done (unless you have further need of it)
Try to run - if WU is still there it might finish (I doubt it is there)
Warning: If WU is not there, the client will download one. If you are quick you can stop the client before it finishes downloading if you don't want another WU for that client.

I would not worry too much about that WU - I have lost many

 

[Foxery]

Happy Monday!
No dice on the b0rked client magically going back to the other WU over the weekend. Maybe I'll play with it at 5:00, but you're probably right about it not being worth the fuss. It'll be reassigned eventually.

Point values and performance of different cores are intriguing to watch. Their reference machine is a P4 with SSE2 *disabled*... It makes my Core2 machine's workload bounce all over the place. But I suppose they want to avoid obsoleting older Athlons and PIIIs that don't have it. S'fine. I'd much rather do it "for the science," as Pande says, than for statistics. Stats just make it fun.

----------

If anyone is feeling technical, here is a list of files with suffix _01 in the \Work directory now:

wudata_01.arc 0kb
wudata_01.bed 3kb
wudata_01.dyn 0kb
wudata_01.goe 0kb
wudata_01.pdo 55kb
wudata_01.sas 0kb
logfile_01.txt 1kb
wudata_01.log 33kb
wudata_01.xtc 327kb

This seems more or less consistent with a newly downloaded WU. I'm slightly worried that the log files contain gibberish rather than their usual plain text. /shrug We'll see what I feel like at 5pm

 

[Insidious]

I'd assume those data files are constructed in a way to prevent people from tampering. Otherwise, it would be a clear avenue to cheating or even project sabotage if a kiddie hacker was so predisposed.

Honestly, I think you'd be much better off just to delete the directory and start clean. You know how those windmill jousts can go.

Cheers

-Sid

 

[Foxery]

Some answers, if anyone cares

Calling FahCore_81.exe directly from the command line does nothing. It doesn't run or return a message or anything.

I found a neat little program called "qd" which reads queue.dat and shows you exactly what WUs the client currently knows. It shows my missing unit as "Status: Deleted," so I guess that's that. The client has continued happily crunching away on new units.

Homepage:
http://linuxminded.xs4all.nl/?...=software-qd-tools.plc
(It's hard to read - scroll down a ways for pre-compiled Windows binaries)

FAH Wiki description:
http://fahwiki.net/index.php/H...o_debug_the_FAH_client
(Long!)

 

[Insidious]

Thanks Foxery

I was curious

-Sid

:beer: