Встреча разработчиков I2P - 7 марта 2006 г.

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> Исправления в механизме ограничения (throttling), похоже, повысили надёжность, но сильно урезали пропускную способность 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> До пикового лимита (burst) так и не дотягивается 15:18 <+Complication> (что само по себе логично — меня беспокоит именно откат до устойчивого лимита) 15:19 <bar> у меня примерно то же, что и у Complication. моё общее потребление полосы — всего 50% от моих максимальных настроек. раньше было ~80% до 0.6.1.11 15:19 <jrandom> у тебя скорость ограничителя 200kbps, с 300kbps пиком (burst)? 15:20 <jrandom> (просто интересно, сколько времени раньше проводило в «пике» (burst)) 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 (которая измеряет в тех же единицах, что и ограничитель), средний общий исходящий — 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, и, похоже, у кого‑то получились результаты, согласно которым 64‑битная версия для Linux медленновата 15:31 <+Complication> У них она оказалась медленнее, чем чистая Java, не уверен, сбой измерений это или нет :O 15:32 <+Complication> Я не смог это повторить 15:32 <jrandom> да, я не был уверен, какую именно .so они использовали для этой платформы 15:32 <+Complication> У меня здесь она была примерно вдвое быстрее, чем чистая Java 15:32 <+dust> мои эксперименты с HTML как дополнительным форматом сообщений в syndie начинают работать. мой локальный 'sucker' теперь может извлекать веб-страницы (с изображениями) и сохранять их как посты syndie 15:33 <jrandom> ах, круто, dust 15:33 <+dust> но без CSS 15:33 <+Complication> Но люди на 32‑битных говорили, что она *намного* быстрее, чем чистая Java (типа 10x или около того) 15:35 <bar> хмм.. Complication, может быть, текущая amd64 .so только для 32‑битных систем, а он тестировал её на 64‑битной ОС? 15:36 <+Complication> bar: может быть, поскольку я тоже тестировал её на 64‑битной ОС :O 15:36 <jrandom> если правильно помню, 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‑битного Athlon на 64‑битном Sempron, на 64‑битной Mandriva... кажется лишь немного быстрее, чем чистая Java 15:40 <+Complication> (о, и 64‑битная ВМ) 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* закрывает встречу