For sure an Intel Broadwell with 128 MB eDRAM, used as L4 cache:
http://www.cpu-world.com/CPUs/Core_i7/Intel-Core%20i7-5775C.html

Detection now works perfekt, FX-8350 is detected as Vishera and uses generic_aes automatically.

But the miner still uses just 2 threads with SumoCoin (Cryptonight-Heavy), ending up at only 115 H/s. Forcing the miner to use 4 threads to fill L2 and L3 cache completely results in 219 H/s 

IPBC still not working. The forked coin is not CN-classic! The hashrate of the official ipbc-miner indicates, that it is Cryptonight-lite, but it is neither CN-lite-AEON, nor CN-lite-V7. It must be something else 

And AMD FX-8350 is detected as Kuma instead of Vishera. Besides, the code the miner uses with auto is generic_sse3. When I set the CPU to vishera manually, it uses generic_aes.
With SumoCoin (Cryptonight-Heavy) the miner chooses 2 threads for AMD FX-8350, reaching ~115 H/s. But since FX has exclusive cache architecture with 4x 2 MB L2 + 1x 8 MB L3, it is better so use 4 threads to fill both cache levels. Then the FX-8350 reaches 216 H/s with CN-heavy.

And I think you have to look at the IPBC code, as well. Shares get rejected immediately.

I hope you are not upset about my bug reports – I just want to help

- AMD A4-5000 is detected as "Llano", but it is a "Kabini"; despite the miner chooses generic_avx, although Llano wouldn't support AVX
- Intel Core i7-870 is detected as "Skylake", but it is a "Lynnfield"; despite the miner chooses a non-AES-code, although Skylake would support AES
- B2Bcoin is missing in the Cryptonight coinlist http://pool.b2bcoin.ml/#

You do a great job

@Mind163
your Broadwell CPU not only has L3 cache, but even L4 cache  Thats why XMR-Stak switched to double hash mode (there called "low_power_mode"). This feature JCE is missing so far, but the developer is just working on, if you have read the thread

Could you please try the following config for your X6; just for interest

"cpu_threads_conf" :
[
     { "cpu_architecture" : "thuban", "affine_to_cpu" : 0, "use_cache" : true },
     { "cpu_architecture" : "thuban", "affine_to_cpu" : 1, "use_cache" : true },
     { "cpu_architecture" : "thuban", "affine_to_cpu" : 2, "use_cache" : true },
     { "cpu_architecture" : "thuban", "affine_to_cpu" : 3, "use_cache" : true, "dual_mine_with": 2 },
     { "cpu_architecture" : "thuban", "affine_to_cpu" : 4, "use_cache" : true },
     { "cpu_architecture" : "thuban", "affine_to_cpu" : 5, "use_cache" : true, "dual_mine_with": 4 },
]
THEORETICALLY, this must be the fastest config for Phenom II X6

Phenom II X4 905e runs at 2500 MHz.

The L3 cache of the G4400 is not big enough for 2 Monero threads. Use just one either or switch to a cryptonight-lite coin like TurtleCoin. Then you can use both cores without flooding the cache.

Yes, indeed, he is right:

3T => 58 H/s
3T + helper => 64 H/s
4T => 70 H/s

And that despite Deneb has only 6 MB L3 cache.  But I forgot the special cache architecture of AMD systems. Intel systems have inclusive caches. So the size of the L3 cache is the maximum cacheable size, because the data in L2 and L1 are just subsets of a copy. AMD systems instead have exclusive caches, where no data is ever stored in L2 and L3 at the same time. That's why you can add L2 and L3 cache size. Deneb has 4x 512 KB L2. Together with the 6 MB L3 you get 8 MB cache altogether; or room for 4 threads. 

But it still can be helpful for non-AES Intel CPUs with limited L3 (Lynnfield) or for Phenom II X6 to use the last two cores, as well

Dual mining is perfect for AMD Phenom II X4. It has an L3 cache of 6 MB, so 3 cryptonight threads fit into it. But is has 4 cores, so with a normal miner, one core is without a job. Thanks to dual mining I can fill the L3 with 3 threads and add a "helper thread" to the 4th core. It looks like this:

"cpu_threads_conf" :
[
     { "cpu_architecture" : "deneb", "affine_to_cpu" : 0, "use_cache" : true },
     { "cpu_architecture" : "deneb", "affine_to_cpu" : 1, "use_cache" : true },
     { "cpu_architecture" : "deneb", "affine_to_cpu" : 2, "use_cache" : true },
     { "cpu_architecture" : "deneb", "affine_to_cpu" : 3, "use_cache" : true, "dual_mine_with": 2 },
]

Without dual mining the Phenom II X4 905e hashes up to 58 H/s. Thanks to dual mining on the last core, it's 64 H/s

Addendum: the bug is fixed mining Aeon, but when mining TurtleCoin with dual-mining-feature, I still get rejected shares. Not using dual-mining, everything is fine even with TurtleCoin. So there must be a small bug somewhere

Edit: this time it has nothing to do with the K10. Lynnfield produces the same rejected shares as soon as I use dual-mining with TurtleCoin

Yeeeees!  Great job! 

In the matter of OS Windows Vista / Server 2008 is min system requirement, isn't it? Any chance to get the code running on Windows XP / Server 2003? I have some of the very old boxes here with these operating systems.

Have you tried the 32-bit version, too? It's a bit strange. With the 64-bit version the results are rejected on AMD Athlon II X2 "Regor" as well as on AMD Phenom II X4 "Deneb". The 32-bit version instead works on "Regor" but doesn't even start on my "Deneb". Can you please try if your AMD Phenom II X6 "Thuban" works with the 32-bit version?

Good job Fixing the K8/K10 bug might be a door opener for your miner. To be realistic, xmrig and xmr-stak have such a strong position in the market and are highly optimized, so it would be difficult to displace them on normal systems. But the strong performance of your miner on non-AES systems could be a market niche, to get those hunderts and thousands of older systems into mining which atm are too weak for cryptonight 

Well, I'm afraid that Excavator has absolutely nothing common with K10. Excavator is the 4th Bulldozer variant with modules instead of cores (CMT), shared L2 caches, AES and AVX, whereas K10 is the last incarnation of good old K8 with classic cores, dedicated L2s, no AES and max SSS3. 

But if I can helf, I would setup a K10 testsystem for you, which you can use via Teamviewer, Anydesk or RDP (depending of your preferences) to fix the issues with this arch

Thank you for explaining the phenomenon. Perhaps you should document the attrib trick somewhere so people don't get suspicious.

Apropos phenom The 64-bit miner seems to have a bug in combination with AMD K10 arch. I tested your miner because of the fast non-AES-code. On an Intel Core i7 "Lynnfield" everything works fine (except the wrong auto detection as Skylake), but AMD Athlon II X2 "Regor" as well as AMD Phenom II X4 "Deneb" get rejected by the pool due to "low difficulty share". Tested Aeon, Monero, Turtle and Leviar. Something is wrong with the K10 implementation. 

The 32-bit miner seems to be ok, even with Regor and Deneb.

Hi,

just tried the miner on a test machine. May I ask, why the miner runs Windows' attrib command C:\Windows\System32 all the time?