Wie lange haben wir bei der derzeitigen Hashrate denn noch ca.?
Wenn ich es gerade richtig überschlagen habe, haben wir ab jetzt noch ca. 4,5 Tage zu 500 THs
Als bis Freitag Abend. Da haben wir ja noch die ganze Woche "Spass und Spannung".
Topic: Gruppenkauf Solo Mining - Bitcoin Run The next Generation 2 - page 5. (Read 11708 times)
Wenn ich es gerade richtig überschlagen habe, haben wir ab jetzt noch ca. 4,5 Tage zu 500 THs
Als bis Freitag Abend. Da haben wir ja noch die ganze Woche "Spass und Spannung".
da lässt sich doch bestimmt was finden!
mag mir jemand das hier mal erläutern bitte?
ein mining gerät geht doch einzelne Hashes durch. Desto schneller der Miner, desto schneller geht er auch die einzelnen hashes durch. doch wer sagt dem miner, welche hashes er überprüfen soll und in welcher Reihenfolge er die hashes abarbeitet? kann man das beeinflussen? ob er jetzt von a oder y anfängt
liebe Grüße
Wie lange haben wir bei der derzeitigen Hashrate denn noch ca.?
Wenn ich es gerade richtig überschlagen habe, haben wir ab jetzt noch ca. 4,5 Tage zu 500 THs
Bitte nicht verwirren lassen. - Offensichtlich stimmen die Werte aus der Pool-Stat. nicht. 
Es wurde heute um 8:40 KEIN Block gefunden. - Es ist z.Z. nicht klar was die RUNTIME aus der Pool-Stat nun wirklich aussagt.
Gruß Carsten.
P.S.: Werde "Last Block found" & "Runtime" erstmal wieder deaktivieren.
Es wurde heute um 8:40 KEIN Block gefunden. - Es ist z.Z. nicht klar was die RUNTIME aus der Pool-Stat nun wirklich aussagt.
Gruß Carsten.
P.S.: Werde "Last Block found" & "Runtime" erstmal wieder deaktivieren.
Lass dich nicht verwirren, con hat den Pool neu gestartet (US/DE), er arbeitet ja an der Software.
Also wurde die Runtime (und nur die) zurückgesetzt.
Wie lange haben wir bei der derzeitigen Hashrate denn noch ca.?
Bitte nicht verwirren lassen. - Offensichtlich stimmen die Werte aus der Pool-Stat. nicht.
Es wurde heute um 8:40 KEIN Block gefunden. - Es ist z.Z. nicht klar was die RUNTIME aus der Pool-Stat nun wirklich aussagt.
Gruß Carsten.
P.S.: Werde "Last Block found" & "Runtime" erstmal wieder deaktivieren.
Es wurde heute um 8:40 KEIN Block gefunden. - Es ist z.Z. nicht klar was die RUNTIME aus der Pool-Stat nun wirklich aussagt.
Gruß Carsten.
P.S.: Werde "Last Block found" & "Runtime" erstmal wieder deaktivieren.
Hallo Jungs,
Ich bin bis jetzt mit Miner aus USA auf den US Solo Pool gegangen, ich stell mal auf EU Miner um und gehe auf den DE Solo Pool, vielleicht bewegt sich da ja mehr....
Viele Grüße
Willi
Ich bin bis jetzt mit Miner aus USA auf den US Solo Pool gegangen, ich stell mal auf EU Miner um und gehe auf den DE Solo Pool, vielleicht bewegt sich da ja mehr....
Viele Grüße
Willi
Guten morgen,
da hängt immer noch der verdammte Superkleber dran
{"hashrate1m": "492T", "hashrate5m": "480T", "hashrate1hr": "495T", "hashrate1d": "482T", "hashrate7d": "178T", "lastupdate": 1456122861, "shares": 30944493036, "bestshare": 15.345.894.093.538525, "bestever": 15345894093}
@lateblooming, dein TX ist nun live, hab dich eingetragen --> gut Ding will Weile haben
da hängt immer noch der verdammte Superkleber dran
{"hashrate1m": "492T", "hashrate5m": "480T", "hashrate1hr": "495T", "hashrate1d": "482T", "hashrate7d": "178T", "lastupdate": 1456122861, "shares": 30944493036, "bestshare": 15.345.894.093.538525, "bestever": 15345894093}
@lateblooming, dein TX ist nun live, hab dich eingetragen --> gut Ding will Weile haben
Bestshare hängt fest :-/
Die Shares hängen nicht davon ab, wie viele im Pool mit minen oder?
Die Shares hängen nicht davon ab, wie viele im Pool mit minen oder?
Für den "POOL" = JA Hier werden einfach von allen SOLO Minern die Shares zusammengezählt.
Für euch (SOLO) = Nein dort Zählen nur die Anzahl der Shares die Ihr übermitteln könnt (Hashrate/Zeit).
--------
Man braucht Gedult und Glück!
und vieleicht jemand der Daumen drückt und "Hühnchen" ißt. (alter running gag)
Bestshare hängt fest :-/
Die Shares hängen nicht davon ab, wie viele im Pool mit minen oder?
Die Shares hängen nicht davon ab, wie viele im Pool mit minen oder?
Quote
{"runtime": 1376646, "lastupdate": 1456085119, "Users": 382, "Workers": 941, "Idle": 335, "Disconnected": 68}
{"hashrate1m": "1.34P", "hashrate5m": "1.27P", "hashrate15m": "1.26P", "hashrate1hr": "1.28P", "hashrate6hr": "1.36P", "hashrate1d": "1.32P", "hashrate7d": "1.48P"}
{"accepted": 242103604840, "rejected": 262390789, "bestshare": 24072982155, "SPS1m": 197.07902309677661, "SPS5m": 195.90629751545347, "SPS15m": 195.30409391368437, "SPS1h": 195.70898345756484}
{"hashrate1m": "1.34P", "hashrate5m": "1.27P", "hashrate15m": "1.26P", "hashrate1hr": "1.28P", "hashrate6hr": "1.36P", "hashrate1d": "1.32P", "hashrate7d": "1.48P"}
{"accepted": 242103604840, "rejected": 262390789, "bestshare": 24072982155, "SPS1m": 197.07902309677661, "SPS5m": 195.90629751545347, "SPS15m": 195.30409391368437, "SPS1h": 195.70898345756484}
Also unser Glück ist nicht von anderen abhängig. Wenn mehr im gleichen Pool minen, dann steigt eben einfach die Wahrscheinlichkeit für den Pool als ganzes, für den einzelnen Miner jedoch ändert sich nichts. Das hat keine negativen Auswirkungen auf uns.
Bestshare hängt fest :-/
Die Shares hängen nicht davon ab, wie viele im Pool mit minen oder?
Die Shares hängen nicht davon ab, wie viele im Pool mit minen oder?
Quote
{"runtime": 1376646, "lastupdate": 1456085119, "Users": 382, "Workers": 941, "Idle": 335, "Disconnected": 68}
{"hashrate1m": "1.34P", "hashrate5m": "1.27P", "hashrate15m": "1.26P", "hashrate1hr": "1.28P", "hashrate6hr": "1.36P", "hashrate1d": "1.32P", "hashrate7d": "1.48P"}
{"accepted": 242103604840, "rejected": 262390789, "bestshare": 24072982155, "SPS1m": 197.07902309677661, "SPS5m": 195.90629751545347, "SPS15m": 195.30409391368437, "SPS1h": 195.70898345756484}
{"hashrate1m": "1.34P", "hashrate5m": "1.27P", "hashrate15m": "1.26P", "hashrate1hr": "1.28P", "hashrate6hr": "1.36P", "hashrate1d": "1.32P", "hashrate7d": "1.48P"}
{"accepted": 242103604840, "rejected": 262390789, "bestshare": 24072982155, "SPS1m": 197.07902309677661, "SPS5m": 195.90629751545347, "SPS15m": 195.30409391368437, "SPS1h": 195.70898345756484}
Da hat er sich aber rein gelegt :-)
Sieht echt toll aus. Bau nur weiter dran rum, irgend wann wirds
"Das soloMining Risk Management Tool"
...du wirst reich und erfolgreich damit, wirst sieben Kinder haben und ... ;-)
Vielen Dank jedenfalls!
PS: wie lange es seit dem letzten Block (nicht unserem) her ist, währ noch das Tüpfelchen auf dem i
Sieht echt toll aus. Bau nur weiter dran rum, irgend wann wirds
"Das soloMining Risk Management Tool"
...du wirst reich und erfolgreich damit, wirst sieben Kinder haben und ... ;-)
Vielen Dank jedenfalls!
PS: wie lange es seit dem letzten Block (nicht unserem) her ist, währ noch das Tüpfelchen auf dem i
Aber Grundsätzlich ist diese Form der Ausgabe einfach nicht konform!
EDIT:
Ich hätte gerne nur eine Zeile { xx : xxx, ... } dann wäre es doch deutlich Unkomplizierter!
EDIT:
Ich hätte gerne nur eine Zeile { xx : xxx, ... } dann wäre es doch deutlich Unkomplizierter!
Genau!
Wer einen guten Draht zu -ck hat, kann ihn ja mal darauf aufmerksam machen
Ja, genau so hatte ich es mir gedacht, nun müßen wir es "Umschiffen", in meinem Pool kann ich den source ja
Abändern, beim cksolopool kann das aber nur der con.
Ich versuche Ihn mal danach zu befragen....
Vieleicht hat Kano ja auch noch eine 'Idee'.
Aber Grundsätzlich ist diese Form der Ausgabe einfach nicht konform!
EDIT:
Ich hätte gerne nur eine Zeile { xx : xxx, ... } dann wäre es doch deutlich Unkomplizierter!
Abändern, beim cksolopool kann das aber nur der con.
Ich versuche Ihn mal danach zu befragen....
Vieleicht hat Kano ja auch noch eine 'Idee'.
Aber Grundsätzlich ist diese Form der Ausgabe einfach nicht konform!
EDIT:
Ich hätte gerne nur eine Zeile { xx : xxx, ... } dann wäre es doch deutlich Unkomplizierter!
Die Ausgabe der Stats des ckpools ist kein valides JSON. Wenn man versucht, den ganzen String (es sind insgesamt 4 Zeilen) als JSON-Objekt zu behandeln kann das nur scheitern.
Ich denke da werden aus drei verschiedenen Modulen Stats geladen und ohne die richtige Syntax in eine "Ausgabedatei" geschrieben. Die einzelnen Ausgaben werden mit einem Zeilenumbruch getrennt. Das bricht JSON. Der Validator sagt "Multiple JSON root elements". Eigentlich muss um diese drei Stats (abgegrenzt mit {...}) um alles herum mit eckigen Klammern [...] ein Array gebildet und die einzelnen Stats mit einem Komma getrennt werden. Es gibt Probleme, nachdem er die erste geschweifte Endklammer findet, es danach aber trotzdem wieder (ohne vorherige Deklaration als Array) mit einem neuen Abschnitt weitergeht. Schaut euch mal den Source-Code der Stats an.
@cagrund: In folgendem Beispiel wird anstatt file_get_contents() die Funktion file() benutzt, welche den Inhalt von der URL lädt und in ein Array schreibt, in dem jede Zeile einzeln in einem eigenen Array-Platz liegt. Danach kann jede Zeile wiederum einzeln in ein JSON-Objekt umgewandelt und normal als JSON-Objekt behandelt werden:
@o_solo_miner: Der Fehler 'Error4 CTRLCHR' (Control Char?) weist doch genau darauf hin, dass der String kein valides JSON ist und der Interpreter nach der ersten gefundenen geschweiften Endklammer ohne Komma direkt wieder eine geschweifte Klammer findet. Die geschweiften und eckigen Klammern, sowie das Komma sind doch (Syntax-)Steuerzeichen.
Damit die ckpool Stats valides JSON wäre, müsste es so aussehen:
[
{"runtime": 1368726, "lastupdate": 1456077199, --snip-- "Disconnected": 41},
{"hashrate1m": "1.31P", "hashrate5m": "1.31P", --snip-- "hashrate7d": "1.48P"},
{"accepted": 239759339040, "rejected": 259340121, --snip-- "SPS1h": 194.75517717118731}
]
Die Änderungen sind in rot markiert, Mittelteile der Zeilen habe ich weggelassen und mit --snip-- ersetzt...
Bis die Ausgabe der Stats geändert wurde, bleibt uns nichts anders übrig, als jede Zeile einzeln als JSON-Objekt zu behandeln.
Ich denke da werden aus drei verschiedenen Modulen Stats geladen und ohne die richtige Syntax in eine "Ausgabedatei" geschrieben. Die einzelnen Ausgaben werden mit einem Zeilenumbruch getrennt. Das bricht JSON. Der Validator sagt "Multiple JSON root elements". Eigentlich muss um diese drei Stats (abgegrenzt mit {...}) um alles herum mit eckigen Klammern [...] ein Array gebildet und die einzelnen Stats mit einem Komma getrennt werden. Es gibt Probleme, nachdem er die erste geschweifte Endklammer findet, es danach aber trotzdem wieder (ohne vorherige Deklaration als Array) mit einem neuen Abschnitt weitergeht. Schaut euch mal den Source-Code der Stats an.
@cagrund: In folgendem Beispiel wird anstatt file_get_contents() die Funktion file() benutzt, welche den Inhalt von der URL lädt und in ein Array schreibt, in dem jede Zeile einzeln in einem eigenen Array-Platz liegt. Danach kann jede Zeile wiederum einzeln in ein JSON-Objekt umgewandelt und normal als JSON-Objekt behandelt werden:
Code:
$url = 'http://solo.ckpool.org/pool/pool.status';
$stats_array = file($url); // Lädt die Statistik und schreibt jede Zeile einzeln in einen eigenen Arrayplatz
$json = json_decode($stats_array[0], true); // Erste Zeile in ein JSON-Objekt umwandeln
echo $json["runtime"];
@o_solo_miner: Der Fehler 'Error4 CTRLCHR' (Control Char?) weist doch genau darauf hin, dass der String kein valides JSON ist und der Interpreter nach der ersten gefundenen geschweiften Endklammer ohne Komma direkt wieder eine geschweifte Klammer findet. Die geschweiften und eckigen Klammern, sowie das Komma sind doch (Syntax-)Steuerzeichen.
Damit die ckpool Stats valides JSON wäre, müsste es so aussehen:
[
{"runtime": 1368726, "lastupdate": 1456077199, --snip-- "Disconnected": 41},
{"hashrate1m": "1.31P", "hashrate5m": "1.31P", --snip-- "hashrate7d": "1.48P"},
{"accepted": 239759339040, "rejected": 259340121, --snip-- "SPS1h": 194.75517717118731}
]
Die Änderungen sind in rot markiert, Mittelteile der Zeilen habe ich weggelassen und mit --snip-- ersetzt...
Bis die Ausgabe der Stats geändert wurde, bleibt uns nichts anders übrig, als jede Zeile einzeln als JSON-Objekt zu behandeln.
Sieht doch SUPER aus!Das Script hat mir bis jetzt echt probleme bereitet, Error4 CTRLCHR vom Solo Pool, es lag nicht an dir!
Aber Minibit hat das ja ganz "praktisch" gelöst! (auch wenn mich das nicht zufrieden stellt
).Ich schaue aber weiter bis ich den "Verursacher" beseitigen kann....
So ich habe mal ein bisschen gebastelt...
Danke für die Hilfe auch an o_solo_miner & minibit.
Gruß Carsten.
Danke für die Hilfe auch an o_solo_miner & minibit.
Gruß Carsten.
du hast json_decode (sollte aber decode_json sein)
Ja, nee. - Ich rufe ja per PHP ab, nicht mit Perl.
Der Code oben funktioniert mit json_decode - siehe --> http://php.net/manual/de/function.json-decode.php
Hallo Carsten
Ich glaube das JSON auf der Stats-Seite ist nicht ganz konform. Da es mehrere geschweifte Klammern hat, ist es in Wirklichkeit doch ein Array, welches mit den eckigen Klammern eingeschlossen und die einzelnen Elemente mit Kommas getrennt werden sollte.
Versuchs mal mit dem:
Code:
$url = 'http://solo.ckpool.org/pool/pool.status';
$data = file_get_contents($url);
$tmp = explode(' ', $data);
$runtime = trim(str_replace(",", "", $tmp[1]));
echo $runtime;
?>
Quick & dirty, aber es funktioniert.
Edit: Habe gerade gesehen, dass die Stats auch Zeilenumbrüche enthalten. Somit sollte es möglich sein, nur die erste Zeile in ein JSON-Objekt umzuwandeln und den Wert auszulesen.
du hast json_decode (sollte aber decode_json sein)
Ja, nee. - Ich rufe ja per PHP ab, nicht mit Perl.
Der Code oben funktioniert mit json_decode - siehe --> http://php.net/manual/de/function.json-decode.php
Jump to: