[ANN] MMCPool.com - GPU,CPU(yam) - The Awesomest Pool!

[OpenCLGuy]

Hello, on my computer monitor is connected to graphic card.

When your gpu miner is working I can't see picture on my monitor. Picture doesn't refresh. I can't even close gpu miner when it need.

GPU miner from 1gh pool doesn't have this problem.

I think this may be the reason that main gpu miner is on 1gh pool.

Please, reboot and run the miner from the start. Tell me your GPU/OS and copy miner's start log if the problem persists.

[chida]

Code: [Select]

13:51:31.013 [GPU0] Platform: Intel(R) OpenCL
13:51:31.013 [GPU0] Device: Intel(R) HD Graphics 4000
13:51:31.013 [GPU0] Total device memory: 1624 MB
13:51:31.013 [GPU0] Maximum buffer size: 406 MB
13:51:31.013 [GPU0] Cannot use the device! Maximum buffer size is less than 1024
MB
13:51:31.013 [GPU1] Platform: NVIDIA CUDA
13:51:31.013 [GPU1] Device: GeForce 610M
13:51:31.013 [GPU1] Total device memory: 2048 MB
13:51:31.013 [GPU1] Maximum buffer size: 512 MB
13:51:31.013 [GPU1] Cannot use the device! Maximum buffer size is less than 1024
MB
13:51:31.013 [GPU2] Device not found
13:51:31.013 Started 0 miner threads

nooo   

is possible set the program for use in Maximum buffer size 512?

[frostybutdelicious]

M7j version of yam miner available. It supports fast CPU mining for PTS, MMC, more mining pools and protocols.

To mine MemoryCoin with yam M7j use provided miner config template named yam-mmc.cfg as a base, check readme.txt for more details.
yam M7j optimised for mining MMC on CPUs with AES-NI support and has 5 different algo variations for HT, non-HT and GPU friendly setups.

yam M7j miner now supports PTS mining at beeeeer and includes fix for Win2003 and other older 64bit systems. Check readme.txt for details.

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

I've got 2 computers running windows 7. One is an 8 core AMD FX cpu and the other is a 4 core AMD FX cpu. Which version of the miner am I supposed to used? Also, is it possible to solo mine protoshares or memorycoin using this miner, or is it only possible to use a pool?

[Firefly]

xeon e5-2670 @2.6ghz with 32 thread 10.011 hpm and now 29.299 hpm

How much memory does it consume?

P.S. At the end, it is MemoryCoin It is supposed to consume A LOT of memory for PoW

It's a FEATURE!!!
yvg1900, marvelous, it's exactly that I've been requesting about a month ago.

Also, one question. From readme-file:
"For MemoryCoin, allowed parameters are:  "av" (algorithm variation, 1 variations in total"
so, we have no fine-tuning at all for MMC, only for PTS, am I right?

[kogv]

Hello, on my computer monitor is connected to graphic card.

When your gpu miner is working I can't see picture on my monitor. Picture doesn't refresh. I can't even close gpu miner when it need.

GPU miner from 1gh pool doesn't have this problem.

I think this may be the reason that main gpu miner is on 1gh pool.

[TiGei99]

Got it. I appreciate.

As a response to the tip, I announce that I will change my priorities towards to MMC CPU mining and will put more efforts into additional optimizations of MMC CPU mining:

- Better support for non-AES-NI CPUS to bring small miners closer to profitable mining;
- Variation of a mining setup with shared 1Gb memory for all threads (expect lower performance fur such setups due to inter-core contention);
- More optimizations to AES-NI algos to come even closer to GPU;
- More pool and protocol support (I encourage pool maintainers to contact me in order to provide better integration and improve general mining experience);
- Built-in NUMA support for better CPU utilization and proper data flow routing.

I will keep concentrating on optimizing miners for physical CPUs, because of cloud servers have numerous issues with memory management, NUMA compatibility, advanced instruction set exposure, etc.

I will not give any ETA, you all can imagine there is a lot of research work going on, and tens of different algo implementations are being tested.

yvg1900

yvg1900 you are my hero
Pool support is already really good. Also http://extasie.net/ works perfect but this pool is at the moment dead. Don't know why. Currently 0% fee there. Maybe it is because you have to register and with the other pools it is easier because you only need a payout address.
mine = getwork://TiGei99.worker5:x@extasie.net:8337/mmc

[badbonez]

badbonez - I had that issue when using machine with 8GB of ram but 24 cores.

Currently, this miner requires 1GB of RAM per thread. So what I ended up doing was using
6 threads - which uses 6GB, and then use another miner that only uses 1GB for the other 18 threads.

I see now I have a similar situation.  How do you tell the miner to use 1GB for the other 18 threads?

[FreeTrade]

Yes! Thanks for bringing mining home to CPUs and Memory. 5000 MMC tip on its way to yvg1900 from MCF.

Got it. I appreciate.

As a response to the tip, I announce that I will change my priorities towards to MMC CPU mining and will put more efforts into additional optimizations of MMC CPU mining:

Wow! Thanks!

Any suggestions for the best linux distribution to base our LiveCD on?

[yvg1900]

With the new coin miner fully justifies its name. 

Yes! Thanks for bringing mining home to CPUs and Memory. 5000 MMC tip on its way to yvg1900 from MCF.

Got it. I appreciate.

As a response to the tip, I announce that I will change my priorities towards to MMC CPU mining and will put more efforts into additional optimizations of MMC CPU mining:

- Better support for non-AES-NI CPUS to bring small miners closer to profitable mining;
- Variation of a mining setup with shared 1Gb memory for all threads (expect lower performance fur such setups due to inter-core contention);
- More optimizations to AES-NI algos to come even closer to GPU;
- More pool and protocol support (I encourage pool maintainers to contact me in order to provide better integration and improve general mining experience);
- Built-in NUMA support for better CPU utilization and proper data flow routing.

I will keep concentrating on optimizing miners for physical CPUs, because of cloud servers have numerous issues with memory management, NUMA compatibility, advanced instruction set exposure, etc.

I will not give any ETA, you all can imagine there is a lot of research work going on, and tens of different algo implementations are being tested.

yvg1900

[FreeTrade]

With the new coin miner fully justifies its name. 

Yes! Thanks for bringing mining home to CPUs and Memory. 5000 MMC tip on its way to yvg1900 from MCF.

[yvg1900]

Unfortunately, here we have nearly the same situation as we had with cloud servers running first versions of PTS mining (before yam, it was jhProtominer M7c-M7h, probably you followed a bit).

I recommend you the following:

1. Post here output of the miner that comes right after banner message - there is info on algo in use, number of threads selected and optimization compatibility checks - there we will see if AES-NI is really working
2. Try running it with ONE thread. You shall get ART value within reasonable time and factor out many potential issues.
3. Post here output of numactl --hardware (this is TYPICAL that cloud services DO NOT properly support NUMA, to be honest I am NOT aware of any that does that right, as well as memory management is completely unacceptable for high performance computing).

From what I see, you have multi-socket system (some Dual Xeon E5-26XX), so proper NUMA support is critical. Default memory allocation policy for such systems is typical to be Interleaved, causing huge underperformance under heavy memory load due to QPI bandwidth limitation, which is exactly our case.

Note that miner updates statistics in between rounds, so not showing statistics means that round takes way too long - compare this with physical machine - some SB, IB or Haswell i7.

As of crash, which EXACTLY CPU is there and which build do you use?

yvg1900

P.S. In other case I would not support cloud services and low end configs because of they simply using outdated and improperly configured software. But let us try to figure out what we can do.

[badbonez]

At the moment I believe that there is no point running yam M7j on non-AES-NI configs - I expect it may be slower even than original miner, because of non-AES-NI codepath did not get enough attention from me. Probably for next versions.

As of less memory usage, I am working on that. Major part of the optimization was to reduce data exchange and contention between cores, that's why separate buffer per thread used. Reverting back to old schema is possible in theory, but it is complete rethink of the optimizations made and needs time. You can imagne even this set of optimizations took long time to get implemented.

As of miner behavior under low RAM situations, there is absolutely no special handling for that except for some null pointer checks. At first, applcation performance will degrade due to swapping (if you have one configured - I don't) and if there is not enough RAM even in case of swapping, it will (may) just crash, but will do so at very early stage.

If you are not getting hashrate, then system runs extremely slow due to swapping (=> more RAM or less threads), inter-socket data exchange over QPI (=> numactl or proper affinity setup) or no AES-NI. There is an ART parameter (Average Round Time in milliseconds) that shall be less than 60000 in regular cases. 45000 is typical, less than 30000 is fast.

If you reduced number of threads due to RAM constrains, consider using av=2 or av=3 to gain from non-HT algo variations.

yvg1900

P.S. At the end, it is MemoryCoin It is supposed to consume A LOT of memory for PoW

Thank you for your reply.  Here's a more specific situation:

I have a cloud server with 24 threads and 24 GB Ram which DOES support AES-NI.  My config looks like this:

Code: [Select]

threads = 0
mining-params = mmc:av=1&aesni=on
mine = getwork://MLzSj31GVDqYLstZjFFqoGjafhiGz5FkRo@work.mmcpool.com:80:8880:8881:8882:8883/mmc
mine = getwork://MLzSj31GVDqYLstZjFFqoGjafhiGz5FkRoGe@mmcpool.1gh.com:8080:8081:8082:8083/mmc
#proxy = socks4a://127.0.0.1:9150
compact-stats = 1
print-timestamps = 1
When I run yam ("./yam -c yam-mmc.cfg") I get about 20 - 30 second of output like this:

Code: [Select]

[2014-01-13 19:22:48.367916]   work.mmcpool.com: On-line, Shares Submitted 0, Accepted 0
[2014-01-13 19:22:48.367963]   mmcpool.1gh.com: Idle, Shares Submitted 0, Accepted 0
[2014-01-13 19:22:48.367981]   mmc.gpools.com: Idle, Shares Submitted 0, Accepted 0
[2014-01-13 19:22:58.367844] MMC Agg. SPM: 0.000, HPM: ?; Rnds C/I: 0/0, Don. C/I: 0/0; Cfg/Thr SPM: 0.000/?, Cfg/Thr HPM: ?/? 0 rnds AV=1, ART=?
And then it crashes.

I can see that it has contacted the server, "work.mmcpool.com: On-line" but no hashing,  I am using the Generic x64 Linux miner on Unbutu 13.04 (x64). 

Any ideas?  Thanks.

PS:  When I look at hugepages (cat /proc/meminfo | grep AnonHugePages)

I get:

Code: [Select]

AnonHugePages:         0 kB
Not good?

[yvg1900]

One of advantages of HugePages is that they bypass OS memory swapping mechanism, so if you are unable to get them allocated, there is a high chance that you will get some of memory swapped out to disk, and this will lead to extreme underperformance.

Possibilities in your case are to add more RAM, further reduce number of threads or wait until I come up with alternate version of miner with lower RAM requirements. But expect that version to be slower. How much - it is matter of tests and efforts put into optimizing.

yvg1900

[Djemi]

If you reduced number of threads due to RAM constrains, consider using av=2 or av=3 to gain from non-HT algo variations.

yvg1900

P.S. At the end, it is MemoryCoin It is supposed to consume A LOT of memory for PoW

In my configuration 2 x 6 core xeon with 12gb and 24 threads if I setup more than 6 threads it allocate those threads in not huge page... Also if I run two instances of the miner, it can't allocate more than 6gb... is it because it is 6gb for Cpu?

[yvg1900]

At the moment I believe that there is no point running yam M7j on non-AES-NI configs - I expect it may be slower even than original miner, because of non-AES-NI codepath did not get enough attention from me. Probably for next versions.

As of less memory usage, I am working on that. Major part of the optimization was to reduce data exchange and contention between cores, that's why separate buffer per thread used. Reverting back to old schema is possible in theory, but it is complete rethink of the optimizations made and needs time. You can imagne even this set of optimizations took long time to get implemented.

As of miner behavior under low RAM situations, there is absolutely no special handling for that except for some null pointer checks. At first, applcation performance will degrade due to swapping (if you have one configured - I don't) and if there is not enough RAM even in case of swapping, it will (may) just crash, but will do so at very early stage.

If you are not getting hashrate, then system runs extremely slow due to swapping (=> more RAM or less threads), inter-socket data exchange over QPI (=> numactl or proper affinity setup) or no AES-NI. There is an ART parameter (Average Round Time in milliseconds) that shall be less than 60000 in regular cases. 45000 is typical, less than 30000 is fast.

If you reduced number of threads due to RAM constrains, consider using av=2 or av=3 to gain from non-HT algo variations.

yvg1900

P.S. At the end, it is MemoryCoin It is supposed to consume A LOT of memory for PoW