I'm happy being able to notice that I am not alone with my observations and questions related to MIP1 (poor) performances.
As I already mentioned, the problem does not seem to be related to hyperthreading (even if HT could amplify the effects). Even on a 4 or 6 core CPU (without HT) - e.g. Athlon II x4 or Phenom II x6 - MIP1 is impacting significantly the overall performance.
On my side, I initially focused on possible Memory Management problem (RAM) , since I did not observe problem with Disk I/O and that the swap space remains empty (enough available RAM).
Even if a concurrent demanding use of a shared FPU could be relevant in some cases, this explanation does not cover all relevant observations. The root cause is somewhere else.
Cheers,
Yves

Check flow through of the air the casing & check MBO data for Tjunc of Northbridge / Southbridge.

I also have noticed a significant drop in points earned in the last 3-4 days. While I have been a volunteer cruncher for years I am now a member of the gridcoin team, trying to mine enough gridcoins to pay for my electricity. The way they figure your earnings has to do with how many points you put one the board in relationship to others crunching the same project. They consider WCG a single project and do not see the various research projects independently.

So, if something is going wrong in MBI, It is literally costing me money. If this doesn't pick up in the next few days, I must switch projects. I am not alone in this and as more crunchers sign up with gridcoin, the science projects that don't deliver WU and get the validated quickly will see fewer participants.

Right now, you have to join the gridcoin to mine gridcoin as you work. The administrators are working on a program that would allow people to stay with their own and also mine at the same time. When that happens, I would expect a high percentage of WCG participants to sign on.

I did notice that i had 187 pages of "in process" tasks. Could this indicate a backlog problem?



B2I

got 7 'puters. mix of windows 7, 10 and linux. one is set to max cache because it is in a remote site that on gets an internet connection once a week when I can get to it to connect via smart phone, the rest are set to 3-4 days because of spotty internet coverage. all but one are i7s, one i5. missed some deadlines last week because I couldn't get to the remote 'puter but that is cleared now.

Whew!. Think I answered all your questions but it is Saturday night and I just finished my 4th drink :).

Sgt Joe. I've been seeing your logo for years now. Are you or were you a Sgt

I'm a retired USAF E8.

B2I
From the wilds of Colorado

After monitoring both chips on a machine running 32 threads with the large memory WUs, both chips report L1_Cache_Miss=0, L2_Cache_Miss=0, and L3_Cache_Miss=0. Since there aren't any L3 Cache misses, it's unlikely there are any cross-chip "snoops" happening. The QPI links are very busy; in the range of 15.3GB/s across 2 links. 5 to 1 read to write ratio. Unfortunately, I don't have the QPI counters turned on in the BIOS so can't see QPI details but it looks like the QPI links are being saturated and I assume this would happen on the AMD HyperTransport Links also. Since control flow for the links happens on-chip, the OS doesn't see any wait state so reports the thread as dispatchable. Also explains why chips with fewer threads see less of a problem than chips with high thread counts. Without QPI counters, its only a guess. Could try and configure the machine for non-NUMA and see if that helps but I suspect it would only be a minor benefit.

Sorry, posted in wrong thread..Can't delete since there is a reply.