Встреча разработчиков I2P - 16 мая 2006

<cervantes> moo: http://dev.i2p.net/pipermail/i2p/2006-May/001289.html <cervantes> 0) привет <cervantes> 1) jrandom'а нет <cervantes> 2) ??? <cervantes> 0) привет <cervantes> привет <cervantes> переходим к 1) <cervantes> jrandom сегодня нет, но завтра он даст нам обновление статуса <cervantes> 2) ??? <cervantes> у кого-нибудь есть что добавить к встрече? <bar> у меня вопрос <cervantes> в таком случае... * cervantes разминается * cervantes перестаёт разминаться <Complication> Ага, вопрос... <bar> исправление PRNG (генератора псевдослучайных чисел) в cvs — оно улучшит общую производительность или относится к чему-то ещё? <cervantes> пока неясно, какие общие последствия это может иметь <Complication> Лично я не знаю его полного влияния, но оно касается как минимум двух вещей, о которых я знаю: <cervantes> но конкретно это исправляет симптом с i2ptunnel * cervantes предоставляет Complication возможность пояснить <Complication> рандомизация длины tunnel и выбор IRC‑сервера (в общем случае — случайный выбор из списка назначений I2PTunnel) <Complication> Рандомизация длины tunnel, вероятно, существенно влияет на общее здоровье сети, поскольку позволяет клиентам, которым допустим компромисс по длине tunnel, действительно это делать <Complication> То есть они будут не только затаив дыхание строить 2‑хоповые tunnels, но и пробовать 1‑хоповые tunnels <Complication> (которые в тяжёлые времена намного легче получить) <cervantes> также соединяемость с IRC может улучшиться, когда это будет развёрнуто. По сути, freshcoffee вообще не получал клиентских подключений, потому что был вторым в списке — так что в следующем релизе нагрузка должна равномерно распределиться между обоими серверами <bar> то есть из‑за бага люди всегда выбирали большую длину tunnel, если была доступна? <Complication> Если я правильно понял, каждая рандомизация с небольшими целыми (например, выбрать 0 или 1) была затронута <Complication> Я думаю, рандомизации с большими целыми (например, выбрать число от 0 до 100) страдали меньше <Complication> если интересно, лучше спросить подробности у jranom, когда он вернётся <Complication> Я могу ошибаться в деталях. <bar> понятно, спасибо. хорошая находка <Complication> ну, cervantes пришёл сюда и начал жаловаться, что не получает никакой перегрузки ;P <cervantes> я это тоже так понял <cervantes> видите... в жизни ничего не добьёшься, если не ворчать :) <cervantes> у кого‑нибудь ещё есть вопросы или темы для встречи? <fox> <duck> да <Pi> вопрос об общем здоровье сети: я вижу всё больше клиентов, отстающих по версии I2P (2 всё ещё используют 0.6.1.11 и т. п.). не усложнят ли эти клиенты мониторинг эффектов изменений в ядре всё сильнее? (так как "меньше" хотят обновляться) <fox> * duck повторяет выше * w423412323 предлагает сменить тему в этом русле. ;) <fox> <duck> Мне интересно: я видел странные коммиты по тюнингу в списке рассылки cvs. Это больше эксперименты? Они основаны на наблюдениях? Они преждевременны? <Complication> Pi: пока их немного, большой разницы быть не должно <Pi> 70 из 300 клиентов используют не 0.6.1.18, согласно моему netdb сейчас <Complication> Это игра чисел и пропускной способности — если либо большинство routers, либо дополнительно самые высокоёмкие routers обновлены достаточно своевременно, то то, что кто‑то забыл, что установил I2P, не должно сильно влиять :) <cervantes> Pi: если старые routers ведут себя неправильно, сеть _должна_ адаптироваться и уменьшить трафик, который router через них <cervantes> *being routed <cervantes> Complication: ты видел вопрос duck? <Pi> и вопрос о статистике на i2p-console, которая появилась некоторое время назад: что означает handle backlog? <Complication> duck: ты имеешь в виду настройки ограничения tunnel? Это тюнинг в том смысле, что они не привносят чего‑то принципиально нового, но сейчас должны быть достаточно хорошо протестированы (напр., они, вероятно, не будут byte) <Complication> Но они могут немного byte, если у тебя экзотическая конфигурация, полностью вне тех параметров, которые я мог предусмотреть <fox> <duck> Complication: мне было интересно, действительно ли '2' вместо '3' в тех штуках так важно <fox> <duck> но, похоже, проблема со случайностью могла быть большой бедой <fox> <duck> (хотя относительное влияние этого на «нездоровье» сети зависит от того, когда это было введено) <cervantes> Pi: handle backlog — это количество ожидающих входящих запросов на присоединение к tunnel (цитата из changelog) <Complication> Если ты имеешь в виду проблему со случайным nextInteger() и влияние на рандомизацию длины tunnel, думаю, эффект был бы значительным <Complication> Разница по стоимости построения 1‑хопового и 2‑хопового tunnel весьма заметна <Pi> спасибо, cervantes :) <fox> <duck> когда это было введено? <Complication> duck: думаю, это появилось вместе с некоторыми переходами на генератор Fortuna или с какими‑то его модификациями <fox> <duck> ок; большое спасибо за твой вклад <Complication> Позволь проверить cvsweb на предмет подробностей... <cervantes> Pi: полагаю, сейчас есть код, который отбрасывает входящие запросы tunnel, если заполняется очередь (чтобы снизить нагрузку на CPU) <Complication> Pi: да, это должен быть видимый индикатор другого параметра, используемого при принятии решения "хватает ли у нас мощности, чтобы участвовать ещё в одном tunnel?" <cervantes> duck: я, безусловно, наблюдаю сильное изменение поведения router с момента введения исправления — надо сказать, не всё к лучшему :) <Complication> большой handle backlog == перегрузка, нет смысла пытаться присоединяться к чужим tunnels <cervantes> на днях был load average 14 и 12000 участвующих tunnels <Complication> Handle backlog кажется особенно важным на высокоёмких routers (имею в виду то, что видел cervantes) <Complication> Низкоёмкие routers обычно ограничивают приём своих tunnel по причинам пропускной способности <Complication> (или по причинам времени тестирования tunnel, если точнее) <Complication> (по крайней мере, пытаются это делать) <cervantes> вау, мы продержались полчаса.... <Complication> И правда :D <cervantes> кто‑нибудь хочет вынести ещё что‑нибудь на обсуждение? <cervantes> в таком случае... * cervantes разминается * cervantes *baffs* закрывает встречу <fox> <duck> спасибо, что взялся за встречу <cervantes> хех, я ожидал «baf» закрыть её до того, как кто‑нибудь что‑нибудь сказал... но bar разрушил этот план :)