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)
In Hoek #1 – 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 – 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 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).
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:
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.
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...
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 met de drie uitzonderingen / verduidelijkingen die volgen:
Testprocedure:
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.
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 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 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 .
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).
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!
