I2P डेवलपर बैठक - 16 मई, 2006

<cervantes> moo: http://dev.i2p.net/pipermail/i2p/2006-May/001289.html <cervantes> 0) हाय <cervantes> 1) jrandom यहाँ नहीं है <cervantes> 2) ??? <cervantes> 0) हाय <cervantes> हाय <cervantes> आइए 1) पर बढ़ते हैं <cervantes> jrandom आज यहाँ नहीं है, लेकिन वह हमें कल स्थिति अपडेट देगा <cervantes> 2) ??? <cervantes> क्या किसी के पास बैठक में जोड़ने के लिए और कुछ है? <bar> मेरे पास एक सवाल है <cervantes> उस स्थिति में... * cervantes तैयार होता है * cervantes तैयारी रोकता है <Complication> आहा, एक सवाल... <bar> cvs में PRNG (छद्म-यादृच्छिक संख्या जनक) का फिक्स, क्या वह समग्र प्रदर्शन में सुधार करेगा या यह किसी और चीज़ से संबंधित है? <cervantes> इसके सामान्य प्रभाव क्या होंगे, यह अनिश्चित है <Complication> मैं व्यक्तिगत रूप से इसके कुल प्रभाव से अवगत नहीं हूँ, लेकिन इसमें कम से कम दो व्यवहार शामिल हैं जिनके बारे में मैं जानता हूँ: <cervantes> लेकिन यह विशेष रूप से i2ptunnel से जुड़े एक लक्षण को ठीक करता है * cervantes Complication को decomplicate करने देता है <Complication> tunnel length randomization और IRC सर्वर का चयन (और सामान्य रूप से, I2PTunnel destinations की सूची में से यादृच्छिक चयन) <Complication> Tunnel length randomization का समग्र नेटवर्क स्वास्थ्य पर सम्भवतः महत्वपूर्ण प्रभाव है, क्योंकि यह उन क्लाइंट्स को, जिन्हें tunnel length पर समझौता करने की अनुमति है, वास्तव में ऐसा करने देता है <Complication> तो वे साँस रोककर केवल 2-hop tunnels नहीं बनाएँगे, बल्कि कुछ 1-hop tunnels भी आज़माएँगे <Complication> (जो मुश्किल समय में, हासिल करना काफी आसान होते हैं) <cervantes> इसके रोलआउट होते ही IRC कनेक्टिविटी भी बेहतर हो सकती है। मूल रूप से freshcoffee को कभी भी कोई client connections नहीं मिल रहे थे क्योंकि वह सूची में दूसरे स्थान पर था - तो अगले रिलीज़ के साथ लोड दोनों सर्वर्स के बीच समान रूप से वितरित होना चाहिए <bar> तो उस बग ने लोगों को, उपलब्ध होने पर, हमेशा लंबी tunnel length चुनने पर मजबूर किया? <Complication> यदि मैं सही समझा हूँ, तो छोटे इंटीजरों के साथ होने वाली हर randomization (उदा. 0 या 1 चुनना) प्रभावित थी <Complication> मुझे लगता है कि बड़े इंटीजरों वाली randomizations (उदा. 0 से 100 के बीच एक integer चुनना) कम प्रभावित थीं <Complication> यदि आपकी रुचि हो, तो जब वह लौटें, तो विवरण के लिए शायद आपको jranom से पूछना चाहिए <Complication> संभव है कि मैं विवरण गलत बता रहा हूँ। <bar> समझ गया, धन्यवाद। अच्छा पकड़ा <Complication> खैर, cervantes यहाँ आया और overload न मिलने की शिकायत करने लगा ;P <cervantes> यह मेरी भी यही समझ थी <cervantes> देखो... ज़िंदगी में बिन शिकायत किए कुछ नहीं मिलता :) <cervantes> क्या किसी के पास बैठक के लिए और प्रश्न या विषय हैं? <fox> <duck> हाँ <Pi> सामान्य नेटवर्क स्वास्थ्य के बारे में एक प्रश्न: मैं देखता हूँ कि अधिकाधिक क्लाइंट्स I2P-वर्ज़न के मामले में पीछे छूट रहे हैं (कुछ अभी भी 0.6.1.11 आदि का उपयोग कर रहे हैं)। क्या ये क्लाइंट्स कोर में बदलावों के प्रभावों की मॉनिटरिंग को और अधिक कठिन नहीं बना देंगे? (क्योंकि "कम" लोग अपडेट करना चाहते प्रतीत होते हैं) <fox> * duck उपरोक्त दोहराता है * w423412323 उस दिशा में विषय बदलने का सुझाव देता है। ;) <fox> <duck> मैं सोच रहा था, मैंने cvs मेलिंगलिस्ट पर कुछ अजीब से ट्यूनिंग कमिट्स देखे हैं। क्या वे अधिक प्रयोग मात्र हैं? क्या वे अवलोकनों पर आधारित हैं? क्या वे समय से पहले हैं? <Complication> Pi: जब तक वे बड़ी संख्या में मौजूद नहीं हैं, तब तक उनका बड़ा फर्क नहीं पड़ना चाहिए <Pi> मेरे netdb के अनुसार अभी 300 में से 70 क्लाइंट्स non-0.6.1.18-version का उपयोग कर रहे हैं <Complication> यह संख्या और क्षमता का खेल है - यदि या तो अधिकांश routers, या अतिरिक्त रूप से सबसे उच्च-क्षमता वाले routers ठीक-ठाक अपडेटेड हैं, तो कुछ लोगों का यह भूल जाना कि उन्होंने I2P इंस्टॉल कर रखा है, ज्यादा मायने नहीं रखेगा :) <cervantes> Pi: यदि पुराने routers गलत व्यवहार करते हैं तो नेटवर्क को _चाहिए_ कि वह अनुकूलित हो और उनके माध्यम से router हो रहे ट्रैफिक को कम करे <cervantes> *being routed <cervantes> Complication: क्या तुमने duck का सवाल देखा? <Pi> और i2p-console पर कुछ समय पहले जो एक सांख्यिकी दिखी थी, उसके बारे में एक प्रश्न: handle backlog का क्या मतलब है? <Complication> duck: क्या तुम tunnel throttle adjustments की बात कर रहे हो? वे ट्यूनिंग हैं इस अर्थ में कि वे स्वभावतः बहुत नया कुछ नहीं लाएँगी, लेकिन अब वे काफ़ी अच्छी तरह टेस्टेड होनी चाहिए (उदा. वे शायद byte नहीं करेंगी) <Complication> लेकिन वे थोड़ा byte कर सकती हैं, यदि आप ऐसा विचित्र setup चलाते हैं जो मेरे सोचे गए पैरामीटर्स से पूरी तरह बाहर है <fox> <duck> Complication: मैं सोच रहा था कि '3' की जगह '2' वाली चीज़ें वास्तव में इतना मायने रखती थीं क्या <fox> <duck> लेकिन ऐसा लगा कि random समस्या शायद बड़ा खलनायक थी <fox> <duck> (हालाँकि नेटवर्क की अस्वस्थता पर उसके सापेक्ष प्रभाव इस पर निर्भर करता है कि उसे कब पेश किया गया था) <cervantes> Pi: handle backlog लंबित inbound tunnel join requests की संख्या है (changelog से उद्धृत) <Complication> यदि तुम random nextInteger() समस्या और tunnel length randomization पर उसके प्रभाव की बात कर रहे हो, तो मुझे लगता है कि उसका महत्वपूर्ण प्रभाव होगा <Complication> 1-hop और 2-hop tunnel बनाने की लागत का अंतर काफ़ी महत्वपूर्ण है <Pi> धन्यवाद, cervantes :) <fox> <duck> यह कब पेश किया गया था? <Complication> duck: मेरा मानना है कि यह Fortuna जनरेटर पर कुछ स्विचओवर के साथ, या उसमें कुछ संशोधनों के साथ पेश हुआ था <fox> <duck> ठीक है; आपके इनपुट के लिए बहुत धन्यवाद <Complication> मुझे अधिक विवरण के लिए cvsweb देख लेने दें... <cervantes> Pi: मेरा मानना है कि अब ऐसा कोड मौजूद है जो queue भर जाने पर inbound tunnel requests को ड्रॉप कर देता है (CPU लोड कम करने में मदद के लिए) <Complication> Pi: हाँ, वह उस दूसरे पैरामीटर का दृश्य सूचक होना चाहिए जिसका उपयोग यह तय करने में होता है कि "क्या हमारे पास किसी और tunnel में भाग लेने की पर्याप्त क्षमता है?" <cervantes> duck: फिक्स आने के बाद से मैंने निश्चित रूप से router behaviour में बड़ा बदलाव अनुभव किया है। - कहना पड़ेगा कि सब अच्छा नहीं है :) <Complication> बड़ा handle backlog == congestion, दूसरों की tunnels में शामिल होने की कोशिश करने का कोई मतलब नहीं <cervantes> कुछ दिन पहले load average 14 था और 12000 participating tunnels थीं <Complication> Handle backlog विशेषकर high-capacity routers पर महत्वपूर्ण लगता है (cervantes ने जो देखा, उसी संदर्भ में) <Complication> Low capacity routers आम तौर पर bandwidth कारणों से अपनी tunnel acceptance को throttle करते हैं <Complication> (या सही कहें तो tunnel test time के कारण) <Complication> (या कम से कम, ऐसा करने की कोशिश के लिए) <cervantes> वाह, हमने आधा घंटा निकाल लिया.... <Complication> वास्तव में :D <cervantes> क्या कोई और कुछ बात उठाना चाहता है? <cervantes> उस स्थिति में... * cervantes तैयार होता है * cervantes *baffs* बैठक को बंद करता है <fox> <duck> बैठक संभालने के लिए धन्यवाद <cervantes> हेह मैं उम्मीद कर रहा था कि कोई कुछ कहने से पहले ही इसे baf करके बंद कर दूँ....लेकिन bar ने वह योजना खराब कर दी :)