Dubbio Kh/S VS Thread concurrency

[djgabryel]

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???

[gdassori]

khs e accepted shares.

[djgabryel]

khs e accepted shares.

perdonami ma non ti ho capito

[lucolo]

La risposta alla tua domanda: KH/S e share accettate.
Questo intendeva dire

[djgabryel]

La risposta alla tua domanda: KH/S e share accettate.
Questo intendeva dire

quindi quale sarebbe il compromesso ottimale? Come faccio a capire quante share accetta la pool in base ai Kh/s prodotti?

[lucolo]

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).

[djgabryel]

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

[FaSan]

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 




FaSan

[lucolo]

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

il compromesso ottimale sarebbe quello di avere il massimo dei KH/S possibili

[djgabryel]

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

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.