Cuộc họp nhà phát triển I2P - 07 tháng 3, 2006

15:08 <jrandom> 0) chào 15:08 <jrandom> 1) Tình trạng mạng 15:08 <jrandom> 2) ??? 15:08 <jrandom> 0) chào 15:08 * jrandom vẫy tay 15:08 <jrandom> ghi chú trạng thái hàng tuần đã được đăng tại http://dev.i2p.net/pipermail/i2p/2006-March/001267.html 15:09 * jrandom cho mọi người vài giờ để đọc qua bài ghi chú đồ sộ đó 15:10 * Complication giả vờ chưa để ý ;) 15:11 <+Complication> Chào :) 15:11 <+susi23> chào :) 15:12 <jrandom> thôi, ta vào thẳng 1) tình trạng mạng 15:12 <jrandom> Email đó nêu quan điểm tổng quát của tôi về những gì đang diễn ra. Nó khớp thế nào với những gì mọi người thấy? 15:13 <+Complication> Các bản sửa cho cơ chế điều tiết có vẻ tăng độ tin cậy, nhưng thật sự làm giảm băng thông 15:13 <+Complication> Đợi một chút, đang lục đồ thị 15:14 <+Complication> http://complication.i2p/files/bw-week.webp 15:14 <+Complication> Đoạn cao là trên bản không phải mới nhất, đoạn thấp là trên bản mới nhất 15:15 <+Complication> Cùng thiết lập bộ giới hạn, có thể còn nới lỏng hơn trên các phiên bản nghiêm ngặt hơn (mới nhất) 15:16 <+Complication> Nhưng không phải vấn đề lớn, vì nó vẫn truyền tải 15:16 <jrandom> hay đấy, giảm sử dụng băng thông là phù hợp khi bạn tiến gần tới giới hạn băng thông thực của mình 15:17 <+Complication> Phần lớn thời gian, có vẻ nó bật lại trước khi chạm tới giới hạn "băng thông duy trì" 15:17 <+Complication> Không bao giờ chạm tới giới hạn đột biến 15:18 <+Complication> (bản thân điều đó là hợp lý - điều làm tôi băn khoăn là việc bật lại trước giới hạn duy trì) 15:19 <bar> tôi thấy khá giống Complication. tổng mức tiêu thụ băng thông của tôi chỉ 50% so với thiết lập tối đa. trước 0.6.1.11 là khoảng ~80% 15:19 <jrandom> bộ giới hạn của bạn là 200kbps, với đột biến 300kbps phải không? 15:20 <jrandom> (chỉ tò mò xem trước đây nó ở trạng thái đột biến bao lâu) 15:20 <jrandom> dù sao giảm sử dụng băng thông cũng là một trong các mục tiêu của những thay đổi gần đây 15:21 <+Complication> ~225 duy trì, ~325 đột biến 15:21 <+Complication> Này, có thể tôi đã... 15:22 <+Complication> Tôi đã *diễn giải* sai chứ? 15:23 <+Complication> Quên đi, tôi ngốc quá... tính toán sai, không tệ đến thế đâu :O 15:23 <jrandom> không đủ dữ liệu :) nó có thể là dấu hiệu của một vấn đề, nhưng những gì bạn mô tả đến giờ cho thấy mọi thứ đang hoạt động như mong muốn 15:23 <+Complication> Hơi thiên về an toàn, nhưng không tệ như tôi nghĩ 15:24 <+Complication> Theo Router Console (đo bằng cùng đơn vị với bộ giới hạn) trung bình tổng đi ra là 2/3 giới hạn duy trì, và 1/2 giới hạn đột biến 15:25 <+Complication> Nhưng trung bình tổng đi vào, phải nói là chỉ nhỉnh hơn 1/3 giới hạn duy trì, và 1/4 giới hạn đột biến 15:26 <+Complication> ví dụ, giả sử giới hạn duy trì là 30, và giới hạn đột biến là 40, đi ra sẽ là 20 và đi vào chỉ hơn 10 một chút (chủ yếu do thiếu tải) 15:26 <jrandom> hay đấy 15:26 <+Complication> Nhưng tôi đã diễn giải nhầm đồ thị, do vấn đề Kb/KB :O 15:27 * Complication xóa đồ thị khỏi lịch sử 15:28 <jrandom> dù vậy, tinh mắt đấy, nhớ báo tôi khi có gì nghe có vẻ kỳ 15:28 <jrandom> được rồi, còn gì nữa về 1) Tình trạng mạng không? 15:28 <jrandom> nếu không, hãy chuyển qua 2) ??? 15:28 <jrandom> ai còn gì khác để thảo luận không? 15:30 <+Complication> Ờ, có vài thử nghiệm jbigi, và hình như ai đó thu được kết quả gợi ý rằng bản 64-bit cho Linux hơi chậm 15:31 <+Complication> Họ thấy nó chậm hơn Java thuần, không chắc có phải trục trặc đo đạc hay không :O 15:32 <+Complication> Tôi không lặp lại được 15:32 <jrandom> ừ, tôi cũng không chắc chính xác họ dùng .so nào cho nền tảng đó 15:32 <+Complication> Ở chỗ tôi, nó nhanh hơn Java thuần khoảng gấp đôi 15:32 <+dust> các thử nghiệm của tôi với html như một định dạng thông điệp bổ sung trong syndie bắt đầu hoạt động. 'sucker' cục bộ của tôi giờ có thể lấy trang web (kèm hình ảnh) và lưu chúng thành bài đăng syndie 15:33 <jrandom> à tuyệt đấy, dust 15:33 <+dust> nhưng chưa có css 15:33 <+Complication> Nhưng những người dùng 32-bit nói nó nhanh *rất* nhiều so với Java thuần (khoảng 10x hoặc tương tự) 15:35 <bar> hmm.. Complication, có thể là .so amd64 hiện tại chỉ dành cho hệ 32-bit, và anh ấy đã thử nó trên hệ điều hành 64-bit? 15:36 <+Complication> bar: có thể, vì tôi cũng đã thử nó trên một hệ điều hành 64-bit :O 15:36 <jrandom> iirc bản amd64 được build để chạy trên Debian pure64 15:37 <+Complication> Dù sao thì, một số người gợi ý rằng dùng gmp mới hơn có thể giúp 15:37 <bar> chỉ đoán mò thôi, tôi không rành mấy thứ này 15:37 <jrandom> ờ, chúng tôi dùng 4.1.4 15:37 <+Complication> Đặc biệt là sau khi họ sắp nhảy phiên bản 15:38 <+Complication> Vì tôi không chuyên về gmp, tôi không nói gì thêm được 15:38 <jrandom> (và các tối ưu sắp tới trong gmp có lẽ sẽ không cải thiện đáng kể) 15:38 <+Complication> Ngoài câu "có lẽ đúng vậy" 15:38 <jrandom> cải tiến đến từ các build theo từng kiến trúc 15:40 <+Complication> Trong thử nghiệm của tôi, được gợi hứng từ thử nghiệm của họ, thư viện Athlon 64-bit trên Sempron 64-bit, trên Mandriva 64-bit... dường như chỉ nhanh hơn Java thuần một chút 15:40 <+Complication> (à, và một VM 64-bit) 15:41 <+Complication> ("nhỉnh hơn" ở đây là gấp đôi) 15:41 <jrandom> hmm 'k 15:42 <+Complication> Tôi sẽ thử trên nhiều tổ hợp nền tảng hơn, và sẽ báo nếu tôi thấy điều gì đáng chuyển tiếp 15:43 <jrandom> hay đấy, cảm ơn 15:43 <jrandom> được rồi, có ai còn gì cho buổi họp không? 15:46 <jrandom> nếu không... 15:46 * jrandom kết thúc 15:47 * jrandom *baf* kết thúc buổi họp