XMR-STAK vs CastXMR – hvem er mere rentabel?

Jeg formoder, at enhver god Rx Vega-mineguide skal objektivt diskutere og evaluere de fremtrædende Vega-minesoftwaremuligheder... som begge har en trofast tilhængerskare inden for Vega Mining-samfundet. Dette vil give en ærlig og objektiv vurdering. Nu sker det!
(Bemærk:Jeg ved ikke, hvem vinderen bliver, mens jeg skriver denne intro... Lad os se, hvordan det ryster ud)

Konkurrenterne

I hjørne #1 – CastXMR ver 0.7 (Bemærk:ver 0.8.1 er nu ude, usikker på ydeevne delta)
Den selverklærede "hurtigste minearbejder til AMD Radeon RX Vega GPU-serien". CastXMR er lukket kildesoftware og har et udviklingsgebyr på 1,5%.

I hjørne #2 – XMR-STAK version 2.0.0. (Bemærk:version 2.2.0 er nu ude, +40t/s på 64'ere)
XMR-STAK har ingen indbygget speciel intern tuning til Vega GPU'er, men tilbyder konfigurationsfilindstillinger, der muliggør selvtuning. Nogle dobbelttrådskonfigurationer er blevet temmelig standard sådan, at jeg synes, det er rimeligt at kalde det "Vega-tunet" fra denne sammenlignings perspektiv. XMR-Stak er open source og har et standardudviklingsgebyr på 2 % (0,5 % højere).

Diskussion af bias:

Her er fakta om min skævhed, der går ind i dette... Jeg prøvede begge programmer, da jeg oprindeligt konfigurerede min minearbejder. Jeg tror, ​​de fleste vil være enige i, at CastXMR er en smule mere noob-venlig, idet startkommandoen er en enkelt linje, og tuningen er indbygget i softwaren. Jeg var en noob, der også var villig til at justere, så mit første fokus var hovedsageligt funktioner og ydeevne. Mine første resultater gav en trivielt lille ydeevnefordel for xmr-stak, men den rigtige tiebreaker for mig var webgrænsefladen. Jeg beskæftigede mig oprindeligt med nogle hash-drop-problemer med begge programmer og værdsat xmr-stak, der gjorde det muligt for mig hurtigt at tjekke minearbejderstatus på min telefon... man kan kalde det en afhængighed :-). I hvert fald, som mange af jer ved, udover det faktum, at hash-drop for mig nu er en mere sjælden begivenhed, har der været to store ændringer siden de "tidlige" dage:

  1. JJs_HashMonitor får den lejlighedsvise Vega-hash til at falde til en non-even. At have en velformateret webgrænseflade er mindre vigtigt, fordi skærmen selv registrerer hash-drop og nulstiller minearbejderne til fuld hastighed. Fantastisk! (Jeg håber, at I alle har tip JJ for at gemme dine hashes!).
  2. CastXMR ny 11/29. udgivelse tilføjede en fjernovervågningsfunktion (Woot!). Selvom JJs_HashMonitor endnu ikke er konfigureret til at understøtte CastXMR... er det blot en gaffel væk, og derfor er jeg villig til at se det som en eksisterende funktion med henblik på denne sammenligning.

Jeg har ingen egeninteresse i nogen af ​​softwarerne, så det er rimeligt at kalde dette en ærlig vurdering, fordi givet (1) og (2) ovenfor, ved jeg ikke, hvad min motivation ville være for bias. Som alle andre prøver jeg bare at finde den mest effektive software til min rig.

Inden jeg går videre vil jeg også sige, at jeg anbefaler, at du ser dette indlæg som en guide til en metode, du kan bruge til at lave en præstationsvurdering for netop din rig . Hver rig er forskellig. Analysen nedenfor vil diskutere min metode og mine tal ... Den vil stoppe med at komme med nogen anbefalinger, fordi som altid ... YMMV.

Diskussion af CastXMR-rapporterede værdier:

Jeg er nødt til at starte med en diskussion af et par uregelmæssigheder i antallet af hashhastighedsvandfaldet, der ruller hen over CastXMR-skærmen. Tallene nedenfor er fra en Monero-minesession, der startede kl. 21:55. Jeg lod programmet køre uhindret i omkring 15 minutter for at sikre, at alt var afklaret og tog derefter et skærmbillede.

Figur 1:CastXMR-resultater efter 17 minutters uforstyrret drift (fjernskrivebord er aktivt)

Når det kører, vises nogle ret flotte tal, som naturligvis bidrager til CastXMRs glødende omdømme. Min Vega 64 (der ikke betjener en skærm) er GPU 0, som i figur 1 viser tal på 2020.9, 2018.6, 2012.9, 2013.5 og 2013.1 t/s.

2020 t/s dukker definitivt ud som imponerende i betragtning af de stabile 2002 t/s, jeg ser, når jeg mine Monero med xmr-stak. Gennemsnittet af disse tal er en smule lavere 2015.8t/s, men stadig imponerende. Score en for CastXMR... men vent... Problemet kommer i næste figur. Når du skriver "s" for at få en hash-rapport fra castXMR, får du følgende:

Figur 2:CastXMR selvgenererede oversigtsdata

Den gennemsnitlige hash-rate for GPU 0 som 1994.6?!?!. Hvordan kan det skyldes, at jeg har set skærmen passere forbi, og der var ikke ét tilfælde, hvor GPU0-værdien var mindre end 1994,6 t/s, endsige lav nok til at parre med en 2020,9 h/s for at skabe et gennemsnit på 1994,6 t. /s. Dette gennemsnit (1994.6) er hele 20 timer/s lavere end det gennemsnit, vi beregnede fra figur 1 (2015.8). Nysgerrig. Måske mere forvirrende er det, at det umiddelbart efter den sammenfattende rapport vender tilbage til branchen med at vise iøjnefaldende tal som 2029,4 t/s. Xmr-stak og det er 2002 t/s kan ikke konkurrere med 2029,4 t/s... men sammenligner sig ganske gunstigt med 1994,6 t/s. Hvilken er det?

Overvej, at 5 GPU-gennemsnittet beregnet fra bunden af ​​figur 2 er (2029,4+1930,0+1931,0+1944,7+1958,5)/5 =1958,7 h/s. I modsætning hertil er gennemsnittet rapporteret i den cyan "andel accepteret rapport" lige over det et mere beskedent 1935,1 t/s. Jeg ved virkelig ikke, hvad jeg skal gøre af de ikke-gennemsnitlige tal, så jeg ser bort fra dem...

Tallene ovenfor er ikke plukket med kirsebær... Disse er typiske for castXMR-ydelsen på min maskine, og det får mig til at klø mig lidt i hovedet. Jeg har ikke mistanke om noget grimt spil her. Jeg formoder, at tallet er fra reel beregning, men repræsenterer måske bare ikke den værdi, vi antager, at de er. Måske viser de den absolut hurtigste hash beregnet over visningsintervallet ... og "s"-gennemsnittet er den sande gennemsnitlige hash-rate over en vis periode? Det er virkelig svært at vide, men én ting er sikkert ... castXMR har ry for at være "hurtig". Det kan faktisk være hurtigere ... vi ved det ikke, før vi kommer til bunden af ​​dette indlæg, men uanset hvad er det ikke SÅ HURTIG, som omdømmet udviklet af det nummer, der ruller hen over skærmen, antyder. Fokuser på de gennemsnitlige værdier, der vises i den sammenfattende rapport ("s") og i den periodiske rapport, der opstår, når en "accepteret andel" rapporteres.

Ok, lad os nu komme til det...

Spillebanen

Jeg har 5 Vegas. To Vega 64’ere og 3 Vega 56’ere. Den ene Vega 64 (GPU 3 / Thread 6&7) betjener en HDMI-dongle, så dens ydeevne svarer ikke til den anden Vega 64 (GPU 0 / Thread 0/1). Vega Miner er sat op som udgivet guide med de tre undtagelser / præciseringer som følger:

  • Det meste af guiden blev skrevet, da min minearbejder havde 4 Vega'er og 1 Nvidia GTX 750. Jeg forklarer i vejledningen, at jeg har købt en anden Rx Vega 56 til at erstatte GTX-750... og at jeg har tilføjet, hvad jeg har lært fra den oplevelse til guiden. Nogle af jer har måske ikke læst det siden da, så jeg ville gerne gentage det for klarhedens skyld.
  • I guiden (og ved minedrift i det virkelige liv) laver jeg CPU-mining parallelt med Vega Mining. Fordi CastXMR ikke kommer med en CPU-miner, har jeg ikke xmr-stak-mining med CPU'en under disse test (det viser sig, at det ikke gjorde en forskel, men jeg var ikke sikker)
  • I vejledningen foreslår jeg, at folk med monitorer/dongler tilsluttet Vega's minedrift bruger en intensitet på 1800 på begge tråde af den pågældende Vega for at få stabilitet.. og derefter arbejde derfra (i forhold til min standard 1932/1932) . Mit system GPU3 er en Rx Vega 64, der betjener min HDMI-dongle, og den er stabil med intensiteter på 1908 og 1800. Det er de værdier, du vil se på GPU 3 (tråde 6+7), når xmr-stak miner.

Testprocedure:

  1. Genstart computeren.
  2. Logget ind via Chrome Remote Desktop
  3. Start JJ's Hash Monitor, så den genstarter mine Vega'er og anvender mine OverdriveNTool-parametre (igen de nøjagtige parametre fra guiden)
  4. Lukket JJs_HashMonitor og tilhørende minearbejder
  5. Åbnet Windows-filhåndtering
  6. Dobbeltklik på cmd-filen, der sender minearbejderen de kommandoer, den skal bruge for at starte
    • cast_xmr inkluderede flaget –remoteaccess
    • xmr-stak inkluderede flaget –noCPU og –noNVIDIA
  7. Når en miner blev startet, lukkede jeg windows filhåndtering, så det eneste åbne vindue var minearbejdervinduet og intet andet.
  8. Jeg afsluttede Chrome Remote Desktop-sessionen
  9. Jeg tog alle værdier fra en separat computer på mit netværk via webgrænsefladen
    • Bemærk, at castXMR ikke viser værdierne i et pænt webformat, men alle data er der og tilgængelige, så det virkede som den bedste måde at få "hovedløs computer" ydeevne på.

Hvad jeg ikke gjorde:Jeg brugte ikke JJs Hash Monitor under testen (fordi jeg ikke ønskede at nulstille Vega'erne mellem testene. Derfor nulstillede jeg ikke Vega'erne mellem de to Monero-minesessioner. Jeg ansøgte ikke igen OverdriveNTool parametre mellem de to sessioner.

Resultater

Det officielle resultat vil være baseret på den gennemsnitlige effektive hash-rate. Den effektive hash-rate beregnes ved at tage den rapporterede gennemsnitlige hash-rate af minesoftwaren og de-ratificere den med procentdelen af ​​afviste aktier. (For eksempel rapporterede CastXMR et 95 % udbytte for de 20 minutters kørsel, der er vist i figur 2 ovenfor). Begge minearbejdere peger på pool.supportXMR:7777 (gennemsnitlig pingtid =15ms).

CastXMR-resultater

CastXMR kørte i omkring 30 minutter, før jeg spurgte webgrænsefladen og fangede figur 3:

Figur 3:CastXMR havde en effektiv Moreno Hash Rate på 9498 t/s, når der blev taget højde for tabte aktier

Så CastXMR viser en indledende gennemsnitshastighed på 9809 t/s men med 3,2 % af dets aktier afvist og et udviklingsgebyr på 1,5 %, er den resulterende effektive hash-rate 9809 x 96,8 % x 98,5 % =9353,7 t/s udbytte
Bemærk: Selvom webgrænsefladen ikke giver årsagen til afvisning ud over, "num_outdated", gør observation af den tidligere kørsel (Figur 2 ovenfor) det sandsynligt, at aktierne blev afvist på grund af:"Forældet på grund af jobskifte". Selvom dette kan virke som et puljeproblem i forhold til et minearbejdersoftwareproblem, er faktum, at jeg rutinemæssigt bruger xmr-stak med supportxmr og får ingen sådanne afvisninger... men de opstår hver gang jeg kører cast_xmr. Jeg konkluderer, at det dermed kan tilskrives softwarejobhåndteringen, og da jeg ikke kender til nogen knapper, kan jeg dreje w.r.t. til dette problem, skal jeg bare rumme det i sammenligningen via en "effektiv hash-rate".

XMR-Stak-resultater:

Xmr-stak kørte i omkring 30 minutter, før jeg spurgte webgrænsefladen og fangede figur 4 og 5:

Figur 4:XMR-stak havde en effektiv Monero Hash Rate på 9734 h/s, når der blev taget højde for tabte aktier
Figur 5:XMR-stak havde ingen tabte aktier under den 30 minutters minesession

Så XMR-stak har en startgennemsnitshastighed på 9734,7 t/s men med 100 % udbytte forbliver den effektive hash-rate det fulde udbytte på 9734,7 h/s. XMR-Stak kommer med et standardudviklingsgebyr på 2 %, så det effektive udbytte reduceres til9540 t/s .

Konklusion

Det har vist sig, at hash-hastighedsværdierne vist på vandfaldet af tal på CastXMR-skærmen skal ignoreres til fordel for CastXMR-rapporterede gennemsnit.

XMR-stak rapporterer en gennemsnitlig hash-rate, der er 99,2% af den CastXMR-rapporterede hash-rate (ca. 15 h/s pr. Vega). Men når man sammenligner det effektive afkast efter at have taget højde for tabte aktier og forskelle i udviklingsgebyrer, er XMR-stak-afkastet 2 % bedre end CastXMR. Det er en forbedring på ca. 185 t/s til fordel for XMR-stak (netværk ca. 35 t/s pr. Vega).

Udholdenhedstest

Jeg var bekymret for, at mine korte testperioder måske havde stillet CastXMR i et uretfærdigt lys, så jeg kørte en udvidet 8-timers test for at se, om antallet af "Forældede" aktier ville falde ud. Desværre forblev udbyttet ens (lidt dårligere).

Der var indsendt 1082 aktier i den forlængede testperiode, og figur 6 viser, at 41 aktier blev afvist som "forældede" (3,9 % spild). CastXMR så ud til at have et gennemsnit på 9813,8 t/s, men når der først er taget højde for tabte aktier og udviklingsgebyr, falder det effektive udbytte til 9289,6 t/s…. det korrigerede udbytte viser, at stak-xmr endnu en gang slog CastXMR. Marginen på 2,7 % til fordel for stak-xmr resulterer i ikke-trivielle 250 t/s på mit 5 Vega-system... ~50 t/s pr. Vega.

Figur 6:CastXMR mistede 3,9 % af sin indsats til "forældede" aktier under den 8,3 timers udholdenhedstest

Det er nok værd at nævne igen, hvad jeg sagde på forhånd... Jeg anbefaler, at du ser dette indlæg som en guide til den metode, du kan bruge til at lave en præstationsvurdering for netop din rig . Hver rig er forskellig. Analysen var en diskussion af min metode og mine tal... YMMV.

Tak til alle, der holdt fast med dette talfyldte analytiske indlæg helt til bunden. Ikke ligefrem en pageturner, men forhåbentlig fandt du det retfærdigt, objektivt og nyttigt. Du er velkommen til at give dette videre til alle, der diskuterer fordele og ulemper ved de forskellige minesoftware!


Minedrift
  1. Blockchain
  2. Bitcoin
  3. Ethereum
  4. Digital valutaveksling
  5. Minedrift