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

[molecular]

Gerade in dieser Hinsicht habe ich mich auch schon gefragt: Wie sieht es eigentlich mit der Transparenz ein? Ist sowas überhaupt festzustellen? Wie weiss ich das ein Poolbetreiber nicht betrügt?

Eigentlich müsste man das im miner einbauen können:

1.) miner besorgt sich irgendwoher die "echte" difficulty
2.) bei gefundener nonce wird einfach geprüft, ob hash < "echte difficulty",
  falls ja: output "BLOCK found, please check if pool announced a block"
  falls nein: weiter wie bisher

nicht wahr?

[redhatzero]

Ja das wäre eine Idee, um ganz sicher zu gehen, müssten das natürlich alle Miner in einem Pool benutzen

[O_Shovah]

Kurzes update zur sidebar:

Die graphen sind zwar mittlerweile schön detailiert  aber die Hashrate in der sidebar ist seitdem irgendwo
die war vor dem update bei mir wesentlich näher um die hashrate herum die von meinen miners angezeigt wird.

Da könntest du vllt bitte den Durchschnittszeitraum wie auf ne halbe oder sogar ganze Stunde raufschrauben. 

[ewibit]

Die graphen sind zwar mittlerweile schön detailiert  aber die Hashrate in der sidebar ist seitdem irgendwo
die war vor dem update bei mir wesentlich näher um die hashrate herum die von meinen miners angezeigt wird.

meinst du da die Per Worker MHashrate?
gibt es dafuer irgendwo eine Erklaerung?
denn meine Kurven schwanken von ca. 10 bis ca. 240, obwohl bei mir ziemlich konstant 234 angezeigt wird....
- oder sagen die Kurven irgendetwas anderes aus?

TIA

[O_Shovah]

Das Pool misst deine Hashrate an der Anzahl der shares die du in einem gewissen Zeitfenster einschickst.

Da dein Miner aber für manche shares länger und manche kürzer braucht entsteht beim pool bei klein genugem messfenster der Eindruck
das deine rates ganz stark schwanken obwohl dein miner fast imme gleich schnell arbeitet.

Dagegen hilft eingentlich nur wenn im pool das messfenster groß genug ist um die schwankungen auszugleichen.

Genau das hab ich in meinem post anregen wollen  weil meine hashrate fährt laut graph auch achterbahn.   

[Mineriner]

Genau das hab ich in meinem post anregen wollen  weil meine hashrate fährt laut graph auch achterbahn.   

Meiner durchschlägt gelegentlich sogar die Nulllinie, was solls

Dagegen hilft eingentlich nur wenn im pool das messfenster groß genug ist um die schwankungen auszugleichen.

Allem Anschein nach wird gerade nur "every x min one snap" verwendet - habe deswegen auch schon überlegt, für jede GPU einen eigenen Miner anzulegen, nur um zu sehen, wie sich der Graph dann verhält.

[yetis]

Die Pool-Hashrate im Graphen stimmt nicht mit der Geschwindigkeit überein, die oben rechts auf der Webseite angezeigt wird.
Sie ist immer ~2 Ghash kleiner.

[turbofoen]

hab mich auch mal angemeldet...

[Mineriner]

Die Pool-Hashrate im Graphen stimmt nicht mit der Geschwindigkeit überein, die oben rechts auf der Webseite angezeigt wird.
Sie ist immer ~2 Ghash kleiner.

Ist mir auch schon aufgefallen, auch meine Single Hashrate pendelt gelegentlich zwischen -0 bis 1200 MHash/s
Mittelt sich aber in einem "gesunden" Bereich um die 1000 Mhash/s, wo sie auch passt.

[Mineriner]

@redhatzero:
Ist ein verringertes Polling möglich, z.b. alle 5 Minuten pro Worker, ohne den Server "Mitarbeitermäßig" in die Knie zu zwingen?

Dazu aber auch gemittelte Werte innerhalb der 5 Minuten als Grundlage für das nächste Polling, damit die Anzeige mal annähernd genau wird

[slammed]

mal eine frage zu dem Pool, wie funktioniert das mit der aufteilung der BTC, wenn einer mit 3g/hash drauf ist bekommt er doch mehr als der der 1g/hash hat oder ?

wenn a z.b allein 30 % der blöcke bearbeitet hat bekommt er dann auch 30 % von den 50 BTC ?

[Chefnet]

japp genau so

[lt.cmdr.data]

jein, von den 50BTC werden 1% =0,5BTC als "Gebühr" im Pool behalten (d.h. die gehen an den Poolbetreiber). von den restlichen 49,5BTC erhält der miner dann seinen %-Anteil vom gesamt geschürften Anteil an BTC.
Ist ja auch nur fair, denn

1. mit hoher Hashrate hast Du höhere Investitions-/Stromkosten
2. die hohen Hashraten helfen dem Pool überhaupt was zu finden

von letzterem profitiert ja auch der kleine Miner, der nur 5MH/s hat, denn ohne die großen würde er sehr wahrscheinlich nie was finden und so bekommt er trotzdem (wenn auch nur einen kleinen Teil) vom gefundenen Kuchen ab.

[mipl]

1. mit hoher Hashrate hast Du höhere Investitions-/Stromkosten
2. die hohen Hashraten helfen dem Pool überhaupt was zu finden

Praktisch ja, theoretisch nein.
Mal ganz platt ausgedrückt: Mit 1 MHash/s für 500,- EUR und 1 kWh findest Du 50 BTC in 1 Jahr... bei 2 MHash/s für 1000 EUR sind es entsprechend 2 kWh und 50 BTC nach einem halben Jahr... also dasselbe Ergebnis. In der Praxis spielen da natürlich andere Dinge rein, schnelle GPUs produzieren zB mehr Hashes/kWh, zwei GPUs pro PC != 2*kWh usw...

[redhatzero]

wegen den Worker Graphen:

ich würd vorschlagen, dass ich wieder "Shares pro X Minuten" anzeige, statt MHash... Nachdem die MHash Anzeige ja eh recht ungenau ist, halte ich Shares als das 'handfestere'

Was meint ihr?

[redhatzero]

Ach übrigens.... so wie's ausschaut:

http://blockexplorer.com/b/133342

 =)

Das wäre dann Nr.3 =)

[minime]

wer hatn gefunden?

[minime]

wer hatn gefunden?

@readhatzero vielleicht könntest du ja mal bei den pool statistiken oder so die finder der/des letzten blocks anzeigen...??

[redhatzero]

gangstarasp war's

minime: hm, jo das wäre eine Idee. Zusätzlich bastel ich auch grad an den öffentlich erreichbaren Profil Seiten/About me/etc. wie man's nennen mag. Da wird's dann auch ein "Gefundene Blöcke geben"

[lt.cmdr.data]

Hi!

Wieso "schaltet" der Pool nicht automatisch in die nächste Runde, wenn ein Block gefunden wurde? Oder ist das nur ein Anzeigeproblem? Sprich rechnen die miner unnötig weiter, oder wird alles nach dem Finden eines Blocks in die nächste (noch nicht angezeigte Runde) übertragen?