• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Most effecient SMP folder. Linux or Windows?

S

SpeedyVV

Supreme [H]ardness
Joined
Sep 14, 2007
Messages
4,210
If I am to dedicate a folder does Linux or Windows make a difference? 32 vs 64 bit?

Red Hat vs Ubunto? XP vs Vista vs Windows 7?

I am sure this info is there somewhere, but if I was to built an i7 box today, which OS should I use. Off course, Ubunto is free, but besides the point (pun intended).

EDIT: which one will have lowest TPF?
 
It's a wash either way unless you plan on diving into the Linux kernel and really tweaking it. Native Linux also can't run bigadv at the moment so I'd stick to native Windows if I were you.
 
Windows can run SMP on 32 or 64 bit.

Linux must be 64 bit for SMP.

Latest version of Ubuntu is broken for FaH. You must use a lower release of Ubuntu (9.10 I think?) or use CentOS.
 
The Fedora series are all working fine on the latest ones just do
service nscd start
as root

also
chkconfig nscd on

other than that they are working very well. But bigadv is where the points are so Windows it if you can.
 
Server 2008R2

The most efficient PPDpW is going to be Windows because windows can run -BIGADV and linux cannot.
 
Win7 process/thread scheduler is more advanced and thus is better than XP for Folding efficiency.
 
It's been a while since I've used Linux, but when the A3 core came out I saw noticeably better performance under Windows. I don't know if anything has changed since then, but if I were you I'd stick with Windows.
 
If I may steal my own thread, I got thinking: Is there a way to keep\copy one or more WUs to do benchmarks?

I guess there has to be a way to keep it from resending the results over and over.
 
You could always disconnect it from the internet to prevent it attempting to send results
 
SpeedyVV said:
If I may steal my own thread, I got thinking: Is there a way to keep\copy one or more WUs to do benchmarks?

I guess there has to be a way to keep it from resending the results over and over.
Click to expand...
After the client downloads a unit, just make a backup of the entire client folder. Stick it in an archive and you can use it at any time. Just don't allow it to upload once it's been completed the first time.
 
There is a setting in the advanced section of -configonly that allows you to prompt before connecting to the internet. Also, when benchmarking, you'll want to configure the client to ignore deadlines.
 
It cant be that simple I dont think.

I mean, which files make up a WU? Can that WU be utilized independent of the core (I am not really sure what i am saying here ;) ). Will it work under different OSes? Same OSes, but different CPUs? What about GPU WU? can they be used on different GPUs bu usind different cores?

Like, right now I am folding a SMP GRO-A3 P6069 (R0, C149, G60). Can I save it and run in on diff OS\CPUs?

Or OPENMMGPU 15 P10632 (R32, C102, G31) project on diff OS\GPUs?
 
Tobit said:
There is a setting in the advanced section of -configonly that allows you to prompt before connecting to the internet. Also, when benchmarking, you'll want to configure the client to ignore deadlines.
Click to expand...

Nice to know. I never noticed it.

Going to read up on all the switches ;)
 
Last edited:
It is that simple, and MIBW has made a science of it. He has a 2686 that he has used for benching for quite a while. I have been using it lately as well. The only problem is that it is a bigadv, and thus takes a while to run. You need to ignore deadlines and ask before sending in the config. You need to delete everything out of the work folder except the two .dat files to restart the benchmark. Assuming it is the first WU, they should look like this:

wudata_01.dat
wuinfo_01.dat

It works amazingly well, and is quite easy to do.

Another note, which you do know Speedy. You can run bigadv in Linux using Wine. According to Tobit's research, they are a little slower on dual proc machines because of the NUMA thing. On a single proc machine, my numbers were almost identical using Ubuntu 10.04 + Wine compared to native Windows 7. There is a Wine bug the writes an error message every so often, but it doesn't seem to hurt anything.
 
To add to what musky said, once you download a WU, you can't move it to a different architecture. You have to keep it on the same host OS. I've tried taking a WU downloaded to a Windows host and running it on the Linux client, it's not pretty as the native Linux client tried downloading the Windows executable of the core upon restart. Moving a WU amongst systems is fine as long as you keep it on the same OS-type.
 
Alright, going to copy the stuff from my Q6600 smp, to my laptop... let's see what it does.
 
Tobit said:
To add to what musky said, once you download a WU, you can't move it to a different architecture. You have to keep it on the same host OS. I've tried taking a WU downloaded to a Windows host and running it on the Linux client, it's not pretty as the native Linux client tried downloading the Windows executable of the core upon restart. Moving a WU amongst systems is fine as long as you keep it on the same OS-type.
Click to expand...

That is a shame, as that was definately one of the usecases I wanted to try.

Get new machine, install Linux, run f@h benchmark, install Windows, run same WU.

Well, I still would like to be able to save 2 or 3 WUs, and test it under diff Windows machines, so all is not lost.

Another usecase, is to put the whole thing (OS\WU) on a usb key, and test a system before buying it.
 
musky said:
It is that simple, and MIBW has made a science of it. He has a 2686 that he has used for benching for quite a while. I have been using it lately as well. The only problem is that it is a bigadv, and thus takes a while to run. You need to ignore deadlines and ask before sending in the config. You need to delete everything out of the work folder except the two .dat files to restart the benchmark. Assuming it is the first WU, they should look like this:

wudata_01.dat
wuinfo_01.dat

....
Click to expand...

So it is ok to delete all this crap except those two files?

Capture-8.jpg
 
Does not work.... It got a new project :(

Question, what about the stuff above the work folder? Do I copy anything from there?
 
I think musky screwed up in his post. I believe you need to retain the queue.dat file as well.
 
Tobit said:
I think musky screwed up in his post. I believe you need to retain the queue.dat file as well.
Click to expand...
Indeed. Deleting the queue.dat file will cause the client to generate a new queue, regardless of the contents of the work folder.
 
Sorry, do you mean I need to copy the queue.dat file, or keep the one that is already there?
 
You need to keep the queue.dat file that was present when the unit you want to save was downloaded.
 
Your benchmark WU should have queue.dat in the top SMP2 directory and wudata_01.dat and wuinfo_01.dat in the work directory. You need to copy over all three of these files.
 
eww 4:07 on a 6069....clock that bad boy up! (3:24 here ;) )
 
Tobit said:
Your benchmark WU should have queue.dat in the top SMP2 directory and wudata_01.dat and wuinfo_01.dat in the work directory. You need to copy over all three of these files.
Click to expand...

Ideally, you should copy the fah folder to a new one called FAH-Benchmark then clean the contents, keep only the good files and reconfigure it to ignore deadlines and ask before sending. Like that, you have a working benchmark setup you can port on any Windows computer.
 
I successfully started a 2684 and a 2685 last night without doing anything to the queue.dat file that was already there from the 2686. It may be that you just need a queue.dat file present, and that it really doesn't matter what is in it. I'll try to confirm this tonight. It would make sense that the client would try to start over if a queue.dat file didn't exist, but I can definately confirm that the queue.dat file speciifc to a particular work unit is not needed.
 
You must log in or register to reply here.
Back
Top