Binding the process to each physical socket performs roughly the same as taskset

Quote from: Delinquency on January 27, 2014, 07:13:32 PM
Dual L5639 CONFIG:
:P

mmc.sh

Code Select Expand


#!/bin/bash
echo always > /sys/kernel/mm/transparent_hugepage/enabled;
killall -9 yam;
killall -9 screen;
screen -mD taskset -c 0-11 ~/yam --config yam-mmc.cfg &
screen -mD taskset -c 12-23 ~/yam --config yam-mmc2.cfg &


yam-mmc.fg

Code Select Expand


threads = 12
mining-params = mmc:av=1&aesni=on&donation-interval=100&m=12288
mine = getwork://[email protected]:8880:8881:8882:8883/mmc
compact-stats = 0
print-timestamps = 0


yam-mmc2.cfg

Code Select Expand


threads = 12
mining-params = mmc:av=1&aesni=on&donation-interval=100&m=12288
mine = getwork://[email protected]:8880:8881:8882:8883/mmc
compact-stats = 0
print-timestamps = 0


Start--

Code Select Expand


chmod +x mmc.sh;./mmc.sh;


This assumes that you only have 24GB and occupying less than 1GB RAM.
uses Screen and taskset.

12.5+ H/m

--Nehalem core

If your OS supports NUMA and numactl, it is better to bind tasks to phys sockets using

numactl -N 0 -m 0 -- ./yam -c yam-mmc-0.cfg
numactl -N 1 -m 1 -- ./yam -c yam-mmc-1.cfg

Using taskset leaves open possibility of cross-socket memory allocation, which causes major underperformance.

Quote from: bppsp1 on January 27, 2014, 01:49:29 PM
I notice that the new version doesnt have a constant 99.9-100% peg on each thread, it fluctuates alot between 92-98 on each threads and rarely pegs at 99.9-100%

Is this by design, surely such fluctuations would kill extra hashrate ?

That would be the case if you use m=1024 and many threads. In this case mining will suffer from inter-thread sync contention.

Max perf can be obtained when m=1024*numberOfThreads, which is exactly the config from prev version.

Dual L5639 CONFIG:
:P

mmc.sh

#!/bin/bash
echo always > /sys/kernel/mm/transparent_hugepage/enabled;
killall -9 yam;
killall -9 screen;
screen -mD taskset -c 0-11 ~/yam --config yam-mmc.cfg &
screen -mD taskset -c 12-23 ~/yam --config yam-mmc2.cfg &


yam-mmc.fg

threads = 12
mining-params = mmc:av=1&aesni=on&donation-interval=100&m=12288
mine = getwork://[email protected]:8880:8881:8882:8883/mmc
compact-stats = 0
print-timestamps = 0


yam-mmc2.cfg

threads = 12
mining-params = mmc:av=1&aesni=on&donation-interval=100&m=11264
mine = getwork://[email protected]:8880:8881:8882:8883/mmc
compact-stats = 0
print-timestamps = 0


Start--

chmod +x mmc.sh;./mmc.sh;


This assumes that you only have 24GB and occupying less than 1GB RAM.
uses Screen and taskset.

12.5+ H/m

--Nehalem core ++Fixed RAM on the second config.

Seems to perform worse than previous miner on dual L5639 :(
threads = 24
mining-params = mmc:av=0&aesni=on&m=22528&donation-interval=100

Been playing around with new k version and noticed few things.

1.) k version ART dropped from previous version 59000 down to 1500 , thats a huge drop not sure what benefits it would give.
2.) k version SPM/HPM is lower on sandy-bridge than on j version using AV=1 (havnt tried all, but AV=1 always turned out fastest in previous version)
3.) k version using different m: values doesnt seem to make any difference at all.
4.) k version fluctuate between 90-100% usage on each thread all the time where the j version pegged to 99.9-100% all the time.

I notice that the new version doesnt have a constant 99.9-100% peg on each thread, it fluctuates alot between 92-98 on each threads and rarely pegs at 99.9-100%

Is this by design, surely such fluctuations would kill extra hashrate ?

That's what i thought but the miner just closes. Early in the morning so i must be doing something wrong here.

Quote from: andhar on January 27, 2014, 10:43:12 AM
What version should i use for a i5-3570?

Don't got the K version.

ivy bridge.

you can learn your cpu's architecture by googling "[CPU MODEL] micro architecture".

What version should i use for a i5-3570?

Don't got the K version.

thanks.

getting ~10 HPM with my 24 core XEON L5639.

Quote from: yvg1900 on January 27, 2014, 08:14:08 AM
Updated M7k version of yam miner is available. It contains reduced memory mode for MMC, improved performance and connection stability.
M7k version of yam allows efficient CPU mining of MemoryCoin with all threads even with 1Gb RAM used for mining.
yam M7k runs significantly faster on AVX2 CPUs (Haswell) and has improved CPU load profile for overclocked configurations.
yam M7k fixes disconnect issues with some MMC mining pools that use get work protocol.

As usual, download at
https://www.dropbox.com/sh/jvp4wwek8jpohj7/RlW6hzYqTz
https://mega.co.nz/#F!h0tkXSxZ!f62uoUXogkxQmP2xO8Ib-g
http://sdrv.ms/18wfjYX
http://pan.baidu.com/s/1xOOWa

yvg1900

Great work !!!

What version do you suggest to using with a westmere-ep cpu ? I'm currently using the nehalem one

Thank you! This is great.
I see that that minimum memory per thread for MMC is still 1024 so I didn't understand what you mean by "It contains reduced memory mode for MMC".
I see that it's the total memory used now.

Thanks!

Updated M7k version of yam miner is available. It contains reduced memory mode for MMC, improved performance and connection stability.
M7k version of yam allows efficient CPU mining of MemoryCoin with all threads even with 1Gb RAM used for mining.
yam M7k runs significantly faster on AVX2 CPUs (Haswell) and has improved CPU load profile for overclocked configurations.
yam M7k fixes disconnect issues with some MMC mining pools that use get work protocol.

As usual, download at
https://www.dropbox.com/sh/jvp4wwek8jpohj7/RlW6hzYqTz
https://mega.co.nz/#F!h0tkXSxZ!f62uoUXogkxQmP2xO8Ib-g
http://sdrv.ms/18wfjYX
http://pan.baidu.com/s/1xOOWa

yvg1900