I2P डेवलपर बैठक - 07 मार्च, 2006

15:08 <jrandom> 0) हाय 15:08 <jrandom> 1) नेट की स्थिति 15:08 <jrandom> 2) ??? 15:08 <jrandom> 0) हाय 15:08 * jrandom हाथ हिलाता है 15:08 <jrandom> साप्ताहिक स्थिति नोट्स यहाँ पोस्ट किए गए हैं http://dev.i2p.net/pipermail/i2p/2006-March/001267.html 15:09 * jrandom आप सबको उन विशाल नोट्स के ग्रंथ को पढ़ने के लिए कुछ घंटे देता है 15:10 * Complication ऐसे जताता है कि अभी तक ध्यान ही नहीं दिया ;) 15:11 <+Complication> हाय :) 15:11 <+susi23> हाय :) 15:12 <jrandom> अच्छा, चलिए 1) नेट की स्थिति पर बात शुरू करते हैं 15:12 <jrandom> ईमेल में मेरा समग्र नज़रिया दिया है कि क्या हो रहा है। यह आप सब जो देख रहे हैं उससे कितना मेल खाता है? 15:13 <+Complication> थ्रोटलिंग से जुड़े सुधारों ने भरोसेमंदता तो बढ़ाई लगती है, लेकिन बैंडविड्थ सच में दब गई है 15:13 <+Complication> एक सेकंड, ग्राफ ढूंढ़ रहा हूँ 15:14 <+Complication> http://complication.i2p/files/bw-week.webp 15:14 <+Complication> ऊँचे हिस्से non-latest पर हैं, और नीचे हिस्से latest पर 15:15 <+Complication> Limiter की सेटिंग्स एक जैसी हैं, शायद सख़्त (latest) versions पर भी कुछ ज्यादा ढील है 15:16 <+Complication> पर यह बहुत बड़ी समस्या नहीं है, क्योंकि ट्रांसफर हो रहा है 15:16 <jrandom> अच्छा, जैसे-जैसे आप अपनी वास्तविक बैंडविड्थ सीमा के करीब आते हैं, बैंडविड्थ का कम उपयोग उपयुक्त है 15:17 <+Complication> अधिकतर समय यह "sustained bandwidth" सीमा तक पहुँचने से पहले ही वापस उछल जाता है 15:17 <+Complication> burst limit को कभी छूता नहीं 15:18 <+Complication> (जो अपने आप में ठीक है - चिंता इस बात की है कि sustained limit से पहले ही वापस आ जाता है) 15:19 <bar> मैं भी लगभग वही देख रहा हूँ जो Complication देख रहा है। मेरा कुल bw उपयोग मेरी max सेटिंग्स का बस 50% है। यह 0.6.1.11 से पहले ~80% हुआ करता था 15:19 <jrandom> is 200kbps your limiter rate, w/ 300kbps burst? 15:20 <jrandom> (बस जानना चाह रहा हूँ कि यह burst में कितनी देर रहता था) 15:20 <jrandom> हालाँकि, बैंडविड्थ उपयोग कम होना हाल के बदलावों के उद्देश्यों में से एक है 15:21 <+Complication> ~225 sustained, ~325 burst 15:21 <+Complication> अरे, हो सकता है कि मैंने... 15:22 <+Complication> क्या मैंने इसे *गलत समझा*? 15:23 <+Complication> जाने दीजिए, मैं मूर्ख हूँ... मैंने गणना गलत की, यह उतना बुरा नहीं है :O 15:23 <jrandom> पर्याप्त डेटा नहीं है :) यह किसी समस्या का संकेत हो सकता है, लेकिन अब तक आपने जो बताया है वह दर्शाता है कि चीजें अपेक्षित रूप से काम कर रही हैं 15:23 <+Complication> यह थोड़ी रूढ़िवादी तरफ है, पर जितना मैंने सोचा था उतना बुरा नहीं 15:24 <+Complication> Router Console के अनुसार (जो limiter की ही इकाई में मापता है) आउटबाउंड कुल औसत sustained limit का 2/3 है, और burst limit का 1/2 15:25 <+Complication> लेकिन इनबाउंड कुल औसत, कहना पड़ेगा, sustained limit के 1/3 से थोड़ा ही ऊपर है, और burst limit के 1/4 15:26 <+Complication> उदाहरण के लिए, यदि sustained limit 30 और burst limit 40 मानें, तो आउटबाउंड 20 होगा और इनबाउंड 10 से थोड़ा ऊपर (अधिकतर कम लोड के कारण) 15:26 <jrandom> अच्छा 15:26 <+Complication> लेकिन मैंने ग्राफ को गलत समझा, Kb/KB के मुद्दों के कारण :O 15:27 * Complication इतिहास से ग्राफ मिटा देता है 15:28 <jrandom> फिर भी अच्छी नज़र है, जब भी कुछ अजीब लगे तो ज़रूर बताइए 15:28 <jrandom> ठीक है, 1) नेट की स्थिति पर और कुछ? 15:28 <jrandom> अगर नहीं, तो चलिए 2) ??? पर चलते हैं 15:28 <jrandom> किसी के पास और कुछ चर्चा करने के लिए है? 15:30 <+Complication> खैर, कुछ jbigi परीक्षण हुए हैं, और लगता है कि किसी को ऐसे परिणाम मिले जिनसे Linux के 64-bit संस्करण के थोड़ा धीमा होने का संकेत मिला 15:31 <+Complication> उनके यहाँ यह pure Java से भी धीमा निकला, पता नहीं माप में कोई गड़बड़ी थी या नहीं :O 15:32 <+Complication> मैं इसे दोहरा नहीं सका 15:32 <jrandom> हाँ, मुझे पक्का नहीं था कि वे प्लेटफ़ॉर्म के लिए कौन सा .so इस्तेमाल कर रहे थे 15:32 <+Complication> यहाँ तो यह pure Java से लगभग दोगुना तेज़ था 15:32 <+dust> Syndie में html को एक अतिरिक्त संदेश फ़ॉर्मेट के रूप में उपयोग करने के मेरे प्रयोग काम करना शुरू कर रहे हैं। मेरा लोकल 'sucker' अब वेब पेज (छवियों सहित) प्राप्त कर सकता है और उन्हें Syndie पोस्ट के रूप में सहेज सकता है 15:33 <jrandom> आह, बढ़िया dust 15:33 <+dust> css नहीं है हालांकि 15:33 <+Complication> लेकिन 32-bit पर लोगों ने बताया कि यह pure Java से *काफी* तेज़ है (लगभग 10x या ऐसा ही) 15:35 <bar> हम्म.. Complication, क्या ऐसा हो सकता है कि मौजूदा amd64 .so सिर्फ़ 32-bit सिस्टम के लिए हो, और उसने उसे 64-bit OS पर टेस्ट किया हो? 15:36 <+Complication> bar: हो सकता है, क्योंकि मैंने भी इसे 64-bit OS पर टेस्ट किया था :O 15:36 <jrandom> iirc amd64 को pure64 debian पर काम करने के लिए बनाया गया था 15:37 <+Complication> जो भी हो, कुछ लोगों ने सुझाव दिया कि नया gmp लाने से मदद मिल सकती है 15:37 <bar> बस अँधेरे में तीर चला रहा हूँ, मैं इन चीज़ों में माहिर नहीं हूँ 15:37 <jrandom> अच्छा, हम 4.1.4 इस्तेमाल करते हैं 15:37 <+Complication> खासकर जब वे अपना जल्द आने वाला version jump कर लेंगे 15:38 <+Complication> चूँकि मैं gmp विशेषज्ञ नहीं हूँ, मैं इसके बारे में बहुत कुछ नहीं कह सकता 15:38 <jrandom> (और gmp में आने वाले optimizations से किसी बड़े सुधार की संभावना नहीं है) 15:38 <+Complication> सिवाय इसके कि "शायद वाकई" 15:38 <jrandom> सुधार per-arch builds से आते हैं 15:40 <+Complication> मेरे परीक्षण में, जो उनके परीक्षण से प्रेरित था, 64-bit Sempron पर 64-bit Mandriva में 64-bit athlon lib... pure Java से केवल थोड़ा ही तेज़ लगी 15:40 <+Complication> (ओह, और 64-bit VM) 15:41 <+Complication> (यहाँ "थोड़ा" का मतलब लगभग दोगुना) 15:41 <jrandom> हम्म 'क 15:42 <+Complication> मैं और प्लेटफ़ॉर्म संयोजनों पर परीक्षण करने की कोशिश करूँगा, और अगर कुछ साझा करने लायक मिला तो बताऊँगा 15:43 <jrandom> अच्छा, धन्यवाद 15:43 <jrandom> ठीक है, बैठक के लिए किसी के पास और कुछ है? 15:46 <jrandom> अगर नहीं... 15:46 * jrandom समेटता है 15:47 * jrandom *baf*s करते हुए बैठक बंद करता है