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

Artikel-Index:

Weitere praktische Parameter

Fein­tu­ning
Bis­her haben wir die config.json so hin­ge­nom­men wie xmrig sie beim ers­ten Start pas­send zur Hard­ware ange­legt hat. Aller­dings birgt sie auf­grund des Umfangs noch viel Raum für Opti­mie­rungs­mög­lich­kei­ten. Daher ein paar Beispiele:

Grund­le­gend kann man erst­mal unter “back­ground” ein­stel­len, ob die Soft­ware im Vor­der­grund sicht­bar im Fens­ter arbei­ten soll oder head­less ohne Fens­ter wenn man es nicht dau­ernd im Weg haben möch­te. “colors” stellt ein, ob man, wie schon gese­hen die Mel­dun­gen far­big haben möch­te, um die Wich­tig­keit schnel­ler erfas­sen zu kön­nen oder nur in Weiß auf Schwarz. Mit “rdmsr” kann man ent­schei­den, ob die erwähn­ten MSR-Mods zur Leis­tungs­stei­ge­rung ange­wen­det wer­den sol­len, mit “wrmsr”, ob sie beim Been­den des Miners wie­der rück­gän­gig gemacht wer­den sol­len oder nicht.

Inter­es­sant ist auch der Para­me­ter “prio­ri­ty”. Stan­dard­mä­ßig läuft xmrig mit Pro­zess-Prio­ri­tät Nor­mal. Wer neben­her an dem PC arbei­tet, auf dem die Mining­soft­ware läuft, wird so jedoch bemer­ken, dass der PC nicht mehr so flink reagiert wie sonst. In die­sem Fall ist hier statt null die Zahl 0 zu set­zen. Dann läuft xmrig mit nied­rigs­ter Prio­ri­tät. Wenn man den PC in Ruhe lässt, ist das nicht lang­sa­mer als Prio­ri­tät Nor­mal. Der Vor­teil ist aber, dass der PC wesent­lich flin­ker auf Benut­zer­ein­ga­ben reagiert, da xmrig in die­sem Fall zurück­ste­cken muss.

Eine Spiel­wie­se sind auch die Kern-Nut­zungs­ein­stel­lun­gen für die jewei­li­gen Algo­rith­men. So sehen wir z.B. beim Algo “Argon2”, dass die Soft­ware die Kon­fi­gu­ra­ti­on so gesetzt hat, dass fix die Ker­ne 0, 1, 2, … durch­ge­hend bis 15 genutzt wer­den. Hier kann man z.B. einen oder zwei Ein­trä­ge ent­fer­nen, sodass nicht alle 16 Ker­ne der CPU ver­wen­det wer­den, son­dern z.B. nur 14. Auch das ver­bes­sert die Respon­si­vi­tät der Maschi­ne wenn man gleich­zei­tig damit arbei­tet, bei womög­lich ver­nach­läs­sig­ba­rer Reduk­ti­on der Hash­ra­te. Da lohnt es sich ein wenig zu tüf­teln. Alter­na­tiv kann man statt den zu nut­zen­den Ker­nen 0, 1, 2, … auch ‑1, ‑1, ‑1, … schrei­ben. Wenn man das 16 Mal ein­trägt, wer­den auch 16 Threads gestar­tet, aller­dings darf dann der Sche­du­ler des Betriebs­sys­tems ent­schei­den, wo wel­cher Thread abge­ar­bei­tet wird. In Sachen Ver­schleiß ist das u.U. rele­vant bei jah­re­lan­ger Dauernutzung.

Prak­tisch sind auch zwei Para­me­ter ganz unten in der config.json:

pau­se-on-bat­tery” bestimmt, ob der Miner pau­sie­ren soll sobald das Gerät vom Strom getrennt wird. Das ist sinn­voll bei Lap­tops, damit einem unter­wegs nicht der Akku aus­geht wenn man ver­ges­sen hat den Miner zu been­den, eben­so wie bei Ser­vern mit USV. Auch hier ergibt es Sinn, den Miner pau­sie­ren zu las­sen wenn Strom aus­fällt, damit die USV lang genug durch­hält bis der Strom wie­der da ist.

pau­se-on-acti­ve” kennt man auch vom BOINC-Cli­ent. Hier pau­siert der Miner, wenn eine Maus- oder Tas­ta­tur­ein­ga­be erkannt wird, der User also gera­de arbei­tet an dem PC. Setzt man hier statt fal­se z.B. die Zahl 10, wird der Miner pau­siert bei Benut­zer-Ein­ga­ben und erst 10 Sekun­den, nach­dem letzt­mals eine Ein­ga­be erkannt wur­de, wie­der weitergerechnet.

Es soll­te auch selbst­ver­ständ­lich sein, dass man so einen Coin-Miner nicht blind auf sei­ne Hard­ware los­lässt. Vie­le Gerä­te sind gar nicht dafür aus­ge­legt, unter Dau­er­voll­last zu lau­fen, wie etwa Detach­a­bles oder Ein­stei­ger-Lap­tops, aber auch Bil­lig-PCs von der Stan­ge. So soll­te man wenigs­tens sicher­stel­len, dass die Tem­pe­ra­tu­ren im grü­nen Bereich sind und es auch blei­ben. Dazu kann das Tool HWMo­ni­tor ver­wen­det werden.