Holy sh*t what have you done?

Ich hab gerade mal gecheckt, wie viele GKeys ich schon habe, und anschließend gabs den Death Kiss.
Also gut, -x...
Dann wundert mich schon, das der Kasten auf einmal 1900MKeys abholt anstatt 1500, und nun steht da 2,18MKeys/s statt 1,6 bei unveränderten Einstellungen usw.
Yeeeehaaaw!

@Real-Duke
das hört sich für mich so an, als ob du der VM nicht genug Kerne eingestellt hast, und damit deine -c-Einstellung von der VM itself begrenzt wird.
Da gibts ja die Einstellung, damit eine VM mit Hunger nicht den Host außer Betrieb nimmt, und genau das passiert hier ja auch.
Der genaue Wortlaut des Fehlers wäre schon interessant, vielleicht nur ein Vertipper im Secret oder so, aber 8 Kerne brauchen auch satt RAM, vielleicht wars das auch.

Whoa, Danke!
Mein anderer Rechner liefert jetzt 3,0x ab, also aus insgesamt 4 sind 5,2MKeys geworden. Nur mal eben so 30% mehr.
Entweder bist du ein sehr guter Mathematiker/Programmierer, oder der Code war bislang sehr schlecht.

Jetzt muss ich auch noch eine native Kiste Lunixen

@Real

Bin kein Windows-Experte, aber die VMware Maschine kann man hinsichtlich Netzwerkconfig entweder im NAT-Modus oder Bridged betreiben.
Wenn man "Bridged" einstellt, dann verhält die sich meiner Erfahrung nach transparent wie die Mutterkiste.

Da das für die Mehrzahl der Fälle auch schön bequem ist, ist das wohl der Default.
Was Du willst, ist aber:

http://www.sysprobs.com/internet-access-proxy-vmware-guest-machine

@Hodl

Es gilt wohl beides. 
Im Nachhinein betrachtet war der Code früher immer schlecht, aber es braucht viel Talent (und Schweiß!), um in die "Im Nachhinein betrachtet" Situation zu kommen.
Ich meine, ich habe ja angefangen mit ca. 13000 keys/s pro CPU Kern...

Da dachte ich es sei geil verglichen mit 128 key/s und habe bissige Bemerkungen Richtung Willi geschickt
https://bt.irlbtc.com/view/1534300.msg15638727#msg15638727

Aus heutiger Sicht war ich damals ebenso Dödel 
Und wer weiß was wir in 1 Jahr sagen...



Mache ich auch gerade auf der Gamer-Maschine meines Sohnes (Ubuntu 16.04 Desktop auf dem USB Stick installieren)
damit ich das mal mit einer AMD GPU ausprobieren kann. Angeblich läuft's ja - sagen die User, nur bei mir bislang noch nicht 



Rico

Anweisung: Vielleicht mal die Beiträge oben lesen.

Kurzfassung: 1.031 holen, dann sollte der Spuk ein Ende haben.


Rico

Bin einen Schritt weiter gekommen.
In der VM habe ich 8 Cores eingestellt, dann erstmal das Update auf 1.031 und schwups mit -t 8 rennt die Kiste auf 100% und kommt auf 2,91Mkeys 
Damit ist der Rechner dann aber echt für nichts anderes mehr zu gebrauchen, außer vieleicht als Zusatzheizung.
Stelle ihn wieder auf 4 Cores und lasse ihn schnurren.

Linux vom USB Stick booten klingt gut! Kann man dafür so ein Bootfähiges Image evtl auch schon vorbereiten wie die VM Images? Wenn ich da mal angekommen bin, möchte ich sehen was meine Geforce 1060 bringt.
Morgen beschäftige ich mich nochmal mit dem Thema Proxyserver in der Firma...danke für den Tip weiter oben.

Dann hast Du eine lahme Platte. :-)

Bevor es diesen -L Parameter gab, ist ein Generator wegen 16M keys gestartet (und wieder beendet) worden.
Dabei hat er mal eben das 512MB BLF File geladen.

Ich habe davon nichts mitbekommen - mit meiner 2.5GB/s SSD. Und auch jetzt sind für mich die neuen Versionen nicht schneller, aber sonst überall im Lahm-Festplattenland sind Jubelschreie zu vernehmen. 

So richtig habe ich das gemerkt als die AWS Instanzen mit ihren 32 GPU generatoren nicht schneller waren als die CPU Instanzen. 

Naja - jetzt wird ja alles gut.


Rico

Gar nicht - ist eine interne Sache zwischen dem LBC client und dem Generator.

Angenommen eine CPU hat 320M keys zu generieren
Anstatt, dass der LBC nun pro 16M Blöcke 20 x einen Generator startet, startet er ihn einmal und sagt ihm "Du machst jetzt 20 x 16M blöcke"
und gibt ihm den Parameter -L 20 it

Das siehst Du in der Prozesstabelle, aber machen musst Du da nichts.

edit:


Alles ist relativ, in diesem Fall aber leider doch. Wenn die Platte so 411 MB/s sequentiell hat (http://www.anandtech.com/show/4863/the-samsung-ssd-830-review/2), dann dauert das Laden des 512MB blf files 1.2 Sekunden. In der Zeit hätte Deine CPU schon so 600-750' Keys pro Kern generieren können. Nun hat Linux zwar Caching-Mechanismen, die greifen aber nur, wenn der Hauptspeicher nicht anderweitig belegt ist und wie das auf einer VM im Zusammenspiel mit dem VMplayer (und dem drunterliegenden Win) ist, entzieht sich meiner Kenntnis, aber performanter als direkt auf HW wird das kaum sein.
In jedem Fall sparen wir uns nun dieses und noch andere startup-Kosten (berechnen von 8192 Konstanten für die ECC Arithmetik u.a.)
das macht sich natürlich in der Keyrate bemerkbar.

Aber wie schon oben erwähnt, kann man das natürlich auch so sehen, dass der Programmcode bislang schlecht war - immer so auf die armen Platten einzudreschen. Glücklicherweise nur lesend, also keine Spätfolgen für SSDs

Rico

Hm. Schwierig. Hängt nämlich davon ab ob/wo/wie der Mailversand konfiguriert ist.
Beispiel wie ich das bei mir habe:


Mutt ist ein mailclient, der es auch ermöglicht über Kommandozeile gesteuert zu werden. (Ich denke obiger Befehl ist selbsterklärend, ggf. Help aufrufen. In diesem fall würde bei Dir bspw. hook-find in etwa so aussehen:




Das größere Problem ist den MTA zu konfigurieren und da gibt es keine Einheitslösung. Exim, postfix, sendmail (Gott bewahre), oder an ein Relay senden... Da müsste man konkret wissen was für eine Mail-Infrastruktur vorhanden ist. Wenn Du bereits einen Mailserver hast, der auf Port 25 z.B. aus dem internen Netz connections akzeptiert, kannst Du das ja direkt an den schieben. Ich verwende manchmal exim, manchmal postfix.

Zu der privkey Sache. Du hast es ja schon herausgefunden, der folgende link

http://directory.io/3196241445567#5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEXxDuJBiUbiVA9e

hilft noch besser/visuell die Zusammenhänge zu sehen. (uncompressed <-> compressed)


Jo.



Rico

Ja, die Datei sollte ausführbar sein, hook-find heißen, dein Kommando in Zeile 2 oder 3 stehen haben und in Zeile 1 sollte eben jenes #!/bin/bash stehen, welches besagt "Dies ist ein Shellskript, also bitte als solches ausführen".


Rico

Ich hätte da mal eine Verständnisfrage.

Der LBC sucht ja alle Adressen mit Guthaben ab.
Die stehen in einer Datei, extrahiert aus der Blockchain, nehme ich an.
Da sich die Adressen ständig ändern und erweitern, muss auch diese Datei erweitert werden, oder?

Wenn ich jetzt Angst hätte, das meine BTC in Gefahr sind, weil "meine Adresse" demnächste gescannt wird: könnte ich das Guthaben transferieren, auf eine Adresse im bereits durchsuchten Bereich, weil da nicht mehr gesucht wird? (Zumindest bis zum nächsten Update der "Schlüsseldatei"...)
Oder sogar erst mit einem kompletten Neustart des LBC-Systems, also ab "Bit 0"?

Wo ist mein Fehler? (Ich bin mir sicher, das ich da was falsch verstanden habe...)