ormai la diff è così alta che con 30tb fai tipo 300burst al giorno... un minimo di correlazione ci deve essere tra hashrate e valore della moneta...
ah si certo bisogna considerare anche questo (anche se la mia media con 20TB è un po' più altina)
|
|
|
io vedo solo sto sito 4co.org registrato anonimamente e senza alcuna informazioni specifica, una pagina con 4 frasi random e il cui unico contatto è un indirizzo email
|
|
|
caspita ragazzi, non seguivo i burst da un pò di tempo, ora li trovo su poloniex a 230 satoshi ? con il prezzo del bitcoin, direi che è oro, fortuna cher avevo holdato stanno andando pesanti con le pubbliche relazioni su burstnation.. sta di sicuro aiutando a tener su il valore
|
|
|
Uno dei punti negativi di storjshare è che pagano quando vogliono loro... una volta al mese si ma quando? il giorno 7, poi 8, 9, oggi siamo il 10 e non ho ancora visto nulla. Potranno passare anche a ethereum ma dovrebbero prima puntare alla puntualità
postano aggiornamenti nella sezione community sul sito ufficiale https://community.storj.io/channel/storjsharepare che i pagamenti siano bloccati e bisogna attendere..
|
|
|
C'erano 300 persone e almeno 50-60 da ogni parte del mondo. le foto girano dappertutto, ma per voi è ovvio, non ci sono!! E' proprio vero...... a parte l'evidenza!
dove girano? link please
|
|
|
ragazzi piccolo problema ...praticamente al mio pc ho collegato hhd esterno da 8tb ....ma quando lo collego in contemporanea con il predecessore anch esso esterno da 2tb e vado a minare mi da overlapped come se i due hhd si sovrapponessero....qualcuno sa come risolvere questo problema in maniera da far camminare contemporaneamente i due hhd?....cordiali saluti a tutti!!! ps: collegandoli separatamente minano entrambi quando plotti i dischi devi controllare sempre che le nonce non si sovrappongano, lo puoi capire dal nome del file esempio: numeroaccount_0_10240000_10240000 in questo caso il file con questo formato indica che per l'account N° xxxx vengono scritte le nonce dalla posizione 0 e ne sono state scritte 10240000 in tutto un nuovo file dovrà tenere conto che per quell'account servirà scrivere nonces a partire dalla numero 10240001 e quindi il formato dovrà essere: numeroaccount_10240001_10240000_10240000 (ovvero, partendo dalla nonce 10240001 me ne scrive altre 10240000) se dovessi fare un nuovo file dovrò partire dalla nonce n° 10240001+10240000=20480001 + 1 = 20480002 e così via... controlla i tuoi file e vedi un po' quante nonce doppie hai creato per sbaglio..
|
|
|
uso spesso kraken e ad oggi non ho mai avuto problemi
|
|
|
disabilita il link tra power limit e temp limit (la catenella tra le due righe) e metti il temp limit sugli 85° ( o vedi tu), imposta il tdp in modo che consumi sui 120W e da li inizi a vedere a quanto puoi alzare le memorie, andando per tentativi
|
|
|
con le memorie micron potrebbe essere necessario un upgrade del bios (con una mia 1070 msi l'ho dovuto fare per poter alzare le memorie a dovere)
|
|
|
dovresti riuscire a fare ~430sol a 120W con la 1070 che memorie monta? sto valutanto di aggiungere delle zotac mini al mio rig, se smanettando riuscissi a confermarmi che viaggia sui valori standard per le 1070 (e a che temperatura) sarebbe una gran cosa
|
|
|
esatto la media tra un blocco e l'altro, a livello teorico, dovrebbe essere circa 4 minuti, può capitare che scenda attorno ai 60 secondi o che salga a 20 minuti sporadicamente
|
|
|
nella schermata del miner Found DL = Hai trovato una deadline il cui "valore" è pari a 780937 secondi che equivalgono a 9 giorni 55 minuti e 37 secondi Send DL = mando la mia deadline alla pool confirmed DL = la pool ha confermato come valida la mia DL andando avanti nel controllo del mio plot file sono riuscito a trovare una deadline pari a 361101 secondi ovvero 4 giorni 4 ore 18 minuti e 21 secondi, la mando alla pool ed andrà a sostituire quella mandata poco fa dato che è migliore i restanti valori sono informazioni aggiuntive riguardanti il tempo impiegato ad analizzare i dischi e le risorse utilizzate (nel mio caso ho impiegato circa 30 secondi a controllare i primi 5 dischi e circa 60 a terminare gli ultimi 2) viene letta solo una porzione minima del plot durante un blocco come ho scritto nell'altro topic l'unica cosa importante è completare il controllo dei dischi prima che esca un nuovo blocco, farlo in mezzo secondo o farlo in 200 non cambia nulla
|
|
|
Le deadline non cambiano, completare il controllo in 5 secondi o in 50 è del tutto ininfluente per quel che riguarda la "qualità" delle deadline. La cosa fondamentale è riuscire a controllare tutti i dischi prima del blocco successivo (ma mediamente si hanno circa 4 minuti tra un blocco e l'altro, salvo rari casi in cui passano solo 60 secondi tra un blocco e l'altro.. così come può capitare che passino 20 minuti..) Con le priority impostate così, ho modo di effettuare il controllo stando sotto i 60 secondi quindi non corro il rischio di perdermi i blocchi.
|
|
|
Ogni pool ha impostato di default un valore massimo (espresso in secondi) oltre il quale rifiuterà le deadline che lo superano; su un lungo periodo la differenza tra una pool e l'altra non si dovrebbe notare, ad ogni modo conviene scelgiere una pool affine alla propria dimensione dei plot per avere un rendimento quanto più costante possibile. Quindi il succo è: la pool migliore per me è quella a cui riesco a mandare mediamente almeno una deadline valida per ogni blocco (ovvero che non super il limite tDeadline impostato su quella pool) Sul mio spreadsheet sotto la voce "check my pool info", anche senza inserire il proprio account, è possibile scegliere dal menu a tendina le varie pool e tra i vari campi c'è anche quello indicato come "Recommended plot size" che ti mostrerà il valore suggerito in TB per minare su quella pool (è parecchio indicativo e cambia spesso anche in base alla difficulty) Ad ogni modo penso di poterti consigliare http://pool.burstmining.club/direi che è tra le più seguite dal punti di vista di sviluppo/manutenzione e i sui attuali gestori ( www.burstnation.com) hanno in cantiere (a detta loro..) una nuova versione che svecchierà parecchie cose
|
|
|
Non è necessario andare a toccare la cpu affinity (ci avevo provato inizialmente ma con un processore da 30€ e due thread a disposizione non mi risolveva il problema), quella che ho modificato è la cpu priority (below normal per il processo burst, e above normal per i miner gpu) in questo modo i carichi sono distribuiti automaticamente sui due thread e al miner burst restano diciamo le "briciole", tanto quanto basta perchè completi il ciclo di controllo dei dischi in tempo prima del prossimo blocco.. senza intaccare minimamente le prestazioni delle mie gpu
|
|
|
grazie
|
|
|
ti rispondo con un esempio, se sulla pool hai scritto 28D+150U+1000 28D sono in burst che stai accumulando e che verranno pagati nel momento in cui raggiungerai la soglia minima di pagamento (di solito è sui 250 burst) o il periodo fisso per i pagamenti impostati sulla pool (di solito 1 ogni 24 ore) , la D sta per Deferred 150U è un pagamento che è stato inviato ma è ancora in attesa di conferme (U = unconfirmed) 1000 sono i burst pagati al tuo account da quando è entrato nella pool Prima di raggiungere la media io ho dovuto aspettare un mesetto... e comunque è sempre molto ballerina e dipende molto dai blocchi che riesco a forgiare ( ricorda che mediamente le pool hanno impostato come rapporto di reward dei blocchi un 60/40, ovvero se un membro della pool forgia un blocco gli spetta il 60% del blocco mentre il rimanente 40% viene distribuito secondo lo storico degli share, basato di solito sugli ultimi 40/50 blocchi) ho creato uno spreadsheet di recente, di base serve per analizzare il proprio portafoglio assets, ma si può anche usare per vedere le proprie statistiche della propria pool https://docs.google.com/spreadsheets/d/10C-VQUeFG46inyPRbdIiP0Iaqd2BcM3trw6fqs6uSnM
|
|
|
|