Show Posts
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.
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.
Anlaşılan bakkal defteri test yöntemleri kullanmak gerekecek verimliliği ölçmek için
