[ANN] BURST - Mining mit freiem Festplattenspeicher - P2P Markt, Crowdfunding ..

[Muenzanstalt]

Ich dachte die Anzeige ist die reine Lesegeschwindigkeit der Platte? Beim Plotten hat das natürlich massive Auswirkungen.
Ich habe noch einen weiteren Rechner mit nem i5, AVX-fähig. Der liest nur eine 300GB Partition aus und kommt dabei auch kaum über 40MB/s.
Allerdings ist das erste Auslesen oft deutlich schneller, dann fällts ab.

[rico666]

Unter Linux teste ich die Plattengeschwindigkeit mit hdparm:

Code:

# RAID-5 Array an Areca Controller
# hdparm -t /dev/sda
/dev/sda:
 Timing buffered disk reads: 1822 MB in  3.00 seconds = 606.96 MB/sec

# 250 BX-100 SSD
# hdparm -t /dev/sdb
/dev/sdb:
 Timing buffered disk reads: 822 MB in  3.01 seconds = 273.51 MB/sec

# WD 2TB SATA
# hdparm -t /dev/sdc
/dev/sdc:
 Timing buffered disk reads: 388 MB in  3.01 seconds = 128.75 MB/sec

# Kingston HyperX PCIe SSD
# hdparm -t /dev/sdd
/dev/sdd:
 Timing buffered disk reads: 2424 MB in  3.00 seconds = 807.89 MB/sec

# Samsung 950Pro NVMe
# hdparm -t /dev/nvme0n1
/dev/nvme0n1:
 Timing buffered disk reads: 4606 MB in  3.00 seconds = 1534.96 MB/sec

Prinzipiell sollten optimierte Plots nicht unter 50% des Wertes stehen, den hdparm zurückliefert.
Ist dies der Fall, ist irgendwas faul (Flaschenhals). Diese Werte für sich sind schon weiter weg
von dem was die Hersteller oft angeben, spiegeln aber die Realität der HW-Leistungsfähigkeit
eher wieder.

Neben dem optimieren der Plots muss auch AHCI Betriebsmodus für SATA Platten im BIOS
gesetzt sein.

[montagid]

Hm irgendwas stimmt gerade nicht, kriege im miner angezeigt. Mein Wallet ist auch der Meinung, dass irgendwas nicht passt. "Incorrect Account" oder so glaube ich stand da.

Code:

[ERROR 1] Incorrect request

Ausgehende Transaktionen von meinem Wallet bekommen auch keine confirmations.

[Muenzanstalt]

Den Fehler bekomme ich auch - Incorrect Request beim submitten einer Nonce.

AHCI ist natürlich aktiviert. Sind die Werte denn in dem Maße kritisch dass ich an einer Runde nicht die optimale Deadline übermitteln kann?

[eneloop]

Den Fehler bekomme ich auch - Incorrect Request beim submitten einer Nonce.

AHCI ist natürlich aktiviert. Sind die Werte denn in dem Maße kritisch dass ich an einer Runde nicht die optimale Deadline übermitteln kann?

Die durchschnittliche Blockdauer sind 4 min. Wenn du in max. 1 min fertig bist mit dem Auslesen, dann musst du dir keine Gedanken machen.

[rico666]

https://i.imgur.com/qjVqI2El.png


Hat noch ein wenig Luft nach oben :-)

[panormal]

Xeon 3440

Ich seh gerade, dass der Xeon X3440 das AVX instruction set nicht beherrscht. Das könnte der Grund sein, weil SSE deutlich langsamer funktioniert, da gabs einige Posts in div. Burst Threads.

Meine CPU (i7 930) ist dem Xeon recht ähnlich und hat auch kein AVX. So 160MB/sec schaffe ich aber schon, die Platten (4 mal 8TB WD Nas an SATA + 2 USB3 Platten) müssten weit über 600MB/s hergeben. Beim Minen sind alle Kerne zu ca. 80% ausgelastet. Die CPU ist definitiv der FAlschenhals. Unter 60MB/sec mit dem Xeon ist aber schon recht wenig.

[Muenzanstalt]

Tja, ich werd noch ein wenig rumprobieren, vielleicht mal einen anderen Miner testen.

Die aktuelle Runde dauert bereits über 1h?

[montagid]

meine dl hat mit 1,25 gereicht. aber scheint nich bestätigt geworden zu sein und grad gings irgendwie schlag auf schlag.
komische sachen passieren da wieder

[eneloop]

Xeon 3440

Ich seh gerade, dass der Xeon X3440 das AVX instruction set nicht beherrscht. Das könnte der Grund sein, weil SSE deutlich langsamer funktioniert, da gabs einige Posts in div. Burst Threads.

Meine CPU (i7 930) ist dem Xeon recht ähnlich und hat auch kein AVX. So 160MB/sec schaffe ich aber schon, die Platten (4 mal 8TB WD Nas an SATA + 2 USB3 Platten) müssten weit über 600MB/s hergeben. Beim Minen sind alle Kerne zu ca. 80% ausgelastet. Die CPU ist definitiv der FAlschenhals. Unter 60MB/sec mit dem Xeon ist aber schon recht wenig.

Alles klar, danke für die Info. Dann liegts nicht an der CPU.

[panormal]

Ich hatte eben die Nachricht welche für all die Unruhe sorgte bekommen und in meinem Wallet gesehen und gelesen, jetzt ist sie wieder weg und taucht unter Recent Transactions nicht mehr auf. Wie kann das sein?

..und jetzt beim tippen dieses Posts ist sie wieder da. Aber eine Position weiter über der letzten Transaktion, statt darunter wie eben.. komisch

Ich habe jetzt übrigens den Pool burst.cryptoguru.org erfolgreich als Reward-Recipient eingetragen und es kommen auch Comfirmations, scheint geklappt zu haben. Hallo werte Mitminer im Pool! ;-)

[Real-Duke]

Ich habe jetzt übrigens den Pool burst.cryptoguru.org erfolgreich als Reward-Recipient eingetragen und es kommen auch Comfirmations, scheint geklappt zu haben. Hallo werte Mitminer im Pool! ;-)

Du bist jetzt Schuld das der Pool aktuell hängt oder? 
Rico, wenn Du noch wach, bist drück mal resett bitte 

[panormal]

Ich habe jetzt übrigens den Pool burst.cryptoguru.org erfolgreich als Reward-Recipient eingetragen und es kommen auch Comfirmations, scheint geklappt zu haben. Hallo werte Mitminer im Pool! ;-)

Du bist jetzt Schuld das der Pool aktuell hängt oder? 
Rico, wenn Du noch wach, bist drück mal resett bitte 

Denke nicht. Wäre jetzt aber auch lieber wieder Solo-Miner - war in der selben Chain und könnte meine Wallet so neu starten. Andererseits hat sich meine alte Wallet heute auch um 11Uhr verabschiedet und ich war erst um 19:00 wieder da - gleicht sich vermutlich aus. Blöd ist nur, dass der Miner sich dann auch fast immer aufhängt, also wenn die Wallet hängt.

[rico666]

Ich habe jetzt übrigens den Pool burst.cryptoguru.org erfolgreich als Reward-Recipient eingetragen und es kommen auch Comfirmations, scheint geklappt zu haben. Hallo werte Mitminer im Pool! ;-)

Du bist jetzt Schuld das der Pool aktuell hängt oder?  
Rico, wenn Du noch wach, bist drück mal resett bitte  

Denke nicht. Wäre jetzt aber auch lieber wieder Solo-Miner - war in der selben Chain und könnte meine Wallet so neu starten. Andererseits hat sich meine alte Wallet heute auch um 11Uhr verabschiedet und ich war erst um 19:00 wieder da - gleicht sich vermutlich aus. Blöd ist nur, dass der Miner sich dann auch fast immer aufhängt, also wenn die Wallet hängt.

Ich denke, es bedarf einiger fachlich klärender Worte.


ES HÄNGT NICHT DER POOL!

Bitte prägt euch das ein.

Es hängt immer die verfickte BURST Wallet, weil die JAVA-Wixscheisse in der das offensichtlich von Junior-Schimpanzendevs programmiert wurde sich bei größerer Belastung aufhängt und einen Restart notwendig macht.

D.h. Wir haben die Wallet bereits in der Konfig gefixt um die DB im Servermodus zu betreiben -> hilft ein wenig.
Wir haben die H2 Datenbank auf Neueste Version gebracht -> hilft ein wenig.

Und die Datenbank hängt unentwegt am Tropf auf der Intensivstation. Lies: wir beobachten die Datenbank unentwegt und wenn sie abschmiert restarten wir sie neu.

Aber: Wir können nicht ständig am Rechner sein und Intensivstation spielen, etwas Schlaf ist auch vonnöten.

Ja, wir werden auch das Problem lösen, vermutlich mit dem 20sten Monitoring Skript und wohl oder übel Abtauchen in o.g. JAVA-Wixscheisse (IT Fachbegriff). Aber wenn "der Pool hängt", und irgendjemand vom Team wach ist, dann wissen wir das früher als es hier gepostet wird.

Edit - Nachtrag:

Ich kann momentan nur jedem empfehlen seine Wallet auszuschalten (zum Mining braucht ihr die nicht), und nur zum Sync anzumachen wenn ihr auch wirklich am Rechner sitzt.

Nachtrag2:

Wer eine formale Definition von JAVA-Wixscheisse braucht, bitte sehr:

Code:

2017-07-22 08:15:36 SEVERE: org.h2.jdbc.JdbcSQLException: General error: "java.lang.IllegalStateException: Reading from nio:/data/soft/lin/BURST/burst_128/burst_db/burst.mv.db failed; file length -1 read length 192 at 266764532 [1.4.196/1]"; SQL statement:
SHUTDOWN COMPACT [50000-196]
org.h2.jdbc.JdbcSQLException: General error: "java.lang.IllegalStateException: Reading from nio:/data/soft/lin/BURST/burst_128/burst_db/burst.mv.db failed; file length -1 read length 192 at 266764532 [1.4.196/1]"; SQL statement:
SHUTDOWN COMPACT [50000-196]
...
Caused by: java.lang.IllegalStateException: Reading from nio:/data/soft/lin/BURST/burst_128/burst_db/burst.mv.db failed; file length -1 read length 192 at 266764532 [1.4.196/1]

Nachtrag2:

Momentan hängt weder der pool noch die Wallet. Die Wallet läuft auf Hochtouren mit 6-20 ausgelasteten Kernen und 45GB Speicherbedarf und recht Traffic:



Da müssen wir durch...

Nachtrag3:

Wir experimentieren gerade damit bei der Wallet MySQL statt H2 zu verwenden. Einen Versuch ist es wert.

[montagid]

Für mein Verständnis:
hat die hohe Auslastung damit zu tun, die ganzen angelaufenen Transaktionen/Nachrichten und Folgetransaktionen abzuarbeiten?

Ist es derzeit also generell eher unsinnig für kleinere Systeme die Wallet zu synchronisieren? Mal abgesehen davon ist bei mir die db Datei schon wieder hinüber und ich krieg die Wallet einfach nicht mehr synchron, kann somit derzeit eigentlich auf kein Wallet zugreifen oder überhaupt mal gucken, wie der aktuelle Stand ist. Hat da jemand ein ähnliches Problem?

[Rudelhund]

Wo stehen wir denn jetzt so im BURST-Netzwerk? Erholt sich das von selbst? Kriegen nachher die Leute auf der "richtigen" Blockchain einen Riesen Payout? Die Typen von Burstnation haben eine Datenbank in Umlauf gebracht, die möglicherweise sicherstellen soll, dass deren Blockchain gewinnt... Meinungen?

[rico666]

Wo stehen wir denn jetzt so im BURST-Netzwerk? Erholt sich das von selbst? Kriegen nachher die Leute auf der "richtigen" Blockchain einen Riesen Payout? Die Typen von Burstnation haben eine Datenbank in Umlauf gebracht, die möglicherweise sicherstellen soll, dass deren Blockchain gewinnt... Meinungen?

Ich würde bei Burstnation ganz vorsichtig sein. Gibt Stimmen, die meinen dass die hinter den ganzen Problemen stecken.

Ich kann nur sagen wir versuchen eine Chain durchzubringen, so wie sie das Netzwerk sieht. Dazu halten wir unter großem Einsatz ein paar Wallets am Laufen, von denen jede momentan so 40 Peers füttert.

Wer sich natürlich die Datenbank von Burstnation holt, führt das BURST Netzwerk ad absurdum (1:N -> Sterntopologie, anstelle eines "Mesh").

Ich habe mir auch überlegt einen Download/Rsync Service für die Datenbank bereitzustellen, bin aber aus o.g. davon ab. Habe ich nämlich eine Wallet laufen, dann ist das keine Einbahnstraße, wenn ich natürlich jemanden dazu bringen kann eine komplette Blockchain zu downloaden (wer überprüft die schon?), dann ist das wie ein Diktat.

Ansonsten zum Thema "erholt":

Naja - wir beißen uns durch. Werden vermutlich harte 10 Tage werden. Dann steht zu erwarten, dass die Angriffe weitergehen.
Folglich lautet die Devise derzeit nicht nur den gegenwärtigen Angriff abzuwehren, sondern sich auch noch pro-aktiv auf künftige mögliche vorbereiten.

[TCM]

Also macht man nichts falsch, wenn man versucht, das offizielle Wallet am Laufen zu halten? Oder was kann man jetzt am besten tun?

[Gucky2000]

Der Pool in dem ich stecke, ist mal wieder down. Gestern abend sah es ganz gut aus, heute morgen hat der Pool irgendwie 5 stellige Block-IDs geliefert....was ja eigentlich richtig alte Blöcke sein müssten. Soweit ich das verstanden habe.

Habe bei mir jetzt auch erstmal das plotten abgebrochen und warte mal ab was jetzt kommt. Pool wechseln kann ich im Moment irgendwie auch nicht. Naja mal schauen wie es weiter geht.

Grüße

[rico666]

Also macht man nichts falsch, wenn man versucht, das offizielle Wallet am Laufen zu halten? Oder was kann man jetzt am besten tun?

Ich habe erstmal auf die Schnelle das hier gehackt:

edit: Neuere Version

https://pastebin.com/aEGpSTVH


Theoretisch sollte es schauen ob die Wallet einen "SEVERE" Error meldet und sie dann neu starten. nicht nur theoretisch. Das Skript tut was es soll.
Das habe ich bislang manuell gemacht - außer wenn ich nicht am rechner war - also sollten sich da die Wallet-Downtimes auch in Grenzen halten.

"Leider" ist natürlich - Gesetz Murphy - die so aufgerufene Wallet bislang noch nicht ein einziges Mal abgeschmiert. (Die burst.cryptoguru.org Wallet habe ich so gestartet). "Leider", weil eben noch ungetestet.