A3 BUG: 10x slowdown (lack of "dynamic load balancing"?)

[extibo]

Well, I have the same problem with A3 core. I'm using Linux FAH console client on this PC: i7 920 + 6GB DDR3 ram. Does anyone know how to fix this, or when it'll be fixed?

I was only able to truly fix it by running the -configonly option and turning off affinity lock. That did the trick on mine, and it's been fine ever since. No idea if it will fix yours, but it could be worth a try. You can also experiment with lower smp values, like -smp 7 or -smp 6.

Thanks for the tip, but it didn't work. I installed HFM.NET to check my PPD while "folding", and I've noticed something odd: Status 0%, PPD 0, ETA 00:00:00 etc. It seems that my client is actually stuck at 0%.

[noorman]

.

I 've installed Ubuntu 10.04 (amd64 Desktop / completely updated = later kernel subversion) on my new i7 860 rig with 4GB of DDR3 RAM (2x 2GB, dual channel) and installed the SMP (Linux Unified) Client.
It wouldn't run and gave an error which I traced back here and was able to fix with the nscd install and configuration (as directed)
After that, I could start and run SMP.
After a whike, I looked for a Monitor and found the Ubuntu 'System Monitor'.
It has a Tab which displays the Cores (or threads) and there usage: I was shocked to see that 6 threads ran at 100%, but the other 2 threads ran variably between 0 and 20% and those figures moved from thread to thread, in time.
So, the Processor isn't working all that efficiently in this case.

I tried to remedy this behavior by reverting the 'Affinity' setting in the Client Config to the Default setting, which I had switched/altered initially ...
There was NO visible improvement in my case; the graphs and figures showed the same inefficiency problem of the load balancing, the start of which is announced during the run of F@H (not long after starting it)

EDIT: the system got a P6012 which ran at a reported ~10 mins per frame / in Win-SMP, that sort of WU did ~4 mins per frame !



.

[noorman]

.

A Team member (who's been Folding with this SMP Client for a long time) suggested to try it out with -smp 7.

So, I gave that a whirl, but the consequence was that the previous data were deemed unusable and that the Client restarted at 0%

That way, you 're not getting the points

Anyway, I tried it with -smp 7 and I was amazed to see Frame times of less than 4 mins (P6012).
Meanwhile, I had lost my network (LAN) connection through a busted onboard NIC ...
Anyway, it works, but I still have a very similar remark to before ...
The Core that 's left out, is of course doing much much less than 100% of any work, but that DOES NOT stay fixed at the Core where it starts.
Might be a clue for the problem with -smp (with 8 threads) ... the Core with much less than 100% usage still moves around and isn't stuck at one specific Core (#)

If this problem could be fixed, I would expect even lower Frame times

Is PG looking in to this problem ?

Due to my broken network link on that PC, I 'll not be able to return that WU in time.

What does that mean for the BONUS points scheme ?
Do I have to start all over again to accumulate 10+ Wu's to be eligible for Bonus points ?
Would be a shame !

And another question; if I use the same username and passkey, are the SMP WU's from my Ubuntu rig eligible for the bonus scheme as well, after I got to the scheme Folding Win-SMP ?

.

[PantherX]

What does that mean for the BONUS points scheme ?
Do I have to start all over again to accumulate 10+ Wu's to be eligible for Bonus points ?
Would be a shame !

And another question; if I use the same username and passkey, are the SMP WU's from my Ubuntu rig eligible for the bonus scheme as well, after I got to the scheme Folding Win-SMP ?.

As long as you use the same Username/passkey combination that has already been qualified for the bonus, you will get it. If this is the first time you have not submitted a WU, then its ok. Generally, out of every 10 WUs given to you, you have to return at lest 8 WUs to be in the Bonus Scheme.

[7im]

You need to report what version of the fahcore you are running. v2.22 fahcore works better 4+ CPU cores. If not running that version, please force the upgrade. And so yes, PG HAS been looking in to this behaviour already.

Your broken NIC means you can't send back the WU, so you will miss the final deadline. And just like every other type of work unit, if you miss the final deadline, you will get 0 points. This has nothing to do with the Bonus system.

No, once you qualify 10 WUs for the bonus, the only way to become UNqualified is to fall below the 80% return rate. Someone with hundreds of SMP WUs like yourself would have to fail on a lot of work units to become unqualified.

Once a user name and passkey are qualified, you can use it on any PC and start getting bonus points immediately.

But all this bonus detail has already been covered in the Bonus program announcement, and resulting discussions. And is probably getting a little off topic for this thead.

[noorman]

.

I know, but the main body of my post was about the SMP Folding problem.

As I said before, I downloaded the latest FahCore_a3, because I just installed the Client (only days ago), so it is and must be 2.22

I let it run with -smp 7 and that gave the expected (or even better) ~4 mins Frame times.
If Thread #8 would be able to join in, that would up the output still and take speed up too.

I just wanted to report that even with the much better workings with that switch 'in action', the remaining 'thread' wasn't in astable setup because it 'wondered' around the set of 8 threads, just as the 2 threads did when the default -smp was used (before).
I thought that this might indicate (more) what or where the problem was or was located (maybe) ...


Meanwhile, I fixed the LAN problem with an extra Wireless setup; the onboard LAN is clearly defective.

.

[PantherX]

Today, I decided to experiment with the -smp X values. I have the 2.22 Core Version. My 860 @ 3.6 with -smp 7 (Non-dedicated) would give me 9:22 TPF so I decided to stop the Client and use -smp to see if it has any positive effect on the TPF. Once I downloaded a 6701 WU, it was using -smp and even when I left my system at idle. it gave me a TPF of 9:44 after 4%. (Using GPU2 Client) I stopped the Client and used -smp 7 and it gave me a TPF of 9:21. I am guessing that they haven't fixed the known bug of WU slowdown but at least the TPF is slightly better than the 2.19 Core Version.

[noorman]

.

As reported, my P6012 did ~10 mins per Frame with the default -smp, but did the expected =4 mins per Frame (as it did in WinXP-SMP) with the -smp 7 setting !

That 's more than a few percentage points

.

[noorman]

.

Seems the Core has been fixed; since a while now, after I got the relocation error fixed, I can run SMP just with the -smp switch and have 'normal' MPF times and correct load balancing throughout ...

Reports in the Logs also confirm the latter because of the very low percentages reported on load balancing time losses

Running very well so far; P60xx WU's at around 3 mins 10 secs now ...

.