Topic: German BTC PoolParty League (Read 2933 times)

Naja dein Pool braucht 17.4 Sekunden um den nächsten Block zu holen  Liegt sicher nicht an der Difficulty.

naja, nicht so wirklich optimiert :-)

Powered by P2Pool Version: 11.3-1-g81a3613-dirty

Pool rate: 699GH/s (19% DOA+orphan) Share difficulty: 1280

Peers: 6 out, 21 in

Shares: 50 total (12 orphaned, 10 dead) Efficiency: 68.91%

jo, je mehr die diff steigt je schlimmer wird das.

Hi,

Pool efficency ist nur bei 90 % , solltest du dir mal angucken.

kleines Update : 
Hab ein paar Optimierungen durchgeführt auf meinem Server und die Getblocktemplate Latenz gesenkt.
Habe dazu Blockgröße und Verbindungen limitiert.

Werde mich aber mal nach einem SSD Hoster erkundigen, wo hostest du xhabit?

klingt interessant, ich mach mal mit zum test *klick*
;-)

ok thx, kannst du bei Gelegenheit mal schauen wie viel für den bitcoin client & p2pool drauf gehen?

also, ich nutze aktuell 2Gb für denn PoolServer. Aber die Nutzt er nicht.

die Liste ist ja fest in deutscher Hand  

EDIT:
Will demnächst auch mal etwas mit p2pool rumspielen.
Wieviel RAM sollte ich dafür einplanen ?

UPDATE:

Ich habe den NodeServer auf aktuelle die Build-Version aktualisiert. Weiterhin habe ich einige Parameter verändert.
Ich hoffe das wird einiges der anvisierten 0.10ms GetworkLatency entgegen kommen. Die Difficult ist erneut gestigen! Lieder!
Diese wird aber in denn kommen Wochen/Monaten dramatisch weiter steigen. Ich hoffe das für alle Nutzer "German BTC PoolParty League" weiterhin ein passabler Ertrag zu erzielen ist. Aktuell, mit meiner eigenen HashRate sieht es ehr schlecht aus. :-( Aber so ist das Leben.  

Auf bitcoinchain.info wird der Node als "Hub Nodes - Eine Liste der am besten verbundenen Bitcoin-Superknoten" http://blockchain.info/de/hub-nodes geführt, aber es geht aktuell Abwärts!

Ich hoffe hier wieder aufzuholen.

Lieber Gruß,
xhabit.

Ich probier mal was auf meinem Server , wenn die Blockchain synchronisiert ist , melde mich dann morgen bei dir zwecks Optimierungen.

oh, bist du jetzt mit 1Gh/s dazu gekommen? Naja, da bin ich mal gespannt, wie sich die Serverstatis verändern.

Aber was die Jungs dort auch schreiben!

The latency seems directly linked to the IO capacity of the medium on which your bitcoind datadir is (by default the .bitcoin subdirectory of the user running bitcoind on Linux systems).
The worst solutions is a traditional platter-based disk at 7200rpm or less which is heavily used by other tasks.
A much better one is a dedicated disk (almost no other disk activity happens on it).
A SSD, even shared with other tasks, is even better.
The fastest is a filesystem based on RAM instead of a storage medium.

also, wäre es in diesem Punkt am besten anzusetzen. und hier noch mal trennen - i/o medium vom server.
ich muesste mal schauen wie ich das machen könnte. mit der server Konstellation.

schoen, wenn du dich auch einliest ... das mache ich auch. lass uns doch beide zusammen einen perfekten node bauen ;-)
klar und frankfurt wäre noch besser im moment sitze ich bei qsc mit dem server an denn Leitungen.

^{Was sind Gründe für die hohe Latenz bei GetBlockTemplate , müsste ja quasi bei 0 sein , wenn p2pool und bitcoind beide auf einer Ramdisk sitzen.}

diese frage stelle mich mir auch. und ich bin für jede idee offen die kiste noch schneller zu bekommen.

Du hast nicht ganz Verstanden was ich ausdrücken wollte. Man nehme diese Seite : http://pool.port-x.de:9332/static/graphs.html?Month und suche Bitcoind GetBlockTemplate Latency.

Dann nimmt man https://bitcointalksearch.org/topic/a-guide-for-mining-efficiently-on-p2pool-includes-fud-repellent-and-faq-153232 , sucht nach Bitcoind latencies and I/O latencies.

Als nächstes betrachtet man dieses Zitat :

Im nächsten Schritt vergleicht man seine eigene Latency mit der aus dem Zitat. Dann denkt man nochmal über eine Ramdisk nach.

Außerdem sagst du dass der ganze Server in einer Ramdisk läuft, also ein Virtueller Server komplett in Ram. Da stellen sich mir ein paar Fragen :

Ist bei einem Neustart nicht alles gelöscht? (mögliche Antwort : Nein , das wird extern gespeichert oder synchron gehalten.)

Was sind Gründe für die hohe Latenz bei GetBlockTemplate , müsste ja quasi bei 0 sein , wenn p2pool und bitcoind beide auf einer Ramdisk sitzen.

Was haben deine Miner zuhause mit GetBlockTemplate auf dem Server zu tuen?(einzige richtige Antwort : nichts. )

Sorry , deine Posts mit der Latenz und wie wichtig die doch sind haben mich bei meinen eigenen Recherchen doch etwas stutzig gemacht. Und ein ideales Backbone für alle wäre nicht in Berlin sondern in Frankfurt in der Nähe vom oder am DE-CIX.

Edit : Ich bin auch Informatiker, grüße.

naja, da der ganze server in einer ramdisk läuft brauche ich das nicht doppelt zu machen. ich habe in berlin einen provider gewählt welcher direkt auf einem backbonknoten sitzt. auf dem server rennt kein miner.  um performance zu bekommen und eine top anbindung. meine miner stehen zuhause.

Ja, keine Ahnung mehr wohin der Ping ging hab sogar 22 ms von hier bekommen. alles im grünen Bereich. Apopros Festplatte , mal an eine Ramdisk für die Blockchain gedacht um die Getwork-Latenz weiter zu verringern ? Weiß jetzt nicht wieviel Sinn das ergibt außerhalb von einem Lan und mindestens 10 Gigabyte müsste man dafür einplanen. Ist allerdings ne interessante Überlegung.
 

ich weiss jetzt nicht wohin du gepingt hast ...

^{ping pool.port-x.de
PING exvm.port-x.de (212.21.75.89): 56 data bytes
64 bytes from 212.21.75.89: icmp_seq=0 ttl=55 time=33.792 ms
64 bytes from 212.21.75.89: icmp_seq=1 ttl=55 time=24.550 ms
64 bytes from 212.21.75.89: icmp_seq=2 ttl=55 time=26.245 ms}


Mit Lantenz ist gemeint, wie, schnell bekomme ich Arbeit. Und wie schnell werde ich das Ergebnis los. Beides erreiche ich am besten
wenn ich einen PoolServer zuhause stehen habe. Nun ist die Frage wie schnell wird mein Ergebnis im PoolNetz geprüft und das
Ergebnis meiner PayOut Add zugeordnent. Sprich möglichst wenig (10 orphaned, 4 dead) Shares erzeugen. Das sollte möglichst so gering wie möglich sein. Erreichen kann man das durch eine sehr gute Anbindung, ich vergleiche es mal mit Lese/Schreibzugriff auf einer Festplatte. Also je schneller ich im Netz meine Arbeit Annonciere und Erhalte je besser rennen die Miner. Im Moment ist das alles noch Moderat. Je mehr Superminer ins Spiel kommen wird diese Latenz immer wichtiger. Und je besser ein PoolNode abgestimmt ist je besser Läuft das ganze.

Welchen Pool oder welche Art Pool jemand für sich Favorisiert ist seine Entscheidung. Auch bei meiner Poolserver Variante (wie ich
sie errichtet habe) Schürft niemand eigentlich bei mir sondern im P2Pool Netz. Da ich Auszahlungen nicht beeinflussen kann sowie auch
nicht die Höhe der gefunden Shares eines Miners. Kann man bei jedem P2Pool Server Minen, es wird immer das gleiche bleiben. Das was ich mache, ist das Server, Poolsoft, Bitcoind etc. mit seinen Parametern versuche auf Höchstleistungen zu Trimmen. Um so die Chancen zu erhöhen eben mehr Shares erfolgreich zu ergattern. Nur weil der Miner Sagt Shares Accepted meint das noch nicht das dass P2Pool Netz das genauso sieht.

lieber gruss,
xhabit

UPDATE:

Dank für die, die dazugekommen sind!!!!

Aber 6Gh/s ist das Minimum +/- ... Um anzufangen an denn Schrauben zu drehen.

alles liebe,
xhabit

grins, wenn Du es selbst ausprobiert hast. Dann wirst Du zwangsläufig zu denn gleichen Schlüssen kommen. das mehr Gh/s mehr Traffic bedeutet. Mehr Traffic je schneller muss propagiert werden. Mehr Ertrag zieht zwangsläufig mehr Abgaben nach sich.
Mehr Traffic kostet mehr und Verdienen wollen die Jungs auch noch. Deutschland hat ein gut ausgebautes Backbone Netz je mehr Nodes die auf einen Konten sitzen, je besser für alle. Ob ich recht habe, oder nicht. es ist eine Rechenaufgabe wo im Ergebnis nur ein Zuwachs raus kommt. Aber das wird die Zeit zeigen.