|
@nejat, bende cgminer aynen dedıgın gıbı tekrar deneyıp mudahale etmeden baglandı. failover mantıklı olmus.
@crazyhacker, calisir
|
|
|
|
30 saniyelik bir restart kesıntısıydı  |
|
|
|
|
su an 3 mh/s gibi bir hashpowerımız var ve bir ay kadar surebılır. tabi biraz da sans ısı. ama pool hash powerı, 25-50 mh/s gibi bır seye cıkardıgımız anda bi iki gunde bir blok bulmaya baslayacagız tahmini olarak. su anda ilk 3 bloka birer ltc odulumuz var ama ılk bloktan aldıgım payın en az yarısını bu odul oranını arttırmaya kullanmayı dusunuyorum arkadaslar.
|
|
|
|
|
bende aynı anakartı kullanıyorum.
riser kablolar ıcın bende lınk alabılırm mıyım?
|
|
|
|
|
hw error 0'a ulastagınızda performansınız tam olarak poola yansıyatacaktır.
|
|
|
|
|
Hardware errorlariniz var cgminerda. Ya konfigurasyon kaynakli yada donanim. Lutfen kullandigini parametreleride belirtin. Poolun bu kadar az share gormesinin nedeni bu. 200 kusur hw hataniz var herseyin normal oldugu sistemde 0 olmasi gerekir. Hw errorlar yaptiginizin isin bosa gitmesine veya bosuna gpu cycle kullanmaniza neden olur
|
|
|
|
|
Pooldaki kullanici adiniz ne? Bende degerleri double check edeyim
+cgminer ekran goruntuzu rica ediyorum khash / share degerlerini kontrol edeyim
|
|
|
|
|
sizlerin de desteğiyle 2 günde 200 mesaja ulastık arkadaslar, oldukca hızlı bir sekilde buyuyoruz.
|
|
|
|
|
PPS konusunda haklısınız, forumuzda konu ilgili bir baslık acıp en azından pool yeterli miktarda hash powera kavusuna kadar PPS ile devam etmek mantıklı olabilir. oprhan block'a denk gelebilir miyiz? evet, ama PPS'ye geçersek kullanıcılarımız acısından bunun etkısı en az olacaktır.
PPS konusu ile ilgili gereklı calısmaya bır once baslayacagım. tabi PPS'yi calıstırmak icin pool fee'ye ihtiyac var. bu durumu en ıyı sekılde degerlendırıp, detaylı bir acıklama yapacagım.
|
|
|
|
|
blok cozumunden aldıgınız pay islem kapasitenizle alakalı ama direk degil. soyle anlatayım. diyelim ki bir fabrikada uretım bandımız var. iste gunde 700 adet urun uretebılıyoruz dıyelım (uretım kapasitemiz). ama bant bazı hatalı urunlerede neden olabiliyor. bu hatalı urunlerı ıscılerımız (pool) ayıklıyor diyelim ve yine ornek verirsek gunde 650 adet urunumuz asagı yukarı olması gerektıgı gıbı uretılıyor diyelim. iste bu 650 saglıklı urun bızım share'ımız oluyor.
bunun nedeni oncelikle stale sharelar. bunu anlatabılmek pool<->miner arasında ki eskı protokole donmemız lazım yani longpoll. temelde miner pool'dan bır gorev ister, uzerınde calısır ve sonucu pool'a geri verip, share (pay) sahibi olur. ama bitcoin'de ozellikle ASIC makinaların cıkması ile islem gucu o kadar arttı ki (600GH/s gibi cihazlar gelecek yakında), network baglantısı bır dar-bogaz olmaya basladı.
bunun uzerıne slush, electrum ıcın yazdıgı stratum protokolunu, pool<->miner arasında kullanmayı dusundu ve kabul gordu. stratumda, longpoll gıbı miner sureklı ıs ıstemez pool'dan. sadece baslangıcta bellı baslı bılgıler alır ve yapacagı ısı kendı yaratır ve is yaptıkca pool'a bunun bılgısını verir. tabi bu durumda stale share durumu ortaya cıkar. ben ve siz aynı poolda calısırken, senkron olmadıgımız ıcın sureklı, aynı ısı ıkımız bırden yapabılırız ve illaki biri digerinden once bu isin sonucunu pool'a bildirir. ben sizden bunu daha gec bildirmem durumunda, pool icerisinde o turda o is zaten yapılmıs oldugu ıcın stale share (bayat, eski) olur.
sımdı sorulara tekrar gerı donersek, pool sızın cihazınızın kh/s degeri ile ilgilenmez kazancların paylastırılması acısından. o sadece hangı miner bana kac tane is gondermıs bu round diye bakar ve bunun uzerınden paylasıma gider. yani ornek veriyorum, siz pooldaki en cok kh/s degerıne sahip olsanız bıle sureklı stale share gonderıyorsanız, kazanc elde edemezsiniz. ama bu stale shareların oranı %1'lerdedir.
Siz cgminer'da 557 kh/s deger gorurken, pool'un sana 77 kh/s demesının nedenine gelelim;
oncelikle, pool ile miner program ararsında veri aktarımında sızın kh/s degeriniz ile ilgili bilgi gitmez. arada sadece ve sadece is istekleri, is sonucları gider - yani share (paylar). vardiff kullanmayan bır sunucuda kh/s degerinizin yanı ıslem kapasitenizin onemı yoktur, pool bu degerle ilgilenmez. sadece frontend (web) yazılımı, kullanıcıya tahmını bır deger sunmak adına, belli bir periyodda gonderdıgınız share sayısından yola cıkarak, tahmini bir deger hesaplar. vardiff olmayan sunucuda bu deger genelde birkac dakika icerisinde cgminerda gordugunuz degeri gosterir.
simdi gelelim vardiffe. VARDIFF, variable difficultydir, yani degisken zorluk derecesi. vardiff kullanan sunucular, yukarıdaki gibi bir hesapla (birim zamanda gonderdıgınız share sayısı), sisteminizin kh/s olarak performansını hesaplar ve size gonderecegı isin zorluk derecesıne ona gore ayarlar. bu temelde, miner yazılımızın yenı ıs almak icin gereken sureyı azaltır. İşin daha da onemlısı ıse pool yazılımı ve sunucusu uzerınde ki stressi azaltır. Pool'lara genelde cok binlerce worker baglı oldugundan, vardiffsiz bir sunucu sureklı bu poollara network uzerınden bılgı akısı saglamak zorundadır. İşte vardiff olan sunucuda bu bılgı akısı mınımale ındırılmıs olur ve sunucu yuku azaltılır. Boylece sunucu daha fazla worker destekleyebilir, blokları kontrol edebılecek daha fazla zamanı olur ve sonucta minerlara efektif olarak daha fazla iş sağlayabilir.
butun bunlardan yola cıkarak, pool frontend zorluk derecenızın sureklı degıstıgını gorebilirsiniz bu normaldir. pool yazılımı sureklı olarak sizi takip eder, gonderdıgınız paylar cok yavas veya cok hızlı ıse zorluk derecenızı degıstırır.
|
|
|
|
harbi public koyda herkes yararlansın bende merak ettim |
|
|
|
kh/s performans degeri, pool' hemen yansımaz, cgminerda ki degerin pool'a yansıması ozellikle VARDIFF'te zaman alır. Havuzdaki sizin uretım mıktarırınızı olcen tek ve gecerli say share (yani pay) miktarınızdır. Yeni blok bulundugunda mevcut kullanıcıların toplam pay sayılarına gore, LTC paylasımı yapılır. Buda sitede istatistikler sayfasında PPLNS kısmında verilir. 'Size ait geçerli pay' kısmı onemlı olan veridir. Keza http://ltc.cointurk.net/index.php?page=statistics&action=pool sayfasından da paylara bakabilirsiniz. |
|
|
|
Bagımsız olma kısmı ilerde oldukça zor mühendislik açıdan incelersen zincirlerin boyu arttıkca o cüzdanlar kişisel bilgisayarların kaldıramayacagı düzeye gelecek buda bir merkez sistemin zincirleri kontrol etmesini zorunlu kılacak bu acıdan bir bankanın serverı sisteminden pek bir farkı kalmıyor.
svp client'ların, full-nodelar gıbı zıncırının hepsını bılmesıne gerek olmayacak pek yakında. |
|
|
|
|
zamanla dogru degerleri gorecektır ve bu temelde vardiffle ilgili. vardiff ve bu konuyla ilgili aksam detaylı bır acıklama yazacagım.
|
|
|
|
|
poolda degerlerin stabil hale gelmesi zaman alacaktır buda VARDIFF kaynaklıdır.
|
|
|
|
|
ayrıca belirtmekte fayda var asusun fiyatları genelde bir tık daha yukarıda
|
|
|
|
|
sagolun arkadaslar, sizlerin de katkılarıyla forum kısa zamanda buyuyecek diye dusunuyoruz.
|
|
|
|
|
butun configi kaldırıp sistemi default ayarlarıda calsıtırmayı deneyin. yavas yavas parametreleri ekleyin ve parametre kaynaklı olup olmadıgını gorun bence.
|
|
|
|
|
Show Posts
