Nagios hatte ich auch schon überlegt, aber dafür muss ich eben auf jedem client einen nagios laufen lassen..
Mit dem Proxy habe ich eine zentrale Stelle "wo alles vorbeikommt". Mit Stale habe ich keine Probleme, solange die DB nicht zu groß wird, daher löscht ein Script alles was älter als 1 Tag ist.
Ist pushpool ähnlich einfach einzurichten? Den Proxy fand ich super, PHP auf den Webserver, Datenbank einrichten und fertig.
Die Anzeige ist mir auch relativ wurschd, ob da nun Rejected steht oder nicht, die Frage ist ja nur, ob es trotzdem läuft.
Solange ich sehe, dass die Rechner sich work units abholen, reicht mir das ja. Gibt es am bitcoind irgendeine Möglichkeit zu sehen, ob die work units zurückkommen?
Topic: mining-Frage (Read 1913 times)
Ich hatte den Proxy auch mal in Verwendung und meine Stale anzahl ist von 2 auf 9% gestiegen. Zudem gab es immer mal Probleme wo zeitweise gar keine Verbindungen angenommen wurden.
Wenn es dir NUR um die Benachrichtigung geht, ist das imo das falsche Programm. Dann würde ich lieber selbst etwas bauen (Nagios z.B. welcher einen Alert ausgibt, sobald die GPU/CPU Load unter einen gewissen Schwellenwert sinkt).
Oder du schaust dir pushpool an, da kann man sicherlich irgendwie auslesen welche Miner connected sind und welche nicht bzw. entsprechendes reporting fahren.
Wenn es dir NUR um die Benachrichtigung geht, ist das imo das falsche Programm. Dann würde ich lieber selbst etwas bauen (Nagios z.B. welcher einen Alert ausgibt, sobald die GPU/CPU Load unter einen gewissen Schwellenwert sinkt).
Oder du schaust dir pushpool an, da kann man sicherlich irgendwie auslesen welche Miner connected sind und welche nicht bzw. entsprechendes reporting fahren.
Hier ist der DB-Stand vom proxy:
http://www.image-share.eu/image/334669-db.jpeg
Wie man sieht, wird jede Menge abgeholt (work_data), aber nichts zurückgeschickt (submitted_work). Die 200 Einträge da haben alle "Result=0" (d.h. Rejected). Wenn ich mir einen guiminer anschaue, dann sieht der z.B. so aus:
http://www.image-share.eu/image/334670-guiminer.jpeg
Daher meine Frage, was bedeuten die Zahlen unter "Accepted" vor und in der Klammer?
http://www.image-share.eu/image/334669-db.jpeg
Wie man sieht, wird jede Menge abgeholt (work_data), aber nichts zurückgeschickt (submitted_work). Die 200 Einträge da haben alle "Result=0" (d.h. Rejected). Wenn ich mir einen guiminer anschaue, dann sieht der z.B. so aus:
http://www.image-share.eu/image/334670-guiminer.jpeg
Daher meine Frage, was bedeuten die Zahlen unter "Accepted" vor und in der Klammer?
Hier ist der Screenshot.
http://www.image-share.eu/image/334668-Dashboard.jpeg
Komischerweise tauchen hier NUR cpu-miner auf (linux-Hosts). Meine GPU-Miner (alles Windows-Hosts) tauchen nicht auf. In der Liste unten sieht man, dass sich alle miner Ihre Work Packages holen, aber kein einziger eine "Last accepted transmission" hat.
Warum Proxy? Wie ich schon oben geschrieben habe, zur Kontrolle, welche Rechner laufen und wo evtl. der Miner hängt, da ich ja sehe, wer sich alles Work-Packages abholt. Bei Anzahl Rechner > 600 ist das damit recht komfortabel. Ansonsten bekomme ich ja keinerlei Übersicht (oder hat der bitcoind unter Linux irgendeine Kommandozeilen-Option, die mir aktuelle Miner-Verbindungen anzeigt?)
Ansonsten wäre das ein reiner Blindflug. Und mit dieser Anzahl an Rechner/GPUs bin ich über 5GH/s, damit mine ich lieber selbst. Strom ist irrelevant, der kommt aus der Steckdose ;-) (fakt ist, den muss NIEMAND zahlen, also ist es mir tendenziell egal, ob ich 1-2 mal pro Monat oder nur alle 2 Monate Glück habe ;-)).
http://www.image-share.eu/image/334668-Dashboard.jpeg
Komischerweise tauchen hier NUR cpu-miner auf (linux-Hosts). Meine GPU-Miner (alles Windows-Hosts) tauchen nicht auf. In der Liste unten sieht man, dass sich alle miner Ihre Work Packages holen, aber kein einziger eine "Last accepted transmission" hat.
Warum Proxy? Wie ich schon oben geschrieben habe, zur Kontrolle, welche Rechner laufen und wo evtl. der Miner hängt, da ich ja sehe, wer sich alles Work-Packages abholt. Bei Anzahl Rechner > 600 ist das damit recht komfortabel. Ansonsten bekomme ich ja keinerlei Übersicht (oder hat der bitcoind unter Linux irgendeine Kommandozeilen-Option, die mir aktuelle Miner-Verbindungen anzeigt?)
Ansonsten wäre das ein reiner Blindflug. Und mit dieser Anzahl an Rechner/GPUs bin ich über 5GH/s, damit mine ich lieber selbst. Strom ist irrelevant, der kommt aus der Steckdose ;-) (fakt ist, den muss NIEMAND zahlen, also ist es mir tendenziell egal, ob ich 1-2 mal pro Monat oder nur alle 2 Monate Glück habe ;-)).
Du bist dir dessen bewusst, dass es nicht wirklich rentabel ist ohne Pool zu minen (es sei denn du hast 5ghash aufwärts, selbst dann noch sehr starke Schwankungen)?
Zu deiner Frage: Habe ich so noch nie gesehen, dass in beiden Feldern "Rejected" kommt, kannst du mal einen Screen davon reinsetzten? Ansonsten ist dein Aufbau prinzipiell korrekt. Fehlendes Long Polling sollte eigentlich nicht diesen Problemen führen - kann aber darin resultieren, dass deine Worker nicht direkt bei der Erzeugung eines neuen Blocks darüber informiert werden, und ihre aktuelle workunit noch fertigrechnen (du verschenkst etwas Rechenzeit).
Was ich mich nur grade frage: Warum setzt du überhaupt den Proxy ein? Der bringt dir nur Vorteile, wenn du pool failover machst (also sobald ein pool ausfällt auf den nächsten switchst). Wenn du dich nur zu deinem eigenen bitcoind verbindest macht das wenig Sinn, da es nur Komplexität (=> Zusätzliche Fehlerquellen) hinzufügt aber keine Vorteile für dich
Zu deiner Frage: Habe ich so noch nie gesehen, dass in beiden Feldern "Rejected" kommt, kannst du mal einen Screen davon reinsetzten? Ansonsten ist dein Aufbau prinzipiell korrekt. Fehlendes Long Polling sollte eigentlich nicht diesen Problemen führen - kann aber darin resultieren, dass deine Worker nicht direkt bei der Erzeugung eines neuen Blocks darüber informiert werden, und ihre aktuelle workunit noch fertigrechnen (du verschenkst etwas Rechenzeit).
Was ich mich nur grade frage: Warum setzt du überhaupt den Proxy ein? Der bringt dir nur Vorteile, wenn du pool failover machst (also sobald ein pool ausfällt auf den nächsten switchst). Wenn du dich nur zu deinem eigenen bitcoind verbindest macht das wenig Sinn, da es nur Komplexität (=> Zusätzliche Fehlerquellen) hinzufügt aber keine Vorteile für dich
Hi!
Ich habe eine Frage zum Mining. Vor einiger Zeit fragt ich hier, ob folgendes Setup zum Mining richtig ist (Antwort war "Ja").
1. Server mit "bitcoind -server -daemon" (Linux).
In bitcoin.conf sind Benutzername und Passwort gesetzt.
2. Server mit mining-proxy (https://github.com/cdhowie/Bitcoin-mining-proxy), der zu o.g. bitcoind als "Pool" verbindet. Dazu einige Worker angelegt.
3. Rechner mit CPUs/GPUs, die alle zu dem Proxy verbinden. Jedes "Rechenwerk" hat seinen eigenen Account auf dem Proxy (zur Kontrolle, ob alle laufen ;-)).
Die cpu/gpu-miner auf den Rechner laufen ohne Fehler. Wenn ich irgendwo in der Kette (miner, proxy, bitcoind) ein Kennwort ändere verhält es sich wie vermutet, die miner brechen die Berechnung ab, weil sie keine Verbindung mehr bekommen.
Es scheint also alles zu laufen, aber: In der Übersicht des Proxys bekomme ich sowohl auf der Seite "Recent work submissions" als auch auf der Seite 2Recent failed work submissions", nur "Rejected" Statusmeldungen, keine "Success". Wenn ich im Proxy einen Pool dazu konfiguriere (eligius), und die miner alle darauf lenke, dann bekomme ich nur noch ganz ganz selten "Reject"-Meldungen und jede Menge "Accepted"-Meldungen.
Daher meine Frage: Läuft das richtig bei mir, oder habe ich irgendwo einen Fehler?
Einen Unterschied zum eligius-Pool habe ich bei den Minern gesehen. Wenn ich den Proxy auf eligius lenke, dann sagen mir die Mining-Clients beim Start etwas von "Long polling", bei meinem eigenen "Pool" nicht. Hat es was damit zu tun?
Kann mir jemand sagen, was die Zahlen beim guiminer zu sagen haben? Da stehen in der Summary unter "Accepted" zwei Zahlen z.B. "1873 (1873)". Was bedeutet das? Wurden 1873 von 1873 angenommen? Unter "Stale" steht "0".
Die Anzeige im Proxy irritiert mich nur ein wenig, da hier wie gesagt nur "Rejected"-Meldungen stehen, beim eligius-Pool aber "Accepted". Nicht, dass ich hier MWh Strom verbrate und alle Berechnung für die Katz ist...
Danke für Eure Antworten!
Ich habe eine Frage zum Mining. Vor einiger Zeit fragt ich hier, ob folgendes Setup zum Mining richtig ist (Antwort war "Ja").
1. Server mit "bitcoind -server -daemon" (Linux).
In bitcoin.conf sind Benutzername und Passwort gesetzt.
2. Server mit mining-proxy (https://github.com/cdhowie/Bitcoin-mining-proxy), der zu o.g. bitcoind als "Pool" verbindet. Dazu einige Worker angelegt.
3. Rechner mit CPUs/GPUs, die alle zu dem Proxy verbinden. Jedes "Rechenwerk" hat seinen eigenen Account auf dem Proxy (zur Kontrolle, ob alle laufen ;-)).
Die cpu/gpu-miner auf den Rechner laufen ohne Fehler. Wenn ich irgendwo in der Kette (miner, proxy, bitcoind) ein Kennwort ändere verhält es sich wie vermutet, die miner brechen die Berechnung ab, weil sie keine Verbindung mehr bekommen.
Es scheint also alles zu laufen, aber: In der Übersicht des Proxys bekomme ich sowohl auf der Seite "Recent work submissions" als auch auf der Seite 2Recent failed work submissions", nur "Rejected" Statusmeldungen, keine "Success". Wenn ich im Proxy einen Pool dazu konfiguriere (eligius), und die miner alle darauf lenke, dann bekomme ich nur noch ganz ganz selten "Reject"-Meldungen und jede Menge "Accepted"-Meldungen.
Daher meine Frage: Läuft das richtig bei mir, oder habe ich irgendwo einen Fehler?
Einen Unterschied zum eligius-Pool habe ich bei den Minern gesehen. Wenn ich den Proxy auf eligius lenke, dann sagen mir die Mining-Clients beim Start etwas von "Long polling", bei meinem eigenen "Pool" nicht. Hat es was damit zu tun?
Kann mir jemand sagen, was die Zahlen beim guiminer zu sagen haben? Da stehen in der Summary unter "Accepted" zwei Zahlen z.B. "1873 (1873)". Was bedeutet das? Wurden 1873 von 1873 angenommen? Unter "Stale" steht "0".
Die Anzeige im Proxy irritiert mich nur ein wenig, da hier wie gesagt nur "Rejected"-Meldungen stehen, beim eligius-Pool aber "Accepted". Nicht, dass ich hier MWh Strom verbrate und alle Berechnung für die Katz ist...
Danke für Eure Antworten!
Jump to: