Deutschsprachiger Pool btc.x8s.de ~110Ghash/s

[gentakin]

Okay, das klingt dann irgendwie gut.

[yetis]

Tja Leute, wenn mich nicht alles täuscht, haben wir seit diesem Block eine neue Difficulty:
http://blockexplorer.com/block/00000000000006f5d58e11e705c01b33a87f6d31f6b5bded34f01c68ad4e3d61

20:35 Uhr.

Ja, haben wir: http://bitcoin.sipa.be/
Der Anstieg ist diesmal jedoch moderat. Wir werden es verkraften :-)

Vielleicht liegt's auch an der Netzwerkgeschwindigkeit (-> Ping). Je schneller ein getwork gefetcht werden kann, desto eher kann der Miner mit dem Hashen anfangen. Die aktiven Worker steigen und steigen und der Daemon hat viel mehr Miner zu bedienen. Das wiederum könnte bedeuten, dass die Netzwerkauslastung ein wenig steigt und der Ping ebenfalls. An der Rechenleistung des Daemons kann es nicht liegen, wenn der Daemon selbst nicht zum Hashen verwendet wird. Mich würde interessieren wie die Netzwerkanbindung unseres Daemons ist und wieviele Verbindungen gleichzeitig er verkraften kann. Und ständige Statusabfragen des Daemons führen auch zu einer erhöhten Netzwerkauslastung. Da wird dann ein getwork in die Schlange gestellt und umgekehrt...
Das wäre meine theoretische Überlegung zu assko seinem Gefühl. ^^

Edit:
Eine Lösung wäre z.B. den Daemon zu splitten, sprich mehrere Daemons einzusetzen, die nicht die gleiche Netzwerkanbindung und nicht denselben Backbone benutzen, wie es zum Beispiel bei BTC-Guild (soweit ich das so sehe) der Fall ist / war.

Das ist Schmarrn. Prost. Wir hatten am Anfang einfach nur Glück. Deepbit hatte letztens auch mit einem Monsterblock zu kämpfen. Die Difficulty steigt ebenfalls.

ABER HEY: BEVOR wir die Hardware für das Minen bestellt haben, war uns das alles doch klar. Wir haben uns trotzdem nicht abhalten lassen! Ahoi!

Hmm... Ein Beispiel:

Du vergisst dabei, dass das Hashen im Nanosekundenbereich, während im Netzwerk die Übertragung im Millisekundenbereich erfolgt.
Das heisst, das nicht die Bandbreite entscheidend ist, sondern die Geschwindigkeit mit dem ein Client an Paketen versorgt werden kann, und der Server dementsprechend der Geschwindigkeit die Shares entgegennimmt und absegnet, etc.

Vielleicht ist diese Erklärung einleuchtender:
Eine typische Festplatte lädt und schreibt Daten mit 8 ms, während eine moderne und schnelle Solid State Drive die selben Daten mit 0,5 ms bereitstellt und abspeichert. Somit ist eine Applikation schneller geladen, das Betriebssystem bootet schneller, usw.

Typisches Flaschenhalsprinzip.^^

Edit: Und bei steigender Ghashleistung der Pools tritt immer mehr die Netzwerkleistung in den Vordergrund beim Rennen um Bitcoins, was früher zu vernachlässigen war, weil die Pools alle kleiner waren. Das kannst du übrigens in ganz wenigen englischen Threads nachlesen, soweit ich mich erinnern kann.

[yetis]

x8s down?

edit:
Boah! Hab' schon 'nen Schock gekriegt als alle Karten und CPUs nur noch Connecting... angezeigt haben.
Gschwitzt hob i. 

[Intertreuton]

Ich habe mir die letzten Posts  kopfschüttelnd durchgelesen und muss wieder einmal feststellen, wie wenig ich das BTC-Prinzip verstanden habe.
Wieso ist es möglich, dass ein gefundener Block durch einen anderen Pool ungültig wird?
Ich fand  den Vergleich mit Goldschürfen immer ganz passend.
Kann man das in etwa auch so ausdrücken: Ich habe in dem Fluß etwas Gold gewaschen, da kommt plötzlich DeBeers (k, die machen mehr in Diamanten, aber auch in Gold) daher und sagt: Ich habe hier die Schürfrechte und nimmt mir die Nuggets weg?
Ein richtig berechneter Block kann doch nicht ungültig sein?
Na wie auch immer, macht weiter mit euerm TechTalk, kann man ja nur von lernen

[redhatzero]

geht wieder? (zumindest bei mir)

Das war wieder das DB Backup... Wenn das läuft akkzeptiert der Pushpool irgendwann keine Verbindungen mehr bis das Backup fertig ist
(Bin grad dabei das Backup auf den Slave zu schieben)

Wegen Flaschenhals Netzwerk:
Laut Trafficstats haben wir wenn's viel ist 600MByte Traffic (Incoming+Outgoing) pro Stunde. Das sind ~1,33MBit/s wenn ich mich nicht verrechnet habe. Der Server ist mit 100MBit angebunden

[redhatzero]

Ich habe mir die letzten Posts  kopfschüttelnd durchgelesen und muss wieder einmal feststellen, wie wenig ich das BTC-Prinzip verstanden habe.
Wieso ist es möglich, dass ein gefundener Block durch einen anderen Pool ungültig wird?
Ich fand  den Vergleich mit Goldschürfen immer ganz passend.
Kann man das in etwa auch so ausdrücken: Ich habe in dem Fluß etwas Gold gewaschen, da kommt plötzlich DeBeers (k, die machen mehr in Diamanten, aber auch in Gold) daher und sagt: Ich habe hier die Schürfrechte und nimmt mir die Nuggets weg?
Ein richtig berechneter Block kann doch nicht ungültig sein?
Na wie auch immer, macht weiter mit euerm TechTalk, kann man ja nur von lernen

Kann er leider schon, auch wenn das aber eher der ausnahmefall ist:

Es gibt einen.. *hm*... Schneekugelsammler =)
Der sammelt durchnummerierte Schneekugeln.
Er gibt den Auftrag für Schneekugel 1 raus, Schneekugelhersteller X baut diese gibt sie zum Schneekugelsammler, von dem er dafür 50 BTC bekommt.
Schneekugel 2 macht Y .. Y bekommt 50 BTC...
etc etc etc...
So, jetzt passiert's aber, dass X+Y gleichzeitig die Schneekugel Nummer 1523 bauen, sie gehen von ihrer Werkstatt zum Schneekugelsammler.
X ist als erstes da, er bekommt die 50BTC
Jetzt kommt Y, der aber auch eine "gültige" Schneekugel mit der gleichen Nummer 1523 hat, aber der Schneekugelsammler mag halt von jeder Nummer immer nur eine Kugel..
deswegen geht Y leer aus.


Bei Bitcoins ist es dann so, dass es zwei Blöcke 1523 (1523.a und 1523.b) gibt. Wenn jetzt Block 1524 gemacht wird, hat er einen Verweis auf den vorherigen Block, wenn da jetzt 1523.a steht, dann hat eben .a gewonnen.

Das ganze könnte durchaus über mehrere Blöcke gehen. Deswegen sollte man ja auch 2-6 Confirmations (=neue Blöcke) warten bis man erhaltenen Bitcoins auch wirklich vertraut.

[yetis]

geht wieder? (zumindest bei mir)

Das war wieder das DB Backup... Wenn das läuft akkzeptiert der Pushpool irgendwann keine Verbindungen mehr bis das Backup fertig ist
(Bin grad dabei das Backup auf den Slave zu schieben)

Wegen Flaschenhals Netzwerk:
Laut Trafficstats haben wir wenn's viel ist 600MByte Traffic (Incoming+Outgoing) pro Stunde. Das sind ~1,33MBit/s wenn ich mich nicht verrechnet habe. Der Server ist mit 100MBit angebunden

Gut. Der Traffic läuft also auf einer einzigen 100 Mbit-Anbindung vom und zum Server!? Wir haben also bei der Bandbreite Luft nach oben. Interessant wäre in dem Fall wie schnell die Anbindung (Ping) ist, und nicht die Bandbreite. Je schneller Dein Server feuert und einsteckt, desto besser. (Wg. Blockbekanntgabe, etc.)

[redhatzero]

mal ein paar ping tests zu fallback nodes ( https://en.bitcoin.it/wiki/Fallback_Nodes ):

PING mining.bitcoin.cz (178.79.179.32) 56(84) bytes of data.
64 bytes from li348-32.members.linode.com (178.79.179.32): icmp_req=1 ttl=52 time=20.1 ms

PING fallback2.bitcoin.me.uk (178.255.199.86) 56(84) bytes of data.
64 bytes from hosted-by.snelis.com (178.255.199.86): icmp_req=1 ttl=56 time=14.7 ms

PING 109.75.176.193 (109.75.176.193) 56(84) bytes of data.
64 bytes from 109.75.176.193: icmp_req=1 ttl=58 time=6.52 ms

PING deepbit.net (46.4.121.119) 56(84) bytes of data.
64 bytes from static.119.121.4.46.clients.your-server.de (46.4.121.119): icmp_req=1 ttl=60 time=0.266 ms



Letzteres dürfte mit ein Grund sein, warum wir bisher keine Probleme mit invalid hatten. Ich geh davon aus, dass die deepbit server (bzw. zumindest der eine) im gleichen Rechenzentrum wie der x8s Server stehen.

[yetis]

Ich habe mir die letzten Posts  kopfschüttelnd durchgelesen und muss wieder einmal feststellen, wie wenig ich das BTC-Prinzip verstanden habe.
Wieso ist es möglich, dass ein gefundener Block durch einen anderen Pool ungültig wird?
Ich fand  den Vergleich mit Goldschürfen immer ganz passend.
Kann man das in etwa auch so ausdrücken: Ich habe in dem Fluß etwas Gold gewaschen, da kommt plötzlich DeBeers (k, die machen mehr in Diamanten, aber auch in Gold) daher und sagt: Ich habe hier die Schürfrechte und nimmt mir die Nuggets weg?
Ein richtig berechneter Block kann doch nicht ungültig sein?
Na wie auch immer, macht weiter mit euerm TechTalk, kann man ja nur von lernen

Kann er leider schon, auch wenn das aber eher der ausnahmefall ist:

Es gibt einen.. *hm*... Schneekugelsammler =)
Der sammelt durchnummerierte Schneekugeln.
Er gibt den Auftrag für Schneekugel 1 raus, Schneekugelhersteller X baut diese gibt sie zum Schneekugelsammler, von dem er dafür 50 BTC bekommt.
Schneekugel 2 macht Y .. Y bekommt 50 BTC...
etc etc etc...
So, jetzt passiert's aber, dass X+Y gleichzeitig die Schneekugel Nummer 1523 bauen, sie gehen von ihrer Werkstatt zum Schneekugelsammler.
X ist als erstes da, er bekommt die 50BTC
Jetzt kommt Y, der aber auch eine "gültige" Schneekugel mit der gleichen Nummer 1523 hat, aber der Schneekugelsammler mag halt von jeder Nummer immer nur eine Kugel..
deswegen geht Y leer aus.


Bei Bitcoins ist es dann so, dass es zwei Blöcke 1523 (1523.a und 1523.b) gibt. Wenn jetzt Block 1524 gemacht wird, hat er einen Verweis auf den vorherigen Block, wenn da jetzt 1523.a steht, dann hat eben .a gewonnen.

Das ganze könnte durchaus über mehrere Blöcke gehen. Deswegen sollte man ja auch 2-6 Confirmations (=neue Blöcke) warten bis man erhaltenen Bitcoins auch wirklich vertraut.

Auch eine gute Erklärung, redhatzero.^^

X hat zum Beispiel ein Schneemobil (vergleichbar mit dem Ping im Netzwerk) und Y muss zu Fuss laufen.

[redhatzero]

Y ist ne arme Sau

[yetis]

mal ein paar ping tests zu fallback nodes ( https://en.bitcoin.it/wiki/Fallback_Nodes ):

PING mining.bitcoin.cz (178.79.179.32) 56(84) bytes of data.
64 bytes from li348-32.members.linode.com (178.79.179.32): icmp_req=1 ttl=52 time=20.1 ms

PING fallback2.bitcoin.me.uk (178.255.199.86) 56(84) bytes of data.
64 bytes from hosted-by.snelis.com (178.255.199.86): icmp_req=1 ttl=56 time=14.7 ms

PING 109.75.176.193 (109.75.176.193) 56(84) bytes of data.
64 bytes from 109.75.176.193: icmp_req=1 ttl=58 time=6.52 ms

PING deepbit.net (46.4.121.119) 56(84) bytes of data.
64 bytes from static.119.121.4.46.clients.your-server.de (46.4.121.119): icmp_req=1 ttl=60 time=0.266 ms



Letzteres dürfte mit ein Grund sein, warum wir bisher keine Probleme mit invalid hatten. Ich geh davon aus, dass die deepbit server (bzw. zumindest der eine) im gleichen Rechenzentrum wie der x8s Server stehen.

Sieht so aus als hättest du den Deepbit vom Rechenzentrum aus intern angepingt?!? weil die ms stark gering sind.

[redhatzero]

Sieht so aus als hättest du den Deepbit vom Rechenzentrum aus intern angepingt?!? weil die ms stark gering sind.

Ja, deswegen sage ich ja, dass ich davon ausgehe, dass deepbit (bzw. zumindest dieser eine jene Server von deepbit) und x8s im gleichen Rechenzentrum stehen (was für bzw. gegen invalid blocks nur gut sein kann)

Edit: ich hab grad nochmal ein paar andere Server von denen ich weiß, in welchen Hetzner RZ die stehen angepingt, und es ist recht egal, auch über verschiedene RZ hinweg sind die Pingzeiten < 1ms

[yetis]

Wenn der zweitletzte Deiner ist, dann sehen wir auch ungefähr die Routing-Geschwindigkeit im Netzwerk selbst?!?
Btw. hab mal deepbit und zweitletzten angepingt und verglichen, und dabei festgestellt, dass der zweitletzte knapp 2 ms schneller ist zu mir.
Kann natürlich auch Toleranz sein.

[redhatzero]

Wenn der zweitletzte Deiner ist, dann sehen wir auch ungefähr die Routing-Geschwindigkeit im Netzwerk selbst?!?
Btw. hab mal deepbit und zweitletzten angepingt und verglichen, und dabei festgestellt, dass der zweitletzte knapp 2 ms schneller ist zu mir.
Kann natürlich auch Toleranz sein.

ne, mein server ist da nicht drauf, weil ich ja von dem aus gepingt hab wenn du x8s pingen willst, dann ping btc.x8s.de an

[yetis]

Wenn der zweitletzte Deiner ist, dann sehen wir auch ungefähr die Routing-Geschwindigkeit im Netzwerk selbst?!?
Btw. hab mal deepbit und zweitletzten angepingt und verglichen, und dabei festgestellt, dass der zweitletzte knapp 2 ms schneller ist zu mir.
Kann natürlich auch Toleranz sein.

ne, mein server ist da nicht drauf, weil ich ja von dem aus gepingt hab wenn du x8s pingen willst, dann ping btc.x8s.de an

Ok. Sind beide gleichschnell zu mir.

[yetis]

Dann wäre das schonmal geklärt. Schneller Server, guter Daemon und 'n guter Ping. Dann können die BTCs ja eintrudeln.

[yetis]

Sieht so aus als hättest du den Deepbit vom Rechenzentrum aus intern angepingt?!? weil die ms stark gering sind.

Ja, deswegen sage ich ja, dass ich davon ausgehe, dass deepbit (bzw. zumindest dieser eine jene Server von deepbit) und x8s im gleichen Rechenzentrum stehen (was für bzw. gegen invalid blocks nur gut sein kann)

Edit: ich hab grad nochmal ein paar andere Server von denen ich weiß, in welchen Hetzner RZ die stehen angepingt, und es ist recht egal, auch über verschiedene RZ hinweg sind die Pingzeiten < 1ms

Das erinnert mich an (mir fällt jetzt der Fachausdruck leider nicht ein):
Der der mehr für's Routing im Web bezahlt und braucht an Netzwerkleistung der bekommt auch das schnellere Routing im Web.
Kann auch sein, dass Hetzner eigene oder gemietete Nodes/Backbones hat, um z.B. die RZ miteinander zu verbinden.

[seldon]

Sind grad wieder alle auf connecting..

btw, bin ich der einzige der es schafft immer rechtzeitig zum Difficulty-Spring neue HW an den Start zu bringen um grade _nicht_ die gute alte Diff mitzunehmen?

[yetis]

Ich kaufe rein aus Wirtschaftlichkeit keine neue Hardware. War eine einmalige Angelegenheit. Ausserdem habe ich auch nicht so viel Platz hier, und laut und heiss ist es auch noch.

Ja, und das mit dem Connecting... das höre ich gut raus. Da brauche ich nicht mal meinen Teamviewer, um zu wissen, das irgendwas los ist.^^ (Ausser ich schlafe den Schlaf des Gerechten. Dann träume ich von Blöcken und Bitcoins und Hashes, etc. *Scherz!)

[klaaster]

Bei mir auch failed to connect, Server scheint down zu sein seit 01:15 Uhr.

Edit: Oder besser gesagt der daemon, die Website funktioniert noch.
Edit 2: Funktioniert wieder, 01:28 Uhr