Hashrate Mining Hardware – Monero, Sumokoin, Electroneum, Intense, B2B

[tomturbo]

i7-2600 CPU @ 3.40GHz - DDR3 1333 - linux - huge pages - xmr-stak-cpu - 4T - highest: 220,3 H/s

 

[tomturbo]

Hey tom 83 H/s scheint mir etwas wenig für einen Quad-Core-Trinity/Richland. Ich hab den A8-5600K hier mit beinahe gleichen Eckdaten als Vergleich, der hasht über 150 H/s weg Wie hast Du denn den Miner konfiguriert (Anzahl der Threads)? Nimm doch probehalber mal den hier und konfiguriere ihn auf 2 Threads falls die Auto-Erkennung das nicht eh macht, damit die Daten in den L2-Cache passen. Dann sollte mehr gehen als 83 H/s

Hm, werde mal mit 2 Threads probieren. Und danach evt mit xmrig.

 

[tomturbo]

Also die Reduktion auf 2T beim A8-6500 brachte tatsächlich eine Steigerung auf nunmehr 132,7 H/s
Danke für den Tipp Nero24.!

Ich sah schon dass, sich die Hashrate durch steigern der Memory-Frequenz steigern lässt, aber auf den L2 habe ich garnicht gedacht.

Evt. ist ein i7 auch mit 2 statt 4 Threads schneller.
Werde das mal testen.

 

[Nero24]

Evt. ist ein i7 auch mit 2 statt 4 Threads schneller.

Wahrscheinlich nicht. Man rechnet beim Cryptonight-Algo mit 2 MB Daten je Thread. Der i7 hat einen 8 MB großen Last-Level-Cache. Da passen genau 4 Threads rein

Ein Sonderfall ist der AMD FX. Der hat 4x 2 MB L2-Cache und 1x 8 MB L3-Cache. Man kann ihn also mit 4 Threads konfigurieren, dann läuft alles weitestgehend im schnellen L2-Cache und man hat immer noch 4 Threads übrig zum arbeiten. Oder man konfiguriert ihn mit 8 Threads, um L2 und L3 gleichermaßen zu füllen. Das geht beim FX (im Gegensatz zu den Intel-CPUs), da der L3-Cache hier ein Victim-Cache ist, also nur Elemente enthält, die nicht mehr im L2 liegen. Man darf die Cachegrößen also gedanklich addieren. Allerdings ist der Leistungszuwachs unter Nutzung von 8T beim FX trotz doppelter Threadanzahl nur ca. +25%, denn der L3 ist natürlich deutlich langsamer als der L2.

 

[tomturbo]

Ganz schafft der i7 2600 nicht die volle Steigerung, denn es ist ja noch etwas anderes zu tun auf der Workstation wo ich arbeite.
2T:139 H/s 4T:220 H/2

Einen 8320e kann ich noch probieren. Was ich im Kopf hatte mit 8T kam er auf 300-400 H/s.
Die genaue Zahl hab ich nicht, da er momentan nicht läuft und sie nur aus dem Gedächtnis ist.

 

[Nero24]

Einen 8320e kann ich noch probieren. Was ich im Kopf hatte mit 8T kam er auf 300-400 H/s.
Die genaue Zahl hab ich nicht, da er momentan nicht läuft und sie nur aus dem Gedächtnis ist.

Mach Dir keine Umstände, wir haben ja schon einige Visheras in der Liste

 

[WindHund]

Wahrscheinlich nicht. Man rechnet beim Cryptonight-Algo mit 2 MB Daten je Thread. Der i7 hat einen 8 MB großen Last-Level-Cache. Da passen genau 4 Threads rein

Ein Sonderfall ist der AMD FX. Der hat 4x 2 MB L2-Cache und 1x 8 MB L3-Cache. Man kann ihn also mit 4 Threads konfigurieren, dann läuft alles weitestgehend im schnellen L2-Cache und man hat immer noch 4 Threads übrig zum arbeiten. Oder man konfiguriert ihn mit 8 Threads, um L2 und L3 gleichermaßen zu füllen. Das geht beim FX (im Gegensatz zu den Intel-CPUs), da der L3-Cache hier ein Victim-Cache ist, also nur Elemente enthält, die nicht mehr im L2 liegen. Man darf die Cachegrößen also gedanklich addieren. Allerdings ist der Leistungszuwachs unter Nutzung von 8T beim FX trotz doppelter Threadanzahl nur ca. +25%, denn der L3 ist natürlich deutlich langsamer als der L2.

Ok, dann sind die 2600 MHz CPU-NB Takt bei meinem Ergebnis doch förderlich, um auf die 452 H/s zu kommen.
Beim Ryzen müsste der L3 Cache mit dem CPU Takt laufen, stimmt das?

 

[tomturbo]

So: Habe jetzt nochmal meinen FX 8320E gecheckt.

Also 8 Threads zahlen sich zumindest unter xmr-stak-cpu nicht wirklich aus.
Die Differenz liegt bei mir nur bei 14%

Hier mein Vergleich:
AMD FX-8320E @ Stock - DDR3 1866 - linux - huge pages - xmr-stak-cpu - 8T - highest: 335,2 H/s

AMD FX-8320E @ Stock - DDR3 1866 - linux - huge pages - xmr-stak-cpu - 4T - highest: 293,8 H/s

Allerdings ist es sehr wichtig die cpu affinity richtig zu setzen und zwar nicht wie bei HT CPUs von intel immer abwechselnd den Core zu nehmen sondern zuerst die ersten 2 Cores dann 2 frei lassen und danach wieder 2 Cores nehmen.

in der config.txt also:

"cpu_threads_conf" : 
[
    { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 0 },
    { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 1 },
    { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 4 },
    { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 5 },
],

Die Frage ist natürlich: Hat das etwas mit der Cache Organisation oder mit den CMT Clustern zu tun?

 

[Gast29012019_2]

Weil der 8 Kerner nur ein 4 Modul-Prozessor ist, ein kleiner aber feiner Unterschied zum Thuban 1090T vs FX 6300. Würdest du ein Ryzen drin haben, der ein echter 8 Kerner ist mit 16 Threads sehe es anders aus.

 

[Nero24]

Allerdings ist es sehr wichtig die cpu affinity richtig zu setzen und zwar nicht wie bei HT CPUs von intel immer abwechselnd den Core zu nehmen sondern zuerst die ersten 2 Cores dann 2 frei lassen und danach wieder 2 Cores nehmen.

Hm, war es nicht so, dass der Linux-Scheduler die Kerne anders zählt als der Windows-Scheduler? Aus der Anleitung von xmr-stak-cpu:

affine_to_cpu - This can be either false (no affinity), or the CPU core number. Note that on hyperthreading
* systems it is better to assign threads to physical cores. On Windows this usually means selecting
* even or odd numbered cpu numbers. For Linux it will be usually the lower CPU numbers, so for a 4
* physical core CPU you should select cpu numbers 0-3.

In Deinem Fall müsstest Du unter Linux die CPUs 0-3 oder aber die CPUs 4-7 nehmen sofern Linux den FX wie einen SMT-Prozessor behandelt so wie Windows es tut. Bei 0,1,4,5 hättest Du die Threads in den ersten beiden Clustern auf den "linken" INT-Kern gelegt und in den anderen beiden Clustern auf den "rechten". Auch nicht verkehrt, aber vermutlich unnötig kompliziert. 0,1,2,3 oder aber 4,5,6,7 sollte unter Linux die gleiche Leistung bringen während man unter Windows 0,2,4,6 (=die linken INT-Kerne der Cluster) oder aber 1,3,5,7 (=die rechten INT-Kerne der Cluster) nehmen müsste.

Die Frage ist natürlich: Hat das etwas mit der Cache Organisation oder mit den CMT Clustern zu tun?

Ich würde auf die Caches tippen. Beim FX teilen sich ja immer zwei INT-Kerne einen L2-Cache von 2 MB Größe. Daher ist es wichtig, dass in jedem L2-Cache nur ein Thread "läuft", weil ja wie gesagt die Datenpakete bei Cryptonight 2 MB groß sind.

 

[tomturbo]

Hm, war es nicht so, dass der Linux-Scheduler die Kerne anders zählt als der Windows-Scheduler? Aus der Anleitung von xmr-stak-cpu:In Deinem Fall müsstest Du unter Linux die CPUs 0-3 oder aber die CPUs 4-7 nehmen sofern Linux den FX wie einen SMT-Prozessor behandelt so wie Windows es tut. Bei 0,1,4,5 hättest Du die Threads in den ersten beiden Clustern auf den "linken" INT-Kern gelegt und in den anderen beiden Clustern auf den "rechten". Auch nicht verkehrt, aber vermutlich unnötig kompliziert. 0,1,2,3 oder aber 4,5,6,7 sollte unter Linux die gleiche Leistung bringen während man unter Windows 0,2,4,6 (=die linken INT-Kerne der Cluster) oder aber 1,3,5,7 (=die rechten INT-Kerne der Cluster) nehmen müsste.

Scheint nicht so zu sein, denn sobald ich einen thread in die ersten oder letzten 4 Cores verschiebe geht die Leistung pro Core von 73-74 auf 45 H/s zurück.

Ich würde auf die Caches tippen. Beim FX teilen sich ja immer zwei INT-Kerne einen L2-Cache von 2 MB Größe. Daher ist es wichtig, dass in jedem L2-Cache nur ein Thread "läuft", weil ja wie gesagt die Datenpakete bei Cryptonight 2 MB groß sind.

Allerdings ist es auch so, dass wenn ich nur 1 Thread pro 4er Gruppe laufen lasse ist dieser auch nicht schneller als wenn ich 2 Threads in einer 4er Gruppe laufen lasse.

Witzig das Ganze.

 

[Nero24]

Mal was anderes: Ich hab gestern einen Bristol Ridge mit Monero getestet, konkret einen AMD A8-9600 (Quad-Core Excavator, 3.1 GHz base, 3.4 GHz turbo). Der ist in dieser Disziplin ein deutlicher Rückschritt gegenüber dem Vorgänger Kaveri A8-7600 mit Steamroller-Kernen. Hier macht sich der von 2 MB auf 1 MB pro Modul reduzierte L2-Cache schmerzhaft bemerkbar; zu wenig für Cryptonight. Als Folge davon stürzt die Hashrate von 177 H/s (Kaveri) auf 43 H/s (Bristol Ridge) ab. Da die Daten so oder so nicht in den L2 passen, sind beim BR 4 Threads schneller als 2 Threads. Für Cryptonight-Währungen wie Monero ist Bristol Ridge daher völlig unbrauchbar.

Einziger Notnagel für diejenigen, die einen BR haben: wählt eine Währung mit Cryptonight-Lite Algorithmus, wie etwa AeonCoin. Dort ist der Datensatz je Thread nur 1 MB groß statt 2 MB, passt also gerade so in die L2s des BR. Allerdings muss man die Miner dafür zu ihrem Glück zwingen und manuell den richtigen Modus wählen. Für Aeon mit Bristol Ridge unter xmrig wäre das algo=cryptonight-lite, av=1 (nicht av=2, was der Miner automatisch wählt bei Aeon) und threads=2 (nicht 1).

@Gozu & Signus: ich hab Eure YenTen-Diskussion in ein eigenes Thema verschoben, da es ja gar nichts mit Monero oder dem zugrunde liegenden Cryptonight-Algo zu tun hat
http://www.planet3dnow.de/vbulletin/threads/429056-Anleitung-YenTen-Mining

 

[hoschi_tux]

Was die Baumaschinen nicht gewuppt bekommen, schafft Zen weg: https://www.computerbase.de/2018-02/mining-monero-cpu/
Eins für alles, oder so ähnlich..

Ulkig: ein 1600X ist schneller UND effizienter als eine GTX1060

Wenn da mal nicht noch für einige CPUs ein Engpass auf uns zukommt. Schließlich braucht man ja auch für jede GPU einen Unterbau. Und wenn der kräftig mit schürfen kann..

 

[Nero24]

Ulkig: ein 1600X ist schneller UND effizienter als eine GTX1060

Naja, der Vergleich hinkt denn mit einer NVIDIA-Grafikkarte schürft man auch nicht Monero oder andere Cryptonight-Coins. Jede Architektur hat ihre Stärken und Schwächen:

CPUs (mit AES-NI-Support und viel Cache) und AMD-Vega-GPU => Cryptonight basierende Coins wie Monero
CPUs (mit AES-NI-Support und wenig Cache) => Cryptonight-Lite basierende Coins wie AeonCoin
AMD GCN-GPUs => Ethereum
NVIDIA-GPU => Equihash basierende Coins wie ZCash oder Bitcoin Gold

 

[hoschi_tux]

Nur gut, dass es für jede Eigenart einer Architektur ein passendes Schürfgut gibt. Was würden wir sonst nur machen

 

[WindHund]

Hm, unter 600W* ETH bei 500 kH/S@7 CPU Threads only : http://abload.de/img/minergate_eth_syslsjuo.jpg
Oge, die zwei GPUs laufen mit jeweils 2 mH/S außer Konkurrenz...

*4,6 mH/S Insgesamt, bei 15 cent die kW/h ohne Grundgebühr...

 

[tm0975]

XMR 15000 H/s Ryzen 3950 @Eco-Modus + PC3200 CL14
XHV 1400 H/s Ryzen 3950 @Eco-Modus + PC3200 CL14

 

[Nero24]

XMR 15000 H/s Ryzen 3950 @Eco-Modus + PC3200 CL14
XHV 1400 H/s Ryzen 3950 @Eco-Modus + PC3200 CL14

Hm ja, das kann man leider nicht mehr vergleichen. Monero nutzte damals, als dieser Vergleichsthread entstand, noch Cryptonight als Algorithmus, inzwischen jedoch RandomX. Damit sind die Hashraten (bei CPUs) stark gestiegen. Du kannst aber gerne einen neuen Thread aufmachen für RandomX und Cryptonight/Haven

 

[Damocles]

ich dachte schon das ich mir das halbwegs gut durchgelesen hab, aber was ist xmr und xhv

 

[Dragonheart69]

Hallo zusammen, ich weiß jetzt nicht ob ich hier richtig bin.
Seit dem update von XMrig auf die neuste Version 6.12. will es bei mir nicht mehr starten. Ja ich habe alle Ausnahmen gesetzt sowohl im Defender als auch im Antivir.
XMrig startet zwar, bleibt dann aber hängen...

selbst die kurzkomandos lassen sich nicht mehr eingeben.
ich bin mit meinem Latein echt am ende.

Grüße