Topic: Mixed mining Poolserver https://miner.ecki.net:444 - page 67. (Read 110508 times)

Kann MasTi mal selber bitte etwas dazu schreiben?
Ich habe hier keinerlei Daten um das im Moment selber zu prüfen und den Entwickler will ich im Moment darauf nicht ansetzen.
Wir werden in wenigen Stunden den WEB Shop zum BETA Test freischalten, der hat im Moment genug um die Ohren... 

Cu,
 Ecki

Ja das ist mir auch schon aufgefallen und ich habe dafür keine Erklärung!
Die Insider bitte vortreten und das mal erläutern.
Das sind doch komplett getrennte Ketten, wieso passiert es so häufig das ein gefundener NMC Block auch gleichzeitig ein Treffer beim BTC ist und/oder umgekehrt?

Mir völlig unklar...  

Hat da irgendeiner eine Idee zu oder noch besser eine logische Erklärung?

Cu,
 Ecki

Wunderlich ist ebenfalls, dass auffallend oft der mineur der einen btc-block geknackt hat, Sekunden später einen nmc-Block hinterherschiebt. Ist ja Wurscht da wir uns für equal-pay entschieden haben, es fiel mir nur auf.

Danke für die Info,

mich hat es nur gewundert das zB MasTi der wenn ich es recht sehe nur LTC macht in den letzten Tagen 100.000 Shares mit 0 BTC/NMC gemacht hat. Da dachte ich das sie eingerechnet werden wie bei den anderen, aber da hab ich mich wohl geirrt und es hat dann logischerweise einen anderen Grund.

sdG SShadow

Moin Sshadow,


Das Thema mit den Stales werde ich noch einmal angehen, wenn ich es komplett verstanden habe.
Solange mir nicht alle Gründe klar sind wie Stales entstehen, macht es für mich wenig Sinn nach Lösungsmöglichkeiten für weniger Stales zu suchen...

LTC Shares werden NICHT in die Top 10 GPU Lifetime Shares eingerechnet sondern logischer Weise in die Top 10 CPU Lifetime Shares (deshalb auch der Rahmen um GPU Mining (Werden wir bald in GPU & FPGA ändern!) und CPU Mining.
Das sind 2 völlig getrenntes Paar Schuhe! Andere Ports, anderer Algorithmus... alles anders und hat nix miteinander zu tun.

Die Diagramme unter my Stats zeigen im Moment nur Daten von Samui an. Dieser Fehler ist bekannt und wird heute Abend noch korrigiert!

Cu,
 Ecki
 

Tinua ist wie der Fels in der Brandung... hat zwar "nur" 4-5 Gh/s ist aber "Mann der ersten Stunde" und von Anfang an dabei. Er hat jetzt schon 10 Millionen Life time Shares und soweit mir bekannt ist, wartet er auch noch auf Hardware zum "aufstocken".... insofern wohl keine Chance an ihm bis zum 4.November noch vorbei zu ziehen.
Ich denke mal nur Mycom oder ich könnten ihn vielleicht noch einholen... schauen wir mal...

Viele Fragen von denen ich so aus dem Stand nur einige beantworten kann.
Die Icarus Boards haben das beste Verhältnis von Energie die du rein steckst (< 20W) und Leistung (380 Mh/s) die du raus holst.
Außerdem funktionieren die direkt mit 12V Gleichstrom was für uns hier in Thailand mit den vielen Stromausfällen (1x pro Woche) sehr wichtig ist, damit können wir die direkt an 12 V Batterien (200 AH) betreiben und die laufen dann auch bei Stromausfall für mehrere Stunden noch weiter.

Wenn ein neuer Block gefunden wird, dann gibt es hier in Samui schon Lastspitzen, weil dann viele Cron-Jobs laufen die alle Grafiken updaten, die Datenbank leeren und so weiter und so fort...
In Berlin findet davon deutlich weniger statt, so das die Lastspitzen dort geringer sein sollten.

Auf beiden Server sind >> 2.000 gleichzeitige Verbindungen offen, deshalb hatten wir ja mit dem vServer in Berlin solche Schwierigkeiten, dort war die Anzahl gleichzeitiger Verbindungen bei dem Standard Image auf 2.000 Verbindungen beschränkt, was deutlich zu wenig war...

Cu,
 Ecki

Morg`N!

Mir fällt hier auf das jedesmal wenn wir einen Block finden meine Stales hochschnellen und damit meinen Schnitt hochtreibt ansonsten muss ich sagen, das seit dem Proxy die Rate von früher Standard 3-4% auf sagen wir mal vertretbare .6% gesunken ist was ich gut finde.

Werden eigentlich die LTC Shares auch in die Top 10 GPU Lifetime Shares eingerechnet?


sdG SShadow

PS: Wenn mal Lust und Liebe ist solltet Ihr mal die Diagramme unter MyStats anschauen, welche bei mir zB seit kurz nach der Aktivierung des Proxy nix mehr anzeigen oder halt nur mehr Müll.

YEAH!! zZ purzeln die Blöcke ja förmlich  

Schön zu hören dass die icarus boards unterwegs sind, auch wenn ich dann platz 3 vergessen kann  
Warum hast du dich eigentlich für genau die FPGAs entschieden?

Hmm gibt es Lastspitzen auf dem server wenn ein neuer Block gefunden wurde?
Wie viele aktive Verbindungen zum Netzwerk haben die Server offen?
Ich hab ja hier extreme stales (Ging bisher aber davon aus dass des von der miesen Verbindung kommt...?), deshalb auch nur eine Karte hier laufen, komme aber heute Nacht/ morgen endlich mal dazu den eu-proxy zu testen :-)

Wird noch eine ganze Weile dauern bis ich bitcoin/dem Thread wieder mehr Zeit einräumen kann, deshalb kurz:

Mein Wissen ich alles theoretisch und sicherlich nicht fehlerfrei, deshalb alles ausdrücklich afaik.
Was du zu longpoll beschrieben hast ist aber -hehe dein Lieblingswort- Schwachsinn  

Mal kurz umrissen:

Der pool gibt den workern einen "job" zum abarbeiten, dieser job zählt nur für den aktuellen Block
und wird geändert wenn ein neuer Block gefunden wird oder wenn der pool eine neue Transaktion in den möglichen Block aufnimmt.

Um sicher zu sein immer  "frische" arbeit zu haben muss der worker also ständig seinen aktuellen job verwerfen und einen neuen anfragen um somit seine stales zu minimieren. Also statt den job 20-30 sec durch zu rechnen bis er fertig ist wird ein neuer einfach nach 10sec angefragt. (kurz am Rande daher kommt der mehr-traffic ohne lp)

Mit lp baut der worker ganz normal eine Verbindung auf:
request getwork --> arbeitet los
 
der pool sendet jetzt seine lp-url mit

der worker startet einen request auf der lp-url die der pool aber nicht beantwortet, sondern erst wenn ein neuer
Block gefunden wurde. der worker bekommt den neuen job, verwirft den bisherigen macht sich an die arbeit und stellt einen
neuen lp request.

EDIT: lp verringert die stales also dadurch dass der pool aktiv "frische" jobs pusht sobald ein neuer Block gefunden wurde, da in dem Moment alle aktuellen in Berechnung befindlichen schon stales sind.

ein link gab es deshalb nicht, weil ich selber suchen müsste, bzw die infos auch eher verstreut sind

Endlich bewegt sich etwas.  
Ich habe gerade eine PM von Ngzhang bekommen:

--- schnipp ----
your package is on the way today. the tracking NO. is :
...
it will appear in 3-4 business days.
--- schnapp ---

Wenn es gut läuft sollten am Montag oder Dienstag hier 15 Icarus Boards eintreffen!

Sobald die angekommen sind, werde ich die zweite Hälfte überweisen und eine Woche später sollten dann die restlichen 15 Icarus Boards hier sein.
(Wer den thailändischen Zoll kennt, der weiß dass Warenpakete über 10.000 USD gerne zurückbehalten werden, solange bis der Empfänger "eine Kleinigkeit unter dem Tisch bezahlt". Der Warenwert EINER Sendung wäre über 14.000 USD gewesen, deshalb haben wir die Sendung in zwei Chargen aufgeteilt, auch wenn ich damit zweimal Portokosten an der Backe habe... das kommt immer noch günstiger als das "under table money"!)

Der Schub für den Pool kommt also in zwei Schüben, nicht einmal 11,4 Gh/s sondern zweimal 5,7 Gh/s...

Jetzt heißt es Daumen drücken, das der thailändische Zoll da nicht doch noch die Hand aufhält!

Cu,
 Ecki

Hallo yxt,


Na dann warten wir halt alle mal darauf das du mehr Zeit hast und deine Meinung technisch mit ein paar Argumenten hinterlegst.

Soweit mir bekannt ist schickt der Server bei Longpoll gleich mehr als nur einen Block zum berechnen an den Client, wenn der Client z.B. mit zwei Threads arbeitet und dann praktisch zwei Blöcke "gleichzeitig" zurückschickt und inzwischen aber der Block wo anders gefunden wurde, dann entstehen dadurch eben zwei Stales, was ohne Longpoll nicht passieren kann!
Dafür geht eben ohne Longpoll jeder Block einzeln über die Leitung mit dem entsprechenden Overhead an Bestätigungen, Rahmen für Adresse, Prüfsumme, etc. (nur ca. 40% eines TCP/IP Pakets sind im Durchschnitt Nutzinformationen!) was natürlich das Gesamtdatenvolumen entsprechend vergrößert was über die Internetleitung übertragen werden muss.

Jetzt bin ich mal auf deine Begründung gespannt, warum Longpoll die Stales verringern soll. 

Ich glaube auch du hast noch nicht so richtig verstanden, was eigentlich Stales produziert.
Da geht es dir wie mir, denn auch ich habe erst 50% von dem Thema wirklich verstanden (deshalb ja auch meine Frage in die Runde!).
Die Hardware hier ist mit 5% CPU Last, 40% RAM Auslastung, 10% Festplattenbelegung jedenfalls mal nicht der Flaschenhals.

Ein Link auf den englischen Thread "wo ja alles nachzulesen ist" wäre bestimmt auch sehr sinnvoll gewesen.

Cu,
 Ecki

auf welcher hardware läuft denn der inselserver dass er bei der kleinen hashrate schon solche stales produziert?

Nein, longpoll verringert die stales!
Hab zZ leider keine Zeit zum hier groß schreiben aber ist ja im englischen teil alles nachzulesen...


beim neusten BTC Block kann man sich die Verteilung nicht anschauen satt "Distribution" steht da jetzt nur "Done"
hat sich erledigt, hab wohl in einem ungünstigen Moment geschaut 
Wär eh angenehm sich schon vor dem Ablauf der 120 Bestätigungen anschauen zu könnte wie viel man bekommt

Ich habe ihm den Link weitergeleitet, danke.

Jedenfalls haben die Stales definitiv was mit der "Last" zu tun, denn seit die Masse der Miner hier von Samui weg ist und in Berlin baggert, habe ich wie früher meine 0,1-0,2% Stale hier...

Soweit ich bisher verstanden habe erhöht auch longpoll die Stale Rate erheblich, aber ohne longpoll wächst das Datenvolumen sehr stark an.
Sieht so aus, als wenn man bei viel Verkehr nicht "alles" haben kann, entweder niedriger Traffic auf der Internet Leitung ODER niedrige Stale Raten...

Ich habe mal einen Tag im Mai (!) für dieses Thema reserviert. Mein Entwickler soll da mal tiefer rein schauen und gucken ob man da was optimieren kann.
Der Mann ist nur die nächsten paar Wochen dermaßen ausgelastet (schon fast überlastet), das ich ihm da nix mehr dazwischen schieben kann (Und auch will, denn ich möchte mich nicht zu der großen Gruppe der Menschen-Ausbeuter zählen lassen! Er hat die letzten paar Tage auf 120% Leistung gearbeitet und das muss wieder runter auf 100%, denn der Mann hat auch Familie!).

Cu,
 Ecki

viellecht kann dein dev damit was anfangen? https://bitcointalksearch.org/topic/m.466294

Nach dem wir vorgestern am 26.2. Premiere mit 2 gefundenen BTCs am Tag hatten, haben wir heute am 28.2. zum ersten Mal seit bestehen des Pool 2 NMCs am gleichen Tag gefunden!

Außerdem haben wir heute auch zum ersten Mal 6 LTC Blöcke an einem Tag gefunden (und der Tag ist ja noch nicht zu Ende)!

Es geht aufwärts... freu! 

Die Richtung stimmt jetzt... bitte so weitermachen...

Cu,
 Ecki

Hiermit geben wir den europäischen Proxy Server von Ecki Co LTD offiziell zur Benutzung frei.

Wir bitten alle Miner aus Europa zukünftig nach Möglichkeit eu-proxy.ecki.net als Miner Adresse für die Clients zu verwenden.
Für GPU & FPGA mining (BTC & NMC) stehen dort die Ports 80 UND 8332 zur Verfügung.
Für CPU mining (LTC) steht dort Port 7332 zur Verfügung.

Miner in Asien sollten weiterhin miner.ecki.net für die Clients verwenden.
Hier steht nur Port 8332 für GPU & FPGA mining (BTC & NMC) zur Verfügung, KEIN Port 80!
Für CPU mining (LTC) steht hier der übliche Port 7332 zur Verfügung.

Für beide Standorte gleich lautet der Link zum WEB Frontend: https://miner.ecki.net:444

Durch die globale Standortübergreifende Verteilung ist es jetzt völlig egal in welchem Standort ein Miner eingewählt ist, er bekommt bei gefundenen Blöcken immer seinem Anteil nach (Letzte N Shares der 1/2 Schwierigkeit) die entsprechenden Münzen ausgezahlt!

Mit sonnigem Gruß von der Insel,
 Ecki

Hallo Micha,


... ist in Arbeit...

Cu,
 Ecki

Edit: Erledigt! Die Anzahl der benötigten Shares wird jetzt in der rechten Spalte für jeden gefundenen Block angezeigt...

Edit2: Wir haben die Liste bei dieser Gelegenheit gleich auf die "last 30 blocks found" erweitert, weil unten noch ein bisschen Platz war...  

Da wir bei bisherigen Abstimmungen maximal 13 Wähler hatten und im Moment bereits 9 von 10 Wählern sich für eine GLOBALE (Standortübergreifende) Verteilung der gefundenen Blöcke ausgesprochen haben, werden wir jetzt bereits diesen Wählerwunsch umsetzen.

Selbst, wenn die 3 noch nicht Wähler für eine LOKALE Verteilung stimmen würden, wäre das Endergebnis morgen Abend maximal 9:4 für die Globale Verteilung, bestenfalls sogar 12:1.

Damit brauchen wir nicht bis morgen Abend zu warten!

Wir werden JETZT am 28.2.2012 um 10.00 Uhr Ortszeit Thailand die GLOBALE (Standortübergreifende) Verteilung von gefundenen Blöcken aktivieren!!!

Mit sonnigem Gruß von der Insel,
 Ecki

Um ganz ehrlich zu sein, habe ich das mit dem eu-proxy auch als zusätzlichen "Einwahlpunkt" gesehen. Das es sich hierbei um einen eigenen Pool handelt hätte besser im Vorfeld kommuniziert werden sollen. Ich denke die meisten haben das nicht gewußt.

Es wäre wirklich nett, wenn man eine bessere Übersicht über die shares/block hätte, am besten als Spalte in der  "last20 blocks" Tabelle. Das Diagramm ist einfach zu unübersichtlich und stößt ja schon bei den zwei gefundenen Blöcken an einem Tag an seine Grenzen.

Übrigens, ich habe für einen gemeinsamen Pool gevotet...

Gruß,
Micha.

da isses wieder, das Sonnengemüt   Du hasst natürlich recht. Ich möchte auch keine Auseinandersetzung sondern eine Zusammensetzung. Sorry@Mecki, falls es in den falschen Hals gerutscht ist. Ich war nur bemüht den Schwerpunkt mehr in Richtung inhaltlicher Diskussion zu verschieben.

edit: bin grad noch dabei die Aufstellung etwas zu erweitern. Ich hoffe sie kann etwas Aufzeigen worum es gerade geht und zur Entscheidungsfindung beitragen.

Hallo Lord Fog,


Also ich hoffe noch sehr stark, das wir hier keine "Auseinandersetzung" haben, sondern eine Diskussion über den bestmöglichen Verteilungsschlüssel innerhalb unseres Pools diskutieren... 

Das klingt mir hier alles etwas zu kontrovers... miteinander klappt in 90% der Fälle viel besser als gegeneinander!

Es ist mir zwar auch etwas übel aufgestoßen das er gleich am Anfang damit "droht" wegzugehen, wenn sich seine Meinung nicht durchsetzt, aber einen gekonnten Diskussionsstiel muss man halt auch erst lernen... 

Das mit den Lösungen hast du aber schön formuliert... gefällt mir!

Cu,
 Ecki