und auch bei den GH fehlen mir ca. 30 im Vergleich zu anderen Pools
Topic: Welcher pool für KnCMiner saturn? (Read 1838 times)
muss ich nach 24h leider bestätigen
und auch bei den GH fehlen mir ca. 30 im Vergleich zu anderen Pools
und auch bei den GH fehlen mir ca. 30 im Vergleich zu anderen Pools
Hashrate sieht ganz gut aus bei mir. Allerdings habe ich eine relativ hohe Orphanrate. Effizienz aktuell (nach ein paar Stunden) bei 92%.
ja ich hab auch den Versuch am laufen - und ich kann mich anschließen: deutlich besser aber noch nicht perfekt
Mit der neuesten Firmware scheint sich einiges verbessert zu haben:
I wouldn't say flawlessly...but it does look much better. I'll run 24 hrs and post results.
Yeah, after a few hours of letting it run, I'd agree that it's not flawless - but it is way, way better than it was.
Ich hab auch mal wieder umgestellt. Läuft seit einer Stunde mit ~ 400 GH/s - also vergleichbar mit den Werten bei Eligius. Wenn sich das so hält, scheint P2Pool wieder eine Alternative für KNC-Miner.
Wow.
The newest firmware from KnC (0.97) makes their miners work FLAWLESSLY with p2pool! The difference is staggering. Before p2pool was literally unusable with my Saturn - but now I am getting close to max hashrate
The newest firmware from KnC (0.97) makes their miners work FLAWLESSLY with p2pool! The difference is staggering. Before p2pool was literally unusable with my Saturn - but now I am getting close to max hashrate
I wouldn't say flawlessly...but it does look much better. I'll run 24 hrs and post results.
Yeah, after a few hours of letting it run, I'd agree that it's not flawless - but it is way, way better than it was.
Ich hab auch mal wieder umgestellt. Läuft seit einer Stunde mit ~ 400 GH/s - also vergleichbar mit den Werten bei Eligius. Wenn sich das so hält, scheint P2Pool wieder eine Alternative für KNC-Miner.
Danke für Eure Hinweise. Aber, um SSH zu meinem Saturn zu machen, müsste ich wohl nach Schweden und mir Zugang zum Rechenzentrum verschaffen. KnC hat die gehosteten Miner komplett abgeschirmt (was ja auch sinnvoll ist) und aktuell gibt es eine sehr spartanische Weboberfläche, in der man Mining-Pool-Adressen eintragen kann (also Hauptpool + beliebige Fallbackpools). Das war's.
ok nach start des initd läufts als screen.
es steht groß und fett drin -x screen
hätte mir halt doch das startscript anschauen sollen ***batsch aufs Hirn***
es steht groß und fett drin -x screen
hätte mir halt doch das startscript anschauen sollen ***batsch aufs Hirn***
ja wenn du schon gekillt hast geht das evtl. nicht mehr
in der Std config läuft der cgminer in einem screen - versuchs mal nach einem reboot wenn es auch dann nicht funktioniert hast du bereits was kaputt gespielt;).
Wenn du genau weißt was du tust kann man das machen aber willkürlich die Nutzung von kill zu empfehlen finde ich nicht hilfreich
in der Std config läuft der cgminer in einem screen - versuchs mal nach einem reboot wenn es auch dann nicht funktioniert hast du bereits was kaputt gespielt;).
Wenn du genau weißt was du tust kann man das machen aber willkürlich die Nutzung von kill zu empfehlen finde ich nicht hilfreich
wieso sollte man den cgminer Prozess killen?
ist da viel besser
STRG+A+d bringt einen dann zurück auf die Konsole
hmmCode:
scren -r
ist da viel besser
STRG+A+d bringt einen dann zurück auf die Konsole
bei "screen -r" bekomm ich nur "There is no screen to be resumed."
cgminer killen und wieder starten dann sieht man die ausgabe von cgminer im putty
wieso sollte man den cgminer Prozess killen?
ist da viel besser
STRG+A+d bringt einen dann zurück auf die Konsole
Code:
scren -r
ist da viel besser
STRG+A+d bringt einen dann zurück auf die Konsole
wenn Du wissen wilst wie schnell dein KNC Miner ist.
Security -> enable SSH
unter status die pid nummer merken
mit Putty und SSH am Miner anmelden
user: root
PW: "vom admin der webkonsole"
kill "pidnummer" + enter
/usr/bin/cgminer --default-config /config/cgminer.conf + enter
und zuschauen wie er mined
Security -> enable SSH
unter status die pid nummer merken
mit Putty und SSH am Miner anmelden
user: root
PW: "vom admin der webkonsole"
kill "pidnummer" + enter
/usr/bin/cgminer --default-config /config/cgminer.conf + enter
und zuschauen wie er mined
Noch ein bisschen Hintergrundinformation aus dem P2Pool-Thread:
Kann man echt gespannt sein, ob sich das mit dem Hashfast-Design (s.o.) dann tatsächlich ändern wird und damit dann die Nutzung von P2Pool wieder attraktiver als aktuell.
Moving forward, we've been trying to get manufacturers to take the idea of work restart a step beyond the current notion of throw all work out and start again and have at least 2 different levels of restart. One for "updated work" to throw out queued work that's not been started on, and one for "block change" which stops all current work and throws out all queued work. As ASIC manufacturers so far have only been interested in getting hardware out ASAP, it's clear these issues have not remotely concerned them, but we see encouraging signs that the next generation of ASICs will be far more professional and raise the bar for what the standard should be.
Kann man echt gespannt sein, ob sich das mit dem Hashfast-Design (s.o.) dann tatsächlich ändern wird und damit dann die Nutzung von P2Pool wieder attraktiver als aktuell.
Aber gerne ich konnts halt nicht recht glauben;)
Ist auch kurios. Der Saturn hatte ja mehr geliefert als eigentlich zu erwarten war. Zufälle gibt's. Ts.
Ein Problem ist auf jeden Fall, dass die KNC Miner nach einem gefundenen Block die bereits erhaltene Arbeit nicht verwerfen und stur weiter rechnen, was natürlich nur zu stales führt. Genau diesen Fehler hatte BFL bereits mit deren FPGAs gemacht 
Das hatte ich gelesen - und gedacht, es wäre beim KnC inzwischen durch ein FW-Update behoben. Das wirkt sich dann natürlich richtig schlecht bei einem P2Pool aus.
Auch die Avalons hatten Probleme mit p2pool, da die Blöcke da ja nur 10 Sekunden (wenn ich mich recht erinnere) betrugen, durch Anhebung auf 30 sek kamen die Avalons dann besser zurecht.
Evtl. ist das auch noch ein Problem oder es gibt noch andere Gründe...
Evtl. ist das auch noch ein Problem oder es gibt noch andere Gründe...
Sieht so aus. Im P2Pool-Thread wird das langsam deutlicher:
The fault lay with the hardware manufacturers, not p2pool, as p2pool was around long before they started making their ASICs. If all the newer hardware follows the same pattern, things will only improve, and old hardware becomes irrelevant very fast in this world anyway.
To forrestv's credit, he made a LOT of changes leading into the ASIC era, like beefing up stratum support, variable difficulty, clamping down on memory leaks and the longer blocks. There is ALWAYS more work to be done when the landscape is changing so fast in the bitcoin mining world, but it's clear the manufacturers till now have not put p2pool on their radar at all.
OMG what a flamer.
The ONLY trouble that HARDWARE has witch P2pool is that LP/work reset is making HARDWARE to stop hashing for like 10 sec, or HARDWARE is IGNORING LP/WR signals at all.
ANY thing that ckolivas or forrestv do will NOT help if HARDWARE is NOT working witch STANDARDS that are around like YEAR or more.
BE BLADE is working ONLY on diff=1 and are IGNORING LP signals.
KNC stuff are FREEZING for like 10sec every LP it got.
How our devs can fight that? Where we NOT have ANY access to BEB soft, and KNC just published miner sources few days ago... not even on git... Still if this is HARDWARE issue we cant do NOTHING to make those wrong designed ASICS to work properly on P2pool.
The ONLY trouble that HARDWARE has witch P2pool is that LP/work reset is making HARDWARE to stop hashing for like 10 sec, or HARDWARE is IGNORING LP/WR signals at all.
ANY thing that ckolivas or forrestv do will NOT help if HARDWARE is NOT working witch STANDARDS that are around like YEAR or more.
BE BLADE is working ONLY on diff=1 and are IGNORING LP signals.
KNC stuff are FREEZING for like 10sec every LP it got.
How our devs can fight that? Where we NOT have ANY access to BEB soft, and KNC just published miner sources few days ago... not even on git... Still if this is HARDWARE issue we cant do NOTHING to make those wrong designed ASICS to work properly on P2pool.
Looks like you re missing ROOT of the trouble. As one and only DECENTRALIZED pool P2pool has to manage some way to keep track of work done by miners and calculate payout in way, that cannot be forged, stolen or broken in any way. Bitcoin block chain is the way. P2pool is using 30 seconds blocks (shares) to keep track of work done by miners and allow every node to correctly calculate payout to all miners in SAME way. This is why we have LP/WR signal every 30s. In "normal" (centralized) pools this is done on one machine and LP is only on block change in bitcoin network - about every ~10 minutes.
So miner that is trying to mine on P2pool and freezing for ~10s every LP is "missing" ~30% of time. Miner that need ~10s to compute one WU and is also ignoring LP has 30% doa.
This is NOT P2pool fault but badly coded/designed miners. LP spec is there like 2 years now, so I not see ANY explanation for miner designers that they NOT implementing it in proper way.
Same is for stratum and vardiff that IS implemented in P2pool. If miner is NOT using it why blame pool?
So miner that is trying to mine on P2pool and freezing for ~10s every LP is "missing" ~30% of time. Miner that need ~10s to compute one WU and is also ignoring LP has 30% doa.
This is NOT P2pool fault but badly coded/designed miners. LP spec is there like 2 years now, so I not see ANY explanation for miner designers that they NOT implementing it in proper way.
Same is for stratum and vardiff that IS implemented in P2pool. If miner is NOT using it why blame pool?
Wenn's also letztlich am ASIC-Design liegt, ist KnC da erstmal raus. Offensichtlich ist das Design anderer Hersteller hier besser vorbereitet:
There is light at the end of the tunnel. Hashfast's ASICs will have a fast longpoll/block change/flush work implementation and it looks like Cointerra's will too.
Warten wir's ab.
p2pool ist halt recht speziell
Ja. Aber ein toller Ansatz. Nur leider keiner, den man mit einem KnC-Miner sinnvoll unterstützen kann.
Ja, sieht wirklich so aus. Oder es sind drei Chips drin statt zwei - um evtl. Support-Aufwand im Hosting zu reduzieren? Die 400 GH/s sind weiterhin konstant auf Eligius.
Besten Dank, fhh, dass Du mich zum Austesten "verleitet" hast. Schade, dass P2Pool da echt ~ 20% der Leistung zu fressen scheint.
Aber gerne ich konnts halt nicht recht glauben;)
Ein Problem ist auf jeden Fall, dass die KNC Miner nach einem gefundenen Block die bereits erhaltene Arbeit nicht verwerfen und stur weiter rechnen, was natürlich nur zu stales führt. Genau diesen Fehler hatte BFL bereits mit deren FPGAs gemacht
Auch die Avalons hatten Probleme mit p2pool, da die Blöcke da ja nur 10 Sekunden (wenn ich mich recht erinnere) betrugen, durch Anhebung auf 30 sek kamen die Avalons dann besser zurecht.
Evtl. ist das auch noch ein Problem oder es gibt noch andere Gründe...
p2pool ist halt recht speziell
Wirklich erstaunlich. Das die aktuelle Statistik von Eligius:
Ich glaub Ja die haben dir nen Schlechten Jupiter hingestellt;) dann passen auchh 300gh/s auf p2pool...
Quote
3 hours 406.40 Gh/s 1021918
22.5 minutes 387.46 Gh/s 121788
256 seconds 494.54 Gh/s 29477
128 seconds 476.72 Gh/s 14207
22.5 minutes 387.46 Gh/s 121788
256 seconds 494.54 Gh/s 29477
128 seconds 476.72 Gh/s 14207
Ich glaub Ja die haben dir nen Schlechten Jupiter hingestellt;) dann passen auchh 300gh/s auf p2pool...
Ja, sieht wirklich so aus. Oder es sind drei Chips drin statt zwei - um evtl. Support-Aufwand im Hosting zu reduzieren? Die 400 GH/s sind weiterhin konstant auf Eligius.
Besten Dank, fhh, dass Du mich zum Austesten "verleitet" hast. Schade, dass P2Pool da echt ~ 20% der Leistung zu fressen scheint.
Wirklich erstaunlich. Das die aktuelle Statistik von Eligius:
Quote
3 hours 406.40 Gh/s 1021918
22.5 minutes 387.46 Gh/s 121788
256 seconds 494.54 Gh/s 29477
128 seconds 476.72 Gh/s 14207
22.5 minutes 387.46 Gh/s 121788
256 seconds 494.54 Gh/s 29477
128 seconds 476.72 Gh/s 14207
Wirklich erstaunlich. Das die aktuelle Statistik von Eligius:
Quote
3 hours 406.40 Gh/s 1021918
22.5 minutes 387.46 Gh/s 121788
256 seconds 494.54 Gh/s 29477
128 seconds 476.72 Gh/s 14207
22.5 minutes 387.46 Gh/s 121788
256 seconds 494.54 Gh/s 29477
128 seconds 476.72 Gh/s 14207
Ich glaub Ja die haben dir nen Schlechten Jupiter hingestellt;) dann passen auchh 300gh/s auf p2pool...
Wirklich erstaunlich. Das die aktuelle Statistik von Eligius:
Quote
3 hours 406.40 Gh/s 1021918
22.5 minutes 387.46 Gh/s 121788
256 seconds 494.54 Gh/s 29477
128 seconds 476.72 Gh/s 14207
22.5 minutes 387.46 Gh/s 121788
256 seconds 494.54 Gh/s 29477
128 seconds 476.72 Gh/s 14207
Ich war leider den ganzen sonntag unterwegs, aber ich glaube ihr seid schon auf das Problem, wenn es denn eins ist, gestoßen 
Ich muss mal schauen ob ich es in der kommenden Nacht zeitlich hinbekomme meinen Saturn wo anders anschaffen gehen zu lassen.
Ich werde eure vorschläge mal durchgehen und mich dann wieder melden...
Cheers
Ich muss mal schauen ob ich es in der kommenden Nacht zeitlich hinbekomme meinen Saturn wo anders anschaffen gehen zu lassen.
Ich werde eure vorschläge mal durchgehen und mich dann wieder melden...
Cheers
Watt wie kann ein Saturn mit angeblich halber Leistung eines Jupiters auf 400 kommen?
Ne Stunde im Eligius-Pool ist sicher noch zu wenig aussagekräftig. Mal schauen, was die Stats nach 24 Stunden sagen.
Watt wie kann ein Saturn mit angeblich halber Leistung eines Jupiters auf 400 kommen?
Hm. Rätselhaft. Sieht so aus, dass ich mich korrigieren muss. Nachdem ich im P2Pool-Thread von den Problemen gelesen habe, habe ich mal testweise den Saturn an GHash.IO und Eligius gehängt. Bei ersterem fällt die Leistung relativ schnell steil ab und pendelt dann um 200 GH/s. Bei letzterem mint der Saturn jetzt seit einer Stunde mit > 400 GH/s. Muss ich mal weiter beobachten (echt ein Mist, wenn man keinen Zugriff auf cgminer hat beim Hosting).
Jump to: