Ik veronderstel dat elke goede Rx Vega-mijngids de prominente Vega-mijnsoftware-opties objectief moet bespreken en evalueren .... die beide een trouwe aanhang hebben binnen de Vega Mining-gemeenschap. Dit zal een eerlijke en objectieve beoordeling opleveren. Daar gaan we!
(Opmerking:ik weet niet wie de winnaar zal zijn terwijl ik deze intro schrijf ... Laten we eens kijken hoe dit uitpakt)

De kanshebbers

In Hoek #1 – CastXMR ver 0.7 (Opmerking:ver 0.8.1 is nu uit, onzeker over prestatiedelta)
De zelfverklaarde "Snelste miner voor AMD Radeon RX Vega GPU-serie". CastXMR is closed source software en heeft een ontwikkelvergoeding van 1,5%.

In Hoek #2 – XMR-STAK versie 2.0.0. (Opmerking:versie 2.2.0 is nu uit, +40h/s op 64's)
XMR-STAK heeft geen speciale interne afstemming voor Vega GPU's ingebakken, maar biedt opties voor configuratiebestanden die zelfafstemming mogelijk maken. Sommige dual-thread-configuraties zijn vrij standaard geworden zodanig dat ik denk dat het redelijk is om het "Vega-tuned" te noemen vanuit het perspectief van deze vergelijking. XMR-Stak is open source en heeft een standaard ontwikkelvergoeding van 2% (0,5% hoger).

Discussie over vooringenomenheid:

Hier zijn de feiten over mijn vooringenomenheid die hierop ingaan ... Ik heb met beide programma's geploeterd toen ik mijn mijnwerker voor het eerst instelde. Ik denk dat de meesten het erover eens zijn dat CastXMR een beetje noob-vriendelijker is omdat het startcommando een enkele regel is en de afstemming in de software is ingebouwd. Ik was een noob die ook bereid was om te tweaken, dus mijn eerste focus lag voornamelijk op functies en prestaties. Mijn eerste resultaten gaven een triviaal klein prestatievoordeel voor xmr-stak, maar de echte tiebreaker voor mij was de webinterface. Ik had aanvankelijk te maken met wat hash-drop-problemen met beide programma's en waardeerde xmr-stak, waardoor ik snel de miner-status op mijn telefoon kon controleren .... je zou het een verslaving kunnen noemen :-). Hoe dan ook, zoals velen van jullie weten, zijn er, naast het feit dat hasj drop voor mij nu een zeldzamere gebeurtenis is, twee grote veranderingen geweest sinds die "vroege" dagen:

1. JJs_HashMonitor maakt de occasionele Vega-hashdrop ongelijkmatig. Het hebben van een goed geformatteerde webinterface is minder belangrijk omdat de monitor zelf hash-drop detecteert en de miners op volle snelheid reset. Geweldig! (Ik hoop dat jullie allemaal JJ hebben getipt voor het opslaan van uw hashes!).
2. CastXMR nieuwe 11/29e release heeft een mogelijkheid voor bewaking op afstand toegevoegd (Woot!). Hoewel JJs_HashMonitor nog niet is geconfigureerd om CastXMR te ondersteunen ... dat is gewoon een splitsing en daarom ben ik bereid om het als een bestaande mogelijkheid te gebruiken voor deze vergelijking.

Ik heb geen gevestigde interesse in beide software, dus het is redelijk om dit een eerlijke beoordeling te noemen, want gezien (1) en (2) hierboven, weet ik niet wat mijn motivatie zou zijn voor vooringenomenheid. Net als iedereen probeer ik gewoon de meest effectieve software voor mijn installatie te vinden.

Voordat ik verder ga, wil ik ook zeggen dat ik u aanraad dit bericht te bekijken als een gids voor een methode die u kunt gebruiken om een ​​prestatiebeoordeling te maken voor uw specifieke rig . Elk tuig is anders. De onderstaande analyse zal mijn methode en mijn cijfers bespreken ... Het zal stoppen met het doen van aanbevelingen, want zoals altijd ... YMMV.

Bespreking van door CastXMR gerapporteerde waarden:

Ik moet beginnen met een discussie over een aantal onregelmatigheden met betrekking tot de hash-snelheidswaterval die over het CastXMR-scherm schuift. De onderstaande cijfers zijn van een Monero-mijnsessie die om 21:55 uur begon. Ik liet het programma ongeveer 15 minuten onbelemmerd draaien om er zeker van te zijn dat alles goed geregeld was en nam toen een schermopname.

Als het draait, worden er behoorlijk mooie cijfers weergegeven die duidelijk bijdragen aan de gloeiende reputatie van CastXMR. Mijn Vega 64 (die geen monitor bedient) is GPU 0 die, in afbeelding 1, de nummers 2020.9, 2018.6, 2012.9, 2013.5 en 2013.1 h/s laat zien.

2020 h/s komt definitief naar voren als indrukwekkend gezien de stabiele 2002 h/s die ik zie wanneer ik Monero min met xmr-stak. Het gemiddelde van die cijfers is iets lager in 2015.8h/s, maar nog steeds indrukwekkend. Scoor er één voor CastXMR... maar wacht... Het probleem komt in de volgende figuur. Wanneer u "s" typt om een ​​hash-rapport van castXMR te krijgen, krijgt u het volgende:

De gemiddelde hash-snelheid voor GPU 0 als 1994,6?!?!. Hoe kan dat, want ik heb het scherm voorbij zien komen en er was geen enkel moment dat de GPU0-waarde lager was dan 1994,6 h/s, laat staan ​​laag genoeg om te koppelen met een 2020.9 h/s om een ​​gemiddelde van 1994,6 h te creëren /s. Dat gemiddelde (1994.6) is een volle 20u/s lager dan het gemiddelde dat we berekenden uit figuur 1 (2015.8). Nieuwsgierig. Misschien nog raadselachtiger is dat het direct na dat samenvattende rapport meteen teruggaat naar het weergeven van oogverblindende cijfers zoals 2029,4 h/s. Xmr-stak en het is 2002 h/s kan niet concurreren met 2029,4 h/s... maar is vrij gunstig vergeleken met 1994,6 h/s. Welke is het?

Bedenk dat het gemiddelde van 5 GPU's, berekend vanaf de onderkant van figuur 2, (2029,4+1930.0+1931.0+1944.7+1958,5)/5 =1958,7 h/s is. Daarentegen is het gemiddelde gerapporteerd in het cyaan "aandeel geaccepteerd rapport" net daarboven een meer bescheiden 1935,1 h/s. Ik weet echt niet wat ik met de niet-gemiddelde cijfers moet, dus ik negeer ze ...

De bovenstaande cijfers zijn niet uit de lucht gegrepen... Dit zijn typerend voor de castXMR-prestaties op mijn machine en het laat me een beetje achter mijn hoofd krabben. Ik vermoed hier geen kwaad opzet. Ik vermoed dat het aantal afkomstig is uit een echte berekening, maar mogelijk niet de waarde vertegenwoordigt waarvan we aannemen dat ze zijn. Misschien laten ze de absoluut snelste hash zien die is berekend over het weergave-interval ... en is het gemiddelde "s" de echte gemiddelde hash-snelheid over een bepaalde tijdsperiode? Het is echt moeilijk om te weten, maar één ding is zeker... castXMR heeft de reputatie "snel" te zijn. Het kan in feite sneller zijn ... we zullen het pas weten als we aan het einde van dit bericht zijn gekomen, maar hoe dan ook, het is niet ZO SNEL als de reputatie die is ontwikkeld door het nummer dat over het scherm rolt, doet vermoeden. Focus op de gemiddelde waarden die worden weergegeven in het samenvattende rapport ("s") en in het periodieke rapport dat optreedt wanneer een "geaccepteerd aandeel" wordt gerapporteerd.

Oké, laten we er nu aan beginnen...

Het speelveld

Ik heb 5 Vegas. Twee Vega 64's en 3 Vega 56's. De ene Vega 64 (GPU 3 / Thread 6&7) bedient een HDMI-dongle, dus de prestaties komen niet overeen met die van de andere Vega 64 (GPU 0 / Thread 0/1). De Vega Miner is ingesteld als gepubliceerde gids met de drie uitzonderingen / verduidelijkingen die volgen:

• Het grootste deel van de gids is geschreven toen mijn mijnwerker 4 Vega's en 1 Nvidia GTX 750 had. Ik leg in de gids uit dat ik een andere Rx Vega 56 heb gekocht om de GTX-750 te vervangen... en dat ik heb toegevoegd wat ik heb geleerd van die ervaring tot de gids. Sommigen van jullie hebben het sindsdien misschien niet meer gelezen, dus ik wilde het voor de duidelijkheid herhalen.
• In de gids (en bij het minen in het echte leven) doe ik CPU-mining parallel met Vega Mining. Omdat CastXMR niet met een CPU-miner wordt geleverd, heb ik tijdens deze tests geen xmr-stak-mining met de CPU (het bleek geen verschil te maken, maar ik wist het niet zeker)
• In de gids raad ik aan dat mensen met monitoren/dongles die zijn aangesloten op Vega's voor het minen, een intensiteit van 1800 op beide threads van die specifieke Vega gebruiken om stabiliteit te krijgen... en van daaruit te werken (vs. mijn standaard 1932/1932) . Mijn systeem-GPU3 is een Rx Vega 64 die mijn HDMI-dongle bedient en het is stabiel met intensiteiten van 1908 en 1800. Dat zijn de waarden die je op GPU 3 (threads 6+7) zult zien wanneer xmr-stak aan het minen is.

Testprocedure:

1. Start de computer opnieuw op.
2. Aangemeld via Chrome Remote Desktop
3. Start JJ's Hash Monitor zodat mijn Vega's opnieuw worden opgestart en mijn OverdriveNTool-parameters worden toegepast (nogmaals, de exacte parameters uit de gids)
4. Gesloten JJs_HashMonitor en bijbehorende mijnwerker
5. Geopende Windows-bestandsmanager
6. Dubbelklik op het cmd-bestand dat de mijnwerker de opdrachten stuurt die nodig zijn om te starten
   • cast_xmr bevatte de vlag –remoteaccess
   • xmr-stak bevatte de vlag –noCPU en –noNVIDIA
7. Zodra een mijnwerker was gestart, sloot ik de Windows-bestandsmanager, dus het enige geopende venster was het mijnwerkervenster en niets anders.
8. Ik heb de Chrome Remote Desktop-sessie beëindigd
9. Ik heb alle waarden van een aparte computer in mijn netwerk gehaald via de webinterface
   • Merk op dat castXMR de waarden niet in een mooi webformaat weergeeft, maar de gegevens zijn er allemaal en zijn toegankelijk, dus het leek de beste manier om 'headless computer'-prestaties te krijgen.

Wat ik niet heb gedaan:Ik heb JJs Hash Monitor niet gebruikt tijdens de test (omdat ik de Vega's tussen de tests niet wilde resetten. Ik heb de Vega's dus niet gereset tussen de twee Monero-miningsessies in. Ik heb me niet opnieuw aangemeld OverdriveNTool-parameters tussen de twee sessies.

Resultaten

Het officiële resultaat is gebaseerd op de gemiddelde effectieve hash-snelheid. De effectieve hash-snelheid wordt berekend door de door de mining-software gerapporteerde gemiddelde hash-snelheid te nemen en deze te verlagen met het percentage afgewezen aandelen. (Bijvoorbeeld, voor de 20 minuten durende run die wordt weergegeven in figuur 2 hierboven, rapporteerde CastXMR een opbrengst van 95%). Beide miners zijn gericht op pool.supportXMR:7777 (ping-tijdgemiddelde =15ms).

CastXMR-resultaten

CastXMR liep ongeveer 30 minuten voordat ik de webinterface opvroeg en Afbeelding 3 vastlegde:

CastXMR geeft dus een initiële gemiddelde snelheid van 9809 h/s maar met 3,2% van zijn aandelen afgewezen en 1,5% ontwikkelingskosten, is de resulterende effectieve hash-snelheid 9809 x 96,8% x 98,5% =9353,7 h/s opbrengst
Opmerking: Hoewel de webinterface de reden voor afwijzing verder niet geeft, "num_outdated", maakt observatie van de vorige run (Figuur 2 hierboven) het waarschijnlijk dat de shares zijn afgewezen voor:"Verouderd vanwege wijziging van taak". Hoewel dit misschien een poolprobleem lijkt versus een mijnwerkersoftwareprobleem, is het een feit dat ik routinematig xmr-stak gebruik met supportxmr en dergelijke afwijzingen niet krijg ... maar ze komen elke keer voor als ik cast_xmr uitvoer. Ik concludeer dat het dus te wijten is aan de softwarematige taakafhandeling en aangezien ik geen knoppen ken, kan ik er aan draaien. wat dit probleem betreft, moet ik het gewoon in de vergelijking opnemen via een "effectieve hash-snelheid".

XMR-Stak-resultaten:

Xmr-stak liep ongeveer 30 minuten voordat ik de webinterface opvroeg en Afbeelding 4 en 5 vastlegde:

Dus, XMR-stak heeft een initiële gemiddelde snelheid van 9734,7 h/s maar met 100% opbrengst blijft de effectieve hash-snelheid de volledige opbrengst van 9734,7 h/s. XMR-Stak wordt geleverd met een standaard ontwikkelvergoeding van 2%, zodat de effectieve opbrengst daalt tot 9540 h/s .

Conclusie

Het is aangetoond dat de hash-snelheidswaarden die worden weergegeven op de waterval van getallen in het CastXMR-scherm moeten worden genegeerd ten gunste van door CastXMR gerapporteerde gemiddelden.

XMR-stak rapporteert een gemiddelde hash-snelheid die 99,2% is van de door CastXMR gerapporteerde hash-snelheid (ongeveer 15 h/s per Vega). Wanneer echter het effectieve rendement wordt vergeleken, nadat rekening is gehouden met verloren aandelen en verschillen in ontwikkelingskosten, is het XMR-stak-rendement 2% beter dan CastXMR. Dat is een verbetering van ongeveer 185 h/s ten gunste van XMR-stak (netto ongeveer 35 h/s per Vega).

Duurtest

Ik was bezorgd dat mijn korte testperiodes CastXMR misschien in een oneerlijk daglicht hadden gezet, dus ik deed een uitgebreide test van 8 uur om te zien of het aantal "verouderde" aandelen zou stabiliseren. Helaas bleef de opbrengst gelijk (iets slechter).

Er waren 1082 aandelen ingediend tijdens de verlengde testperiode en figuur 6 laat zien dat 41 aandelen werden afgewezen als "verouderd" (3,9% afval). CastXMR leek gemiddeld 9813,8 h/s te zijn, maar als rekening wordt gehouden met verloren aandelen en ontwikkelingskosten, daalt de effectieve opbrengst tot 9289,6 h/s.... de gecorrigeerde opbrengst laat zien dat stak-xmr wederom CastXMR versloeg. De marge van 2,7% ten gunste van stak-xmr resulteert in een niet-triviale 250 h/s op mijn 5 Vega-systeem... ~50 h/s per Vega.

Afbeelding 6:CastXMR verloor 3,9% van zijn inspanningen om "verouderde" aandelen te krijgen tijdens de 8,3 uur durende duurtest

Het is waarschijnlijk de moeite waard om nog eens te vermelden wat ik van tevoren heb gezegd ... Ik raad je aan dit bericht te bekijken als een gids over de methode die je kunt gebruiken om een ​​prestatiebeoordeling te maken voor jouw specifieke installatie . Elk tuig is anders. De analyse was een bespreking van mijn methode en mijn cijfers... YMMV.

Bedankt aan iedereen die vasthield aan dit aantal gevulde analytische bericht helemaal tot op de bodem. Niet bepaald een pageturner, maar hopelijk vond je het eerlijk, objectief en nuttig. Aarzel niet om dit door te geven aan iedereen die de voor- en nadelen van de verschillende mijnbouwsoftware bespreekt!