-0.01 BTC. Musste man ja mal ausprobieren --> langweilig.
dito.
|
|
|
hallo.
ich würde mich gern an der sammelbestellung beteiligen mit einer einheit. bitte, falls jemand schon eine sammelbestellung koordiniert schreibt mir eine pm.
wenn man den preis von 88 btc im vergleich zum momentaren wechselkurs zum euro sieht ist der preisanstieg schon heftig. aber ich würde meine gpu-geminten btc dafür investieren. ideologischer weise müsste das schicksal mir einen neuen asic-miner zukommen lassen. würde mich freuen wenn es klappt.
mfg
|
|
|
rfye4DsBCc1rKJiUP4Yvyq67gLytuVKKtZ
|
|
|
schaut mal: ein neuer pool in kasachstan. sieht ein bisschen aus wie ecki's ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
1% von 25 BTC + 0.01 Transaktions-fee = 0.26, nach meiner Rechnung passt das.
steht SO aber nicht auf der hp. da steht das 1% fee aufn block genommen wird, und 0,01 transactionsfee genommen wird. 0,01 fee steht so auch nochmal an anderer stelle. aber auch wenn man selbstständig 1%+0,01 subtrahiert, wird einem nicht alles ausgezahlt, es bleibt ein bruchteil aufm kto. hier ein paar hunderstel dort ein paar tausendsel und schon ist wieder ein ganzer voll. aber wenn daran grad rumgebastelt wird, hoffe ich mal das es nur besser wird.
|
|
|
hallo.
sorry ecki, aber die art und weise wie man sich bei dir auszahlen lässt ist echt schlecht gelöst. sehr user-unfreundlich. die manuele auszahlungssteuerung solltet ihr überarbeiten. deine fee sollte das system abziehen und nicht vom user errechnet werden müssen. so bleiben immer restbeträge übrig. ein auszahlungsbutton bei dem einfach alles im+ abzüglich deiner fee überwiesen wird wäre eine gute möglichkeit.
habe gerade 0.26 fee auf 25.0 überweisungsbetrag zahlen müssen, dachte immer es wären nur 0.01
darüber hinaus, ich hatte es schon mal erwähnt, ist die hp total überladen mit informationen. die wesentlichen nötigen informationen lassen sich nicht übersichtlich darstellen. manchmal ist weniger mehr.
|
|
|
8 stunden und 350k shares: wieder ein block 180226 - das gefällt mir ausserordentlich !! ![Grin](https://bitcointalk.org/Smileys/default/grin.gif)
|
|
|
Die Anteile am Block sind halt auf PPLNS bezogen. Zusammen ergeben die ganzen Share halt N, in Eckis Pool halt Difficulty/2. Die gesamt Anteile am Block sind damit natürlich nicht heraus findbar. Ich bin über das gewählte N auch nicht besonders glücklich gerade weil man bei den riesigen Blöcken letztens quasi immer dabei bleiben musste, um nicht die wichtigen 800k Shares zu verpassen, die letztlich entscheidend für die Auszahlung sind. Vielleicht sollten wir N auf die derzeit gefühlte Difficulty von 3 Millionen setzen ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) . ahh, danke für die info, jetzt begreif ich langsam... 1.) Dann würde ich an deiner Stelle in Berlin baggern, wenn die Stale Rate so dramatisch geringer ist.
...ja dachte ich auch: ich lass es jetzt erstmal so, bis zur nächsten veränderung. vielen dank, für die infos.
|
|
|
hallo. will eine info zu den stales nachtragen. auf dem pariser-server habe ich immer 2,5%-3% stales mit poclbm. über berlin sind es 0,1%-0,3%. ich habe die worker ca. 3 tage auf den jeweiligen server laufen lassen, um diese durchschnittswerte zu erhalten. ich werde zum teil aus den daten der hp-seite nicht schlau. insgesamt gesehen finde ich die hp mit informationen überladen. die wirklich wichtigen daten (besonders: shares/block, eigene shares/block) lassen sich nicht schnell & übersichtlich darstellen. wenn ich mir die links zu confirmten blöcken ansehe, denke ich die daten stimmen nicht, schaut mal selber nach! z.b. https://miner.ecki.net:444/distribution.php?f=btc&b=179978&p=parisein ca.3,5mio shares/block bei ca.3 tagen schürfzeit und https://miner.ecki.net:444/distribution.php?f=btc&b=179539&p=parisein ca.200k shares/block bei ca 5 std. schürfzeit diese daten sind nicht nachvollziehbar. ich kann also nicht wissen wieviel shares ich zu den blöcken geliefert habe. ich muss darauf vertrauen, dass alles mit rechten dingen zugeht. das einzige was ich sehe ist wieviel shares ich insgesamt auf diesem pool gemint habe. in den obigen links - & andere - ist mir aufgefallen, das pdm_miner stets mehr shares als ich hat, aber so gut wie nie in den top10 der gpu-hashrate auftaucht, jedenfalls nicht durchgehend. wenn dies ein "lastNshares/diff" pool ist wie kommt das? ich kann das nicht so ohne weiteres nachvollziehen. bis dann......
|
|
|
eu-miner.ecki.net und eu-proxy.ecki.net sind beides der Pool-Server in Paris.... Die Stale-Raten sollten da deutlich unter 1% liegen. ![Cool](https://bitcointalk.org/Smileys/default/cool.gif) so langsam scheint es sich auf 3% stales einzupendeln, das ist mir aber ein bisschen zuviel. in der regel starte ich meine worker mit der februar.version von poclbm auf der kommandozeile als *.bat datei mit folgenden flags: -w 128 -f 1 -v die hashraten sind prima, nur wie gesagt die stales sind heftig. gewohnt bin ich 0,3% stales.... mal sehen.... vielleicht lass ich die worker mal stundenweise über berlin laufen um zu schauen ob da auch so viel stales anfallen - obwohl ich weiss, dass du das eigentlich nicht willst. schönen abend noch, bis dann...
|
|
|
ein hallo an die ecki-pool-gemeinde.
ich habe meine worker nun auch bei euch am laufen. mal sehen wie es sich so entwickelt. in 14-21 tagen werd ich mal resümieren. ich war zuerst auf dem asia-server(miner.ecki.net:8332). aber da sind einfach zuviel ungülitge shares 10%+, ich selbst sitze auch im berliner raum. bin nun auf dem eu-server(eu-miner.ecki.net:8332) - bisher stales-frei, jetzt schon ne gute halbe std. ^^ wenns so bleibt freue ich mich.
bis dann.....
|
|
|
sehr gut geschrieben. macht spass zu lesen.
ja, dem schliesse ich mich an: hat spass gemacht zu lesen. es macht immer spass dirk m. zuzuhören wenn er mal wieder in einer polittalkshow auftritt. er ist einer seiner zunft, die die dinge differenziert sehen können, und auch mal tacheles reden, wie es ein politiker nie tun würde. wenn ich kanzler wäre würde ich einen wie ihn zum berater für finanzfragen machen, oder gleich zum finanzminister ^^
|
|
|
hallo nocheinmal.
also, so wie es aussieht liegt mein problem an einem bug bei poclbm. und es haben auch viele andere. die lösung - für mich - ist eine andere miner-software zu benutzen oder auf einen patch für poclbm zu warten. dann muss ich wieder an den flags rumschrauben bis ich auf zufriedenstellende ergebnisse komme.
mein problem mit dem monitorausfall und der darauffolgenden fehlersuche hat überhaupt nichts damit zu tun, und ist wohl "zufall" dass es zur gleichen zeit passiert ist.
@yxt: schönen dank für die syntax verbesserungen^^ & über dezentralisierung denke ich nach. wenn mein miner wieder richtig funktioniert schau ich mal bei ecki vorbei. @tinua: schönen dank für den input @Lord des Nebels: schönen dank für den input, die fehlerursache wurde gefunden. @chefnet: ich werd mal andere amd/sdk vers. ausprobieren. was ist mit der antivir meldung bezüglich des downloads von CGminer von github? @antares: ich habe keine ahnung was was eine buggy bits-konstellation bei der difficulty ist, aber ich bin froh das es leute gibt die das wissen :-) & was ist hashkill-gpu?
edit: mir ist aufgefallen,das die datei phoenix.exe von guiminer 23 kilobyte gross ist, aber die von mir runtergeladene phoenix vers. 1.7.5 über 8.000 kilobyte gross ist. woran liegt das? weiss das einer?
|
|
|
vielen dank für den ersten input, leider bin ich nicht weitergekommen
ich habe phoenix 1.7.5 ausprobiert und JA, er sandte endlich auch wieder shares aber die hashrate war 50 mHash weniger als ich es gewohnt bin "phoenix.exe -u http://workername:passwort@pit.deepbit.net:8332 -k phatk2 DEVICE=0 vectors worksize=128 aggression=11" mit powercolor5870 900MHz/202MHz bei knappen 350 mHash - mit poclbm seinerzeit 400 mHash
CGminer wollte ich mir von github runterladen. mein antivirenprog intervenierte aber heftig mit dem hinweis auf trojaner. habs gelassen weil ich mir nicht sicher bin. ich weiss dass es bei manchen progs die okey sind zu probs führen kann. solls ich es dennoch runterladen? ^^
ich hab poclbm auf der eingabeaufforderung gestartet wie folgt C:\Users\ASUS\guiminer-20110824\guiminer>poclbm.exe workername:passwort@pit.deepbit.net:8332 --device=0 --platform=0 --verbose -v -w128 -f1
04/02/2012 23:39:21, Setting server (workername @ pit.deepbit.net:8332) pit.deepbit.net:8332 04/02/2012 23:39:21, Unexpected error: Traceback (most recent call last): File "HttpTransport.pyo", line 45, in loop File "Transport.pyo", line 117, in queue_work File "Transport.pyo", line 76, in process File "Transport.pyo", line 71, in set_difficulty error: unpack requires a string argument of length 32 pit.deepbit.net:8332 04/02/2012 23:39:22, LP connected to pit.deepbit.net:8332 pit.deepbit.net:8332 04/02/2012 23:39:22, [175.589 MH/s (~0 MH/s)] [Rej: 0/0 (0.00%)] pit.deepbit.net:8332 04/02/2012 23:39:23, [442.104 MH/s (~0 MH/s)] [Rej: 0/0 (0.00%)] pit.deepbit.net:8332 04/02/2012 23:39:23, Unexpected error: Traceback (most recent call last): File "HttpTransport.pyo", line 50, in loop File "Transport.pyo", line 88, in send TypeError: 'NoneType' object is unsubscriptable pit.deepbit.net:8332 04/02/2012 23:39:24, [454.355 MH/s (~0 MH/s)] [Rej: 0/0 (0.00%)] pit.deepbit.net:8332 04/02/2012 23:39:26, [389.748 MH/s (~0 MH/s)] [Rej: 0/0 (0.00%)] pit.deepbit.net:8332 04/02/2012 23:39:27, [372.896 MH/s (~0 MH/s)] [Rej: 0/0 (0.00%)] pit.deepbit.net:8332 04/02/2012 23:39:28, [389.774 MH/s (~0 MH/s)] [Rej: 0/0 (0.00%)] pit.deepbit.net:8332 04/02/2012 23:39:28, long poll: new block 0000025dc774e3b1 pit.deepbit.net:8332 04/02/2012 23:39:29, [368.663 MH/s (~0 MH/s)] [Rej: 0/0 (0.00%)] pit.deepbit.net:8332 04/02/2012 23:39:30, [378.694 MH/s (~0 MH/s)] [Rej: 0/0 (0.00%)] pit.deepbit.net:8332 04/02/2012 23:39:31, [389.287 MH/s (~0 MH/s)] [Rej: 0/0 (0.00%)] pit.deepbit.net:8332 04/02/2012 23:39:32, [384.296 MH/s (~0 MH/s)] [Rej: 0/0 (0.00%)] pit.deepbit.net:8332 04/02/2012 23:39:33, [385.437 MH/s (~0 MH/s)] [Rej: 0/0 (0.00%)] pit.deepbit.net:8332 04/02/2012 23:39:34, [389.774 MH/s (~0 MH/s)] [Rej: 0/0 (0.00%)] pit.deepbit.net:8332 04/02/2012 23:39:36, [385.437 MH/s (~0 MH/s)] [Rej: 0/0 (0.00%)] pit.deepbit.net:8332 04/02/2012 23:39:37, [389.774 MH/s (~0 MH/s)] [Rej: 0/0 (0.00%)] pit.deepbit.net:8332 04/02/2012 23:39:38, [385.818 MH/s (~0 MH/s)] [Rej: 0/0 (0.00%)] ... ... der pool ist nur exemplarisch gewählt es kann auch ein anderer sein
hat jemand noch eine idee für mich?
|
|
|
hallo @ all
vorne weg: computer sind mein hobby, ich bin amateur. ich bin weder elektrotechniker oder informatiker etc. ich habe bei der problemsuche vieles versucht und weiss jetzt nicht mehr weiter. ich hoffe ihr/jemand kann mir helfen.
ich habe einen miner mit folgenden spezifikationen: asus board mit 3x pciE2.0 x16 sapphireXtreme5850 bei gpu800MHz, mem202MHz x2 sapphireXtreme5850 bei gpu800MHz, mem202MHz x1 PowerColorRadeon5870 mit riser bei gpu900MHz, mem202MHz amdcatalyst suite 11.11, guiminer v2011-08-24, win7pro64
der lief jetzt monatelang stabil bei ca. 1020 - 1040 mHash (320, 320, 400)
das erste, eher unwichtigere problem hatte ich letzte woche als ich dummerweise amdCatalyst von 11.11 auf 12.1 updatete und dannach nur noch hashraten von 980 - 1010 herauskamen. ich schaute ins forum und fand recht schnell, dass das ein allgemeines prob ist. also machte ich das update rückgänig. (12.1 deinstalliert, 11.11 wieder installiert). Das Probelm dabei war, dass ich auch nach der umkehrung nur noch 1000 - 1020 mHash hatte, bis heute. Ich fand mich damit ab.
das echte problem kam heute. der monitor des miners wurde plötzlich schwarz, ging aber nicht auf standby. der stromverbrauch verringerte sich nicht. was war los? ich hab den rechner ausgemacht (resetknopf drücken/halten, netzschalter aus). erneutets booten - der monitor blieb schwarz. auf der fehlersuche machte ich auch mal den miner sauber die lüfter die rippen, habe die grakas aus dem board genommen, sauber wieder eingebaut. habe bei der fehlersuche die 5850 vertauscht wieder eingebaut, die 5870 nicht. die fehlerquelle war der monitor, der ist einfach kaputt, bleibt schwarz, egal an welchem rechner.
so nun zum kern. als ich dann - mit anderem monitor - den miner wieder an einen pool hängen wollte, stellte sich heraus das keine shares mehr an den pool gesendet werden. ich bin ratlos. die guiminer-software erkennt drei cypress (1, 2, 0) die auch hashen mit gewohnten tempo, jedenfalls zeigt die guiminer-software das an, auch die wärmeentwicklung spricht dafür das sie hashen, und GPUZ. aber es werden keine shares gezeigt, auch bei verschiedenen pools kommt nichts an. auf der konsole des guiminer steht nur: "Unexpected error:" alle paar sekunden. manchmal springt die anzeige für akzeptierte shares kurz von 0 auf 1, dann aber wieder zurück auf 0 innerhalb sek.bruchteile immr wieder gibts auch verbindungsfehler.
ich hoffe jemand kann mir helfen. gruss
|
|
|
...ich denke dass liegt an den ganzen ddos angriffen der letzten tage. wenn bitcoincz/slush wieder on ist wird die torte wieder anders aussehen. gestern nacht war die torte über 75% auf other. glücklicherweise war deepbit relativ schnelll wieder on. was mich aber gewundert hat, dass die hashrate auf btcwatch nicht angepasst wurde obwohl zeitweilig über 5 terahash einfach weg waren.
|
|
|
Fands übrigens schade dass du die sammelbestellung nur so kurz laufen lassen hast. Es gäbe sonst bestimmt noch den ein oder anderen käufer. Ich hätte z.b. auch noch welche genommen;)
+1 ...muss sich nur einer finden der eine neue sammelbestellung organisiert, und dann macht ihr das einfach nochmal...
|
|
|
Also ich habe auch schon 8 Wochen auf Lieferungen aus den USA gewartet, ist aber bisher alles angekommen :-)
ahh... wenn ich mal so drüber nachdenke, habe ich mir noch nie was aus den usa schicken lassen, aber schon öfter aus china, thailand und taiwan. wenn ich euch dann so lese, beruhigt mich das. ![Cheesy](https://bitcointalk.org/Smileys/default/cheesy.gif)
|
|
|
Liegen die coins jetzt seit 5 Tagen in LA auf dem Postamt rum? ![Huh](https://bitcointalk.org/Smileys/default/huh.gif) Nicht, dass Winnetou mit seiner Andeutung am Ende doch nicht so Unrecht hatte ... jetzt liegen die coins 10 tage iwo rum.....also entweder die sind echt noch in californien oder die sind schon beim deutschen zoll in frankfurt und der kack-transporteur hat das noch nicht eingescannt. wär ja mal nett wenn du belkaar da mal nachhackst. und ich hoffe auch dass du meinen ratschlag aus meiner pm zu herzen genommen hast bzw. dem versender mitgeteilt hast. ich habe kein bock nochmal 19%ust zu bezahlen. und überhaupt eine frechheit das eigentum anderer leute so lange iwo rumliegen zu lassen. so lange hat das noch nie gedauert, wenn ich mir was aus dem nicht eu ausland bestellt hab.
|
|
|
|