Stale Rate

पूल वह सेवा है जो माइनरों में काम बाँटती है। नेटवर्क को नया ब्लॉक मिलने पर आम तौर पर उसके ऊपर अगला ब्लॉक बनाना शुरू करना होता है। पहले वाले कार्य से निकला नतीजा अब नए काम के लिए उपयुक्त नहीं रहता। माइनिंग उपकरणों के संचार प्रोटोकॉल Stratum V2 में SetNewPrevHash संदेश यह बदलाव करता है: उपकरण अब बताए गए ब्लॉक के आगे जुड़ने वाला ब्लॉक खोजना शुरू करता है। पहले से तैयार कार्यों में केवल वही वैध रहता है जिसकी पहचान job_id में दी गई है। इसलिए पेट्रा केवल भेजने का समय नहीं, कार्य की वैधता भी जाँचती है। [1]

एक सरल उदाहरण में पेट्रा समान कठिनाई के 100 नतीजे भेजती है। पूल 98 स्वीकार करता है, 1 को stale कहकर और 1 को किसी दूसरे कारण से अस्वीकार करता है। अस्वीकृत stale नतीजे 1% हैं; सभी अस्वीकृतियाँ मिलकर 2% हैं। F2Pool सभी भेजे गए नतीजों में सभी अस्वीकृत नतीजों के अनुपात को rejection rate कहता है। हमारे उदाहरण में stale उसका केवल एक हिस्सा है। ये संख्याएँ गणना समझाती हैं, स्वीकार्य संचालन सीमा नहीं बतातीं; अलग वर्गीकरण वाले डैशबोर्ड का मतलब अलग हो सकता है। [2]

Share की कठिनाई तय करती है कि भेजे जाने वाले नतीजे को कितनी सख्त शर्त पूरी करनी होगी। Braiins कठिनाई d वाले नतीजे को काम की d मूल इकाइयों के रूप में गिनता है। मान लें कि कठिनाई 1 की एक stale share है और कठिनाई 9 की एक स्वीकार की गई share है। नतीजों की संख्या गिनें तो 50%, काम के भार से गिनें तो 10% मिलता है। कोई गणना अपने आप में गलत नहीं है, लेकिन दोनों अलग सवालों का जवाब देती हैं। इसलिए पेट्रा तुलना में अंश और हर की इकाई समान रखती है और कठिनाई मापने का तरीका भी जाँचती है। [3]

F2Pool के दस्तावेज़ Staled नाम की श्रेणी, जिससे इनाम मिलता है, और अस्वीकृत stale shares, जिनसे इनाम नहीं मिलता, में अंतर करते हैं। इसलिए नाम भर यह नहीं बताता कि पेट्रा का पैसा खोया है या नहीं। यह नीति हर पूल पर लागू नहीं मानी जा सकती: उस सेवा के नियम और वास्तविक हिसाब मायने रखते हैं। सेवाओं की तुलना करते समय पेट्रा पहले नतीजों की श्रेणी पता करती है। तभी वह आय पर उनका असर आँक सकती है। [2]

संचालन लॉग पढ़ते समय यह बात छूट सकती है कि Stratum V2 एक SubmitShares.Success संदेश से कई भेजे गए नतीजों की पुष्टि कर सकता है। new_submits_accepted_count नए पुष्ट नतीजों की संख्या देता है, जबकि new_shares_sum उनकी कठिनाइयाँ जोड़ता है। इसलिए सर्वर के जवाब गिनना स्वीकार की गई shares गिनना नहीं है। अस्वीकृति पर SubmitShares.Error में sequence_number, भेजे गए नतीजे की पहचान, और error_code, त्रुटि का कारण, मिलता है। यह फर्क न करें तो पेट्रा हर त्रुटि को देर से पहुँचा काम समझ सकती है। [1]

नए ब्लॉक की खबर पहले Bitcoin की जाँच करने वाले कंप्यूटरों के बीच पहुँचनी चाहिए। BIP152 में Compact Block Relay बताया गया है: P2P नेटवर्क, यानी सीधे जुड़े प्रतिभागियों के नोडों के बीच कम डेटा से ब्लॉक भेजने का तरीका। कम डेटा से भेजने में लगने वाली देरी घट सकती है। लेकिन यह ब्लॉक फैलाने की व्यवस्था है, पूल में shares का हिसाब नहीं। इसलिए मुख्य चेन से बाहर रह गए ब्लॉकों का अनुपात पेट्रा की मशीन के देर से आए नतीजों का माप नहीं है। [4]

Braiins अलग अवधियों के काम के आँकड़े देता है: shares_5m (पिछले 5 मिनट), shares_60m (पिछले 60 मिनट) और shares_24h (पिछले 24 घंटे)। पेट्रा छोटे अंतराल के देर से आए नतीजों को पूरे दिन के काम से भाग देकर दूसरी मशीन के घंटे भर के आँकड़ों से तुलना नहीं कर सकती। गणना के दोनों हिस्सों में वही अवधि और वही उपकरण होने चाहिए। यदि कोई भेजा गया नतीजा देखा ही नहीं गया, तो अनुपात परिभाषित नहीं है; यह मापा गया 0% नुकसान नहीं है। निगरानी में अंतराल या जवाब का गायब होना भी अपने आप साबित नहीं करता कि नतीजा stale था। [5]

पेट्रा एक ही अवधि में कार्य के बदलाव, अस्वीकृति के कारण और कनेक्शन की स्थिति से शुरुआत करती है। F2Pool stale नतीजों को नेटवर्क की दशा से जोड़ता है। दूसरी अस्वीकृतियाँ firmware, यानी मशीन चलाने वाले सॉफ्टवेयर की त्रुटियों, या अत्यधिक overclocking से हो सकती हैं। Overclocking में अधिक गणनाएँ करने की कोशिश में चिप की काम करने की आवृत्ति बढ़ाई जाती है। Braiins ping सुझाता है: यह एक साधारण परीक्षण है कि सर्वर नेटवर्क से भेजे गए जाँच अनुरोध का जवाब देता है या नहीं। जवाब मिलने से माइनिंग की शुद्धता या इनाम खाते में जुड़ने की पुष्टि नहीं होती। कुल प्रतिशत का कम होना अपने आप कारण दूर होने का प्रमाण नहीं है। लक्ष्य यह समझना है कि क्या बदला, और तुलनीय परिस्थितियों में खास त्रुटि पर नज़र रखना है। [2] [6]