Встреча разработчиков I2P - 22 марта 2005 года

13:01 <@jrandom> 0) привет 13:01 <@jrandom> 1) 0.5.0.3 13:01 <@jrandom> 2) batching 13:01 <@jrandom> 3) updating 13:01 <@jrandom> 4) ??? 13:01 <@jrandom> 0) привет 13:01 * jrandom машет рукой 13:01 <@jrandom> только что выложены еженедельные заметки о статусе @ http://dev.i2p.net/pipermail/i2p/2005-March/000654.html 13:02 <+detonate> hi 13:02 <+cervantes> прив 13:02 <@jrandom> сразу переходим к 1) 0.5.0.3 13:02 <@jrandom> релиз вышел несколько дней назад, и отклики положительные 13:02 <+cervantes> jrandom: скажи нам, когда голубые танцующие гномы заберутся на твой монитор, и мы закончим встречу пораньше 13:03 <@jrandom> хех, cervantes 13:03 <@jrandom> (спасибо Бобу за редактируемые логи встреч ;) 13:04 <@jrandom> мне особо нечего добавить по 0.5.0.3 сверх того, что в том письме 13:04 <@jrandom> есть комментарии/вопросы/опасения по нему? 13:04 <bla> jrandom: Есть новые измерения по коду выбора быстрых пиров? 13:05 <@jrandom> ах, знал, что есть ещё кое-что в 0.5.0.3, что я упустил ;) 13:06 <@jrandom> жёстких метрик пока нет, но по наблюдениям выбор быстрых пиров находит тех, кого я заведомо считаю «быстрыми» (например, routers на той же машине и т. п.) 13:07 <bla> jrandom: Иногда eepsites всё ещё требуют нескольких повторов, чтобы найти подходящий tunnel 13:07 <@jrandom> поступали сообщения и о вполне приличной пропускной способности (в диапазоне 10–20 КБ/с), но это всё ещё редкость (мы всё ещё держим параметры заниженными) 13:08 <+ant> <Connelly> упс, тут встреча 13:09 <@jrandom> хмм, да, надёжность всё ещё не на нужном уровне. Однако многократные повторы — не решение: если сайт не загрузился после 1 повторной попытки, подождите 5–10 мин перед следующей 13:09 <@jrandom> в сети, однако, я наблюдал слишком частые всплески задержек на транспортном уровне 13:10 <@jrandom> например, требуется 5–20+ секунд, чтобы просто протолкнуть через сокет сообщение 1–2 КБ 13:10 <@jrandom> добавьте к этому путь в 5 hops (2-hop tunnels) — и проблемы обеспечены 13:11 <@jrandom> это как раз часть того, что подталкивает код batching — сокращение # сообщений к отправке 13:13 <@jrandom> ок, есть ли ещё вопросы/комментарии/опасения по 0.5.0.3? 13:13 <bla> jrandom: Выглядит хорошо. Спрошу об этом больше в следующем «разделе» 13:14 <@jrandom> ага, ок, тогда можно перейти дальше — 2) batching 13:15 <@jrandom> письмо и мой блог (jrandom.dev.i2p</spam>) описывают основы того, что планируется 13:15 <@jrandom> и, в общем, это довольно базовые вещи 13:15 <@jrandom> текущий предобработчик у нас был максимально простым в реализации (имя класса: TrivialPreprocessor) ;) 13:16 <@jrandom> у нового есть настраиваемые параметры частоты batching, а также некоторая аффинность к outbound tunnel внутри отдельных пулов tunnel (где мы пытаемся выбирать один и тот же outbound tunnel для последующих запросов в течение, скажем, до 500 мс, чтобы оптимизировать batching) 13:17 <@jrandom> это примерно всё, что могу добавить — есть вопросы/комментарии/опасения? 13:18 <bla> Для этого всем узлам нужно запускать новый предобработчик или может сосуществовать смесь Trivial/NewOne? 13:18 <+Ragnarok> это добавит 0,5 с к задержке, верно? 13:19 <@jrandom> bla: неа, этот предобработчик используется только на tunnel gateway, и уже этот gateway решает, как и нужно ли вообще batch-ить 13:20 <@jrandom> Ragnarok: обычно нет — сообщение 1 может задержаться до 0,5 с, но сообщения 2–15 передадутся гораздо быстрее, чем без этого. Это ещё и простой порог: как только набирается полный tunnel message по объёму данных, он отправляется 13:20 <+Ragnarok> круто 13:20 <+Ragnarok> насколько это сокращает накладные расходы? 13:21 <@jrandom> существенно ;) 13:21 <+Ragnarok> существенно — это хорошо, хоть и расплывчато :P 13:21 <@jrandom> посмотри у себя http://localhost:7657/oldstats.jsp#tunnel.smallFragments 13:21 <@jrandom> сравни с #tunnel.fullFragments 13:22 <bla> jrandom: Это касается только обмена endpoint->IB-gateway? 13:22 <@jrandom> с batching соотношение full к small вырастет, а число байтов заполнения в small уменьшится 13:23 <@jrandom> bla: хмм, это касается всех tunnel gateway, и inbound, и outbound 13:24 <mihi> full fragments: lifetime average value: 1,00 over 1.621,00 events 13:24 <bla> jrandom: ок 13:24 <mihi> а может быть дробное число фрагментов? 13:24 <@jrandom> full: 1.00 over 807,077.00 events small: 746.80 over 692,682.00 events 13:25 <@jrandom> хех, mihi 13:25 <@jrandom> (это small: 746 означает, что для тех 692k сообщений 746 из 996 байт были впустую потраченными байтами заполнения!) 13:26 <@jrandom> ну, не совсем впустую — они выполняли свою роль 13:26 <+detonate> в любом случае лишние накладные расходы 13:27 <@jrandom> ага, и большую их часть мы сможем снять с batching-предобработчиком 13:28 <@jrandom> к сожалению, это не войдёт в следующий релиз 13:28 <@jrandom> но войдёт в ревизию 0.5.0.6 (или, возможно, 0.5.1) 13:28 <@jrandom> эм, 0.5.0.5 или 0.5.1 13:28 * jrandom путается в цифрах 13:29 <bla> jrandom: Почему нет? 13:29 <+cervantes> хэш и таблетки... чёрт 13:30 <@jrandom> !thwap cervantes 13:30 <@jrandom> bla: в 0.5.0.3 (и ранее) есть баг, из‑за которого обработчик фрагментированных сообщений отбрасывает последующие фрагменты внутри одного и того же tunnel message 13:31 <@jrandom> если бы мы прямо сейчас выкатили batching-предобработчик, мы бы получили существенное число потерянных сообщений 13:31 <@jrandom> не беда, у нас в рукаве есть и другие классные штуки, так что грядущий 0.5.0.4 не будет совсем уж скучным ;) 13:31 <bla> jrandom: А, вот оно 13:32 <bla> jrandom: А, значит поэтому нам нужно делать это после того, как 0.5.0.4 станет массовым.. Понятно. Спс. 13:33 <@jrandom> да, было бы здорово, если бы обработчик фрагментов справлялся с этим, и вообще он справляется, просто слишком рано освобождает буфер байтов, зануляя последующие фрагменты (упс) 13:33 <@jrandom> ок, что‑нибудь ещё по 2) или перейдём к 3) updating? 13:35 <@jrandom> ок, как упоминалось в заметках о статусе (и обсуждалось какое‑то время в разных местах), мы собираемся добавить функциональность для простого и безопасного обновления, не требующего от конечного пользователя заходить на сайт, читать рассылку или топик в канале :) 13:36 <+detonate> круто 13:36 <@jrandom> smeghead написал немного кода, чтобы автоматизировать и обезопасить процесс, работая с cervantes над интеграцией как с fire2pe, так и с обычной routerconsole 13:37 <@jrandom> в письме приведено общее описание того, что будет доступно, и хотя большая часть уже работает, осталось несколько моментов, которые ещё не до конца обдуманы 13:37 <@jrandom> в отличие от batching, это /будет/ доступно в следующей ревизии, хотя толком воспользоваться этим получится лишь к 0.5.0.5 (когда придёт время обновляться) 13:39 <+Ragnarok> и... какие клёвые штуки будут в 5.0.4 тогда? 13:42 <@jrandom> вместе с кодом обновления появится возможность подтягивать данные объявлений, показывая, например, кусочек новостей вверху router console. Кроме того, в составе кода обновления у нас появился новый надёжный компонент загрузки, который работает либо напрямую, либо через eepproxy, с повторами и продолжением докачки. Возможно, на этом появятся родственные фичи, но обещать не буду 13:42 <+Ragnarok> занятно 13:43 <@jrandom> ок, есть ли ещё вопросы/комментарии/опасения по 3) updating? 13:45 <@jrandom> если нет, переходим к 4) ??? 13:45 <@jrandom> кто‑нибудь хочет поднять ещё что‑нибудь? уверен, я кое‑что упустил 13:45 <+detonate> известно, что i2p работает с sun jvm на OpenBSD 3.7 :) 13:45 <@jrandom> круто! 13:47 <bla> Каков статус по UDP‑транспорту? 13:48 <+detonate> udp будет грязноватым, думаю, лучше украсть pipelining‑код из bt и адаптировать ;) 13:48 <@jrandom> *кхм* 13:49 <@jrandom> не ожидаю особых проблем, но работы там хватает 13:49 <@jrandom> интересно будет, как будет работать политика очередей, а также ограничение пропускной способности для допуска в очередь 13:50 <bla> Кто делал ту предварительную работу? 13:50 <@jrandom> bla: detonate и mule 13:50 <+detonate> да... но я последние месяц‑другой сачкую 13:50 <bla> detonate: Надеюсь, ты пошутил насчёт BT? 13:51 <+detonate> наполовину серьёзно 13:51 <+detonate> по крайней мере можно было бы сократить число потоков транспорта вдвое, если так сделать 13:51 * jrandom швыряет в detonate ведро грязи 13:51 <jdot> вууху. мой router теперь работает на выделенном сервере, а не на моём паршивом кабельном соединении. 13:51 <@jrandom> круто, jdot 13:52 <@jrandom> мы сможем обойтись 3–5 потоками в транспортном слое для всей связи со всеми пирами 13:52 <bla> detonate: Но половины будет мало, когда сеть станет большой (> пара сотен узлов) 13:52 <jdot> с 1000 ГБ трафика в распоряжении 13:53 <jdot> к сожалению, j.i2p и chat.i2p будут недоступны ещё несколько часов, пока я всё мигрирую 13:53 <duck> detonate: addressbook тоже на паузе? 13:53 <+detonate> да, он тоже на паузе 13:54 <+detonate> единственное, что не на паузе, — монолитное хранилище профилей; я собирался заставить его заработать позже сегодня 13:54 <@jrandom> угу 13:54 <+detonate> тогда i2p не будет дико фрагментировать диск 13:54 <jdot> jrandom: что касается ограничений BW, это средние значения? 13:54 <+frosk> современные файловые системы не фрагментируют, глупости 13:55 <+detonate> ntfs — да 13:55 <@jrandom> jdot: ограничения пропускной способности — это строгие token buckets (алгоритм «ведро с токенами») 13:55 <@jrandom> jdot: если задать длительность burst'а, то это тот период, по которому усредняется 13:56 <@jrandom> (ну, 2x burst == период) 13:56 <@jrandom> ((примерно)) 13:56 <jdot> хммм... ну у меня 1000 ГБ, и я хочу, чтобы i2p мог съедать до 800 ГБ/мес.... 13:56 <+ant> <mihi> detonate: ntfs хранит очень маленькие файлы в MFT, что означает почти отсутствие фрагментации 13:57 <jdot> и мне всё равно, до каких значений оно будет burst'ить 13:57 <+detonate> когда запускаешь дефрагментатор, он 10 минут двигает все 6000 профилей... значит, они таки фрагментируются 13:58 <@jrandom> jdot: хмм, ну, 800 ГБ, вероятно, больше, чем он вообще захочет прокачать, так что можно, вероятно, и без лимитов ;) 13:58 <@jrandom> с другой стороны, если опишешь желаемую политику, возможно, сможем её реализовать 13:58 <jdot> jrandom: пока сделаю так и посмотрю, как оно пойдёт 13:58 <bla> detonate: NTFS, если верно помню, — журналируемая ФС. Так что даже монолитный файл будет фрагментироваться, если записывать в него маленькими порциями 13:58 <+detonate> всё пишется сразу 13:59 <+detonate> и читается сразу 13:59 <bla> detonate: Ок. Понял. 13:59 <jdot> jrandom: ну, давай подождём, прежде чем решать, будет ли это вообще проблемой. 13:59 <bla> detonate: Тогда хорошая работа! 13:59 <+detonate> мне было бы интересно узнать, какая на самом деле будет нагрузка, если оставить без ограничений 14:00 <+detonate> на хорошем соединении 14:00 <jdot> мне тоже интересно! 14:00 <@jrandom> мои colo routers работают без ограничений, хотя ограничены по CPU 14:00 <+Ragnarok> можно ли использовать bitbucket для усреднения за месяц? 14:00 <jdot> jrandom: CPU ограничен? какой CPU? 14:01 <@jrandom> 4d transfer 3.04GB/2.73GB 14:01 <+detonate> хмм, ожидал меньше 14:01 <@jrandom> jdot: ограничен по CPU, потому что я гоняю на нём 3 routers, плюс ещё пару JVM'ов, иногда с профилированием 14:01 <+detonate> должно быть, это те ребята с bt 14:01 <+detonate> когда заработает batching, будет интересно посмотреть, как это изменится 14:02 <@jrandom> detonate: часть этого трафика — это ещё и я гоняю файлы по 50 МБ между ним же самим ;) 14:02 <+detonate> хех 14:02 <jdot> ааа. ок. ну, посмотрим, как поведёт себя эта система. это AMD XP 2400 с 512 МБ и соединением 10 Мбит 14:02 <@jrandom> Ragnarok: token buckets так не работают 14:02 <@jrandom> jdot: ага, да, это p4 1.6, если правильно помню 14:03 <@jrandom> Ragnarok: в token bucket каждую (например) секунду добавляется некоторое число токенов согласно заданной скорости. если bucket полон (size = burst period), лишние токены отбрасываются 14:04 <@jrandom> когда требуется передать данные, нужно получить достаточное количество токенов 14:04 <@jrandom> (1 token = 1 byte) 14:04 <+Ragnarok> я знаю, как они работают... что будет, если просто сделать bucket очень большим? 14:05 <+detonate> тогда ты никогда не прекратишь отправку данных 14:05 <+detonate> если он бесконечного размера 14:05 <+detonate> эм, и заполнен токенами 14:05 <@jrandom> если он очень большой, после периода низкой активности может случиться burst до неограниченных скоростей 14:06 <@jrandom> хотя местами это и желаемо 14:07 <@jrandom> дело в том, что нельзя просто установить token bucket на 800 ГБ, это не будет ограничивать общий объём переданного 14:08 <+detonate> нужно поле, где можно задать число токенов в секунду, тогда можно просто разделить месячное потребление полосы на число секунд 14:08 <+detonate> :) 14:10 <@jrandom> это то же, что задать скорость, усреднённую по месяцу, что будет несбалансировано. Но вообще есть куча сценариев — если у кого‑то есть такие, которые не покрываются тем, что уже есть, пожалуйста, дайте знать 14:10 <+Ragnarok> но если задать желаемую среднюю скорость... Думаю, здесь 308 кБ/с, а затем выставить bitbucket на что‑нибудь очень большое... почему это не сработает? 14:11 <+Ragnarok> s/larger/large/ 14:12 <+detonate> можно настроить так, чтобы он никогда не отправлял больше чем 800 ГБ/44000 за 60‑секундный период burst 14:12 <+detonate> 44000 — это примерно число минут в месяце 14:13 <@jrandom> размер bucket/длительность burst описывает, сколько мы отправим без ограничений, а большинство /всё же/ хочет ограничения, чтобы router не жрал 10 Мбит/с 5 минут, пока опустошает bucket (и т. п.) 14:14 <@jrandom> возможен и дополнительный дроссель на выходе токенов из bucket (и нужен ли этому дросселю свой token bucket, и тому bucket — свой дроссель, и т. д.) 14:16 <+Ragnarok> я думал, bucket пополняется только когда полоса не используется 14:16 <@jrandom> токены добавляются в bucket с постоянной скоростью (например, 64k токенов в секунду) 14:17 <@jrandom> всё, что хочет полосу, всегда обращается к bucket 14:18 <+Ragnarok> ага.. ок 14:19 <@jrandom> ок, круто, есть ли ещё что‑нибудь для обсуждения на встрече? 14:21 <@jrandom> ок, если нет 14:21 * jrandom замахивается 14:21 * jrandom *бах* закрывает встречу