اجتماع مطوري 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> إصلاحات التقييد (throttling) تبدو وكأنها زادت الاعتمادية، لكنها فعلاً كبحت النطاق الترددي 15:13 <+Complication> لحظة واحدة، أبحث عن الرسم البياني 15:14 <+Complication> http://complication.i2p/files/bw-week.webp 15:14 <+Complication> الفترات العالية كانت على الإصدارات غير الأحدث، والمنخفضة على الأحدث 15:15 <+Complication> إعدادات المُحدِّد نفسها، وربما أكثر تراخياً على الإصدارات الأشدّ صرامة (الأحدث) 15:16 <+Complication> لكنها ليست مشكلة كبيرة، لأنه ما زال ينقل البيانات 15:16 <jrandom> جميل، تقليل استخدام النطاق الترددي مناسب عندما تقترب من حد النطاق الترددي الفعلي لديك 15:17 <+Complication> في معظم الوقت، يبدو أنه يرتد قبل بلوغ حد «النطاق الترددي المُستدام» 15:17 <+Complication> لا يلامس أبداً حد الاندفاع (burst) 15:18 <+Complication> (وهذا بذاته منطقي — ما يقلقني هو الارتداد قبل الحد المُستدام) 15:19 <bar> أنا أرى تقريباً ما يراه Complication. إجمالي استهلاكي للنطاق الترددي (bw) هو فقط 50% من إعداداتي القصوى. كان سابقاً نحو ~80% قبل 0.6.1.11 15:19 <jrandom> هل 200kbps هي قيمة المُحدِّد لديك، مع حد اندفاع 300kbps؟ 15:20 <jrandom> (أتساءل فقط كم من الوقت كان يقضيه في الاندفاع) 15:20 <jrandom> على أي حال، تقليل استخدام النطاق الترددي هو أحد أهداف التغييرات الأخيرة 15:21 <+Complication> ~225 مُستدام، ~325 اندفاع 15:21 <+Complication> مهلاً، ربما كنت قد... 15:22 <+Complication> هل قمتُ بـ*تفسير* الأمر بشكل خاطئ؟ 15:23 <+Complication> انسَ الأمر، أنا أحمق... أخطأت في الحساب، ليست سيئة إلى ذلك الحد :O 15:23 <jrandom> بيانات غير كافية :) قد يكون ذلك مؤشّراً على مشكلة، لكن ما وصفته حتى الآن يوحي بأن الأمور تعمل كما هو مرغوب 15:23 <+Complication> إنها تحفظية قليلاً، لكنها ليست سيئة كما ظننت 15:24 <+Complication> وفقاً لـ Router Console (الذي يقيس بالوحدة نفسها التي يستخدمها المُحدِّد) فإن متوسط الخرج الإجمالي هو 2/3 من الحد المُستدام، و1/2 من حد الاندفاع 15:25 <+Complication> لكن متوسط الدخل الإجمالي، عليّ أن أقول، يزيد قليلاً فقط على 1/3 الحد المُستدام، و1/4 حد الاندفاع 15:26 <+Complication> على سبيل المثال، بافتراض حد مُستدام قدره 30، وحد اندفاع قدره 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، ويبدو أن أحدهم حصل على نتائج توحي بأن النسخة ذات 64-بت على لينكس بطيئة قليلاً 15:31 <+Complication> كانت أبطأ من Java الخالصة، لست متأكداً إن كان خللاً في القياس أم لا :O 15:32 <+Complication> لم أستطع تكراره 15:32 <jrandom> نعم، لم أكن متأكداً بالضبط أي .so كانوا يستخدمونه لهذه المنصّة 15:32 <+Complication> عندي هنا كانت أسرع بنحو الضعف مقارنةً بجافا الخالصة 15:32 <+dust> تجاربي مع html كصيغة رسائل إضافية في syndie بدأت تعمل. الـ 'sucker' المحلي لدي يمكنه الآن جلب صفحات الويب (مع الصور) وتخزينها كمنشورات syndie 15:33 <jrandom> آه، رائع يا dust 15:33 <+dust> لكن بدون css 15:33 <+Complication> لكن أشخاصاً على 32-بت قالوا إنها أسرع *بكثير* من Java الخالصة (مثل 10x أو نحو ذلك) 15:35 <bar> همم.. Complication، هل يمكن أن تكون مكتبة amd64 ‏.so الحالية مخصّصة لأنظمة 32-بت فقط، وهو اختبرها على نظام تشغيل 64-بت؟ 15:36 <+Complication> bar: ممكن، لأني أنا أيضاً اختبرتها على نظام تشغيل 64-بت :O 15:36 <jrandom> حسب ما أذكر، تم بناء amd64 للعمل على pure64 debian 15:37 <+Complication> على أي حال، اقترح بعض الناس أن استيراد gmp أحدث قد يساعد 15:37 <bar> مجرد محاولة عمياء، لستُ خبيراً في هذه الأمور 15:37 <jrandom> إيه، نحن نستخدم 4.1.4 15:38 <+Complication> خصوصاً بعد أن يجروا قفزة الإصدار الوشيكة لديهم 15:38 <+Complication> وبما أنني لست مختصاً في gmp، فلا أستطيع أن أقول الكثير بشأنه 15:38 <jrandom> (والتحسينات القادمة في gmp ليس من المرجّح أن تُحدِث تحسّناً كبيراً) 15:38 <+Complication> عدا عن «ربما بالفعل» 15:38 <jrandom> التحسينات تأتي من بُنى لكل معمارية 15:40 <+Complication> في اختباري، الذي حرّكه اختبارهم، فإن مكتبة athlon ذات 64-بت على Sempron ذي 64-بت، على Mandriva ذات 64-بت، تبدو... أسرع بشكل طفيف فقط من Java الخالصة 15:40 <+Complication> (أوه، ومع VM ذات 64-بت) 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 يُغلق الاجتماع