dann reicht auch ein pool
mit 15 wird das nur noch alle 20-30 sek 1x angezeigt
Topic: Solo Mining mit KNC (Read 1227 times)
hab im cgminier die Queue auf 15 hochgestellt
dann reicht auch ein pool
mit 15 wird das nur noch alle 20-30 sek 1x angezeigt
dann reicht auch ein pool
mit 15 wird das nur noch alle 20-30 sek 1x angezeigt
hab jetzt mal
cgminer -o 192.168.0.241:8332 -u werner -p 1qay -o 192.168.0.241:8332 -u werner -p 1qay -o 192.168.0.241:8332 -u werner -p 1qay
gestartet
das komische immer noch
"Pool 0 not providing work fast enough"
nicht für pool 1 oder 2
es ist auch deutlich seltener geworden.
cpulast für bitcoin_qt weiterhin zwischn 0-5%
habs auch mit 6-7x probiert dann gehts nicht mehr
cgminer -o 192.168.0.241:8332 -u werner -p 1qay -o 192.168.0.241:8332 -u werner -p 1qay -o 192.168.0.241:8332 -u werner -p 1qay
gestartet
das komische immer noch
"Pool 0 not providing work fast enough"
nicht für pool 1 oder 2
es ist auch deutlich seltener geworden.
cpulast für bitcoin_qt weiterhin zwischn 0-5%
habs auch mit 6-7x probiert dann gehts nicht mehr
ah interessant, danke für den hinweis - ich werd's mal bei Gelegenheit näher anschauen
Was geklappt zu haben schien war folgendes:
den bitcoind als 1 von 3 Pools eintragen mit Loadbalancing, die Pakete die der Miner und der bitcoind ausgetauscht hatten sahen zumindest nach sinnvoller Kommunikation aus, konnte da keine Fehlercodes/msg drinnen finden
Pool stats im cgminer haben angezeigt, dass auch work gequeued wird aber kein accpeted share (wäre dann ja auch ein block gewesen?) aber auch kein rejected share
Was geklappt zu haben schien war folgendes:
den bitcoind als 1 von 3 Pools eintragen mit Loadbalancing, die Pakete die der Miner und der bitcoind ausgetauscht hatten sahen zumindest nach sinnvoller Kommunikation aus, konnte da keine Fehlercodes/msg drinnen finden
Pool stats im cgminer haben angezeigt, dass auch work gequeued wird aber kein accpeted share (wäre dann ja auch ein block gewesen?) aber auch kein rejected share
genau die Fehlermeldung hatte ich auch, check mal den CPU load - ist bestimmt bei 100%
der bitcoind muss ganz mies implementiert sein, was das solomining angeht - so von wegen ursprünglich für CPU-Mining mit einstelligen MH/s ausgelegt
ne gesammt bei ca 1-5% bei 8 Kernender bitcoind muss ganz mies implementiert sein, was das solomining angeht - so von wegen ursprünglich für CPU-Mining mit einstelligen MH/s ausgelegt
Festplattenlast von bitcoin_qt bei ca 400kb/sek - 2 MB/sek
CPU-last von btcoin_qt bei ca 0-10%
Raidcontroller hat 512 MB Cache
genau die Fehlermeldung hatte ich auch, check mal den CPU load - ist bestimmt bei 100%
der bitcoind muss ganz mies implementiert sein, was das solomining angeht - so von wegen ursprünglich für CPU-Mining mit einstelligen MH/s ausgelegt
der bitcoind muss ganz mies implementiert sein, was das solomining angeht - so von wegen ursprünglich für CPU-Mining mit einstelligen MH/s ausgelegt
solo-mining hatte ich auch mal kurz angtested - wollte ich 12h als lotto laufen lassen, jedoch ist meine dual core auf dem bitcoind server nicht hinterher gekommen. 100% load, und cgminer hat sich beschwert er würde nicht schnell genug die Arbeit bekommen.
habe in die bitcoin.conf
server=1
daemon=1
rpcport=
rpcallowip=
rpcuser=
rpcpassword=
und das ganze im cgminer als 'normalen' pool eingetragen
man sollte jedoch bedenken, dass die Diff weiter steigt, verpasster gleichmäßiger Payout wenn Solomining ohne Erfolg statt findet und ein diff jump kommt, ist eben einfach Verlust. Egal ob mathematisch bei konstanter diff es nach x Tagen/Wochen/Monaten/Jahren auf's selbe rausläuft - da die diff steigt, macht das Glück in einer Diff-Spanne sehr viel aus - auch pools haben mal bessere und mal schlechtere Tage/Wochen
das hab ich schon alles drin bis auf deamon=1 habe in die bitcoin.conf
server=1
daemon=1
rpcport=
rpcallowip=
rpcuser=
rpcpassword=
und das ganze im cgminer als 'normalen' pool eingetragen
man sollte jedoch bedenken, dass die Diff weiter steigt, verpasster gleichmäßiger Payout wenn Solomining ohne Erfolg statt findet und ein diff jump kommt, ist eben einfach Verlust. Egal ob mathematisch bei konstanter diff es nach x Tagen/Wochen/Monaten/Jahren auf's selbe rausläuft - da die diff steigt, macht das Glück in einer Diff-Spanne sehr viel aus - auch pools haben mal bessere und mal schlechtere Tage/Wochen
der miner arbeitet auch
aber ständig
"Pool 0 not providing work fast enough"
Server ist ein Dual Quad Xeon mit 32 GB ram und 2x GB Netzwerkanbindung
Festplatten laufen im raid 5 und schaffen ca 350-400 MB/sek (Kein SSD)
solo-mining hatte ich auch mal kurz angtested - wollte ich 12h als lotto laufen lassen, jedoch ist meine dual core auf dem bitcoind server nicht hinterher gekommen. 100% load, und cgminer hat sich beschwert er würde nicht schnell genug die Arbeit bekommen.
habe in die bitcoin.conf
server=1
daemon=1
rpcport=
rpcallowip=
rpcuser=
rpcpassword=
und das ganze im cgminer als 'normalen' pool eingetragen
man sollte jedoch bedenken, dass die Diff weiter steigt, verpasster gleichmäßiger Payout wenn Solomining ohne Erfolg statt findet und ein diff jump kommt, ist eben einfach Verlust. Egal ob mathematisch bei konstanter diff es nach x Tagen/Wochen/Monaten/Jahren auf's selbe rausläuft - da die diff steigt, macht das Glück in einer Diff-Spanne sehr viel aus - auch pools haben mal bessere und mal schlechtere Tage/Wochen
habe in die bitcoin.conf
server=1
daemon=1
rpcport=
rpcallowip=
rpcuser=
rpcpassword=
und das ganze im cgminer als 'normalen' pool eingetragen
man sollte jedoch bedenken, dass die Diff weiter steigt, verpasster gleichmäßiger Payout wenn Solomining ohne Erfolg statt findet und ein diff jump kommt, ist eben einfach Verlust. Egal ob mathematisch bei konstanter diff es nach x Tagen/Wochen/Monaten/Jahren auf's selbe rausläuft - da die diff steigt, macht das Glück in einer Diff-Spanne sehr viel aus - auch pools haben mal bessere und mal schlechtere Tage/Wochen
Bin nicht grade ein Mining-Proxy Experte, aber Du musst in cgminer soweit ich weiß rpcuser/-pass von Bitcoin-QT angeben,
-cu & -cp hab ich bei meinen Versuchen zumindest nie verwendet, ich hab immer gleich die Worker-Daten des entsprechenden Pools mit Host & Port des Proxies angegeben.
-cu & -cp hab ich bei meinen Versuchen zumindest nie verwendet, ich hab immer gleich die Worker-Daten des entsprechenden Pools mit Host & Port des Proxies angegeben.
die -cu -cp muss ich angeben sonst verbindet sich der proxy nicht mit bitcoin_qt
Bin nicht grade ein Mining-Proxy Experte, aber Du musst in cgminer soweit ich weiß rpcuser/-pass von Bitcoin-QT angeben,
-cu & -cp hab ich bei meinen Versuchen zumindest nie verwendet, ich hab immer gleich die Worker-Daten des entsprechenden Pools mit Host & Port des Proxies angegeben.
-cu & -cp hab ich bei meinen Versuchen zumindest nie verwendet, ich hab immer gleich die Worker-Daten des entsprechenden Pools mit Host & Port des Proxies angegeben.
hast Du zufällig die parameter damit das auf localhost funktioniert?
bis jetzt
mining_proxy.exe -oh 127.0.0.1 -gp 8332 -sh 192.168.0.241 -sp 9332 -cu werner -cp 1qay
ich seh zwar im proxy peer conectet aber der peer zeigt an
[2013-10-18 11:35:41] Started cgminer 3.4.0
[2013-10-18 11:35:41] Probing for an alive pool
[2013-10-18 11:35:41] pool 0 JSON stratum auth failed: (null)
und ohne username/pw startet cgminer nicht
bis jetzt
mining_proxy.exe -oh 127.0.0.1 -gp 8332 -sh 192.168.0.241 -sp 9332 -cu werner -cp 1qay
ich seh zwar im proxy peer conectet aber der peer zeigt an
[2013-10-18 11:35:41] Started cgminer 3.4.0
[2013-10-18 11:35:41] Probing for an alive pool
[2013-10-18 11:35:41] pool 0 JSON stratum auth failed: (null)
und ohne username/pw startet cgminer nicht
An den getwork-Parametern von Bitcoin-QT kannste (soweit ich weiß) nichts drehn,
aber vielleicht klappts ja mit slush's Stratum-Proxy.
Zumindest einen Versuch wärs Wert.
Edith flüstert mir grad ins Ohr, daß man das Bitcoin-DataDir noch auf eine schnelle SSD packen könnte (wenns da nicht schon liegt), damit holt man sicher noch ein paar hundert Millisekunden raus.
das Bitcoin datadir liegt auf einem Raid 5 mit 12 TB aber vielleicht klappts ja mit slush's Stratum-Proxy.
Zumindest einen Versuch wärs Wert.
Edith flüstert mir grad ins Ohr, daß man das Bitcoin-DataDir noch auf eine schnelle SSD packen könnte (wenns da nicht schon liegt), damit holt man sicher noch ein paar hundert Millisekunden raus.
An den getwork-Parametern von Bitcoin-QT kannste (soweit ich weiß) nichts drehn,
aber vielleicht klappts ja mit slush's Stratum-Proxy.
Zumindest einen Versuch wärs Wert.
Edith flüstert mir grad ins Ohr, daß man das Bitcoin-DataDir noch auf eine schnelle SSD packen könnte (wenns da nicht schon liegt), damit holt man sicher noch ein paar hundert Millisekunden raus.
aber vielleicht klappts ja mit slush's Stratum-Proxy.
Zumindest einen Versuch wärs Wert.
Edith flüstert mir grad ins Ohr, daß man das Bitcoin-DataDir noch auf eine schnelle SSD packen könnte (wenns da nicht schon liegt), damit holt man sicher noch ein paar hundert Millisekunden raus.
Ich wolte zum Test etwas solominen aber der KNC-Miner zeigt mir sehr oft bzw 2-20x sek
Pool 0 not providing work fast enough
an.
Kann man an dem parametern von bitcoin-qt.exe rumspielen damit das weg ist?
z.Z laufen ca 1900-1950 WU/m
laut cgminer aber ca 500-520 GH/sek
startparameter sind
-server -no-longpoll -blockminsize=128
Pool 0 not providing work fast enough
an.
Kann man an dem parametern von bitcoin-qt.exe rumspielen damit das weg ist?
z.Z laufen ca 1900-1950 WU/m
laut cgminer aber ca 500-520 GH/sek
startparameter sind
-server -no-longpoll -blockminsize=128
Jump to: