{"id":2054,"date":"2019-12-04T17:33:23","date_gmt":"2019-12-04T14:33:23","guid":{"rendered":"https:\/\/crypto-mining.club\/?p=2054"},"modified":"2019-12-04T17:39:09","modified_gmt":"2019-12-04T14:39:09","slug":"xmr-stak-vs-castxmr-who-will-win","status":"publish","type":"post","link":"https:\/\/crypto-mining.blog\/en\/mining\/xmr-stak-vs-castxmr-who-will-win\/","title":{"rendered":"XMR-STAK vs CastXMR – who is more profitable?"},"content":{"rendered":"\n
\"XMR-STAK<\/figure>\n\n\n\n

I suppose any good Rx Vega mining guide needs to objectively discuss and evaluate the prominent Vega mining software options….  both of which have a faithful following within the Vega Mining community.  This will present an honest and objective assessment. Here we go!
(Note: I don’t know who the winner will be as I write this intro… Let’s see how this shakes out)
<\/p>\n\n\n\n

The Contenders<\/strong><\/h2>\n\n\n\n

In Corner #1 – CastXMR<\/a><\/noindex> ver 0.7    (Note: ver 0.8.1 is now out, unsure of performance delta)<\/strong>
The self proclaimed “Fastest miner for AMD Radeon RX Vega GPU series”.  CastXMR is closed source software and has a development fee of 1.5%.

In Corner #2 – XMR-STAK<\/a><\/noindex> ver 2.0.0.   (Note: ver 2.2.0 is now out, +40h\/s on 64’s)<\/strong>
XMR-STAK has no baked in special internal tuning for Vega GPU’s but offers configuration file options which enable self tuning.  Some dual thread configurations have become pretty standard<\/a><\/noindex> such that I think it’s fair to call it “Vega tuned” from the perspective of this comparison.  XMR-Stak is open source and has a default development fee of 2% (.5% higher).
<\/p>\n\n\n\n

\nDiscussion of Bias:<\/strong>  <\/h2>\n\n\n\n

\nHere are the facts on my bias going into this…  I dabbled with both \nprograms when I initially setup my miner.  I think most would agree that\n CastXMR is a bit more noob friendly in that the start command is a \nsingle line and the tuning is built into the software.  I was a noob who\n was also willing to tweak so my initial focus was mainly features and \nperformance.  My initial results gave a trivially small performance \nbenefit for xmr-stak but the real tiebreaker for me was the web \ninterface.  I was initially dealing with some hash drop issues with both\n programs and appreciated xmr-stak enabling me to quickly check miner \nstatus on my phone…. one might call it an addiction :-).  Anyway, as \nmany of you know, besides the fact that hash drop for me is now a more \nrare occurrence, there have been two major changes since those “early” \ndays:
<\/p>\n\n\n\n

  1. JJs_HashMonitor<\/a><\/noindex>\n makes the occasional Vega hash drop a non-even.  Having a well \nformatted web interface is less important because the monitor self \ndetects hash drop and resets the miners to full speed.  Awesome! (I hope\n you have all tipped JJ<\/a><\/noindex> for saving your hashes!).  <\/li>
  2. CastXMR new 11\/29th release added a remote monitoring capability \n(Woot!).  While JJs_HashMonitor is not yet configured to support \nCastXMR… that is simply a fork away and thus I am willing to seed it \nas an existing capability for the purpose of this comparison. <\/li><\/ol>\n\n\n\n

    I have no vested interest in either software so it’s fair to call this an honest assessment because given (1) and (2) above, I don’t know what my motivation would be for bias. Like everybody else I am just trying to find the most effective software for my rig.

    Before going any other farther I also want to say that I recommend you view this post as a guide on a method you can use to make a performance assessment for your particular rig<\/strong>.  Each rig is different.  The analysis below will discuss my method and my numbers…  It will stop short of making any recommendations because as always… YMMV.
    <\/p>\n\n\n\n

    \nDiscussion of CastXMR Reported Values:<\/h2>\n\n\n\n

    I have to start with a discussion a few number irregularities regarding the hash rate waterfall that scrolls across the CastXMR screen.  The figures below are from a Monero mining session that started at 9:55PM.  I let the program run unobstructed for about 15 minutes to ensure everything was settled in and then took a screen capture.
    <\/p>\n\n\n\n

    \"\"
    Figure 1: CastXMR Results after 17 Minutes of Undisturbed Operation (Remote Desktop is Active) <\/figcaption><\/figure><\/div>\n\n\n\n

    When it’s running some pretty nice numbers are displayed which obviously contribute to the glowing reputation of CastXMR.  My Vega 64 (not serving a monitor) is GPU 0 which, in Figure 1, shows numbers of 2020.9, 2018.6, 2012.9, 2013.5, and 2013.1 h\/s.

    2020 h\/s definitively pops out as impressive considering the steady 2002 h\/s I see when I mine Monero with xmr-stak.  The average of those numbers is a bit lower 2015.8h\/s but still impressive.  Score one for CastXMR… but wait…  The problem comes in the next figure.  When you type “s” to get a hash report from castXMR you get the following:
    <\/p>\n\n\n\n

    \"\"
    Figure 2: CastXMR self generated summary data <\/figcaption><\/figure><\/div>\n\n\n\n

    The average hash rate for GPU 0 as 1994.6?!?!.  How can that be because I have been watching the screen pass by and there was not one instance when the GPU0 value was less then 1994.6 h\/s, let alone low enough to pair with a 2020.9 h\/s to create an average of 1994.6 h\/s.  That average (1994.6) is a full 20h\/s lower then the average we calculated from Figure 1 (2015.8).  Curious.  Perhaps more puzzling is that directly after that summary report it gets right back to the business of displaying eye popping numbers like 2029.4 h\/s.  Xmr-stak and it’s 2002 h\/s can’t compete with 2029.4 h\/s… but compares quite favorable with 1994.6 h\/s.  Which is it?

    Consider that the 5 GPU average calculated from the bottom of figure 2 is (2029.4+1930.0+1931.0+1944.7+1958.5)\/5 = 1958.7 h\/s.  By contrast, the average reported in the cyan “share accepted report” just above it is a more modest 1935.1 h\/s.  I really don’t know what to make of the non-average numbers so I disregard them…

    The figures above are not cherry picked… These are typical of the castXMR performance on my machine and it leaves me scratching my head a bit.  I do not suspect any foul play here.  I suspect the number are from real calculation but might just not represent the value we assume them to be.  Perhaps they show the absolute fastest hash calculated over the display interval… and the “s” provided average is the true average hash rate over some time period?  It is really hard to know but one thing is for sure…  castXMR has the reputation for being “fast”.  It may in fact be faster… we won’t know until we get to the bottom of this post, but whatever the case, it is not AS FAST as the reputation developed by the number that roll across the display would suggest.  Focus on the average values that is displays in the summary report (“s”) and in the periodic report that occurs when an “accepted share” is reported.

    Ok, now lets get to it…<\/p>\n\n\n\n

    The Playing Field<\/strong><\/h2>\n\n\n\n

    \nI have 5 Vegas.  Two Vega 64’s and 3 Vega 56’s.  One Vega 64 (GPU 3 \/ \nThread 6&7) serves an HDMI dongle so it’s performance does not meet \nthat of the other Vega 64 (GPU 0 \/ Thread 0\/1).  The Vega Miner is setup\n up as published guide<\/a><\/noindex> with the three exceptions \/ clarifications that follow:

    <\/p>\n\n\n\n