Jag antar att alla bra Rx Vega gruvguider måste objektivt diskutera och utvärdera de framstående Vega gruvmjukvarualternativen .... som båda har en trogen följare inom Vega Mining-gemenskapen. Detta kommer att ge en ärlig och objektiv bedömning. Nu kör vi!
(Obs:Jag vet inte vem vinnaren kommer att bli när jag skriver det här introt... Låt oss se hur detta skakar ut)

Tävlande

I hörn #1 – CastXMR ver 0.7 (Obs:ver 0.8.1 är nu ute, osäker på prestanda delta)
Den självutnämnda "snabbaste gruvarbetaren för AMD Radeon RX Vega GPU-serien". CastXMR är mjukvara med stängd källkod och har en utvecklingsavgift på 1,5 %.

I hörn #2 – XMR-STAK ver 2.0.0. (Obs:ver 2.2.0 är nu ute, +40h/s på 64:or)
XMR-STAK har ingen speciell intern justering för Vega GPU:er men erbjuder konfigurationsfilalternativ som möjliggör självjustering. Vissa konfigurationer med dubbla trådar har blivit ganska standard sådan att jag tycker att det är rättvist att kalla det "Vega tuned" ur denna jämförelses perspektiv. XMR-Stak är öppen källkod och har en standardutvecklingsavgift på 2 % (0,5 % högre).

Diskussion om partiskhet:

Här är fakta om min partiskhet som går in på det här... Jag pysslade med båda programmen när jag först ställde in min miner. Jag tror att de flesta håller med om att CastXMR är lite mer noob-vänligt genom att startkommandot är en enda rad och inställningen är inbyggd i programvaran. Jag var en noob som också var villig att justera så mitt första fokus var främst funktioner och prestanda. Mina första resultat gav en trivialt liten prestandafördel för xmr-stak men den verkliga tiebreaken för mig var webbgränssnittet. Jag hade till en början att göra med några hash-drop-problem med båda programmen och uppskattade xmr-stak som gjorde det möjligt för mig att snabbt kontrollera miner-status på min telefon... man kan kalla det ett beroende :-). Hur som helst, som många av er vet, förutom det faktum att hash-drop för mig nu är en mer sällsynt företeelse, har det skett två stora förändringar sedan dessa "tidiga" dagar:

1. JJs_HashMonitor gör att en och annan Vega-hash faller till en non-even. Att ha ett välformaterat webbgränssnitt är mindre viktigt eftersom monitorn själv upptäcker hashfall och återställer gruvarbetarna till full hastighet. Grymt bra! (Jag hoppas att ni alla har tippat JJ för att du har sparat dina hash!).
2. CastXMRs nya 11/29:e version lade till en fjärrövervakningsfunktion (Woot!). Även om JJs_HashMonitor ännu inte är konfigurerad för att stödja CastXMR... det är bara en gaffel bort och därför är jag villig att se det som en befintlig funktion för denna jämförelse.

Jag har inget egenintresse i någondera mjukvaran så det är rimligt att kalla detta en ärlig bedömning eftersom givet (1) och (2) ovan vet jag inte vad min motivation skulle vara för partiskhet. Som alla andra försöker jag bara hitta den mest effektiva programvaran för min rigg.

Innan du går längre vill jag också säga att jag rekommenderar att du ser det här inlägget som en guide till en metod du kan använda för att göra en prestandabedömning för just din rigg . Varje rigg är olika. Analysen nedan kommer att diskutera min metod och mina siffror ... Det kommer att sluta med några rekommendationer eftersom som alltid ... YMMV.

Diskussion om CastXMR-rapporterade värden:

Jag måste börja med en diskussion om några oegentligheter när det gäller hashhastighetsvattenfallet som rullar över CastXMR-skärmen. Siffrorna nedan är från en Monero gruvsession som startade 21:55. Jag lät programmet köra obehindrat i cirka 15 minuter för att se till att allt var fixat och tog sedan en skärmdump.

När den är igång visas några ganska fina siffror som uppenbarligen bidrar till CastXMRs lysande rykte. Min Vega 64 (som inte tjänar en bildskärm) är GPU 0 som, i figur 1, visar siffror på 2020.9, 2018.6, 2012.9, 2013.5 och 2013.1 h/s.

2020 h/s blir definitivt lika imponerande med tanke på de stadiga 2002 h/s jag ser när jag bryter Monero med xmr-stak. Genomsnittet av dessa siffror är lite lägre 2015.8h/s men fortfarande imponerande. Gör ett poäng för CastXMR... men vänta... Problemet kommer i nästa figur. När du skriver "s" för att få en hashrapport från castXMR får du följande:

Den genomsnittliga hashhastigheten för GPU 0 som 1994.6?!?!. Hur kan det bero på att jag har sett skärmen passera och det inte fanns ett enda fall då GPU0-värdet var mindre än 1994,6 h/s, än mindre tillräckligt lågt för att paras ihop med en 2020,9 h/s för att skapa ett genomsnitt på 1994,6 h/s /s. Det genomsnittet (1994.6) är hela 20h/s lägre än det genomsnitt vi beräknade från figur 1 (2015.8). Nyfiken. Kanske mer förbryllande är att direkt efter den sammanfattande rapporten går det direkt tillbaka till verksamheten med att visa uppseendeväckande siffror som 2029,4 h/s. Xmr-stak och det är 2002 h/s kan inte konkurrera med 2029,4 h/s... men jämför ganska gynnsamt med 1994,6 h/s. Vilken är det?

Tänk på att medelvärdet för 5 GPU beräknat från botten av figur 2 är (2029,4+1930,0+1931,0+1944,7+1958,5)/5 =1958,7 h/s. Däremot är det genomsnittliga snittet som rapporteras i den cyan "aktie accepterade rapporten" strax ovanför en mer blygsam 1935,1 h/s. Jag vet verkligen inte vad jag ska göra med de icke-genomsnittliga siffrorna så jag bortser från dem...

Siffrorna ovan är inte körsbärsplockade... Dessa är typiska för castXMR-prestandan på min maskin och det får mig att klia mig lite i huvudet. Jag misstänker inget fulspel här. Jag misstänker att siffran är från verklig beräkning men kanske inte representerar det värde vi antar att de är. Kanske visar de den absolut snabbaste hash-hastigheten beräknad över visningsintervallet ... och "s"-genomsnittet är den sanna genomsnittliga hashhastigheten under en viss tidsperiod? Det är verkligen svårt att veta men en sak är säker... castXMR har rykte om sig att vara "snabb". Det kan faktiskt vara snabbare ... vi vet inte förrän vi kommer till botten av det här inlägget, men hur som helst är det inte SÅ SNABBT som ryktet som utvecklats av numret som rullar över skärmen skulle antyda. Fokusera på de medelvärden som visas i den sammanfattande rapporten (”s”) och i den periodiska rapport som uppstår när en ”accepterad aktie” rapporteras.

Ok, nu ska vi komma till det...

The Playing Field

Jag har 5 Vegas. Två Vega 64:or och 3 Vega 56:or. En Vega 64 (GPU 3 / Thread 6&7) serverar en HDMI-dongel så att dess prestanda inte motsvarar den andra Vega 64 (GPU 0 / Thread 0/1). Vega Miner är konfigurerad som publicerad guide med de tre undantagen/förtydligandena som följer:

• Det mesta av guiden skrevs när min gruvarbetare hade 4 Vega och 1 Nvidia GTX 750. Jag förklarar i guiden att jag har köpt en annan Rx Vega 56 för att ersätta GTX-750... och att jag har lagt till det jag lärt mig från den erfarenheten till guiden. Vissa av er kanske inte har läst den sedan dess så jag ville upprepa den för tydlighetens skull.
• I guiden (och vid gruvdrift i verkligheten) gör jag CPU mining parallellt med Vega Mining. Eftersom CastXMR inte kommer med en CPU-miner, har jag inte xmr-stak-mining med CPU:n under dessa tester (det visar sig att det inte gjorde någon skillnad men jag var inte säker)
• I guiden föreslår jag att personer med monitorer/donglar kopplade till Vega använder en intensitet på 1800 på båda trådarna i just den Vega för att få stabilitet.. och sedan arbeta därifrån (mot min standard 1932/1932) . Mitt system GPU3 är en Rx Vega 64 som betjänar min HDMI-dongel och den är stabil med intensiteter på 1908 och 1800. Det är värdena du kommer att se på GPU 3 (trådar 6+7) när xmr-stak bryts.

Testprocedur:

1. Starta om datorn.
2. Inloggad via Chrome Remote Desktop
3. Starta JJ:s Hash Monitor så att den startar om mina Vegas och tillämpar mina OverdriveNTool-parametrar (återigen, de exakta parametrarna från guiden)
4. Stängd JJs_HashMonitor och tillhörande miner
5. Öppnade Windows-filhanteraren
6. Dubbelklicka på cmd-filen som skickar gruvarbetaren de kommandon den behöver för att starta
   • cast_xmr inkluderade flaggan –remoteaccess
   • xmr-stak inkluderade flaggan –noCPU och –noNVIDIA
7. När en gruvarbetare väl startades stängde jag windows filhanterare så det enda fönstret som var öppet var gruvarbetarfönstret och inget annat.
8. Jag avslutade Chrome Remote Desktop-sessionen
9. Jag tog alla värden från en separat dator i mitt nätverk via webbgränssnittet
   • Observera att castXMR inte visar värdena i ett snyggt webbformat men all data finns där och tillgänglig så det verkade vara det bästa sättet att få prestanda för en "huvudlös dator".

Vad jag inte gjorde:Jag använde inte JJs Hash Monitor under testet (eftersom jag inte ville återställa Vega mellan testerna. Således återställde jag inte Vega mellan de två Monero gruvsessionerna. Jag ansökte inte igen OverdriveNTool parametrar mellan de två sessionerna.

Resultat

Det officiella resultatet kommer att baseras på den genomsnittliga effektiva hashhastigheten. Den effektiva hashhastigheten beräknas genom att ta den rapporterade genomsnittliga hashhastigheten för gruvprogramvaran och sänka den med andelen avvisade aktier. (Till exempel, för den 20 minuters körning som presenteras i figur 2 ovan, rapporterade CastXMR ett utbyte på 95 %). Båda gruvarbetarna pekar på pool.supportXMR:7777 (genomsnittlig pingtid =15ms).

CastXMR-resultat

CastXMR körde i cirka 30 minuter innan jag frågade webbgränssnittet och fångade figur 3:

Så, CastXMR visar en initial medelhastighet på 9809 h/s men med 3,2 % av aktierna avvisade och en utvecklingsavgift på 1,5 %, är den resulterande effektiva hashfrekvensen 9809 x 96,8 % x 98,5 % =9353,7 h/s avkastning
Obs! Även om webbgränssnittet inte tillhandahåller anledningen till avslag utöver, "num_outdated", gör det att observera den tidigare körningen (Figur 2 ovan) det troligt att andelarna avvisades för:"Outdated på grund av jobbbyte". Även om detta kan tyckas vara ett problem med en pool jämfört med ett problem med gruvarbetare, är faktum att jag rutinmässigt använder xmr-stak med supportxmr och får inga sådana avslag... men de inträffar varje gång jag kör cast_xmr. Jag drar slutsatsen att det alltså är hänförligt till mjukvarujobbhanteringen och eftersom jag inte känner till några rattar kan jag vrida w.r.t. till den här frågan måste jag bara tillgodose det i jämförelsen via en "effektiv hash-rate".

XMR-Stak-resultat:

Xmr-stak körde i cirka 30 minuter innan jag frågade webbgränssnittet och fångade figur 4 och 5:

Så XMR-stak har en initial medelhastighet på 9734,7 h/s men med 100 % avkastning förblir den effektiva hashhastigheten hela 9734,7 h/s avkastning. XMR-Stak kommer med en standardutvecklingsavgift på 2 % så att den effektiva avkastningen minskar till 9540 h/s .

Slutsats

Det har visat sig att hashhastighetsvärdena som visas på vattenfallet av siffror på CastXMR-skärmen ska ignoreras till förmån för CastXMR-rapporterade medelvärden.

XMR-stak rapporterar en genomsnittlig hashfrekvens som är 99,2 % av den CastXMR-rapporterade hashfrekvensen (cirka 15 h/s per Vega). Men när man jämför den effektiva avkastningen efter redovisning av förlorade aktier och skillnader i utvecklingsavgifter, är XMR-stak-avkastningen 2 % bättre än CastXMR. Det är en förbättring med cirka 185 h/s till förmån för XMR-stak (nät ca 35 h/s per Vega).

Uthållighetstest

Jag var orolig för att kanske mina korta testperioder hade kastat CastXMR i ett orättvist ljus så jag körde ett utökat 8 timmars test för att se om antalet "Outdated" aktier skulle lösa sig. Tyvärr förblev avkastningen likartad (lite sämre).

Det lämnades in 1082 aktier under den förlängda testperioden och figur 6 visar att 41 aktier avvisades som "föråldrade" (3,9 % avfall). CastXMR verkade ha ett genomsnitt på 9813,8 h/s, men när man väl tagit hänsyn till förlorade aktier och utvecklingsavgifter minskar den effektiva avkastningen till 9289,6 h/s... den korrigerade avkastningen visar att stak-xmr återigen slog CastXMR. Marginalen på 2,7 % till förmån för stak-xmr resulterar i icke-triviala 250 h/s på mitt 5 Vega-system... ~50 h/s per Vega.

Figur 6:CastXMR förlorade 3,9 % av sin ansträngning till "Outdated" aktier under det 8,3 timmar långa uthållighetstestet

Det är förmodligen värt att nämna igen vad jag sa i förväg... Jag rekommenderar att du tittar på det här inlägget som en guide för metoden du kan använda för att göra en prestationsbedömning för just din rigg . Varje rigg är olika. Analysen var en diskussion om min metod och mina siffror... YMMV.

Tack till alla som fastnade för detta nummerfyllda analytiska inlägg hela vägen till botten. Inte precis en pageturer men förhoppningsvis tyckte du att det var rättvist, objektivt och hjälpsamt. Skicka gärna detta vidare till alla som diskuterar för- och nackdelarna med de olika gruvprogramvaran!