Topic: [ANN] [XMG] MAGI | CPU mining | mPoW | mPoS | [MagiPay] - page 489. (Read 2375638 times)

Indeed, I'm glad I withdrew all my coins from Polo.
Seems shady.
Polo updated their terms, basicaly saying that you won't sue them if they "go broke".

Cool - great to hear we are getting some marketing =)

Glad we are no longer on Polo, the site has been all but down since last night

Hello awesome Magi community,

Keep eyes on this channel: https://www.youtube.com/user/WTINP
Magi will be on there soon!

It was the rate viewed in the miner console - if I remember correctly - XMG didn't interfere with XMR but there was a bit of a loss in hashing on XMG, but you are effectlyely mining XMG for free on a normal XMR rig. XMR rewards are not anywhere near where they used to be though.

Hello, I didn't posted since a while but I follow this thread regularly, I will try your pool with my little CPU

I had no problem with the registration and the mails came fast, no problem so far.


Anyone know where I can sell my BCC ? I have it in a wallet but nowhere to send, I would like have free magi 

Hi,

I have set up a new pool for the XMG (Coin Magi).
For those who would like to join and mine together with us on our new pool are welcome.
The address is: https://magi.trasmamod.com/

We are running Pay Per Last N Shares (PPLNS) and using the MPOS software (Mining Portal Open Source).

We will try our best to keep a steady uptime.
Please let me know if its something.

Today was BCC day, sold a few XMG, bought BCC and enjoyed the ride.
Until now I made a nice profit for buying back my XMG.

I made sure I bought extra magi diuring everybody else's mad dash for BTC - looks like a good day for alts so far - Magi usually follows a little behind lets see where we get to over the next few days =)

That's very interesting! I'd never considered that the algorithms might not interfere with each other, that could almost definitely be tweaked with the efficiency setting for XMG as well. I'll definitely have to look into this! Thanks for the heads up. Was that the rate as viewed in the miner console? or on the pool, if you remember.

Cheers. Indeed MPOS isn't that hard to do and was running okay except that gash rates where not right.  Got it working now with some work yet to be done. Thanks

magi-stratum is basically working as m-hash is relying on that. p2pool is much helpful, but it's probably not an easy go. MPOS should be the one straightforward; the guide on MPOS itself is actually good and enough for having the pool up. It might also be helpful to google MPOS.

I changed my last BTC cent into XMG, this morning. Let the price go up again!

Wow, even the basic version of the CPU kicks my pretty old i7 out of the park

one thing I noticed with HT enabled i7's was that I could mine same number of XMR and XMG threads as my physical cores without seeing any peformance drop (where with same number of virtual threads had a massive perf impact). Not sure if that hack also works on the new AMD's

Not a problem! Also, I'm fairly certain I've posted in the thread before... I may not have, either way, I've been around magi for some time now, but thank you! As friendly as ever.

Wow thanks for the nice test. I need some time to read it.
Also welcome in our friendly Magi community

So, a quick search and looking through more recent forum posts shows there is not much data regarding the newer AMD Ryzen CPU for mining with XMG. So I thought I would run some tests for those interested in the community, and in the process I found some interesting results.
Testing was done with a r5 1600 on an Asrock Taichi x370 board, not sure on the BIOS revision, I'm more than happy to check if anyone is interested. I used m-minerd for the testing. I felt that some users may be interested in the performance differences with different -e settings, so I've included a number of different settings. I was interested to see if RAM speed played as large of a role in XMG as in other tasks, as well as the impact of an overclock, so tests have been run at 3.4/2133, 3.4/3200, 3.9/2133, 3.9/3200. This was run on my horribly messy installation of windows, simply because I didnt have a good working linux boot when I had time for the tests. The numbers are my perceived "average" of the reported hashrate inside of the miner. Not the most scientific of methods, but again this was a quick test.
here's the results:
3.9/3200CAS15
6t 25% - 4.5/26.8
6t 50% - 9.9/59.5
6t 75% - 19.3/116.5
6t 90% - 19.3/112.5
6t 95% - 19.5/117.1
6t 100% - 19.5/117.1
---
12t 25% - 3.0/36.5
12t 50% - 4.8/57.3
12t 75% - 9.8/117.3
12t 90% - 9.9/118.3
12t 95% - 9.9/118.3
12t 100% - 12.5/151.4
----------------------
3.4/2133CAS15
6t 25% - 3.0/18.0
6t 50% - 8.5/52.5
6t 75% - 9.0/54.3
6t 90% - 17.0/101.8
6t 95% - 8.5/52.4
6t 100% - 16.8/99.1
---
12t 25% - 2.3/27.7
12t 50% - 4.8/57.9
12t 75% - 9.6/114.1
12t 90% - 9.6/116.2
12t 95% - 11.0/132.23
12t 100% - 11.0/131.6
---------------------
3.4/3200CAS15
12t 25% - 3.0/36.4
12t 50% - 4.9/58.3
12t 75% - 9.7/116.9
12t 90% - 9.8/117.8
12t 95% - 11.3/136.0
12t 100% - 11.1/132.6
----------------------
3.9/2133CAS15
12t 25% - 3.0/36.7
12t 50% - 4.7/56.8
12t 75% - 9.7/117.3
12t 90% - 9.9/119.1
12t 95% - 12.5/151.0
12t 100% - 12.6/151.6
What do I make of it?
Well, for starters, there seems to be a large drop off in performance gains after 75% in all situations, which to me seems to suggest a lack of optimizations for the new architecture or newer CPU in general. Also, it appears to me that clock speed is king, at least for now on Ryzen CPU. This could be due to the lack of optimization again, but that's all over my head!
Something else I noticed that may explain some of the strange performance numbers is for m-minerd, my reported CPU usage often exceeded or under performed the -e setting, ie. -e 75, usage at 20%. This could be a reporting issue, this could be a m-minerd issue, this could be a user error or installation issue. There are a lot of variables, which I am working to resolve. I'd like to retest on a clean installation of linux/windows, as well as try the other miners (spexx and wolf are the only other two I am familiar with). I would also like to do more testing with SMT disabled and compare these results to the 6 core tests with SMT enabled, if for no other reason to see how zen is utilized by the miner as well as under the current windows scheduler, etc.
Overall, however, I feel these results are more or less valid, and should work as a good representation of the Ryzen series chips, from this we can estimate performance of other models given the scaling of the zen architecture (assuming e-100, perfect scaling, similar performance to current testing method):
4c/4t - 77.8
4c/8t - 100.9
8c/16t - 201.8
12c/24t - 302.8
16c/32t - 403.7!!!
Overall very interesting!! Really nice performance, although I feel some optimizations can almost certainly be made, but again I am unsure as much of that goes right over my head!
If anyone would like me to run specific tests or gather other information please let me know! I'd be more than happy to!

Magi might hit the bottom this week. In $ the value did not drop much because of the high btc value. But when it goes higher this is not a bad period to purchase some XMG.  

Reminder Magi XMG has awesome roadmap with great improvements & developments in progress.
https://roadmap.coinmagi.org

I didn't even know there was the option for that - I'll configure it and check - but might take a long time before my miner goes idle LOL

@suprnova miners, @ocminer
do you guys also having problems with idle worker email notifications?
I checked monitor ON and idle worker notification but still not getting emails when my worker goes idle.

Good day.

I'm trying to build a pool for our lovely coinmagi but stratum seems to fail. Hashrate is showing wrong in mpos. Now trying p2pool buy I'm missing coin info.
Can you help me as magi-stratum on github.com isn't much help.

Many thanks for help

Edward0181