USB Eruptor stabile Leistung

[Constructor]

Hallo, ich benutze 60 USB Eruptor auf 6 Anker gut gekühlt.
Das Ganze lass ich bei Slush's laufen. Leider bekomme ich keine stabile Leistung.
Die zu erwartende Vergütung schwankt zwischen 0,007 bis 0,01 und das innerhalb von Sekunden.
Dabei scheint es keine Rolle zu spielen, ob die Cluster-Performance bei 58000.000 oder 49000.000 Gh/s liegt.
Die von mir generierten Mh/s liegen zwischen 17000.000 und 23000.000. So wird es da jedenfalls angegeben. 
Ich benutze den cgminer 3.4.2 und bekomme dauerhaft ca. 20.16 Gh/s angezeigt.
Ist das normal, oder mache ich irgendwas falsch?
Ich habe auch das Gefühl, dass es egal ist ob ich von Anfang bis Ende mitmache oder kurz vor der Lösung eines Blocks einsteige, die Vergütung bleibt gleich.
Ich hoffe das mir jemand weiterhelfen kann.

[Nigeria Prince]

Nimm bfgminer.

[BitLex]

Die von mir generierten Mh/s liegen zwischen 17000.000 und 23000.000. So wird es da jedenfalls angegeben. 
Ich ... bekomme dauerhaft ca. 20.16 Gh/s angezeigt.

na, das passt doch.
der pool zeigt dir 17-23GH an, dein miner zeigt dir dauerhaft ziemlich genau den durchschnitt der anzeige des pools, eben 20GH.

du wirst im pool nie eine "stabile leistung" sehen, da dein glück nunmal nicht "stabil" ist.
der pool weiß ja nicht, wie schnell dein miner läuft, der weiß nur, wieviele shares du in einem bestimmten zeitraum gefunden hast und berechnet danach die leistung, die er dir dann anzeigt.
die schwankung ist dein glück, mal findest du ein paar shares mehr, mal ein paar weniger, das nennt sich "varianz".

deine mining-software zeigt dir aber die aktuelle leistung an, sie sagt dir genau, wieviele hashes pro sekunde sie durchprobiert und zählt nicht nur die gefundenen shares, also diejenigen hashes, die sie an den pool sendet.

kurz: du machst nix falsch und das ist völlig normal

[Constructor]

(25 BTC + block fees - 2% fee) * (shares found by user's workers) / (total shares in current round)
Wobei ich keine Ahnung habe was "block fees" sind.
Ich habe das so verstanden, dass mit "shares found by user's workers" die gesamte Anzahl der produzierten "shares" gemeint ist und nicht nur ein bestimmter kleiner Zeitraum.
Macht es also keinen Unterschied ob ich nun zB. 3 St. Mine oder 10 Min. vor Lösung eines Blocks einsteige?
Das mit der "varianz" habe ich auch noch nicht verstanden. Ist damit die "Stichprobenvarianz", "korrigierte Stichprobenvarianz" oder "Totale Varianz" gemeint. Bei den Berechnungen wird mir ja schwindlig.
Mir kam die Schwankung halt sehr groß vor, 0,002 auf 50 gelösten Blocks sind immerhin 0,1 BTC und das bei gefühlter konstanter Leistung.
Ich sehe schon, da muss ich noch einiges lernen

Nimm bfgminer

Hab ich auch schon probiert. Macht erstens keinen Unterschied und zweitens blitzen bei dem nach ca. 20 Sec. alle USB Eruptor gleichzeitig auf, was ich sehr irritieren finde.
Und noch ne Frage. Was hat es mit "Suggested difficulty" auf sich. Hab ich da Vorteile oder Nachteile wenn ich die höher stelle?

[BlueHawaii]

(25 BTC + block fees - 2% fee) * (shares found by user's workers) / (total shares in current round)
Ich habe das so verstanden, dass mit "shares found by user's workers" die gesamte Anzahl der produzierten "shares" gemeint ist und nicht nur ein bestimmter kleiner Zeitraum.

"shares found by user's workers" = Deine beigetragenen Shares
"total shares in current round" = Shares des kompletten Pools

... immer bezogen auf die aktuelle Runde

Macht es also keinen Unterschied ob ich nun zB. 3 St. Mine oder 10 Min. vor Lösung eines Blocks einsteige?

Ausschlaggebend ist die Anzahl Deiner Shares, denn diese sind der Multiplikator zur Berechnung Deiner Vergütung.
Je mehr Shares Du beisteuerst, um so höher ist Deine Auszahlung. Wann Du Deine Rechenleistung in die Runde einbringst ist unerheblich.
Wichtig ist also nicht das "wann", sondern das "wie lange" 

[Constructor]

Gestern gab es eine Runde die 14:02:10 Stunden gedauert hat.
Die ungefähre Cluster-Performance lag zu Anfang bei 53000.000 Gh/s, was in laufe der zeit auf ca 58000.000 Gh/s gestiegen ist.
Meine Vergütung war zwischen 0,01 und 0,007.
Dann gab es Runden mit einer Cluster-Performance von ca. 49000.000 Gh/s.
Meine Vergütung war zwischen 0,01 und 0,007.
Ich war immer von Anfang bis Ende dabei.
Bei einer höheren Cluster-Performance sollte man doch von mehr gemeinsam erzeugten Shares ausgehen und andersrum.
Entschuldige meine Verwirrung, aber wieso komme ich dann immer auf die gleiche Vergütung?

[BitLex]

(25 BTC + block fees - 2% fee) * (shares found by user's workers) / (total shares in current round)
Wobei ich keine Ahnung habe was "block fees" sind.

"block fees" sind die gebühren, die von den bitcoin-nutzern für jede transaktion bezahlt werden

Ich habe das so verstanden, dass mit "shares found by user's workers" die gesamte Anzahl der produzierten "shares" gemeint ist und nicht nur ein bestimmter kleiner Zeitraum.

na klar ist damit die gesamte anzahl der shares gemeint,
das hat aber nichts mit der dir angezeigten hashleistung (also den GH/s) zutun, die wird meist nur über einen bestimmten zeitraum (bspw. 1std) berechnet.
das eine sind äpfel, das andere birnen, du mischt beides.

Macht es also keinen Unterschied ob ich nun zB. 3 St. Mine oder 10 Min. vor Lösung eines Blocks einsteige?

das kommt darauf an, wieviele shares du ablieferst.
wenn du nur 2shares findest, spielt es keine rolle, ob du dafür 3std, oder nur 10min gebraucht hast, du bekommst anteilig 2shares bezahlt.
wie hoch dein anteil bei 2shares ausfällt, hängt natürlich davon ab, wieviel shares insgesamt von allen usern abgeliefert wurden.

Das mit der "varianz" habe ich auch noch nicht verstanden. Ist damit die "Stichprobenvarianz", "korrigierte Stichprobenvarianz" oder "Totale Varianz" gemeint. Bei den Berechnungen wird mir ja schwindlig.

nochmal: "varianz" = dein glück
das hat nichts mit stichproben, oder korrekturen zutun,
du findest nunmal nicht immer gleichschnell einen share, auch wenn die wahrscheinlichkeit gleich bleibt.
hast du pech findest du 1std keinen share, hast du glück findest du 3shares in 5min.
das gleiche gilt ja auch für die blöcke, die vom pool gefunden werden, mal dauert das 14std, mal nur wenige minuten.


und deine vergütung berechnet sich wahrscheinlich (ich nutze slush nicht) nichtnur durch die shares im letzten block, sondern verteilt über die letzten N blöcke (PPLNS oder so ähnlich), dadurch verteilt sich die schwankung über mehrere blöcke und deine vergütung scheint gleich/ähnlich, auch wenn die "cluster-performance", oder die zeit, die du am aktuellen block aktiv warst, sich ändert.


mach dir da mal keinen kopf,
beobachte lieber deine erträge pro tag (die auch erheblichen schwankungen unterlegen sind) und vergleiche die mit den theoretisch möglichen erträgen bei deiner (von cgminer angezeigten) hashleistung (dafür gibts genug mining-rechner).

[Constructor]

Danke für die wirklich ausführliche Erklärung.
Ich denke nun hab ich´s verstanden

[trasla]

Macht es also keinen Unterschied ob ich nun zB. 3 St. Mine oder 10 Min. vor Lösung eines Blocks einsteige?

Ausschlaggebend ist die Anzahl Deiner Shares, denn diese sind der Multiplikator zur Berechnung Deiner Vergütung.
Je mehr Shares Du beisteuerst, um so höher ist Deine Auszahlung. Wann Du Deine Rechenleistung in die Runde einbringst ist unerheblich.
Wichtig ist also nicht das "wann", sondern das "wie lange" 

Das stimmt bei Slush' Pool nicht.
Shares später in der Runde werden höher gewertet.

Die Vereilung findet nicht auf Basis der Shares statt, sondern auf Scores. Deine Shares verdienen dir Punkte, und die Anzahl Punkte pro Share steigt ständig an. Oder andersrum formuliert, der Wert deiner schon geleisteten Shares verfällt mit der Zeit. Damit kriegst du also, wenn du nur am Ende einer Runde dabei bist fast so viel oder das gleiche, wie wenn du durchgängig da bist. Das ist absicht, damit kein Pool-Hopping betrieben wird, du sollst nicht nur am Anfang jeder Runde mitmachen und zu nem anderen Pool wechseln, sobald die Runde dir zu lange dauert.

Daher kommen auch ggf. deine Schwankungen bei der Vergütung - wenn du Glück hast und direkt am Ende der Runde ein paar mehr shares übermittelst, ist dein Ertrag höher, kommen zufällig am Ende der Runde weniger shares als durchschnittlich von dir, kriegst du weniger. Das gleicht sich aber über ein paar Runden gegenseitig aus.



Die Difficulty, die du einstellen kannst, sorgt dafür, dass dein miner mehr oder weniger shares an den Server sendet (bei höherer diff weniger), wodurch die Last auf dem Netzwerk verringerst. Dein Ertrag bleibt durchschnittlich gleich, die Varianz steigt dadurch, also es schwankt etwas stärker. Inzwischen ist aber eigentlich auch die automatische Diff-Anpassung aktiv, dein miner sollte also über stratum ohnehin eine an die Hash-Leistung deines Workers angepasste diff gesetzt kriegen.

[trasla]

und deine vergütung berechnet sich wahrscheinlich (ich nutze slush nicht) nichtnur durch die shares im letzten block, sondern verteilt über die letzten N blöcke (PPLNS oder so ähnlich), dadurch verteilt sich die schwankung über mehrere blöcke und deine vergütung scheint gleich/ähnlich, auch wenn die "cluster-performance", oder die zeit, die du am aktuellen block aktiv warst, sich ändert.

Ajo, und bei SLush sind es tatsächlich nur die shares eines blocks kein PPLNS sondern wie oben geschrieben sein eigenes System der zunehmenden Scores per Share.

[Constructor]

Es mag ja gegen das Pool-Hopping helfen, aber so richtig kann ich mich nicht damit anfreunden.
Ich möchte ja von einer dauerhaft gebrachten Leistung was haben, also einen Vorteil gegenüber denen die erst später eingestiegen sind.
Es ist doch etwas befremdlich wenn man Stunden mitgemacht hat und am Ende in die Röhre guckt, weil in dem Moment wo der Block gelöst wird etwas weniger Shares produziert werden.
Vielleicht sollte die Gewichtung mehr auf der erbrachten Gesamtleistung liegen.
Vorher war ich bei bitminter.com. Da hat man auch einen Score, der wird aber über die gesamte Leistung (auch Block übergreifend) berechnet und war einfacher auszurechnen (25 * Score / 100) jedenfalls so ungefähr.
Die Difficulty wird wohl automatisch gesetzt (cgminer: diff 13 with stratum), ist wohl egal was ich da einstelle.
Ist aber gut zu wissen, dass ich nicht an der Bitcoinerittis erkrankt bin und meine Beobachtungen doch nicht so falsch wahren  

[BlueHawaii]

Macht es also keinen Unterschied ob ich nun zB. 3 St. Mine oder 10 Min. vor Lösung eines Blocks einsteige?

Ausschlaggebend ist die Anzahl Deiner Shares, denn diese sind der Multiplikator zur Berechnung Deiner Vergütung.
Je mehr Shares Du beisteuerst, um so höher ist Deine Auszahlung. Wann Du Deine Rechenleistung in die Runde einbringst ist unerheblich.
Wichtig ist also nicht das "wann", sondern das "wie lange"  

Das stimmt bei Slush' Pool nicht.
Shares später in der Runde werden höher gewertet.

OK, wusste ich nicht ...  wieder was dazu gelernt

[Constructor]

Leider fehlt mir noch der Durchblick (PPLNS, PPS, PPS/PPLNSG shared on PPLNSG... ).
Wo währe ich denn mit der Rechenleistung am besten aufgehoben?

[h2o@7970]

Leider fehlt mir noch der Durchblick (PPLNS, PPS, PPS/PPLNSG shared on PPLNSG... ).
Wo währe ich denn mit der Rechenleistung am besten aufgehoben?

ist doch ganz einfach, deine 60 sticks für 4 Wochen aufteilen zb. so

20 x zu btcguild
20 x zu eligius
20 x zu aka Slush's

für mich 1. aka Slush's pool -> 2. btcguild -> eligius

[Constructor]

Werde wohl erst mal bei Slush's bleiben, bis auf die angesprochene Sache finde ich den Pool ganz gut und ab jetzt habe ich 70 Sticks .
Eine Aufteilung kann ich sowieso vergessen, denn bei mir steht in "Geräte und Drucker" nur "CP2102 USB to UART Bridge Controller" (kein (COM1), (COM2) ...).
Daher kann ich die einzelnen Sticks keiner bestimmten Instanz vom cgminer zuweisen.
  Ich finde es aber klasse wie mir hier als Neuling vorbehaltslos weitergeholfen wird!  

[trasla]

Es mag ja gegen das Pool-Hopping helfen, aber so richtig kann ich mich nicht damit anfreunden.
Ich möchte ja von einer dauerhaft gebrachten Leistung was haben, also einen Vorteil gegenüber denen die erst später eingestiegen sind.
Es ist doch etwas befremdlich wenn man Stunden mitgemacht hat und am Ende in die Röhre guckt, weil in dem Moment wo der Block gelöst wird etwas weniger Shares produziert werden.

Naja, du schaust nicht in die Röhre, es schwankt halt mal etwas hoch und mal etwas runter.
Das tut es bei anderen Systemen auch, weil du ja nicht gleichmäßig shares lieferst, unterschiedlich ist halt, wie stark es schwankt.

Und der Trick ist, dass niemand vorher wissen kann, wann die Runde endet, also kann man nicht absichtlich nur am profitableren Ende der Runde minen.
Wenn es über die gesamte Zeit gleichmäßigen Ertrag gäbe, wäre es möglich, immer nur am Anfang der Runde zu minen, und nach einer bestimmten Zeit den Pool zu wechseln.
Damit wäre der durchschnittliche Ertrag höher.
Ich will das hier garnicht weiter ausbreiten, wenn du nach "Pool Hopping" suchst, findest du schnell ausführliche Erklärungen dazu - auch zu den verschiedenen Vergütungsmodellen der Pools, die das verhindern sollen.

[trasla]

Eine Aufteilung kann ich sowieso vergessen, denn bei mir steht in "Geräte und Drucker" nur "CP2102 USB to UART Bridge Controller" (kein (COM1), (COM2) ...).
Daher kann ich die einzelnen Sticks keiner bestimmten Instanz vom cgminer zuweisen.

Du kannst entweder bei cgminer als flag --usb :10 anhängen, dann nimmt er nur 10 Sticks, und dann ne neue Instanz mit den nächsten 10 starten usw.
Oder du stellst mehrere Pools ein, und von failover auf load balance, dann teilt die eine cgminer Instanz deine Rechenleistung auf die Pools auf.

(Mehrere Pools mit Failover ist ohnehin sinnvoll, dann wechselt cgminer auf den zweiten Pool, falls Slush mal down sein sollte, und automatisch zurück, sobald es wieder geht - dadurch verlierst du keine Rechenzeit, falls es mal Probleme beim Pool gibt...)

[Constructor]

Ich will das hier garnicht weiter ausbreiten, wenn du nach "Pool Hopping" suchst, findest du schnell ausführliche Erklärungen dazu - auch zu den verschiedenen Vergütungsmodellen der Pools, die das verhindern sollen.

Ich werde mal versuchen mich einzulesen. Da ich aber kaum Englisch kann, ist das nicht immer so einfach.

Du kannst entweder bei cgminer als flag --usb :10 anhängen, dann nimmt er nur 10 Sticks, und dann ne neue Instanz mit den nächsten 10 starten usw.

Das hatte ich schon versucht, da ist der cgminer total ausgeflippt und hat was von Mehrfachverwendung erzählt.
War eventuell auch falsch von mir deklariert:
1 Instanz: -u xxx -p xxx --usb :10
2 Instanz: -u xxx -p xxx --usb :10
oder hätte ich 11-20 schreiben müssen?
das mit "load balance" klingt aber sehr interessant.

[trasla]

Ich will das hier garnicht weiter ausbreiten, wenn du nach "Pool Hopping" suchst, findest du schnell ausführliche Erklärungen dazu - auch zu den verschiedenen Vergütungsmodellen der Pools, die das verhindern sollen.

Ich werde mal versuchen mich einzulesen. Da ich aber kaum Englisch kann, ist das nicht immer so einfach.

Wenn du konkrete Fragen hast, immer raus damit.
Es wäre nur ziemlich umständlich, alles zu erklären, wenn es doch schon öfter schön aufgeschrieben wurde

Du kannst entweder bei cgminer als flag --usb :10 anhängen, dann nimmt er nur 10 Sticks, und dann ne neue Instanz mit den nächsten 10 starten usw.

Das hatte ich schon versucht, da ist der cgminer total ausgeflippt und hat was von Mehrfachverwendung erzählt.
War eventuell auch falsch von mir deklariert:
1 Instanz: -u xxx -p xxx --usb :10
2 Instanz: -u xxx -p xxx --usb :10
oder hätte ich 11-20 schreiben müssen?
das mit "load balance" klingt aber sehr interessant.

Ne, das ist schon richtig so - ensprechend hab ich das bei mir auch.
Der meckert beim Start vom zweiten halt, dass die Teile schon in Verwendung sind, und probiert dann so lange neue, bis er genug hat.

Du solltest natürlich bei den zwei Instanzen unterschiedliche Worker in deinem Pool nehmen, hast du das?
Ansonsten versuch einfach mal, zwei Pools anzugeben (einfach die gleichen Flags nochmal mit anderen Daten dran hängen) und dann in den Settings von Failover auf Load Balance umstellen.

[Constructor]

Hab´s gerade mal ausprobiert.
Leider gibt er jetzt "Filed to list usb devices with err -8" aus.
Das hat wohl nix mit den Einstellungen zu tun, dass macht er immer wenn man versucht meht als 60 Sticks an einem Rechner zu starten.
Und ja, ich habe 2 Worker, Rechner 1 mit 60 Sticks, Rechner 2 derzeit mit 10 Sticks.
Ich werde es wohl erstmal so wie vorher laufen lassen, da hat es ja ganz gut geklappt.