Large Bitcoin Collider (Collision Finder Pool) - Deutscher Thread

[Coinpiet]

Ich habe die GPU Treiber probiert installieren aber beim Treiber selber habe ich immer ein Kleines Problem da kommt immer ist abhängig von und dan ne Liste die sich net installieren lässt.

Aber die AMD SDK hat sich ohne Probleme installieren lassen.

[rico666]

Ich habe die GPU Treiber probiert installieren aber beim Treiber selber habe ich immer ein Kleines Problem da kommt immer ist abhängig von und dan ne Liste die sich net installieren lässt.

Aber die AMD SDK hat sich ohne Probleme installieren lassen.

Bei genauerem Nachdenken, glaube ich nicht, dass sich da ein Treiber wird installieren lassen. Da läuft ja kein Kernel (soweit ich weiß).
Das ist so eine API-Zwischeschicht und drunter ist eben Windows.

Wäre natürlich interessant zu wissen, was die API Zwischenschicht alles leisten kann - sprich wenn auf Windows OpenCL installiert ist...

EDIT:

geht leider nicht. 

https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/16108045-opencl-cuda-gpu-support

bzw. noch nicht. Angeblich, wenn sich viele Leute rühren, die das möchten...

[cagrund]

Ich habe mal dafür gevoted.

Gruß Carsten.

[rico666]

Gruß Carsten.

Lustig in den Statistiken anzuschauen, wie Du und __KULME__ um den 2. Platz rotiert.
Du mit konstanten 25 Mkeys/s und __KULME__ scheint wohl ab und an seine 150 Mkeys/s Maschine zu starten um Dich zu überholen.
Dann schaltet er sie wieder ab und Du überholst ihn... ^^

Da bräuchte es schon fast einen dedizierten Sportreporter. 

[Real-Duke]

Ich habe mal dafür gevoted.

Gruß Carsten.

Ich auch gerade, kann nicht verkehrt sein! Sind jetzt 1306 Votes

Auf meinem Notebook habe ich den LBC gestern noch nicht zum Laufen bekommen, irgendetwas fehlte immer beim compilieren bzw wurde dann abgebrochen und wieder Teile nachinstalliert.
Morgen geht es damit weiter...

Lustig in den Statistiken anzuschauen, wie Du und __KULME__ um den 2. Platz rotiert.
Du mit konstanten 25 Mkeys/s und __KULME__ scheint wohl ab und an seine 150 Mkeys/s Maschine zu starten um Dich zu überholen.
Dann schaltet er sie wieder ab und Du überholst ihn... ^^

Da bräuchte es schon fast einen dedizierten Sportreporter. 

Ich hab Dich bald 

[rico666]

Ich hab Dich bald 

Ich bin ja wohl kein ebenbürtiger Gegner. Wenn Arulbero mal wieder was an der ECC lib dreht, bin ich ja froh, wenn ich den Generator überhaupt compiliert bekomme. 
Und während dem Programmieren kann ich es nicht abhaben, wenn die Lüfter heulen.

MaW die Spikes die man bei mir sieht: https://lbc.cryptoguru.org/stats/__rico666__
sind wenn ich mal promised/undelivered Blöcke schludriger Clients abarbeite bzw. einen neuen Generator teste.

Aber sollte mich der Ehrgeiz packen, dann baue ich mir ein ASIC und dann... hehe



Naja - back to work: ECC lib umgekrempelt, angeblich 13% schneller

Code:

hrd-core.c: In function ‘main’:
hrd-core.c:452:22: warning: passing argument 4 of ‘mul’ from incompatible pointer type [-Wincompatible-pointer-types]
   mul(cxp, cyp, czp, k);
                      ^
In file included from hrd-core.c:18:0:
ecc_new.h:352:6: note: expected ‘const long unsigned int *’ but argument is of type ‘__mpz_struct * {aka struct <anonymous> *}’
 void mul(unsigned long int *kxp, unsigned long int *kyp, unsigned long int *kzp, const unsigned long int *k){
      ^~~
hrd-core.c:455:14: warning: passing argument 1 of ‘jac_to_aff’ from incompatible pointer type [-Wincompatible-pointer-types]
   jac_to_aff(Px, Py, cx, cy, invcz);
              ^~
In file included from hrd-core.c:18:0:
ecc_new.h:417:6: note: expected ‘long unsigned int *’ but argument is of type ‘__mpz_struct * {aka struct <anonymous> *}’
 void jac_to_aff(unsigned long int* axp, unsigned long int* ayp, unsigned long int* jaxr, unsigned long int* jayr, unsigned long int* invjazr){
...

[shortcircuit]

Hi rico,

hab mich heute mal mit deinem Projekt beschäftigt und bekomme den Client leider nicht zum laufen.
Habe alles installiert, den CLinet aktualisiert aber jedes mal beim Start kommt folgende Meldung:

Will use 1 CPUs.
Benchmark info not found - benchmarking... Can't exec "gen-hrdcore-generic-linux64": No such file or directory at ./LBC line 2025.
Can't benchmark generator: No such file or directory at ./LBC line 2025.

Was mache ich falsch?

PS: die Datei ist vorhanden.

[Real-Duke]

Hänge mich hier auch mit ran.
Mein Linux PC wird gerade benutzt, aber hier auf dem Notebook habe ich eben die Appliance gestartet.
Er meldet das Update auf die neue Version und anschließend nochmal LBC starten = Läuft
Nach einem Loop habe ich dann ./LBC -x laufen lassen und es läuft nichts mehr

[rico666]

 

Im Namen seiner heiligsten Durchlaucht, der Security, habe ich das böse "qx" durch einen Open Pipe ersetzt.

Code:

- qx{./$config{generator} -I 0000000000000000000000000000000000000000000000000000000000000001 -c 10000 > $devnull};
	
+ my @bench_param = qw(-I 0000000000000000000000000000000000000000000000000000000000000001 -L 1 -c 10000);
+ push @bench_param, ('-d', $gpu_device) if ($gpu_auth);
+ open my $FH, '-|', $config{generator}, @bench_param or die "Can't benchmark generator: $!";

Wer sieht den Fehler?

Der neue Code funktioniert natürlich nur auf meinen Testmaschinen, weil ich prinzipiell den aktuellen Pfad in $PATH habe

Code:

export PATH=$PATH:.

und eure Generatoren sollten auch loslaufen. Ich schieb' mal ein Update nach...

[shortcircuit]

Danke :-)

[Real-Duke]

Dann sollte das auch mein Problem mit dem GPU Collider den ich im englischen Thread angesprochen habe beheben 
Leider ist mein Pc immer noch in der Gewallt meiner Tochter, aber heute Abend werde ich das prüfen.
Thx!

[rico666]

Dann sollte das auch mein Problem mit dem GPU Collider den ich im englischen Thread angesprochen habe beheben 

LBC -u -> holt 1.140, dann ist das auch gegessen.

[rico666]

...oder der Code war bislang sehr schlecht.

...
Das Schlüsselwort lautet Entwicklungsaufwand und daraus resultiert Fortschritt.

Endlich mache ich wieder das, was mir am LBC am meisten Spaß macht: An der Speed schrauben.

Momentan kommen bei mir aus einem Prozessorkern knapp 6.5 Mkeys/s herausgepurzelt (die GPU macht das Hashing) und da ist die avisierte Verdoppelung durch Nutzen der n-k Symmetrie noch überhaupt nicht drin.

Meine GPU hasht momentan irgendwas um die 42 mio hash160 die Sekunde (80% Last), aber wenn ich mich an hashcat orientiere, dann sollte 85.7 mio hash160 (bei 100% Last) das Limit sein.

Wie ich auf die blöde Idee kommen konnte den OpenCL code als payload im LBC client zu haben ist mir auch fast schleierhaft (naja - es war schnell zusammengehackt), daher werden die nächsten Generatoren ihren eigenen OpenCL code bereits "intus" haben. Kein hash160_deparsed.cl Gepfriemel mehr. (Theoretisch ermöglicht das sogar einen Betrieb auf Maschinen die AMD und Nvidia Karten verbaut haben)

Die Generatoren werden nicht nur schneller sein, sondern auch einheitlicher - vermutlich werde ich CPU und GPU Version zusammenführen. Wenn nicht im nächsten, dann im übernächsten Release.

hrd-core -> kardashev

Parallel zu diesen usability-Aspekten arbeiten wir mit arulbero an weiteren Optimierungen. Das geht so weit, dass wir mittelfristig nicht mehr gegen die libgmp linken werden, sondern unseren eigenen bignum-code verwenden, der naturgemäß - weil exakt auf den Bedarf zugeschnitten - schneller sein wird. Obige 6.5 Mkey/s sind ein kleiner Vorbote. Dann handelt es sich um eine neue Generation von Generatoren und als solche wird sie auch einen neuen Namen tragen.

Soweit die News aus dem Nähkästchen.

[Real-Duke]

Das klingt fast danach, das man in Zukunft auf ein extra LBC-Rig (wegen Abwärme) setzen muß und nicht mehr "nebenbei über Nacht" im Heim PC per GPU rechnen lässt
Braucht Ihr Betatester fürs Nähkästchen?

[rico666]

Das klingt fast danach, das man in Zukunft auf ein extra LBC-Rig (wegen Abwärme) setzen muß und nicht mehr "nebenbei über Nacht" im Heim PC per GPU rechnen lässt
Braucht Ihr Betatester fürs Nähkästchen?

Ich möchte eigentlich die Situation erreichen, dass wir Releases hinbekommen die ohne Betatester auskommen.  
Aber ja, wenn was Hakeliges ist, bitte ich vorher meine Pappenheimer um Hilfe.

Bzgl. "nebenbei über Nacht" - natürlich geht das auch in Zukunft. Nur wird man dann eben nicht mehr alle CPU Kerne starten, sondern nur noch -c 1 oder -c 2
Das hängt vom individuellen Show-off-Faktor ab.  

edit:

Heute hat das erste Mal ein "Kardashev"-Generator im regulären (produktiv) Pool mitgemischt.
Die 4-Kern Peak-Performance ist mit 21.6-21.7 Mkeys/s ok (die 20.9x kommen daher, weil ich ja noch auf der Maschine arbeite).
Das Binary ist sowohl für CPU wie auch für GPU Betrieb, gpuauth entscheidet einfach welcher Codepfad genommen wird.
Einen Release mache ich erst dann, wenn GPU-Support auf den Amazon GPU-Maschinen läuft.

Code:

$ LBC -t 1
GPU authorized: yes
Time interval given (1) < 5 minutes. Setting loop to max. 5 iterations only.
Ask for work... got blocks [5030834511-5030835854] (1409 Mkeys)
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo (21.59 Mkeys/s)
Ask for work... got blocks [5030842895-5030844238] (1409 Mkeys)
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo (20.95 Mkeys/s)
Ask for work... got blocks [5030844239-5030845582] (1409 Mkeys)
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo (20.96 Mkeys/s)
Ask for work... got blocks [5030855359-5030856702] (1409 Mkeys)
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo (20.94 Mkeys/s)
Ask for work... got blocks [5030873151-5030874494] (1409 Mkeys)
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo (20.94 Mkeys/s)

[rico666]

Demnächst in ihrem Kino: https://lbc.cryptoguru.org/static/generators/ (siehe die unteren Zeilen)

Für Leute, die nur CPU Generatoren betreiben:

• Es wird einen leichten Geschwindigkeitszuwachs geben ~1.7% - nichts Außergewöhnliches, aber immerhin.
• Es ist notwendig - auch für den CPU client - OpenCL installiert zu haben. Egal welches, Hauptsache eine libOpenCL.so ist vorhanden. (ich habe auf GPU-losen Maschinen die Mesa-OpenCL-ICD installiert)

Ansonsten - ab und an den Link "News" in meiner Signatur klicken, da schreibe ich aktuelle Infos rein. Manchmal...

Zur Pool-Speed: So sieht es ohne Unknownhostname aus.  

[Real-Duke]

Zur Pool-Speed: So sieht es ohne Unknownhostname aus.  

Wieso darf "der" eigentlich so lange Urlaub machen? 

[rico666]

Wieso darf "der" eigentlich so lange Urlaub machen? 

k.A. - kann mir vorstellen, dass 1.9 Gkeys/s mit CPUs auf die Dauer für einen Einzelnen zuviel des Guten sind.
Ich schaue mal ob/wie ich GPU clients auf den AWS Maschinen zum Laufen bekomme.

Dann besteht aber die "Gefahr", dass er so 10 Gkeys/s auf den Pool wirft.   

[Coinpiet]

Das wäre doch gar net so schlecht

Wie steht es jetzt mit GPU kann man da schon was auf der VM nutzen ?

Piet

[rico666]

Wie steht es jetzt mit GPU kann man da schon was auf der VM nutzen ?

Ob/Wann GPU auf VMs funktionieren wird, liegt nicht im Einflussbereich des LBC.

Dazu muss der Kernel, der GPU-Treiber, die VM, die Hardware und weiß Gott wer noch alles diese GPU Virtualisierung unterstützen.
https://www.heise.de/ct/ausgabe/2017-10-Linux-4-11-verlaengert-Akkulaufzeit-3694446.html#p_22
Der LBC Client bzw. der Generator kann höchstens feststellen "GPU Hardware da/nicht da) und in einer VM - wenn nicht da - dann sieht das für die
Software auch so aus egal ob unter der VM die Hardware da ist.

Ich habe ohnehin den Verdacht, dass die GPU Systeme in der Amazon Cloud, bzw. bei Google Compute auch virtualisiert sind.
So wie echte Hardware verhält sich das nicht. Die haben vermutlich eigene Lösungen und sind den OpenSource Projekten
entsprechend etwas voraus.

Früher als 6 Monate sehe ich das nicht mit den GPUs in VMs. Dann vermutlich auch nicht mit jeder Hardware und sonstigen Einschränkungen.