I2P Geliştirici Toplantısı - 07 Mart 2006

15:08 <jrandom> 0) merhaba 15:08 <jrandom> 1) Ağ durumu 15:08 <jrandom> 2) ??? 15:08 <jrandom> 0) merhaba 15:08 * jrandom el sallar 15:08 <jrandom> haftalık durum notları http://dev.i2p.net/pipermail/i2p/2006-March/001267.html adresinde yayınlandı 15:09 * jrandom o devasa notlar külliyatını okumanız için hepinize saatler verir 15:10 * Complication henüz fark etmemiş gibi yapar ;) 15:11 <+Complication> Merhaba :) 15:11 <+susi23> merhaba :) 15:12 <jrandom> pekâlâ, 1) ağ durumu'na dalalım 15:12 <jrandom> E-posta olup bitene dair genel görüşümü veriyor. Bu, sizin gördüklerinizle nasıl örtüşüyor? 15:13 <+Complication> Throttling (bant kısıtlama) düzeltmeleri güvenilirliği artırmış gibi görünüyor, ama bant genişliğini gerçekten bastırdı 15:13 <+Complication> Bir saniye, grafiği arıyorum 15:14 <+Complication> http://complication.i2p/files/bw-week.webp 15:14 <+Complication> Yüksek bölümler en son olmayan sürümlerde, düşük bölümler en son sürümlerde 15:15 <+Complication> Aynı sınırlayıcı ayarları, hatta daha sıkı (en son) sürümlerde belki daha gevşek 15:16 <+Complication> Ama çok büyük bir sorun değil, çünkü aktarım yapıyor 15:16 <jrandom> güzel, gerçek bant sınırına yaklaştıkça bant kullanımının azalması uygun 15:17 <+Complication> Çoğu zaman, "sustained bandwidth" sınırına gelmeden önce geri dönüyor gibi görünüyor 15:17 <+Complication> Asla burst (patlama) sınırına dokunmuyor 15:18 <+Complication> (bu başlı başına mantıklı - beni endişelendiren, sürdürülebilir sınıra gelmeden önce geri dönmesi) 15:19 <bar> ben de Complication'ın gördüğüyle aşağı yukarı aynı şeyi görüyorum. toplam bant tüketimim azami ayarlarımın sadece %50'si. 0.6.1.11 öncesinde ~%80'di 15:19 <jrandom> sınırlayıcının hızı 200kbps, 300kbps burst ile mi? 15:20 <jrandom> (sadece daha önce burst içinde ne kadar zaman geçirdiğini merak ediyorum) 15:20 <jrandom> yine de, azalan bant kullanımı son değişikliklerin hedeflerinden biri 15:21 <+Complication> ~225 sürdürülebilir, ~325 burst 15:21 <+Complication> Hey, yapmış olabilirim... 15:22 <+Complication> Bunu yanlış mı *yorumladım*? 15:23 <+Complication> Boş verin, aptallık etmişim... hesabı yanlış yapmışım, o kadar da kötü değil :O 15:23 <jrandom> yetersiz veri :) bir soruna işaret ediyor olabilir, ama şimdiye kadar anlattıkların işlerin istenildiği gibi davrandığını düşündürüyor 15:23 <+Complication> Biraz muhafazakâr tarafta, ama sandığım kadar kötü değil 15:24 <+Complication> Router Console'a göre (sınırlayıcı ile aynı birimde ölçer) giden toplam ortalama sürdürülebilir sınırın 2/3'ü ve burst sınırının 1/2'si 15:25 <+Complication> Ama gelen toplam ortalama, söylemeliyim ki, sürdürülebilir sınırın 1/3'ünün biraz üzerinde ve burst sınırının 1/4'ü 15:26 <+Complication> örneğin, sürdürülebilir sınırın 30 ve burst sınırının 40 olduğunu varsayarsak, giden 20 ve gelen de 10'un biraz üzerinde olur (çoğunlukla yük eksikliğinden) 15:26 <jrandom> güzel 15:26 <+Complication> Ama grafiği Kb/KB meseleleri yüzünden yanlış yorumlamışım :O 15:27 * Complication grafiği geçmişten siler 15:28 <jrandom> yine de iyi göz, bir şeyler tuhaf gelirse mutlaka bana haber ver 15:28 <jrandom> tamam, 1) Ağ durumu hakkında başka bir şey? 15:28 <jrandom> yoksa, 2) ???'ye doğru geçelim 15:28 <jrandom> konuşmak isteyen başka bir şey var mı? 15:30 <+Complication> Şey, biraz jbigi testi yapıldı ve görünüşe göre birisi Linux için 64-bit sürümün biraz yavaş olduğunu ima eden sonuçlar elde etti 15:31 <+Complication> Saf Java'dan daha yavaş çıkmış; ölçüm hatası mı değil mi emin değilim :O 15:32 <+Complication> Ben bunu tekrarlayamadım 15:32 <jrandom> evet, platform için tam olarak hangi .so'yu kullandıklarından emin değildim 15:32 <+Complication> Burada, saf Java'dan yaklaşık iki kat hızlıydı 15:32 <+dust> syndie'de ek bir mesaj formatı olarak html ile yaptığım deneyler çalışmaya başlıyor. yerel 'sucker'ım artık web sayfalarını (görsellerle birlikte) alıp syndie gönderileri olarak depolayabiliyor 15:33 <jrandom> ah harika dust 15:33 <+dust> ama css yok 15:33 <+Complication> Ama 32-bit kullananlar, saf Java'dan çok daha hızlı olduğundan bahsettiler (10x ya da benzeri) 15:35 <bar> hmm.. Complication, mevcut amd64 .so sadece 32-bit sistemler için olabilir mi ve o da bunu 64-bit bir OS'de mi test etti? 15:36 <+Complication> bar: olabilir, çünkü ben de 64-bit bir OS'de test ettim :O 15:36 <jrandom> yanlış hatırlamıyorsam amd64 pure64 debian üzerinde çalışacak şekilde derlendi 15:37 <+Complication> Her hâlükârda, bazıları daha yeni bir gmp kullanmanın yardımcı olabileceğini öne sürdü 15:37 <bar> sadece karanlığa bir taş, bu işlerde usta değilim 15:37 <jrandom> eh, 4.1.4 kullanıyoruz 15:37 <+Complication> Özellikle yakında yapacakları sürüm sıçramasından sonra 15:38 <+Complication> gmp uzmanı olmadığım için bunun hakkında pek bir şey söyleyemem 15:38 <jrandom> (ve gmp'deki yakında gelecek optimizasyonların kayda değer bir iyileşme sağlaması pek olası değil) 15:38 <+Complication> "belki gerçekten" dışında 15:38 <jrandom> iyileştirmeler mimariye özel derlemelerden gelir 15:40 <+Complication> Benim testimde, onların testi tetikledi ama 64-bit Mandriva'da 64-bit Sempron üzerinde 64-bit athlon kitaplığı saf Java'dan sadece sınırlı ölçüde daha hızlı görünüyor 15:40 <+Complication> (ah, bir de 64-bit VM) 15:41 <+Complication> (sınırlı derken iki kat) 15:41 <jrandom> hmm tamam 15:42 <+Complication> Daha fazla platform kombinasyonunda test etmeyi deneyeceğim ve iletmeye değer görünen bir şey bulursam haber vereceğim 15:43 <jrandom> güzel, teşekkürler 15:43 <jrandom> tamam, toplantı için başka bir şey var mı? 15:46 <jrandom> yoksa... 15:46 * jrandom toparlar 15:47 * jrandom toplantıyı *baf* diye kapatır