Kryptomining mit AMD-Prozessoren – ein How-To für Interessierte

Optimierungen und zur Hardware passende Coins

Ein genaue­rer Blick lohnt sich jedoch auf die Aus­ga­be von xmrig. Grün ist gut, rot und gelb sind schlecht. Wir sehen z.B. dass sich xmrig freut, Huge-Pages- und AES-Sup­port ent­deckt zu haben (1 GB Pages gibt’s nur unter Linux), dass mit dem kor­rek­ten Pool über den Port Kon­takt auf­ge­nom­men wird, den wir vor­her ein­ge­stellt haben, aber auch ein paar War­nun­gen. So sehen wir z.B. dass xmrig zwar Lar­ge-/Hu­ge-Pages nut­zen kann, aber nur 11% des Spei­cher­be­reichs auf die­se schnel­le Art und Wei­se gesperrt wer­den konn­ten. Meist pas­siert das, wenn der PC schon eine Wei­le lief und der Arbeits­spei­cher ent­spre­chend frag­men­tiert ist. Ein Neu­start behebt das Pro­blem meist.

Ein ande­rer Hin­weis betrifft einen MSR-Mod, den die Soft­ware nicht set­zen konn­te. xmrig ist ein hoch­op­ti­mier­ter Miner. Des­sen Ent­wick­ler hat sich dem Umstand ange­nom­men, dass die Hard­ware-Pre­fet­cher moder­ner CPUs in ihrem Über­ei­fer kon­tra­pro­duk­tiv sind für das Mining mit Ran­domX. Daher wür­de xmrig ger­ne, sofern die Soft­ware das CPU-Modell kennt, einen MSR-Mod anwen­den, um die Hard­ware-Pre­fet­cher zu deak­ti­vie­ren. Das geht aber nur, wenn der Miner mit “Rechts­klick / Als Admi­nis­tra­tor aus­füh­ren” gestar­tet wur­de, da ihm sonst die Rech­te dazu fehlen.

Im Ide­al­fall sieht das dann so aus:

Alles grün und wie man sieht ist die Hash­ra­te nun auch ent­spre­chend höher. Dass Open­CL und CUDA rot sind, inter­es­siert uns an die­ser Stel­le nicht, da Ran­domX ein rei­ner CPU-Algo­rith­mus ist, der zwar auch mit Gra­fik­kar­ten geschürft wer­den könn­te, aber nur sehr inef­fi­zi­ent. Sprich: Gra­fik­kar­ten lässt man in jedem Fall auf einen ande­ren Algo­rith­mus los als RandomX!

Nun kön­nen wir den Miner lau­fen las­sen und auf der Pool-Web­sei­te beob­ach­ten was dort so alles geschieht. Sobald der Pool einen Block gefun­den hat, wird das ange­zeigt und der eige­ne Anteil erscheint im Kas­ten “Pen­ding Rewards”. Sobald sicher­ge­stellt ist nach einer Wei­le, dass der Block vali­de ist, wird der Betrag gut­ge­schrie­ben auf “Con­firm­ed Balan­ce”. Aller­dings zah­len die Pools nicht jeden Kleinst­be­trag sofort auf die Wal­let-Adres­se aus, son­dern erst wenn ein bestimm­ter Min­dest­wert erreicht wur­de. Das unter­schei­det sich von Pool zu Pool. Bei Hash­v­ault ist das sog. Min Pay­out Limit bei Mone­ro 0,001 XMR. Erst wenn man die­sen Wert erreicht hat, wird ausbezahlt.

Wel­cher Coin?
Für unser ers­tes Bei­spiel haben wir Mone­ro ver­wen­det. Aber nicht jede Hard­ware eig­net sich gleich gut für jeden Coin. Wie wir schon geschil­dert haben, ver­wen­det der Ran­domX-Algo von Mone­ro eine Scratch­pad-Grö­ße von 2 MB je Thread. Das ist bei einem Ryzen 7 2700 gut um 8 Threads gleich­zei­tig lau­fen zu las­sen. Ide­al ist es aber nicht, da die CPU ja dank SMT 16 Threads star­ten könn­te. Dafür jedoch ist der Last-Level-Cache mit 16 MB zu klein. Da sieht es beim Nach­fol­ger Ryzen 7 3700X bes­ser aus. Der hat 32 MB Last-Level Cache, also per­fekt, um in Mone­ro alle zur Ver­fü­gung ste­hen­den Res­sour­cen zu nut­zen. Daher (und auf­grund der Archi­tek­tur-Ver­bes­se­run­gen von Zen 2 gegen­über Zen 1) ist der Ryzen 7 3700X mit ca. 8.000 H/s trotz glei­cher Kern­an­zahl deut­lich schnel­ler als der Ryzen 7 2700 mit ca. 5.000 H/s.

Ande­res, extre­mes Bei­spiel: ein AMD Bris­tol Ridge hat gar kei­nen L3-Cache und der L2-Cache, der hier den Last-Level-Cache bil­det, ist ledig­lich 1 MB je Modul groß. Es passt also nicht mal das Scratch­pad eines ein­zel­nen Threads in den Cache, daher ist Mone­ro für einen Bris­tol Ridge gänz­lich unge­eig­net. Der Algo­rith­mus muss zur Hard­ware pas­sen. xmrig lis­tet auf der Web­sei­te detail­liert auf, wel­cher Algo­rith­mus wel­che Scratch­pad-Grö­ße verwendet:

Was hier als Memo­ry bezeich­net wird, ist die Scratch­pad-Grö­ße je Thread. Um am Bei­spiel AMD Bris­tol Ridge zu blei­ben, müss­ten wir also einen Algo­rith­mus wäh­len, der höchs­tens 1 MB je Thread ver­wen­det, damit wenigs­tens das Scratch­pad eines Threads je Modul in den Cache passt. rx/wow wäre so ein Algo­rith­mus, den der Coin Wow­ne­ro ver­wen­det. Auf der oben bereits ver­link­ten Web­sei­te Mining­Pool­Stats kann man nach­schla­gen, wel­cher Coin wel­chen Algo verwendet.

Wer sich nicht sicher ist, wie­viel Cache die eige­ne CPU besitzt, kann das Tool CPU‑Z konsultieren:

Ent­schei­dend ist die letz­te Cache-Stu­fe, hier 2x 8 MB, genug also, um acht Mone­ro-Threads zu star­ten. Bei einem AMD A8-9600 “Bris­tol Ridge” z.B. wäre der L2-Cache die letz­te Cache­stu­fe. Hier wür­de 2x 1 MB stehen.

Doch wie kann man ande­re Coins minen? Im Ide­al­fall – und des­we­gen haben wir als Bei­spiel Hash­V­ault ver­wen­det – betreibt der Pool sei­ner Wahl neben Mone­ro noch ande­re Coins, hier wie man sieht eine gan­ze Rei­he von Alter­na­ti­ven, ohne dass man sich in Sachen Look&Feel umge­wöh­nen müsste.

Man wählt also statt den Mone­ro-Bereich den gewünsch­ten ande­ren. Alles wei­te­re erfolgt äqui­va­lent zur Anlei­tung oben. Wal­let des gewünsch­ten Coins her­un­ter­la­den, die Mining-Soft­ware xmrig haben wir bereits, im Get­ting-Star­ted-Bereich des Pools die rele­van­ten Anga­ben machen und die Pool-Sek­ti­on der Kon­fi­gu­ra­ti­ons­da­tei in die config.json-Datei kopieren.

Wich­tig ist, dass man die Daten nicht durch­ein­an­der bringt. Wenn man z.B. Wow­ne­ro minen möch­te und die Pool-Anga­ben ent­spre­chend gemacht hat, muss man auch eine Wow­ne­ro-Wal­let-Adres­se ange­ben. Man kann also nicht Wow­ne­ro minen wol­len und eine Mone­ro- oder gar Bit­co­in-Adres­se ange­ben, in dem Glau­ben, man wür­de dann Mone­ro oder Bit­co­ins aus­be­zahlt bekom­men. Wer Wow­ne­ro minen möch­te, muss hier auch eine Wow­ne­ro-Wal­let-Adres­se ange­ben, damit der Betrag aus­be­zahlt wer­den kann sobald er die Min-Pay­out-Schwel­le über­schrit­ten hat.