Hallo sorry die Frage mit Minera ist aber immer noch nicht geklärt.
Habe leider mit Linux so gut wie null Erfahrung deshalb wollte ich die Minera Weboberfläche nutzen.
Schon alleine aus dem Grund.Das ich dafür an meinem
Raspberry.Nicht extra einen Monitor anschließen muss. Da der miner im Gartenhaus
Und über solar laufen soll.Komme aber mit den Einstellungen überhaupt nicht klar.
Der gridseed gc3355 kann übrigens beides scrypt und Sha.
Ich hoffe das mit vielleicht jemand weiterhelfen kann.
Bei meinen Monnladern sieht's ähnlich aus die generieren zwar coins aber leider wird die Frequenz und die Temperatur nicht angezeigt also auch ich nicht die richtige config für die Moonlander.
Topic: gridseed gc3355 projekt , bitte um hilfe (Read 192 times)
Ah ok,danke für die Aufklärung.
Frage 1.
In der poolwallet zum beobachten der Miner wird immer angezeigt wie lange es benötigt bis ein Block gefunden wird (schwankt zwischen ca. 100.000 jahren und 220.000jahren
).
Ist das die Zeit die die Miner brauchen um einen ganzen Bitcoin zu finden ?
(Sry. wenns ne blöde Frage ist)
Frage 2.
Der CGminer zeigt zwischen durch immer wieder mal :
"Pool 0 stale share detected, submitting as user requested"
In der poolwallet zum beobachten der Miner wird immer angezeigt wie lange es benötigt bis ein Block gefunden wird (schwankt zwischen ca. 100.000 jahren und 220.000jahren
).Ist das die Zeit die die Miner brauchen um einen ganzen Bitcoin zu finden ?
(Sry. wenns ne blöde Frage ist)
Frage 2.
Der CGminer zeigt zwischen durch immer wieder mal :
"Pool 0 stale share detected, submitting as user requested"
Zu Frage 2 , Stale shares sind shares die in der zeit bearbeitet werden aber in der selben zeit wurde der Block gefunden und ist fertig und der neue Block wird schon bearbeitet.
Somit war jemand schneller mit größerer hashrate und hat die Share eher fertig bekommen als du .
Das passiert meistens wenn auf dem pool lauter miner mit sehr hoher hashrate connectet sind und der jenige mit der kleinsten oder weniger hashrate dort du bist.
Zu Frage 1 , das mit den 100.000 jahren und 220.000 jahren ist eine kalkulation vom pool anhand der hashrate die mit dem pool verbunden ist und wird aus der Netzwerk Hashrate
und dem momentanen Schwierigkeitsgrad (Difficulty) der Blockchain berechnet.
Das heißt die wahrscheinlichkeit einen Block zu finden dauert soviele jahre , hängt aber mit der Difficulty zusammen .
Es kann aber auch durch glück ein block morgen auf dem pool gefunden werden aber die chancen stehen da eher bei 0.1 - 1 % denk ich
Wird ein Block gefunden von deinem Miner und dem pool wo du minest bekommst du aber nur einen gewissen anteil entsprechend der Leistung was du zum finden des Blocks beigesteuert hast.
so,nach langem probieren und testen dann mal die kleine rückmeldung mit ein paar Fragen,vielleicht mag sie mir ja einer beantworten.
bei dem Minera tool hatte ich immer das problem das die Miner zwar mit um die 24Gh/s angezeigt wurden,aber immer grau unterlegt waren.
Laut minera also "possible dead".
Sie wurden zwar im Pool als Arbeiter angezeigt und auch die Gh/s wurden angezeigt, aber ergebnisse hab ich auch nach drei Tagen durchlaufen lassen nicht sheen können.
Bei dem CGminer hab ich ewig gebraucht bis ich mich da rein gefuxt hab,
aber mit Unicornhasher Thread ging es dann einigermaßen und schluß endlich hab ich die miner dort jetzt auch zum laufen bekommen und sie werden mir auch im Pool angezeigt und nun warte ich mal was passiert...
Frage 1.
In der poolwallet zum beobachten der Miner wird immer angezeigt wie lange es benötigt bis ein Block gefunden wird (schwankt zwischen ca. 100.000 jahren und 220.000jahren).
Ist das die Zeit die die Miner brauchen um einen ganzen Bitcoin zu finden ?
(Sry. wenns ne blöde Frage ist)
Frage 2.
Der CGminer zeigt zwischen durch immer wieder mal :
"Pool 0 stale share detected, submitting as user requested"
Weiß jemand was das bedeutet?
Ansonsten sieht es so aus:
Stratum from pool 0 requested work restart
[2021-01-29 18:22:04] Accepted 035f7a2c Diff 76/48 GSD 0
[2021-01-29 18:22:08] Accepted 04d59a6a Diff 53/48 GSD 0
[2021-01-29 18:22:09] Accepted 027bb435 Diff 103/48 GSD 0
[2021-01-29 18:22:13] Accepted 01d1e15f Diff 141/48 GSD 0
[2021-01-29 18:22:13] Accepted 053fd902 Diff 49/48 GSD 1
Ich bin jedenfalls schonmal zufrieden,und ja es geht mir hier bei meinen Projekten nicht darum morgen reich zu werden,ist mir also quasi wumpe ob ich 300k Jahre leben muss um den ersten bitcoin zu sehen...
Aber merkwürdig fand ich es schon das mir in der Poolwallet zum überprüfen der Fortschritte nichts angezeigt wird außer der Hashrate,als refferenz steht mir mein ausgedientes Windowsphone das seid jahren mit der Bitcoin Miner App läuft,und da wird mir im selben zeitraum mehr angezeigt,zum vergleich:
Dort wird mir einmal im Monat 0.00004** BTC an meine Wallet transverriert.
Da sollte ich doch bei den beiden Miner schon eher was sehen oder?
Na ich bin jedenfalls mal gespannt und bedanke mich nochmals für eure unterstützung.
Und vielleicht hat ja jemand ne gute idee für mein nächstes kleines Projekt
Gruß aus dem Norden
bei dem Minera tool hatte ich immer das problem das die Miner zwar mit um die 24Gh/s angezeigt wurden,aber immer grau unterlegt waren.
Laut minera also "possible dead".
Sie wurden zwar im Pool als Arbeiter angezeigt und auch die Gh/s wurden angezeigt, aber ergebnisse hab ich auch nach drei Tagen durchlaufen lassen nicht sheen können.
Bei dem CGminer hab ich ewig gebraucht bis ich mich da rein gefuxt hab,
aber mit Unicornhasher Thread ging es dann einigermaßen und schluß endlich hab ich die miner dort jetzt auch zum laufen bekommen und sie werden mir auch im Pool angezeigt und nun warte ich mal was passiert...
Frage 1.
In der poolwallet zum beobachten der Miner wird immer angezeigt wie lange es benötigt bis ein Block gefunden wird (schwankt zwischen ca. 100.000 jahren und 220.000jahren
).Ist das die Zeit die die Miner brauchen um einen ganzen Bitcoin zu finden ?
(Sry. wenns ne blöde Frage ist)
Frage 2.
Der CGminer zeigt zwischen durch immer wieder mal :
"Pool 0 stale share detected, submitting as user requested"
Weiß jemand was das bedeutet?
Ansonsten sieht es so aus:
Stratum from pool 0 requested work restart
[2021-01-29 18:22:04] Accepted 035f7a2c Diff 76/48 GSD 0
[2021-01-29 18:22:08] Accepted 04d59a6a Diff 53/48 GSD 0
[2021-01-29 18:22:09] Accepted 027bb435 Diff 103/48 GSD 0
[2021-01-29 18:22:13] Accepted 01d1e15f Diff 141/48 GSD 0
[2021-01-29 18:22:13] Accepted 053fd902 Diff 49/48 GSD 1
Ich bin jedenfalls schonmal zufrieden,und ja es geht mir hier bei meinen Projekten nicht darum morgen reich zu werden,ist mir also quasi wumpe ob ich 300k Jahre leben muss um den ersten bitcoin zu sehen...
Aber merkwürdig fand ich es schon das mir in der Poolwallet zum überprüfen der Fortschritte nichts angezeigt wird außer der Hashrate,als refferenz steht mir mein ausgedientes Windowsphone das seid jahren mit der Bitcoin Miner App läuft,und da wird mir im selben zeitraum mehr angezeigt,zum vergleich:
Dort wird mir einmal im Monat 0.00004** BTC an meine Wallet transverriert.
Da sollte ich doch bei den beiden Miner schon eher was sehen oder?
Na ich bin jedenfalls mal gespannt und bedanke mich nochmals für eure unterstützung.
Und vielleicht hat ja jemand ne gute idee für mein nächstes kleines Projekt
Gruß aus dem Norden
jup,das hab ich auch schon rausgefunden,
nur meine Walletadresse will minera/der Pool noch nicht aktzeptieren (ja eben eine für LTC angelegt).
Hab jetzt einen am Minera zum testen laufen und einen am 2ten berry um mich mal mit dem CGminer von Solo_miner aus einander zu setzen.
Aber danke für die hilfe und Gruß aus dem Norden
nur meine Walletadresse will minera/der Pool noch nicht aktzeptieren (ja eben eine für LTC angelegt).
Hab jetzt einen am Minera zum testen laufen und einen am 2ten berry um mich mal mit dem CGminer von Solo_miner aus einander zu setzen.
Aber danke für die hilfe und Gruß aus dem Norden
Es kommt auch ganz auf den Pool drauf an , bei den Pools wo du die worker erstellen kannst nimmst du in deiner config bei CGminer :
-u Dein_Worker_name -p Dein_Passwort
Code:
-u = user
-p =passwort
-p =passwort
Du kannst auch mal diese config ausprobieren habe die mal für einen freund geschrieben :
Code:
cgminer -o stratum+tcp://Dein_Pool:Dein_Port -u Dein_User_Name -p Dein_Passwort (meistens x) --bmsc-options 115200:20 --api-listen --api-allow 0/0
pause
pause
Der hatte auch einen Gridseed Miner , eventuell klappt es auch bei dir
Eventuell kannst ja auch schreiben ob es funktioniert hat.
PS und Edit :
Habe gerade diesen Thread hier noch gefunden eventuell hilft es dir !
[GUIDE] GridSeed GC3355 5 Chip Setup/power/windows/linux/rpi by UnicornHasher
jup,das hab ich auch schon rausgefunden,
nur meine Walletadresse will minera/der Pool noch nicht aktzeptieren (ja eben eine für LTC angelegt).
Hab jetzt einen am Minera zum testen laufen und einen am 2ten berry um mich mal mit dem CGminer von Solo_miner aus einander zu setzen.
Aber danke für die hilfe und Gruß aus dem Norden
nur meine Walletadresse will minera/der Pool noch nicht aktzeptieren (ja eben eine für LTC angelegt).
Hab jetzt einen am Minera zum testen laufen und einen am 2ten berry um mich mal mit dem CGminer von Solo_miner aus einander zu setzen.
Aber danke für die hilfe und Gruß aus dem Norden
Soweit ich weis kannst du mit den Gridseed Miners nur Scrypt Algo minen !
Der von dir angegebene Pool und die settings sind für ethermine.org und dort kann man nur mit Ethash Algo minen.
Das ist der erste fehler , und wenn du bei einem LTC pool minen willst denke ich das du dort einen Worker bzw eine LTC wallet adresse hinterlegen must.
Mit dieser Adress erkennt der pool dann deinen miner wenn er sich connected anhand der :
in deiner config datei , das sollte auch der grund dafür sein das du die fehlermeldung " Stratum authentication failed " bekommst.
Der von dir angegebene Pool und die settings sind für ethermine.org und dort kann man nur mit Ethash Algo minen.
Das ist der erste fehler , und wenn du bei einem LTC pool minen willst denke ich das du dort einen Worker bzw eine LTC wallet adresse hinterlegen must.
Mit dieser Adress erkennt der pool dann deinen miner wenn er sich connected anhand der :
Code:
"user": "Walletadresse",
"pass": "x"
"pass": "x"
in deiner config datei , das sollte auch der grund dafür sein das du die fehlermeldung " Stratum authentication failed " bekommst.
Ja Hallo erstmal,
dein Post ist im Bitcoin Bereich, sollte aber in den Altcoinbereich.
Nur als Info, dem Mod habe ich mal gebeten das zu "Moven".
dein Post ist im Bitcoin Bereich, sollte aber in den Altcoinbereich.
Nur als Info, dem Mod habe ich mal gebeten das zu "Moven".
Oh,sry,
das wusste ich nicht, ja dann bitte kurz verschieben und danke für den hinweis,
und danke für den tip.
Ja Hallo erstmal,
dein Post ist im Bitcoin Bereich, sollte aber in den Altcoinbereich.
Nur als Info, dem Mod habe ich mal gebeten das zu "Moven".
Gridseed und LTC =Scrypt.
Am besten nimmst du auf deinem Raspi CGMiner 4.3.5 oder neuer,
hier mal der Auszug:
bekommen kannst du das über github:
https://github.com/dmaxl/cgminer
dein Post ist im Bitcoin Bereich, sollte aber in den Altcoinbereich.
Nur als Info, dem Mod habe ich mal gebeten das zu "Moven".
Gridseed und LTC =Scrypt.
Am besten nimmst du auf deinem Raspi CGMiner 4.3.5 oder neuer,
hier mal der Auszug:
Code:
cgminer-scrypt
==============
CGMiner 4.3.5 with GridSeed and Zeus scrypt ASIC support.
This file describes Scrypt-specific settings and options.
For general CGMiner information refer to README.
Scrypt algorithm code was ported from CGMiner version 3.7.2.
## Zeus ##
./autogen.sh
./configure --enable-scrypt --enable-zeus
make
### Option Summary ###
```
--zeus-chips Default number of chips per device
--zeus-clock Default chip clock speed (MHz)
--zeus-options,,[;,,...]
Set chips and clock speed for individual devices
--zeus-nocheck-golden Skip golden nonce verification during initialization (serial mode only)
--zeus-debug Enable extra Zeus driver debugging output in verbose mode
```
The `zeus-chips` and `zeus-clock` options apply to every device unless overridden
on a per-device basis using `zeus-options`. The ID values to use with that option
depend on how CGMiner is communicating with the miners, explained in the next section.
### Device Selection ###
The driver supports using either libusb or directly reading/writing to the serial
port to communicate with the miner. Libusb is generally more convenient on Linux
while Windows users may prefer serial to bypass the requirement of installing special
libusb drivers. Mode selection depends on the `scan-serial` option:
* By default with no `--scan-serial` options the driver will use libusb to autodetect
any connected miners and to perform all device I/O operations. In this mode the ID
assigned to each miner for use with `--zeus-options` will be the miner's serial number
(except for Blizzard models, see note below).
* For serial I/O each miner must be specified manually using `--scan-serial zeus:`
and providing the path to the serial port (i.e. `/dev/ttyUSBx` on Linux or `\\.\COMx`
on Windows). The prefix "zeus:" is optional if CGMiner has been compiled with only the
Zeus driver enabled, otherwise it is required. In this mode the ID assigned to each
miner for use with `--zeus-options` will be the final part of the port (i.e.
`ttyUSBx` or `COMx`). Note that autodetection is not supported in this mode.
* On Linux systems only it is possible to use serial I/O and still have autodetection
by specifying `--scan-serial zeus:auto`. In this mode the driver will use libudev to
identify which USB-serial ports are from a Zeus miner. All I/O will still be done
using direct serial reads and writes (not through libusb) and the ID for each miner
will still be the final part of the port (ttyUSBx). This method is not recommended
if multiple drivers are compiled in as autodetection can be quirky in those cases.
The following three examples are equivalent assuming three miners are connected:
# Using libusb
./cgminer --scrypt --zeus-chips 96 --zeus-clock 328
# Direct serial I/O, manual port specification
./cgminer --scrypt --zeus-chips 96 --zeus-clock 328 --scan-serial /dev/ttyUSB0 \
--scan-serial /dev/ttyUSB1 --scan-serial /dev/ttyUSB2
# Direct serial I/O, auto-detect ports (Linux only)
./cgminer --scrypt --zeus-chips 96 --zeus-clock 328 --scan-serial zeus:auto
### Notes ###
Blizzard ID note: Blizzard models use a different USB-Serial chip which does not provide
a valid serial number. When using libusb mode with one of these the ID shown in CGMiner and
used with `--zeus-options` is the USB bus and device address in this format:
`:`
Chip count for different models:
Blizzard: 6, Hurricane X2: 48, Hurricane X3: 64, Thunder X2: 96, Thunder X3: 128
The model name displayed in the CGMiner UI depends on the chip count being specified correctly.
It is not auto-determined.
Zeus driver is based on [documentation][zeus] and the official reference implementation.
Many thanks also to sling00 and LinuxETC for providing access to test hardware.
[zeus]:
- - - - - - - -
## Gridseed ##
./autogen.sh
./configure --enable-scrypt --enable-gridseed
make
GC3355-specific options can be specified via `--gridseed-options` or
`"gridseed-options"` in the configuration file as a comma-separated list of
sub-options:
* baud - miner baud rate (default 115200)
* freq - any frequency multiple of 12.5 MHz, non-integer frequencies rounded up (default 600)
* pll_r, pll_f, pll_od - fine-grained frequency tuning; see below
* chips - number of chips per device (default 5)
* per_chip_stats - print per-chip nonce generations and hardware failures (only for 5-chip models)
* start_port - first port number for scrypt proxy mode (default 3350); see below
* voltage - switch the voltage to the GC3355 chips; see below
* led_off - turn off the LEDs on the Gridseed miner
When mining scrypt-only this version of cgminer does not initialize the SHA cores so that
power usage is low. On a 5-chip USB miner, power usage is around 10 W.
Gridseed support is based largely on the original [Gridseed CGMiner][] and
[dtbartle][]'s scrypt modifications.
[Gridseed CGMiner]:
[dtbartle]:
### Frequency Tuning ###
If `pll_r/pll_f/pll_od` are specified, freq is ignored, and calculated as follows:
* Fin = 25
* Fref = int(Fin / (pll_r + 1))
* Fvco = int(Fref * (pll_f + 1))
* Fout = int(Fvco / (1 << pll_od))
* freq = Fout
### Dual Mining ###
When dual-mining `start_port` will set the listening proxy port of the first gridseed
device on the SHA256 instance of cgminer, with additional miners using successive ports.
The scrypt instance of cgminer will attempt to connect starting at this port.
When dual mining, start the SHA mining instance of cgminer first, wait for it to begin
mining and then start the scrypt version. The second instance will detect that the USB
ports are in use and will attempt to connect to the first via UDP.
If everything is working the same devices will appear in both cgminer windows.
### Voltage Modding ###
If `voltage=1` is set the gridseed chips will be switched to an alternate voltage.
Specifically, this flag will cause the MCU to assert the VID0 input to the voltage
regulator. This *requires* a voltmodded miner. On a stock unit this will actually
reduce the regulator's output voltage.
### More Complex Options ###
The options can also be specified for each device individually by serial number via
`--gridseed-freq` or `--gridseed-override` or their configuration file equivalents.
`--gridseed-freq` takes a comma-separated list of serial number to frequency mappings
while `--gridseed-override` takes the same format as `--gridseed-options`:
--gridseed-freq "=[,...]"
--gridseed-override ":freq=,voltage=<0/1>[,...];:freq=[,...[;...]]"
==============
CGMiner 4.3.5 with GridSeed and Zeus scrypt ASIC support.
This file describes Scrypt-specific settings and options.
For general CGMiner information refer to README.
Scrypt algorithm code was ported from CGMiner version 3.7.2.
## Zeus ##
./autogen.sh
./configure --enable-scrypt --enable-zeus
make
### Option Summary ###
```
--zeus-chips
--zeus-clock
--zeus-options
Set chips and clock speed for individual devices
--zeus-nocheck-golden Skip golden nonce verification during initialization (serial mode only)
--zeus-debug Enable extra Zeus driver debugging output in verbose mode
```
The `zeus-chips` and `zeus-clock` options apply to every device unless overridden
on a per-device basis using `zeus-options`. The ID values to use with that option
depend on how CGMiner is communicating with the miners, explained in the next section.
### Device Selection ###
The driver supports using either libusb or directly reading/writing to the serial
port to communicate with the miner. Libusb is generally more convenient on Linux
while Windows users may prefer serial to bypass the requirement of installing special
libusb drivers. Mode selection depends on the `scan-serial` option:
* By default with no `--scan-serial` options the driver will use libusb to autodetect
any connected miners and to perform all device I/O operations. In this mode the ID
assigned to each miner for use with `--zeus-options` will be the miner's serial number
(except for Blizzard models, see note below).
* For serial I/O each miner must be specified manually using `--scan-serial zeus:
and providing the path to the serial port (i.e. `/dev/ttyUSBx` on Linux or `\\.\COMx`
on Windows). The prefix "zeus:" is optional if CGMiner has been compiled with only the
Zeus driver enabled, otherwise it is required. In this mode the ID assigned to each
miner for use with `--zeus-options` will be the final part of the port (i.e.
`ttyUSBx` or `COMx`). Note that autodetection is not supported in this mode.
* On Linux systems only it is possible to use serial I/O and still have autodetection
by specifying `--scan-serial zeus:auto`. In this mode the driver will use libudev to
identify which USB-serial ports are from a Zeus miner. All I/O will still be done
using direct serial reads and writes (not through libusb) and the ID for each miner
will still be the final part of the port (ttyUSBx). This method is not recommended
if multiple drivers are compiled in as autodetection can be quirky in those cases.
The following three examples are equivalent assuming three miners are connected:
# Using libusb
./cgminer --scrypt --zeus-chips 96 --zeus-clock 328
# Direct serial I/O, manual port specification
./cgminer --scrypt --zeus-chips 96 --zeus-clock 328 --scan-serial /dev/ttyUSB0 \
--scan-serial /dev/ttyUSB1 --scan-serial /dev/ttyUSB2
# Direct serial I/O, auto-detect ports (Linux only)
./cgminer --scrypt --zeus-chips 96 --zeus-clock 328 --scan-serial zeus:auto
### Notes ###
Blizzard ID note: Blizzard models use a different USB-Serial chip which does not provide
a valid serial number. When using libusb mode with one of these the ID shown in CGMiner and
used with `--zeus-options` is the USB bus and device address in this format:
`
Chip count for different models:
Blizzard: 6, Hurricane X2: 48, Hurricane X3: 64, Thunder X2: 96, Thunder X3: 128
The model name displayed in the CGMiner UI depends on the chip count being specified correctly.
It is not auto-determined.
Zeus driver is based on [documentation][zeus] and the official reference implementation.
Many thanks also to sling00 and LinuxETC for providing access to test hardware.
[zeus]:
- - - - - - - -
## Gridseed ##
./autogen.sh
./configure --enable-scrypt --enable-gridseed
make
GC3355-specific options can be specified via `--gridseed-options` or
`"gridseed-options"` in the configuration file as a comma-separated list of
sub-options:
* baud - miner baud rate (default 115200)
* freq - any frequency multiple of 12.5 MHz, non-integer frequencies rounded up (default 600)
* pll_r, pll_f, pll_od - fine-grained frequency tuning; see below
* chips - number of chips per device (default 5)
* per_chip_stats - print per-chip nonce generations and hardware failures (only for 5-chip models)
* start_port - first port number for scrypt proxy mode (default 3350); see below
* voltage - switch the voltage to the GC3355 chips; see below
* led_off - turn off the LEDs on the Gridseed miner
When mining scrypt-only this version of cgminer does not initialize the SHA cores so that
power usage is low. On a 5-chip USB miner, power usage is around 10 W.
Gridseed support is based largely on the original [Gridseed CGMiner][] and
[dtbartle][]'s scrypt modifications.
[Gridseed CGMiner]:
[dtbartle]:
### Frequency Tuning ###
If `pll_r/pll_f/pll_od` are specified, freq is ignored, and calculated as follows:
* Fin = 25
* Fref = int(Fin / (pll_r + 1))
* Fvco = int(Fref * (pll_f + 1))
* Fout = int(Fvco / (1 << pll_od))
* freq = Fout
### Dual Mining ###
When dual-mining `start_port` will set the listening proxy port of the first gridseed
device on the SHA256 instance of cgminer, with additional miners using successive ports.
The scrypt instance of cgminer will attempt to connect starting at this port.
When dual mining, start the SHA mining instance of cgminer first, wait for it to begin
mining and then start the scrypt version. The second instance will detect that the USB
ports are in use and will attempt to connect to the first via UDP.
If everything is working the same devices will appear in both cgminer windows.
### Voltage Modding ###
If `voltage=1` is set the gridseed chips will be switched to an alternate voltage.
Specifically, this flag will cause the MCU to assert the VID0 input to the voltage
regulator. This *requires* a voltmodded miner. On a stock unit this will actually
reduce the regulator's output voltage.
### More Complex Options ###
The options can also be specified for each device individually by serial number via
`--gridseed-freq` or `--gridseed-override` or their configuration file equivalents.
`--gridseed-freq` takes a comma-separated list of serial number to frequency mappings
while `--gridseed-override` takes the same format as `--gridseed-options`:
--gridseed-freq "
--gridseed-override "
bekommen kannst du das über github:
https://github.com/dmaxl/cgminer
Moin,
da ich mich mit dem mining noch nicht so auskenne habe ich vor kurzem den ersten Versuch unternommen, mal mit meinem PC ein wenig erfahrungen zu sammeln.
Nach einem kleinen anfänglichem Stolperstein hat das mit dem Phoenixminer auch ganz gut funktioniert und die ersten kleinen Erfolge sind in der Wallet zu sehen.
Daraufhin habe ich mich an den nächsten kleinen schritt gemacht und mir mal zwei alte Gridseed GC3355 besorgt um dann mal damit ein paar Erfahrungen zu sammeln.
Hab mir also den Thread von Unicorn und etliche weitere durchgelesen und angelesen und unter anderem auch diesen:
https://electrodrome.net/scrypt-mining-rig-gridseed-mini-raspberry-pi-2-b-minera/
Das ist im wesentlichen auch der "Versuchs Aufbau" , nur halt mit 2 von den Minern.
Das programm ist Minera als IMG und auch mit den Einstellungen komme ich soweit klar.
Allerdings bekomme ich keine H/s .
Und nach ein paar Tagen am suchen und testen bitte ich hier mal um Hilfe.
Es ist ein Raspberry PI 2B+ (über LAN am Router)
2x Gridseed GC3355
und dieses Minera IMG
https://getminera.com/download/latest
mit dieser JSON Conf:
{
"log": "\/var\/log\/minera\/cpuminer.log",
"gc3355-detect": true,
"gc3355-autotune": true,
"freq": "725",
"debug": true,
"pools": [
{
"url": "stratum+tcp:\/\/eu1.ethermine.org:4444",
"user": "Walletadresse",
"pass": "x"
}
]
}
Hat jemand nen Rat für mich wo mein Fehler liegt ?
So sieht die logdatei dann aus...
[2021-01-19 18:05:38.2565] Switching to pool: stratum+tcp://eu1.ethermine.org:4444
[2021-01-19 18:05:38.3139] Failed to get Stratum session id
[2021-01-19 18:05:38.3148] Failed to get extranonce1
[2021-01-19 18:05:38.3416] Failed to get Stratum session id
[2021-01-19 18:05:38.3423] Failed to get extranonce1
[2021-01-19 18:05:38.3432] ...retry after 5 seconds
Danke und Gruß aus dem Norden
Update:
Wenn ich den auf Litecoin (LTC) umstelle dann taucht als Fehler nur noch der authentication auf,
und das ist wenn ich nicht irre meine wallet adresse oder ?
(Ich bin oben auf dem falschen coin unterwegs oder ?)
[2021-01-19 18:57:41.0521] Switching to pool: stratum+tcp://ltc.hashcity.org:3000
[2021-01-19 18:57:41.1770] Stratum session id: 04038287
[2021-01-19 18:57:41.2297] Stratum authentication failed
[2021-01-19 18:57:41.2307] ...retry after 5 seconds
[2021-01-19 18:57:46.3018] Stratum session id: 06039280
[2021-01-19 18:57:46.3287] Stratum authentication failed
[2021-01-19 18:57:46.3297] ...retry after 5 seconds
da ich mich mit dem mining noch nicht so auskenne habe ich vor kurzem den ersten Versuch unternommen, mal mit meinem PC ein wenig erfahrungen zu sammeln.
Nach einem kleinen anfänglichem Stolperstein hat das mit dem Phoenixminer auch ganz gut funktioniert und die ersten kleinen Erfolge sind in der Wallet zu sehen.
Daraufhin habe ich mich an den nächsten kleinen schritt gemacht und mir mal zwei alte Gridseed GC3355 besorgt um dann mal damit ein paar Erfahrungen zu sammeln.
Hab mir also den Thread von Unicorn und etliche weitere durchgelesen und angelesen und unter anderem auch diesen:
https://electrodrome.net/scrypt-mining-rig-gridseed-mini-raspberry-pi-2-b-minera/
Das ist im wesentlichen auch der "Versuchs Aufbau" , nur halt mit 2 von den Minern.
Das programm ist Minera als IMG und auch mit den Einstellungen komme ich soweit klar.
Allerdings bekomme ich keine H/s .
Und nach ein paar Tagen am suchen und testen bitte ich hier mal um Hilfe.
Es ist ein Raspberry PI 2B+ (über LAN am Router)
2x Gridseed GC3355
und dieses Minera IMG
https://getminera.com/download/latest
mit dieser JSON Conf:
{
"log": "\/var\/log\/minera\/cpuminer.log",
"gc3355-detect": true,
"gc3355-autotune": true,
"freq": "725",
"debug": true,
"pools": [
{
"url": "stratum+tcp:\/\/eu1.ethermine.org:4444",
"user": "Walletadresse",
"pass": "x"
}
]
}
Hat jemand nen Rat für mich wo mein Fehler liegt ?
So sieht die logdatei dann aus...
[2021-01-19 18:05:38.2565] Switching to pool: stratum+tcp://eu1.ethermine.org:4444
[2021-01-19 18:05:38.3139] Failed to get Stratum session id
[2021-01-19 18:05:38.3148] Failed to get extranonce1
[2021-01-19 18:05:38.3416] Failed to get Stratum session id
[2021-01-19 18:05:38.3423] Failed to get extranonce1
[2021-01-19 18:05:38.3432] ...retry after 5 seconds
Danke und Gruß aus dem Norden
Update:
Wenn ich den auf Litecoin (LTC) umstelle dann taucht als Fehler nur noch der authentication auf,
und das ist wenn ich nicht irre meine wallet adresse oder ?
(Ich bin oben auf dem falschen coin unterwegs oder ?)
[2021-01-19 18:57:41.0521] Switching to pool: stratum+tcp://ltc.hashcity.org:3000
[2021-01-19 18:57:41.1770] Stratum session id: 04038287
[2021-01-19 18:57:41.2297] Stratum authentication failed
[2021-01-19 18:57:41.2307] ...retry after 5 seconds
[2021-01-19 18:57:46.3018] Stratum session id: 06039280
[2021-01-19 18:57:46.3287] Stratum authentication failed
[2021-01-19 18:57:46.3297] ...retry after 5 seconds
Jump to: