Author

Topic: Dubbio Kh/S VS Thread concurrency (Read 734 times)

member
Activity: 106
Merit: 10
December 13, 2013, 06:55:32 AM
#10
Premettiamo che di scrypt mining so quanto il sentito dire ed una blanda lettura può avermi informato.

Detto questo il compromesso ottimale sarebbe quello di avere il massimo dei KH/S possibili (facendo attenzione ad overclock/costi corrente) cercando di perdere il minor numero di shares (a causa di down di internet ad esempio).

quindi in proporzione magari meglio perdere un po di khs ma è preferibile far lavorare le gpu su piu thread possibili
No, ho detto il contrario Grin
Quote
il compromesso ottimale sarebbe quello di avere il massimo dei KH/S possibili

si ma ho notato che trovando settings per fa aumentare molto i khs l'hardware inizia a creare errori, ergo i thread vanno di pari passo al modello della gpu che si utilizza.
legendary
Activity: 1092
Merit: 1021
December 13, 2013, 05:17:55 AM
#9
Premettiamo che di scrypt mining so quanto il sentito dire ed una blanda lettura può avermi informato.

Detto questo il compromesso ottimale sarebbe quello di avere il massimo dei KH/S possibili (facendo attenzione ad overclock/costi corrente) cercando di perdere il minor numero di shares (a causa di down di internet ad esempio).

quindi in proporzione magari meglio perdere un po di khs ma è preferibile far lavorare le gpu su piu thread possibili
No, ho detto il contrario Grin
Quote
il compromesso ottimale sarebbe quello di avere il massimo dei KH/S possibili
hero member
Activity: 658
Merit: 500
December 12, 2013, 07:12:15 PM
#8
Io sono dell' idea che è meglio cercare di tirar su più KH/s possibili senza che l' HW vada in errore. In cgminer e in bfgminer basta attivare il verbose per rendersi conto se l' HW và in errore o meno, digitando D e poi V ed infine INVIO

Se hai quindi un elevato KH/s e l' HW non presenta errori allora sei apposto, puoi incrementare un pò e ricontrolli, finchè non sei al limite degli errori o poco meno  Tongue




FaSan
member
Activity: 106
Merit: 10
December 12, 2013, 07:07:04 PM
#7
Premettiamo che di scrypt mining so quanto il sentito dire ed una blanda lettura può avermi informato.

Detto questo il compromesso ottimale sarebbe quello di avere il massimo dei KH/S possibili (facendo attenzione ad overclock/costi corrente) cercando di perdere il minor numero di shares (a causa di down di internet ad esempio).

quindi in proporzione magari meglio perdere un po di khs ma è preferibile far lavorare le gpu su piu thread possibili
legendary
Activity: 1092
Merit: 1021
December 12, 2013, 05:57:46 PM
#6
Premettiamo che di scrypt mining so quanto il sentito dire ed una blanda lettura può avermi informato.

Detto questo il compromesso ottimale sarebbe quello di avere il massimo dei KH/S possibili (facendo attenzione ad overclock/costi corrente) cercando di perdere il minor numero di shares (a causa di down di internet ad esempio).
member
Activity: 106
Merit: 10
December 12, 2013, 04:28:07 PM
#5
La risposta alla tua domanda: KH/S e share accettate.
Questo intendeva dire Grin
quindi quale sarebbe il compromesso ottimale? Come faccio a capire quante share accetta la pool in base ai Kh/s prodotti?
legendary
Activity: 1092
Merit: 1021
December 12, 2013, 03:16:07 PM
#4
La risposta alla tua domanda: KH/S e share accettate.
Questo intendeva dire Grin
member
Activity: 106
Merit: 10
December 12, 2013, 03:03:13 PM
#3
khs e accepted shares.

perdonami ma non ti ho capito Cheesy
hero member
Activity: 980
Merit: 1002
December 12, 2013, 03:00:04 PM
#2
khs e accepted shares.
member
Activity: 106
Merit: 10
December 12, 2013, 02:58:12 PM
#1
Salve ragazzi ho un dubbio amletico.
Ma i thread concurrency sono direttamente proporzionali alla quantità che possiamo ottenere di un blocco?
Perchè vi spiego sto testando una R280x e sta tenendo fissa 750Kh/s il punto è che ho impostato "solo" 8192 thread concurrency.
LA domanda quindi è va cosi veloce perchè ha pochi thread oppure l'importante per colpire i blocchi sono i Kh/s???
Jump to: