Всем привет, снова пришло время обновления

  • Index
  1. Статус сети 2) Статус SSU 3) Байесовское профилирование пиров 4) Статус Q 5) ???
    1. Net status

Last week’s 0.5.0.6 release seems to have fixed the netDb issues we were seeing (yay). Sites and services are much more reliable than they were on 0.5.0.5, though there have been some reports of trouble where a site or service would become unreachable after a few days uptime.

    1. SSU status

Достигнут значительный прогресс в работе над UDP-кодом для версии 0.6: первая партия коммитов уже внесена в CVS. Это пока ещё нельзя реально использовать, но фундамент уже заложен. Согласование сеанса работает хорошо, а полунадежная доставка сообщений работает как ожидается. Тем не менее, впереди ещё много работы: нужно написать тестовые случаи и отладить нестандартные ситуации, но прогресс есть.

Если все пойдет хорошо, на следующей неделе мы сможем провести небольшое альфа‑тестирование, только для людей, которые могут вручную настроить свои межсетевые экраны/NAT. Мне бы хотелось сначала отладить общую работу, прежде чем добавить обработчик ретрансляции, подстроить netDb для более быстрого истечения срока действия routerInfo и выбрать ретрансляторы для публикации. Я также воспользуюсь этой возможностью, чтобы провести целую серию тестов, поскольку сейчас решаются несколько критически важных факторов, связанных с очередями.

    1. Bayesian peer profiling

bla активно ведёт работу над некоторыми изменениями в том, как мы решаем, через каких пиров прокладывать tunnel, и хотя bla не удалось присоединиться к встрече, есть некоторые интересные данные, о которых стоит сообщить:

<+bla> Я провёл прямые измерения скорости узлов: я профилировал около 150 узлов, используя OB tunnels длины 0, IB tunnels длины 1, batching-interval = 0ms <+bla> Кроме того, я только что сделал очень базовую и предварительную оценку скорости с использованием наивной байесовской классификации <+bla> Последнее было сделано с использованием стандартных длин expl. tunnels <+bla> Пересечение множества узлов, по которым у меня есть “истинные значения”, и множества узлов в текущих измерениях, — 117 узлов <+bla> Результаты не так уж плохи, но и не слишком впечатляющие <+bla> См. http://theland.i2p/estspeed.webp <+bla> Базовое разделение «очень медленные/быстрые» работает более-менее, но тонкая дифференциация среди более быстрых пиров могла бы быть намного лучше <+jrandom2p> хм, как вычислялись фактические значения — это полный RTT (время кругового прохода) или RTT/длине ? <+bla> При использовании обычных expl. tunnels почти невозможно избежать задержек из‑за пакетирования. <+bla> Фактические значения — это истинные значения: полученные при OB=0 и IB=1 <+bla> (и variance=0, и без задержек пакетирования) <+jrandom2p> хотя отсюда результаты выглядят довольно хорошо <+bla> Оценённые времена — это те, что получены байесовским выводом из реальных expl. tunnels длины 2 +/- 1 <+bla> Это получено из 3000 RTT, записанных за период около 3 часов (это долго) <+bla> Предполагается (пока), что скорость пиров статична. Взвешивание я ещё не реализовал <+jrandom2p> звучит круто. хорошая работа, bla <+jrandom2p> хм, значит оценка должна равняться 1/4 от фактической <+bla> jrandom: Нет: Все измеренные RTT (с использованием обычных expl. tunnels) скорректированы по числу хопов в круговом проходе <+jrandom2p> ага, ок <+bla> И только после этого обучается байесовский классификатор <+bla> Пока я раскладываю измеренные времена на хоп в 10 классов: 50, 100, …, 450 мс, и дополнительный класс >500 мс <+bla> Например, малые задержки на хоп могут взвешиваться большим коэффициентом, как и полные отказы (>60000 мс). <+bla> Впрочем… 65% оценённых времен попадают в пределы 0.5 стандартного отклонения от фактического времени узла <+bla> Однако это надо переделать, поскольку на стандартное отклонение сильно влияют отказы >60000 мс

После дальнейшего обсуждения bla представил сравнение с существующим калькулятором скорости, опубликованное по адресу http://theland.i2p/oldspeed.webp Зеркала этих PNG доступны по адресам http://dev.i2p.net/~jrandom/estspeed.webp и http://dev.i2p.net/~jrandom/oldspeed.webp

(для терминологии, IB=число хопов во входящем tunnel, OB=число хопов в исходящем tunnel, и после некоторых уточнений, измерения “ground truth” были получены при 1 хопе в исходящем и 0 хопах во входящем, а не наоборот)

    1. Q status

Aum также добился значительного прогресса в Q, в последнее время работая над веб‑интерфейсом клиента. Следующая сборка Q не будет обратно совместима, поскольку включает целую кучу новых возможностей, но я уверен, что мы услышим от Aum больше подробностей, когда будет чем поделиться :)

    1. ???

На данный момент это, пожалуй, всё (надо закончить это до начала встречи). Ах да, кстати, похоже, я перееду раньше, чем планировалось, так что, возможно, некоторые сроки в дорожной карте немного сдвинутся, пока я буду в пути туда, где в итоге окажусь. В общем, забегайте на канал через несколько минут, чтобы помучить нас новыми идеями!

=jr