SMPFR

GG les mineurs.
Faut compter combien pour une HD 6970 en occasion ?

J'en ai acheté deux à 265in ya presque un mois. Très bonnes cartes, je sors du 500kh/s avec

normalement le hestimate doit pas changer, plus de puissance=plus de blocks dans la meme durée...
ça change si la difficulté augmente.
edit; la diffuculté a augmenté e 3% environ d'ailleur...

Ah, bien vu. Ca fait déjà 3.5 jours Bon cela dit 3% d'augmentation c'est ridicule, donc les gens quittent Litecoin ou ça se stabilise en tous cas.

Vous avez tous les deux raisons en fait Par round tu touches moins mais ya plus de rounds. Je me suis pas rendu compte des 3.5 jours sur la diff, ça me parait louche.

edit; paulo t'es a 5% du pool.
Tu as reçut combien sur les deux block qui sont tombé?
Commencé quand?

Le premier 1.84 LTC, et le second 0.14.
J'ai commença le GPU mining le 19 à 23h

0.14 c'est pas beaucoup oui...
je sais pas si il y a moyen de verif...

Surtout que j'ai actuellement un Estimated Per Payout de 2.4599495 LTC

On va attendre le prochain block, si c'est une erreur solitaire c'est pas grave.

T'as pas eu de coupure sur la journée ou la nuit dernière ? Ton hashrate est stable sur cette période ? Parce que 0.14 c'est très peu en effet. T'es sûr que c'est pas 1.84 sur le dernier et 0.14 sur le précédent ?

PPLNS donc faut un certain temps pour que la moyenne se mette en marche
la logique est expliqué dans le about

et pour jouer la transparence

$ cat 21-04-2013_22h15m01s.debug | cut -d" " -f1,3
poulpito:1 3.72000000
biour:3 7.74459900
4u9ur:4 4.94317096
gizmo15:5 1.52462618
GuYZmo:6 2.65856066
micha30000:7 5.58790904
yazyaz:8 3.34058500
steff00:9 0.00718700
TheMartel:11 2.98470249
assoslens:12 0.00398969
kalistyan:13 0.00007400
lls59:14 0.00158300
jhdscript:15 13.25040750
LILILUNE:16 0.93147516
leon57:17 0.70079328
IvanleFou:18 0.08994800
jes38:19 0.17573600
ZeuZ:20 0.84230047
darkremus:21 0.03351599
Teflon:24 0.36756400
angel038:27 0.08128000
Fungraphic:28 0.15195114
Lorenzo:32 0.00004800
Paulothekid:33 0.15157300
zoobidoo:34 0.15813765
Droopy:35 0.00962900
bozabonanza:36 0.02457600
streetmobo1:37 0.00373300
BelkaV:38 0.00035000

Miner 49.49000521
Pool 0.50999479

je trouve cela chelou aussi mon estimated était au double quasiment a 1.49ltc et je touche 0.7, de plus lililune avait moins de share que moi dans les stats,

dans les faits je m'en fou, je vais pas gueuler pour 1€, mais juste pour savoir comment est calculé cette répartition!

Pareil ZeuZ avait bien plus de share que moi, pourtant...

est ce que le stale pourrit les resultats? je suis a 0.34 environ sur la globalité de mes workers...

0.34% de stale c'est rien. Par contre pour la répartition je pense que c'est le jeu du PPLNS

pas du stale a 0.34, non...

Le nbre de shares on sen tape. Seul le last million est pris en compte.

T'as pas eu de coupure sur la journée ou la nuit dernière ? Ton hashrate est stable sur cette période ? Parce que 0.14 c'est très peu en effet. T'es sûr que c'est pas 1.84 sur le dernier et 0.14 sur le précédent ?

C'est bien 1.84 en premier chronologiquement parlant, c'est illogique. J'ai eu du downtime, mais pas autant (j'ai 10 fois moins qu'au premier round).

Hm on va attendre poulpi, y doit y avoir une explication dans la façon de calculer du pool. Si ya un pb faut le trouver de toute façon

bonjour

chez moi je cherche pourquoi après 4 a 5h le systeme se met en veille
et la moyenne descend a vue d'oeil de 580 a 80 et même a Zero

et toutes les options économies sont coupées win et bios

disabled ce qui ne sert a rien ( 3 des4 port lan) usb port , sata raid card etc il est au plus simple fonctions

j'ai même fait en même temps un occt pour maintenir le tout en pleine charge , quelqu'un a une piste ?

je change de config dès que je recois l'autre 5970 et cela serait un I7 pas un xeon ,

jvai regarder paulo t'en fait pas
et zeuz jsui dessus je me connecte pour regarer

encore un soucis de
-- error from accept() call too many open files --

j'ai encore augmenté la limite des fichiers ouvert sur le système j'avais pas encoremonté assez haut le palier
dsl pour le bug :/

-- le temps que tout se relance vous en faites pas pour le Khash/sec le calcul peut se planter --

bon maintenant je vais regarder cette histoire de paulo

j'ai coupé et relancer mes workers, 10% de stales suite au bug du pool
la sa rentre dans l'ordre

pour le paiement apparement y'a eu un soucis vers
21-04-2013_12h45m01s enfin entre 45 et 13h
pourquoi je ne sais pas encore toutes les estimations ont changées :/

ce que je vous propose c'est de laisser comme ca pour le moment et je vais voir comment je peux faire
pour essayer rapidement de coder qqchose ou de voir ce qui peut être remplacé facilement
parce que la .... je pige rien a ces changements d'humeur

le calcul est censé être simple :

c'est une analyse des backend php que je me suis faite pour mieux comprendre le fonctionnement

######### Calcul PPLNS 

-> SELECT DISTINCT s.blockNumber FROM shares_uncounted s, networkBlocks n WHERE s.blockNumber = n.blocknumber AND s.counted=0 AND n.confirms > 119 ORDER BY s.blockNumber ASC (on select un nombre de bloc valide qui n'as pas encore était compté )

-> pour chaque block qui a des shares uncounted = 0 et qui a les confirm on va prendre les shares totales 
-> on ajoute le total de shares par block (desc) jusqu'a ce qu'on arrive a Nshares (1M)
-> si on a on définie le block qui correspond comme l_bound  
-> si l_bound est inf au bloc en cours on marque tt les shares en shares_uncounted comme counted=1

-> on select la somme des shares par user ayant travaillé sur les 1M derniers blocs 

-> pour chaque user on calcul le $shareRatio = $uncountedShares/$totalRoundShares; 

-> on applique le % de don de pool si il y en a (pas ici) 
-> on enlève le % de don individuel de la somme finale : $totalReward = $totalReward - ($totalReward * ($donatePercent/100));

-> on inscrit la transaction dans mysql en - pour le pool et en + pour la balance du user et on inscrit la transaction dans la base ledger 

-> on marque les shares comptés pour qu'ils ne soient pas repris en compte 

sauf que je pense que la merde se situe entre les requetes croisées sur les 3 tables shares / shares_uncounted / share_counted + sur le fait que dans un round court une fois que les shares sont comptés pour arriver aux 1M bah on remonte aux blocs précédents (genre l'avant/avant dernier) ou la certaines personnes n'ont pas calculé d'ou le bon dans les sous recus

admettons mon cas (les chiffres sont faux ein) je soumet x shares / round
bloc 1 : 100000 shares
bloc 2 : 150000 shares
bloc 3 : 100000 shares
bloc 4 : 100000 shares
bloc 5 : 50000 shares
(admettons que je fasse 1/10 du pool en calcul donc sur 1M de PPLNS on va me calculer sur 100k)

bloc 1 : OK y'a de quoi calculer 100k sans aller piocher ailleurs
bloc 2 : OK y'a de quoi calculer 100k et il reste 50K
bloc 3 : OK y'a de quoi calculer 100k sans aller piocher ailleurs
bloc 4 : OK même chose

MAIS
bloc 5 : y'a que 10k shares .... donc soucis puisque dans le même ratio le calcul total pour tout le pool sera obligé de remonter dans le temps pour arriver à trouver des shares manquant pour le calcul ....
en l’occurrence bloc 2 ou y'a 50k shares non comptés en réserver

donc il suffit que toi tu arrive entre le bloc 3 et le 5 tu crunch mais le 5 est super court et le 3-4 on été comptés plein pot ... bah on compte les shares du 2 ou tu étais pas la ....


je vois aussi ce soucis donc pour moi y'a un peu de faute de calcul mais potentiellement pas tant que ca

c est normal que les paid ont baisé. On est passé de 13M/h a 20M/h aussi

le mieux ca serait pas de faire une repartition sur tous les shares du block ?