First of all thanks to all three of you for the info and suggestions. I appreciate that.
What caused me to write this orginally was seeing the Points Per Hour/per core go from the 24 range to app 10 and that didn't make sense to me. Could have been the particular batch of WU and it's looking like that may be true. Keep in mind that I set for a 3 days cache and having 48 threads running, that 3 day cache is huge! I wrote "resolved" because after seeing 3 days of lets call it "low" point awards it went back to the "normal" range so I had to assume it was a fluke and not an issue that WCG could "fix"..
Now to all, Linux is coming to this machine inside the next week and then we can do a apples to apples comparision.
Thanks again guys. I know my hardware but on the software end I'm not quite a beginner but far from as informed as you folks are..

Trotador. No, FAHV [AD VINA type], is 2 parts, a worker and a controller/stager only one of 2 using CPU time. If you have 32 threads, you would have 32 jobs running. Presuming your repo client is 7.2.7 [think that's what listed for 13.10], it controls jobs based on a % of processors. If that's 100%, then 32 threads are expected to run and the 'number of CPU's' setting of the web profile is ignored. Check that, as the setting is default I think 16. If it is and upping to 32, then doing an update in the client does not start 32 threads, you have a reportable bug for the developers.

You did notice that the starter of this thread had 48 concurrent running... it wont have been CEP2 [that is a 3 or 4 part app... depends on OS]

edit: There's also the more far-fetched possibility that BOINC is set the % of CPU time, not being 100%. Check that too [default on clean profile, unless using Maximum Output is 60% IIRC].

We're going way OT, how I run Linux [Ubu], is log out in the GUI, do Ctrl-Alt-F2 [or F1 if you prefer], sign in [to a terminal session] and end the gui process, which kills a number of GUI related tasks [for the various Unity/Gnome such as the scope and zeitgeist]. The code is

sudo service lightdm stop

(replace lightdm with gdm or kdm, whatever GUI base you're on.)

This gives me pretty much 99+% efficiency on faah and FAHV and the new BETAs, same as on Windows-7-64. (with exception of CEP2, that is just not doing optimal on this Lnx, for me, albeit, now having switched to ext2 for disk-format, getting no improvement over ext3 or ext4). Regrettably been unable to boot to btrfs to test that nwst and maturing disk-format... suspect the BIOS is too old to handle that one... not upgradable, CPU 7+ years old.

Hi Movieman,
I have the feeling that FA@H is really particular in terms of credit.
The Autodock part is consistently granting low credit since many years.
The Vina part seems to be better and a little bit more generous. However, the large majority of my hosts compute only FA@H WUs currently, I see strong variations without any explanation.
The daily average contribution can vary between 14'000 and 18'000 boinc points.
The variation is not caused by late validation but it is directly related to the WU, already by claimed and later by granted credits.
Sometime the rate of errored or invalid WUs is higher than usual but it does not justify such variations.
A couple of years ago, my pool of hosts was able to maintain the same level of contribution without any noticeable variation during about 18 months although it was much more different projects available at this time.
I do not have any idea for the variability of FA@H but there is one.

I am a little bit jealous regarding your new host.
I would appreciate if Santa Claus could bring me the same device for Christmas
I would like to experience a dual or quad Opteron (e.g. 6272) based system, with Linux (but Vina should be more tolerant with AMD results).

Cheers,
Yves

Just checked and had 14 completed WU all in the 57-59 minute range..Looking good so far.. Dave the Linux n00b