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

13:01 <@jrandom> 0) chào 13:01 <@jrandom> 1) 0.5.0.3 13:01 <@jrandom> 2) batching (gộp lô) 13:01 <@jrandom> 3) cập nhật 13:01 <@jrandom> 4) ??? 13:01 <@jrandom> 0) chào 13:01 * jrandom vẫy tay 13:01 <@jrandom> ghi chú tình trạng hàng tuần vừa đăng xong có tại http://dev.i2p.net/pipermail/i2p/2005-March/000654.html 13:02 <+detonate> chào 13:02 <+cervantes> chào 13:02 <@jrandom> vào thẳng mục 1) 0.5.0.3 13:02 <@jrandom> bản phát hành đã ra vài ngày trước, và các báo cáo đều tích cực 13:02 <+cervantes> jrandom: báo cho bọn tôi biết khi những chú lùn màu xanh nhảy múa leo lên màn hình của bạn, tụi này sẽ kết thúc cuộc họp sớm 13:03 <@jrandom> heh cervantes 13:03 <@jrandom> (cảm ơn Bob vì nhật ký cuộc họp có thể chỉnh sửa ;) 13:04 <@jrandom> tôi thực sự không có nhiều điều để bổ sung liên quan đến 0.5.0.3 ngoài những gì trong thông báo đó 13:04 <@jrandom> ai có bình luận/câu hỏi/quan ngại gì về nó không? 13:04 <bla> jrandom: Có phép đo mới nào về mã chọn peer (nút ngang hàng) nhanh không? 13:05 <@jrandom> à, tôi biết là còn thứ khác trong 0.5.0.3 mà tôi đã bỏ sót ;) 13:06 <@jrandom> tôi chưa có số liệu cứng, nhưng theo kinh nghiệm thì cơ chế chọn peer nhanh đã tìm ra đúng những peer mà tôi biết rõ là "nhanh" (ví dụ: router trên cùng một máy, v.v.) 13:07 <bla> jrandom: Đôi khi, eepsites vẫn cần thử lại vài lần để tìm một tunnel tốt để dùng 13:07 <@jrandom> cũng có báo cáo đạt thông lượng khá hợp lý vào đôi lúc (khoảng 10-20KBps), nhưng vẫn chưa thường xuyên (chúng ta vẫn đặt tham số ở mức thấp) 13:08 <+ant> <Connelly> ôi, có cuộc họp à 13:09 <@jrandom> hmm, đúng vậy, tôi thấy độ tin cậy vẫn chưa đạt yêu cầu. thử lại quá một lần thật ra không phải giải pháp đâu - nếu một site không tải được sau 1 lần thử lại, hãy chờ 5-10 phút rồi mới thử lại 13:09 <@jrandom> những gì tôi thấy trên mạng là có những đột biến độ trễ ở transport (tầng truyền tải) xảy ra khá thường xuyên 13:10 <@jrandom> ví dụ: mất 5-20+ giây chỉ để flush một thông điệp 1-2KB qua một socket 13:10 <@jrandom> kết hợp với đường đi 5 hop (tunnel 2 hop) thì sẽ gặp rắc rối 13:11 <@jrandom> đó thực ra là một phần lý do thúc đẩy mã batching - giảm số lượng thông điệp cần gửi 13:13 <@jrandom> ok, còn ai có câu hỏi/bình luận/quan ngại gì về 0.5.0.3 không? 13:13 <bla> jrandom: Trông ổn. Tôi sẽ hỏi thêm về nó ở "phần" tiếp theo 13:14 <@jrandom> w3rd, ok, vậy ta chuyển sang - 2) batching 13:15 <@jrandom> email và blog của tôi (jrandom.dev.i2p</spam>) đã mô tả những gì dự định làm 13:15 <@jrandom> và, ờ, thực ra đây là những thứ khá cơ bản 13:15 <@jrandom> bộ tiền xử lý hiện tại là loại đơn giản nhất có thể để triển khai (tên lớp: TrivialPreprocessor) ;) 13:16 <@jrandom> cái mới có một số tham số có thể tinh chỉnh cho tần suất batching, cũng như một chút "affinity" với outbound tunnel trong từng nhóm tunnel (nơi ta cố chọn cùng một outbound tunnel cho các yêu cầu tiếp theo trong tối đa, ví dụ, 500ms, để tối ưu hóa việc batching) 13:17 <@jrandom> tôi chỉ có bấy nhiêu để bổ sung về mục đó - có câu hỏi/bình luận/quan ngại gì không? 13:18 <bla> Cái này có yêu cầu tất cả nút tham gia chạy bộ tiền xử lý mới không, hay có thể trộn Trivial/NewOne cùng tồn tại? 13:18 <+Ragnarok> cái này sẽ cộng thêm 0,5 giây độ trễ, đúng không? 13:19 <@jrandom> bla: không, bộ tiền xử lý này chỉ dùng ở tunnel gateway, và tùy gateway đó quyết định có gộp hay không và gộp thế nào 13:20 <@jrandom> Ragnarok: thường là không - thông điệp 1 có thể bị trễ tối đa 0,5s, nhưng thông điệp 2-15 sẽ được chuyển nhanh hơn nhiều so với bình thường. cũng có một ngưỡng đơn giản - ngay khi có đủ dữ liệu bằng một thông điệp tunnel đầy, nó sẽ được flush 13:20 <+Ragnarok> hay đấy 13:20 <+Ragnarok> tiết kiệm bao nhiêu overhead? 13:21 <@jrandom> đáng kể ;) 13:21 <+Ragnarok> "đáng kể" là tốt, dù mơ hồ :P 13:21 <@jrandom> xem ở http://localhost:7657/oldstats.jsp#tunnel.smallFragments của bạn 13:21 <@jrandom> so sánh với #tunnel.fullFragments 13:22 <bla> jrandom: Cái này chỉ liên quan đến giao tiếp endpoint->IB-gateway thôi à? 13:22 <@jrandom> với batching, tỷ lệ full so với small sẽ tăng, và số byte đệm trong small sẽ giảm 13:23 <@jrandom> bla: hmm, nó liên quan đến mọi tunnel gateway, cả inbound lẫn outbound 13:24 <mihi> full fragments: lifetime average value: 1,00 over 1.621,00 events 13:24 <bla> jrandom: ok 13:24 <mihi> can there be a frational number of fragments? 13:24 <@jrandom> full: 1.00 over 807,077.00 events small: 746.80 over 692,682.00 events 13:25 <@jrandom> heh mihi 13:25 <@jrandom> (cái small: 746 nghĩa là trong 692k thông điệp đó, 746 trong 996 byte là byte đệm "lãng phí"!) 13:26 <@jrandom> à, cũng không hẳn là lãng phí - chúng vẫn có tác dụng của chúng 13:26 <+detonate> dù sao cũng là overhead không cần thiết 13:27 <@jrandom> đúng vậy, phần lớn trong số đó ta sẽ loại bỏ được với bộ tiền xử lý batching 13:28 <@jrandom> tiếc là nó sẽ không được đóng gói trong bản phát hành tiếp theo 13:28 <@jrandom> nhưng nó sẽ có trong bản 0.5.0.6 (hoặc có thể 0.5.1) 13:28 <@jrandom> ờm, 0.5.0.5, hoặc 0.5.1 13:28 * jrandom bị rối với #s 13:29 <bla> jrandom: Sao lại không? 13:29 <+cervantes> hash và thuốc... chết tiệt 13:30 <@jrandom> !thwap cervantes 13:30 <@jrandom> bla: có một lỗi trong 0.5.0.3 (và trước đó) khiến trình xử lý thông điệp bị phân mảnh loại bỏ các mảnh theo sau trong cùng một thông điệp tunnel 13:31 <@jrandom> nếu ta triển khai bộ tiền xử lý batching ngay, sẽ mất một lượng lớn thông điệp 13:31 <@jrandom> đừng lo, vẫn còn vài thứ hay ho khác, nên bản 0.5.0.4 sắp tới sẽ không nhàm chán đâu ;) 13:31 <bla> jrandom: À, ra vậy 13:32 <bla> jrandom: À, ra vậy là vì sao ta phải làm sau khi 0.5.0.4 phổ biến... hiểu rồi. Cảm ơn. 13:33 <@jrandom> ừ, sẽ tốt hơn nếu trình xử lý mảnh xử lý được chuyện đó, và nói chung là nó xử lý, chỉ là nó giải phóng bộ đệm byte quá sớm, làm các mảnh theo sau bị zero hóa (ối) 13:33 <@jrandom> ok, còn gì ở mục 2) không, hay chuyển sang 3) cập nhật? 13:35 <@jrandom> ok, như đã nói trong ghi chú tình trạng (và đã bàn ở nhiều nơi), chúng ta sẽ thêm chức năng cập nhật đơn giản và an toàn, không yêu cầu người dùng cuối phải vào website, đọc mailing list, hay đọc topic trong kênh :) 13:36 <+detonate> hay 13:36 <@jrandom> smeghead đã ráp một ít mã để tự động hóa và bảo mật quy trình, phối hợp với cervantes để gắn vào fire2pe cũng như routerconsole thông thường 13:37 <@jrandom> email liệt kê mô tả chung về những gì sẽ có, và dù phần lớn đã hoạt động, vẫn còn vài mảnh chưa hoàn thiện 13:37 <@jrandom> không như batching, cái này /sẽ/ có trong bản kế tiếp, dù người dùng sẽ chưa tận dụng được nhiều cho đến 0.5.0.5 (khi tới lúc cập nhật) 13:39 <+Ragnarok> vậy... mấy thứ ngầu cho 5.0.4 là gì? 13:42 <@jrandom> kèm theo mã cập nhật là khả năng kéo dữ liệu thông báo, hiển thị ví dụ một đoạn tin ở trên cùng của router console. ngoài ra, như một phần của mã cập nhật, chúng tôi có một thành phần tải xuống tin cậy mới hoạt động trực tiếp hoặc qua eepproxy, tự thử lại và tiếp tục khi cần. có thể sẽ có vài tính năng liên quan xây dựng dựa trên đó, nhưng không hứa trước 13:42 <+Ragnarok> hay thật 13:43 <@jrandom> ok, ai còn câu hỏi/bình luận/quan ngại gì về 3) cập nhật không? 13:45 <@jrandom> nếu không thì chuyển sang 4) ??? 13:45 <@jrandom> còn điều gì ai muốn nêu không? chắc tôi đã bỏ lỡ vài thứ 13:45 <+detonate> i2p chạy được với sun jvm trên OpenBSD 3.7 :) 13:45 <@jrandom> hay! 13:47 <bla> Tình trạng UDP transport thế nào rồi? 13:48 <+detonate> udp sẽ lằng nhằng đấy, tôi nghĩ tốt hơn là chôm mã pipelining từ bt rồi chỉnh lại ;) 13:48 <@jrandom> *khụ* 13:49 <@jrandom> tôi không nghĩ sẽ có nhiều rắc rối, nhưng chắc chắn còn nhiều việc phải làm 13:49 <@jrandom> cách chính sách xếp hàng hoạt động, cũng như throttling băng thông để cho vào hàng đợi sẽ khá thú vị 13:50 <bla> Ai làm phần việc sơ bộ đó? 13:50 <@jrandom> bla: detonate và mule 13:50 <+detonate> đúng rồi.. dạo tháng vừa rồi tôi hơi lười 13:50 <bla> detonate: Tôi đoán bạn đùa vụ BT? 13:51 <+detonate> tôi nửa đùa nửa thật 13:51 <+detonate> ít nhất bạn có thể giảm một nửa số luồng cho transport nếu làm vậy 13:51 * jrandom ném một xô bùn vào detonate 13:51 <jdot> woohoo. router của tôi giờ chạy trên máy chủ riêng thay vì kết nối cáp POS của tôi. 13:51 <@jrandom> tuyệt đấy jdot 13:52 <@jrandom> ta sẽ có thể chỉ cần 3-5 luồng ở transport layer cho toàn bộ liên lạc với tất cả peer 13:52 <bla> detonate: Nhưng một nửa sẽ không đủ khi mạng lớn lên (> vài trăm nút) 13:52 <jdot> với 1000GB băng thông sẵn dùng 13:53 <jdot> tiếc là j.i2p và chat.i2p sẽ down thêm vài giờ nữa trong khi tôi di chuyển mọi thứ 13:53 <duck> detonate: addressbook cũng tạm dừng hả? 13:53 <+detonate> đúng, nó cũng tạm dừng 13:54 <+detonate> thứ duy nhất không tạm dừng là bộ lưu trữ hồ sơ dạng monolithic, tôi định làm cho nó chạy được trong hôm nay 13:54 <@jrandom> w3rd 13:54 <+detonate> như vậy i2p sẽ không phân mảnh ổ đĩa khủng khiếp nữa 13:54 <jdot> jrandom: về giới hạn BW, chúng là giá trị trung bình à? 13:54 <+frosk> hệ thống tập tin hiện đại không phân mảnh đâu, ngốc 13:55 <+detonate> ntfs thì có 13:55 <@jrandom> jdot: giới hạn băng thông là token bucket (xô thẻ – cơ chế điều tiết băng thông) nghiêm ngặt 13:55 <@jrandom> jdot: nếu bạn đặt burst duration (đột biến), đó là khoảng thời gian nó lấy trung bình 13:56 <@jrandom> (ờ thì, 2x burst == period) 13:56 <@jrandom> ((đại khái)) 13:56 <jdot> hmmm... tôi có 1000GB và muốn i2p có thể dùng tới 800GB/tháng.... 13:56 <+ant> <mihi> detonate: ntfs lưu các tệp rất nhỏ trong mft nên gần như không phân mảnh 13:57 <jdot> và tôi không quan tâm nó burst tới mức nào 13:57 <+detonate> ờ, khi bạn chạy trình chống phân mảnh, nó mất 10 phút để di chuyển toàn bộ 6000 hồ sơ.. vậy chắc chắn là có phân mảnh 13:58 <@jrandom> jdot: hmm, 800GB có lẽ nhiều hơn mức nó muốn đẩy rồi, nên bạn có thể không cần đặt giới hạn ;) 13:58 <@jrandom> mặt khác, nếu bạn mô tả chính sách bạn muốn, có thể chúng tôi sẽ hỗ trợ được 13:58 <jdot> jrandom: tôi sẽ làm vậy tạm thời và xem nó hoạt động ra sao 13:58 <bla> detonate: NTFS, IIRC, là một FS có ghi nhật ký. Vậy nên ngay cả một tệp đơn khối cũng sẽ bị phân mảnh nếu bạn ghi từng phần nhỏ 13:58 <+detonate> mọi thứ được ghi một lần 13:59 <+detonate> và đọc một lần 13:59 <bla> detonate: Ok. Tôi hiểu rồi. 13:59 <jdot> jrandom: thôi, chờ xem có vấn đề gì không đã. 13:59 <bla> detonate: Làm tốt đấy! 13:59 <+detonate> tôi muốn biết thực tế dùng bao nhiêu nếu bạn để mở không giới hạn 14:00 <+detonate> trên một kết nối tốt 14:00 <jdot> tôi cũng tò mò! 14:00 <@jrandom> các router colo của tôi chạy không giới hạn, dù bị giới hạn CPU 14:00 <+Ragnarok> có thể dùng bitbucket để lấy trung bình theo tháng không? 14:00 <jdot> jrandom: bị giới hạn CPU? CPU loại gì? 14:01 <@jrandom> 4d transfer 3.04GB/2.73GB 14:01 <+detonate> hmm, tôi kỳ vọng ít hơn 14:01 <@jrandom> jdot: bị giới hạn CPU vì tôi chạy 3 router trên đó, cộng vài JVM khác, đôi khi còn profiling 14:01 <+detonate> chắc do mấy người bt 14:01 <+detonate> khi batching online, sẽ thú vị khi xem nó thay đổi thế nào 14:02 <@jrandom> detonate: một phần lưu lượng đó cũng là tôi đẩy các tệp 50MB qua lại chính nó ;) 14:02 <+detonate> heh 14:02 <jdot> à. ok. xem hệ thống này chạy sao. là AMD XP 2400 với 512MB và kết nối 10Mbit 14:02 <@jrandom> Ragnarok: token bucket không hoạt động theo cách đó đâu 14:02 <@jrandom> jdot: word, vâng, cái này là p4 1.6 nếu tôi nhớ không nhầm 14:03 <@jrandom> Ragnarok: trong token bucket, mỗi (ví dụ) giây bạn thêm một số token vào, theo tốc độ đặt trước. nếu bucket đầy (kích thước = khoảng đột biến), các token sẽ bị bỏ 14:04 <@jrandom> bất cứ khi nào bạn muốn truyền dữ liệu, bạn cần đủ số token 14:04 <@jrandom> (1 token = 1 byte) 14:04 <+Ragnarok> Tôi biết nó hoạt động thế nào... nếu bạn làm bucket thật lớn thì sao? 14:05 <+detonate> thì bạn sẽ không bao giờ ngừng gửi dữ liệu 14:05 <+detonate> nếu nó có kích thước vô hạn 14:05 <+detonate> à, và nó đầy token 14:05 <@jrandom> nếu quá lớn, nó có thể bung ra và burst tới tốc độ không giới hạn sau thời gian dùng ít 14:06 <@jrandom> dù có thể trong một số trường hợp đó là điều mong muốn 14:07 <@jrandom> vấn đề là bạn không thể chỉ đặt token bucket thành 800GB, vì như thế sẽ không hạn chế được tổng lượng đã truyền 14:08 <+detonate> bạn cần một trường để đặt số token mỗi giây, rồi bạn chỉ việc chia mức sử dụng băng thông mỗi tháng cho số giây 14:08 <+detonate> :) 14:10 <@jrandom> đó cũng như đặt tốc độ trung bình theo tháng, điều này sẽ không cân bằng. nhưng dù sao cũng có nhiều kịch bản - nếu ai có nhu cầu không đáp ứng được với những gì hiện có, xin hãy liên hệ 14:10 <+Ragnarok> nhưng nếu bạn đặt tốc độ bằng mức trung bình bạn muốn... Tôi nghĩ là 308 kB/s ở đây, rồi đặt bitbucket thật lớn... tại sao không được? 14:11 <+Ragnarok> s/larger/large/ 14:12 <+detonate> bạn có thể đặt sao cho nó không bao giờ gửi quá 800GB/44000 trong một khoảng burst 60 giây 14:12 <+detonate> 44000 là số phút xấp xỉ trong một tháng 14:13 <@jrandom> kích thước bucket / thời lượng burst mô tả lượng ta sẽ gửi mà không hạn chế, và đa số người dùng /do/ muốn có hạn chế, để router không ngốn 10mbps trong 5 phút khi xả bucket (hay gì đó) 14:14 <@jrandom> cũng có thể có một bộ điều tiết bổ sung cho dòng token đi ra khỏi bucket (và liệu bộ điều tiết đó có token bucket riêng không, rồi bucket đó lại có bộ điều tiết riêng, v.v.) 14:16 <+Ragnarok> Tôi tưởng bucket chỉ được nạp khi có băng thông không dùng tới 14:16 <@jrandom> token được thêm vào bucket với tốc độ không đổi (ví dụ 64k token mỗi giây) 14:17 <@jrandom> bất cứ thứ gì cần băng thông đều luôn hỏi bucket 14:18 <+Ragnarok> à.. ok 14:19 <@jrandom> ok hay lắm, còn ai muốn nêu gì cho cuộc họp không? 14:21 <@jrandom> nếu không thì 14:21 * jrandom lấy đà 14:21 * jrandom *baf* đóng cuộc họp