• 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.

Linux+Wine+A3smp =Bigadv

But if you have a sever (that is stuck on linux) with 16 threads, and it does other tasks beside F@H, you have run -smp 12 or something and run -bigadv and have your sever too.

If that works, it's a great workaround.
 
I'll try it with a -smp 8 machine tonight. If that works and I get really motivated, I'll see how high I can go on my smp 16 or smp 24 machine. I don't know that I will get that motivated, though.... :)
 
Haven't pulled a bigadv yet, but I do have an I7 920 running Ubuntu 10.04 Desktop and the WinSMP client under Wine. It was turning over 20K ppd on one of the standard A3 units yesterday at around 4 GHz, which sounds about as good as I ever got running Windows on a quad I7.
 
Haven't pulled a bigadv yet, but I do have an I7 920 running Ubuntu 10.04 Desktop and the WinSMP client under Wine. It was turning over 20K ppd on one of the standard A3 units yesterday at around 4 GHz, which sounds about as good as I ever got running Windows on a quad I7.

That sounds pretty impressive, indeed! :cool: I'm wondering if I shouldn't give this a shot with a couple of my Linux Mint Boxen (i7-860 @ 3.6 and an i7-920 @ 4.0). they already run A3 units nicely, but if there is the possibility that they'll pull the occasional -bigadv and process it well then it might be wirth a shot.
 
That sounds pretty impressive, indeed! :cool: I'm wondering if I shouldn't give this a shot with a couple of my Linux Mint Boxen (i7-860 @ 3.6 and an i7-920 @ 4.0). they already run A3 units nicely, but if there is the possibility that they'll pull the occasional -bigadv and process it well then it might be wirth a shot.

Try it on just the faster one first. I'm still waiting on pulling a bigadv before I put my stamp of approval on it, but it looks like it will work for quad I7s. What is probably the limiting factor is that the client only recognizes 1.8 Gb of memory on my 6 Gb machine. This probably has to do with the 32-bit nature of Wine, and it may be fixable. That is probably why it failed on an -smp 16 machine.
 
Try it on just the faster one first. I'm still waiting on pulling a bigadv before I put my stamp of approval on it, but it looks like it will work for quad I7s. What is probably the limiting factor is that the client only recognizes 1.8 Gb of memory on my 6 Gb machine. This probably has to do with the 32-bit nature of Wine, and it may be fixable. That is probably why it failed on an -smp 16 machine.

Will a -bigadv unit even pull up if it only detects less than 2 GB?
 
An update on this - I would not recommend doing it. I never did pull a bigadv after a dozen regular A3 units. The client does funny things over time, and will eventually crash due to some Wine errors. I am switching back to Windows until Stanford releases a true Linux bigadv client.
 
It's very unfortunate for Linux users this is taking so long. I'm wondering if some of my systems that were able to run -bigadv in the past can do so again when this becomes reality. Case in point, I was able to process P2684 WUs within the preferred deadline when they were introduced in Linux A2, but not when they migrated to Windows A3. Everyone else reported faster TPFs - not in my case. Of course the 2684s crashed half the time in Linux but that is another story...
 
It's very unfortunate for Linux users this is taking so long.
I'm beginning to have some concerns about the future of Linux in general @ Pande Group. I'm only speculating and unable to go into much detail but, as a Linux user, I am very concerned with my speculations.
 
I'm beginning to have some concerns about the future of Linux in general @ Pande Group. I'm only speculating and unable to go into much detail but, as a Linux user, I am very concerned with my speculations.

I would think the heaviest of the heavy hitters (those who have high-end production server equipment to break in or use) are getting hurt badly by this lack of support for *nix OS's. I certainly understand the need to cater to Windows users, but I also think they are shooting themselves in the foot by excluding a bunch of the equipment they had in mind with things like the bigadv program.
 
I would think the heaviest of the heavy hitters (those who have high-end production server equipment to break in or use) are getting hurt badly by this lack of support for *nix OS's. I certainly understand the need to cater to Windows users, but I also think they are shooting themselves in the foot by excluding a bunch of the equipment they had in mind with things like the bigadv program.
Agreed and this is just one of my concerns. :eek:
 
F@h is becoming more lopsided as time goes by. Currently, we are seeing emphasis on Windows, Intel processors and nVidia GPUs. The competition is way out of the running.
 
I would think the heaviest of the heavy hitters (those who have high-end production server equipment to break in or use) are getting hurt badly by this lack of support for *nix OS's. I certainly understand the need to cater to Windows users, but I also think they are shooting themselves in the foot by excluding a bunch of the equipment they had in mind with things like the bigadv program.

Tell me about it. The WinSMP proxy handling is messed up, so I have to use ccproxy (which isn't very straight forward) to get it to talk to our proxy correctly. I have 1x8 cores, 6x16 cores, 1x48 cores, that were all on RHEL. I just moved the 48 core over to Windows 2K8 R2 and it is faster, but the proxy is a pain.

Does anyone know of a better proxy re-director than ccproxy?

Keith
 
Tell me about it. The WinSMP proxy handling is messed up, so I have to use ccproxy (which isn't very straight forward) to get it to talk to our proxy correctly. I have 1x8 cores, 6x16 cores, 1x48 cores, that were all on RHEL. I just moved the 48 core over to Windows 2K8 R2 and it is faster, but the proxy is a pain.
Geez, are you the fortunate one, what architectures are these servers?
 
Geez, are you the fortunate one, what architectures are these servers?

4 of them are 4 core x 4P AMD ~3GHz. 2 are 8 core x 2P Intel. 1 is a 12 core x 4P Intel 1.8GHz. 1 is a 4 core x 2P Intel (old school, barely worth a few thousand/day). I also have a GTX 285 and 8800 GTS 512 at home.

For a short time, I had a 12 core x 4P AMD 3GHz box that smoked the frames, less than a minute each on Linux while I was stress testing the file system. Would love to see that handle a bidadv under Windows! I am trying to get that one back soon.

Keith
 
My bad, all of the Intel (except for the old school) are dual thread, so halve all of the core counts. So the 48 is actually 4P x 6C x 2T. D'oh!

Keith
 
Back
Top