Bitcoin Forum
December 03, 2016, 12:41:10 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 [45] 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 »
  Print  
Author Topic: Deutschsprachiger Pool btc.x8s.de ~110Ghash/s  (Read 161272 times)
gentakin
Member
**
Offline Offline

Activity: 98


View Profile
July 06, 2011, 09:50:31 PM
 #881

Okay, das klingt dann irgendwie gut. Smiley

1HNjbHnpu7S3UUNMF6J9yWTD597LgtUCxb
1480725670
Hero Member
*
Offline Offline

Posts: 1480725670

View Profile Personal Message (Offline)

Ignore
1480725670
Reply with quote  #2

1480725670
Report to moderator
1480725670
Hero Member
*
Offline Offline

Posts: 1480725670

View Profile Personal Message (Offline)

Ignore
1480725670
Reply with quote  #2

1480725670
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480725670
Hero Member
*
Offline Offline

Posts: 1480725670

View Profile Personal Message (Offline)

Ignore
1480725670
Reply with quote  #2

1480725670
Report to moderator
1480725670
Hero Member
*
Offline Offline

Posts: 1480725670

View Profile Personal Message (Offline)

Ignore
1480725670
Reply with quote  #2

1480725670
Report to moderator
yetis
Member
**
Offline Offline

Activity: 112


View Profile
July 06, 2011, 09:57:02 PM
 #882

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
Member
**
Offline Offline

Activity: 112


View Profile
July 06, 2011, 10:03:46 PM
 #883

x8s down?

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

Intertreuton
Member
**
Offline Offline

Activity: 65



View Profile
July 06, 2011, 10:06:03 PM
 #884

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? Huh
Na wie auch immer, macht weiter mit euerm TechTalk, kann man ja nur von lernen Wink
redhatzero
Full Member
***
Offline Offline

Activity: 126



View Profile
July 06, 2011, 10:08:38 PM
 #885

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 Smiley

redhatzero
Full Member
***
Offline Offline

Activity: 126



View Profile
July 06, 2011, 10:16:00 PM
 #886

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? Huh
Na wie auch immer, macht weiter mit euerm TechTalk, kann man ja nur von lernen Wink

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
Member
**
Offline Offline

Activity: 112


View Profile
July 06, 2011, 10:19:19 PM
 #887

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 Smiley

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. Wink (Wg. Blockbekanntgabe, etc.)

redhatzero
Full Member
***
Offline Offline

Activity: 126



View Profile
July 06, 2011, 10:25:07 PM
 #888

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
Member
**
Offline Offline

Activity: 112


View Profile
July 06, 2011, 10:26:00 PM
 #889

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? Huh
Na wie auch immer, macht weiter mit euerm TechTalk, kann man ja nur von lernen Wink

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
Full Member
***
Offline Offline

Activity: 126



View Profile
July 06, 2011, 10:26:30 PM
 #890

Y ist ne arme Sau Sad

yetis
Member
**
Offline Offline

Activity: 112


View Profile
July 06, 2011, 10:29:39 PM
 #891

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
Full Member
***
Offline Offline

Activity: 126



View Profile
July 06, 2011, 10:30:56 PM
 #892

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
Member
**
Offline Offline

Activity: 112


View Profile
July 06, 2011, 10:36:03 PM
 #893

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
Full Member
***
Offline Offline

Activity: 126



View Profile
July 06, 2011, 10:38:58 PM
 #894

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 Wink wenn du x8s pingen willst, dann ping btc.x8s.de an

yetis
Member
**
Offline Offline

Activity: 112


View Profile
July 06, 2011, 10:45:25 PM
 #895

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 Wink wenn du x8s pingen willst, dann ping btc.x8s.de an


Ok. Sind beide gleichschnell zu mir.

yetis
Member
**
Offline Offline

Activity: 112


View Profile
July 06, 2011, 10:56:55 PM
 #896

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

yetis
Member
**
Offline Offline

Activity: 112


View Profile
July 06, 2011, 11:08:02 PM
 #897

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
Sr. Member
****
Offline Offline

Activity: 353



View Profile
July 06, 2011, 11:17:43 PM
 #898

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
Member
**
Offline Offline

Activity: 112


View Profile
July 06, 2011, 11:21:45 PM
 #899

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
Full Member
***
Offline Offline

Activity: 126



View Profile
July 06, 2011, 11:24:18 PM
 #900

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
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 [45] 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!