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

16:09 <jrandom> 0) हाय 16:09 <jrandom> 1) नेट स्थिति 16:09 <jrandom> 2) Syndie स्थिति 16:09 <jrandom> 3) ??? 16:09 <jrandom> 0) हाय 16:09 * jrandom हाथ हिलाता है 16:10 <jrandom> साप्ताहिक स्थिति नोट्स यहां पोस्ट किए गए हैं: http://dev.i2p.net/pipermail/i2p/2006-May/001285.html 16:11 <jrandom> ठीक है, जब तक आप सब वह रोमांचक मेल पढ़ते हैं, चलिए 1) नेट स्थिति पर चलते हैं 16:13 <jrandom> अब तक, लगता है कि पूरी congestion collapse (नेटवर्क भीड़भाड़ के कारण पतन) की समस्या ठीक हो गई है, और tunnel निर्माण दरें काफी अच्छी चल रही हैं। फिर भी, कुछ मुद्दे बाकी हैं जिन्हें सुलझाना है 16:14 <jrandom> पहले चर्चा किया गया चक्रीय व्यवहार (अक्सर 10-12 मिनट के अंतराल पर) अब भी मौजूद है, जिससे उल्टानुपाती रूप से अस्वीकार हो रहे हैं। -1 के अनुसार कोड में नया सुधार है जो इसे हटा देना चाहिए 16:15 <jrandom> (यानी, tunnel expirations को /ठीक से/ रैंडमाइज़ करना, पहले की टूटी हुई रैंडमाइज़ेशन के विपरीत) 16:16 <jrandom> वह, और बेहतर ssu तथा tunnel टेस्ट शेड्यूलिंग मिलकर मदद करेंगे, पर किस हद तक, मैं अभी पूरी तरह निश्चित नहीं हूं 16:17 <jrandom> ठीक है, फिलहाल मेरे पास इतना ही है। 1) नेट स्थिति पर किसी के पास कोई प्रश्न/टिप्पणी/चिंता? 16:18 <green> हम्म, max bw limits कभी छूती ही नहीं हैं और यह पहले से काफी अलग है 16:18 <green> जैसे 1-7 में 16:18 <green> s/1-7/.12-7 16:18 <jrandom> आपका bw share प्रतिशत कैसे सेट है? वह अब एक बहुत शक्तिशाली नियंत्रण है 16:19 <green> 80% 16:19 <green> लेकिन कुल बैंडविड्थ का सिर्फ लगभग 40% ही उपयोग हो रहा है 16:20 <green> यह तो बस एक "कुछ न करने वाला router" है :P 16:20 <jrandom> हम्म, आपकी बैंडविड्थ कितनी बार 80% तक spike करती है, और क्या आप अक्सर tunnel अनुरोधों को अस्वीकार करते हैं (http://localhost:7657/oldstats.jsp#tunnel.reject.30 और tunnel.reject.*) 16:21 <jrandom> tunnel अनुरोधों में दिखने वाली आवधिकता अक्सर लोगों को overload का पता चलने का कारण बनती है, जबकि वास्तव में वह होता नहीं 16:21 <jrandom> (क्योंकि routers के पास दूसरे समय पर अतिरिक्त क्षमता होती है, बस तब नहीं जब उन पर spike आता है) 16:22 <green> tunnel.reject.30 बहुत फ्लैट है, जैसे 1,00 over 14 025,00 events 16:22 <jrandom> ओह, माफ़ करना, उस stat के लिए event count ही मुख्य बात है - आपने bandwidth overload के कारण 14,000 से अधिक tunnel अनुरोध अस्वीकार किए हैं 16:23 <jrandom> (उस stat का "value" यह है कि उस event पर कितने tunnels अस्वीकार हुए, और वह हमेशा 1 होता है, क्योंकि event एक संदेश से ट्रिगर होता है) 16:27 <jrandom> ठीक है, अगर 1) नेट स्थिति पर और कुछ नहीं है, तो 2) Syndie स्थिति पर चलते हैं 16:27 <jrandom> syndie के संबंध में ईमेल में जो है उससे अधिक जोड़ने के लिए मेरे पास बहुत कुछ नहीं है, बस एक अपडेट देना था 16:28 <jrandom> ठीक है, तो, जब तक कोई syndie wrt कुछ उठाना नहीं चाहता, चलिए अपने पुराने भरोसेमंद 3) ??? पर चलते हैं 16:28 <jrandom> क्या बैठक के लिए किसी के पास और कुछ है जो उठाना चाहते हों? 16:31 * tethra .17 के लिए (फिर से) "धन्यवाद" कहना चाहता है, क्योंकि इससे काफी सुधार हुआ है 16:33 <jrandom> मदद करके खुशी हुई, और और भी चीजें रास्ते में हैं 16:33 <jrandom> ठीक है, लेकिन अगर आज की बैठक के लिए और कुछ नहीं है... 16:33 * jrandom समेटता है 16:33 * jrandom *baf*s बैठक समाप्त करता है