I2P 开发者会议 - 2006年3月7日

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> 图上高的那段是在非最新版本，低的那段是在最新版本 15:15 <+Complication> 限速器设置相同，不过在更严格（最新）的版本上我可能设得更宽松一点 15:16 <+Complication> 但问题不大，毕竟它确实还能传输 15:16 <jrandom> 不错，随着接近你的实际带宽上限，降低带宽占用是合理的 15:17 <+Complication> 大多数时候，它似乎在达到“持续带宽”上限之前就回落了 15:17 <+Complication> 从未触及突发上限 15:18 <+Complication> （这本身是合理的——让我担心的是在达到持续上限之前就回落） 15:19 <bar> 我看到的和 Complication 基本一样。我的总带宽占用只有我最大设置的 50%。在 0.6.1.11 之前通常是约 80%。 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（I2P 路由控制台，度量单位与限速器相同），出站总平均为持续上限的 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 的测试，看来有人得到的结果显示 Linux 的 64 位版本有点慢 15:31 <+Complication> 他们测得比纯 Java 还慢，不确定是不是测量误差 :O 15:32 <+Complication> 我复现不出来 15:32 <jrandom> 是啊，我也不确定他们在那个平台上到底用的是哪个 .so 15:32 <+Complication> 在我这儿，比纯 Java 大约快一倍 15:32 <+dust> 我在 syndie 中用 HTML 作为额外消息格式的实验开始有进展了。我的本地“sucker”现在可以抓取网页（含图片）并把它们存成 syndie 帖子 15:33 <jrandom> 啊，太赞了 dust 15:33 <+dust> 不过没有 CSS 15:33 <+Complication> 但 32 位那边的人说它比纯 Java *快多了*（比如 10 倍之类） 15:35 <bar> 嗯……Complication，会不会现在的 amd64 .so 其实只适用于 32 位系统，而他是在 64 位 OS 上测试的？ 15:36 <+Complication> bar：有可能，因为我也是在 64 位 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> 尤其是在他们即将进行版本跳跃之后 15:38 <+Complication> 因为我不是 gmp 专家，也说不出太多 15:38 <jrandom> （而且 gmp 即将到来的优化不太可能带来显著提升） 15:38 <+Complication> 除了“也许确实如此”之外 15:38 <jrandom> 提升主要来自按架构分别构建 15:40 <+Complication> 在我的测试中（受他们的测试触发），在 64 位 Mandriva 上的 64 位 Sempron 上使用 64 位 athlon 库，看起来……只比纯 Java 略快 15:40 <+Complication> （哦，还有 64 位 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 会议结束