Differences

This shows you the differences between two versions of the page.

--- etc:common_activities:olpc:mesh:links:wireless_recommendations [2008/09/21 01:10] – создано raa
+++ etc:common_activities:olpc:mesh:links:wireless_recommendations [2008/10/07 22:30] (current) – raa
@@ Line 1: / Line 1: @@
-==== The Mesh Adaptation Daemon (MAD) - Демон настройки Mesh ====
+====== I1. The Mesh Adaptation Daemon (MAD) - Демон настройки Mesh ======
-Реализовать демон, ориентированный на пользователя, который будет наблюдать за mesh-средой и соответствующе реагировать/настраиваться на нее для улучшения мастабируемости и надежности сети.
+Цель - реализовать демон, ориентированный на пользователя, который будет настраивать mesh-сеть для улучшения ее масштабируемости и надежности. В будущем возможно использование адаптации для уменьшения потребления энергии.
-==== Уменьшение управляющего трафика ====
+Демон получает статистику от драйвера или другого подходящего источника и настраивает параметры сети по заданным заранее схемам.
+===== Эвристики работы MAD =====
+Идея: сделать частоту multicast-рассылок зависящей от плотности сети. Для этого нужно определить, через что определять плотность и как ее измерять.
+==== Плотность против периодичности рассылок ====
+В плотной сети увеличивать периодичность multicast/broadcast рассылок.
+Периодичность рассылок определяет компромисс между покрытием сети и затрачиваемым временем. Редкие рассылки дойдут до удаленных узлов, но они могут застопорить/перегрузить сеть собой (это долго живущие пакеты) и необходимостью их постоянно пересылать (:?: непонятный момент). В плотной сети велика вероятность получения кадра при частой рассылке, так как узлы ближе расположены друг к другу и число пересылок в такой сети больше.
+**Возможным недостатком** такой политики может стать обособление отдельных удаленных узлов, которые станут меньше участвовать в работе сети. Необходима проверка, действительно ли эти узлы будут испытывать трудности и в какой степени (если да).
+**Варианты механизма нахождения активных соседей**:
+  - просмотр таблицы маршрутов и расчет числа обратных маршрутов (:!: вероятно время  окончания срока действия маршрута станет адаптивным и тогда оно должно будет влиять на данный алгоритм);
+  - число обнаруженных за определенный интервал кадров-маячков (:!: требует встраивания в прошивку);
+  - число адресов удаленных источников или пересылающих узлов, обнаруженных за определенный интервал (:!: требует встраивания в прошивку).
+==== Производительность против метрик ====
+Если узел работает на батарее, он должен акцентировать (показывать:?:) худшие метрики.
+Механизм нахождения маршрутов должен в первую очередь обрабатывать узлы, питающиеся от аккумулятора и т.п., что поможет продлить время работы батареи.
+**Возможный недостаток** - появление в маршруте лишних переходов (хопов).
+====== I2. Уменьшение управляющего трафика ======
 Частота, с которой ХО передает управляющий трафик (запросы/ответы специального устройства для сбора информации), может быть уменьшена без ущерба функциональности, что значительно сэкономит время передачи.
-==== Реализация лучшего алгоритма адаптации скорости передачи ====
+FIXME добавить подробное описание
-Из-за ограниченных ресурсов памяти в ХО встроен простой алгоритм подсчета ошибок передачи кадров, который уменьшает уровень передачи, если заданное число последовательных кадров потеряется, и, аналогично, увеличивает этот показатель, когда заданное число кадров успешно пересылаются. Проблема заключается в том, что когда пакеты теряются из-за
+====== I3. Реализация лучшего алгоритма адаптации скорости передачи ======
-перегрузки сети, уменьшение показателя передач сделает ситуацию еще хуже.
-==== Агностицизм сервиса присутствия в сети ====
+Из-за ограниченных ресурсов памяти в ХО встроен простой алгоритм подсчета ошибок передачи кадров, который уменьшает уровень передачи, если заданное число последовательных кадров потеряется, и, аналогично, увеличивает этот показатель, когда заданное число кадров успешно пересылаются. Проблема заключается в том, что когда пакеты теряются из-за перегрузки сети, уменьшение показателя передач сделает ситуацию еще хуже.
+FIXME добавить подробное описание
+====== I4. Агностицизм сервиса присутствия в сети ======
 Когда сервис присутствия решает, что ХО находится в mesh-сети, он использует mDNS для опубликования и получения информации о присутствии. Когда сервис решает, что в сети есть сервер, он переключается с mDNS- на XMPP-сервер. Сервис присутствия должен выдавать решение, агностическое (независимое?) от наличия или отсутствия сервера.
-==== Разработка нового физического (PHY) уровня ====
+====== I5. Разработка нового физического (PHY) уровня ======
+Улучшить mesh через использование 802.11n PHY, который обеспечивает скорость передачи данных до 600 Мб. Улучшения на MAC-уровне в .11n включают агрегирование кадров, что может быть полезно для сети при передаче коротких кадров. В использовании .11n MAC для mesh-сети есть вопросы, требующие решения в рабочей группе по стандартам.
+====== I6. Подгон затрат (метрик) в каждом пакете PREQ ======
+====== I7. Улучшение спектральной эффективности при broadcast рассылках ======
+Заставить  mesh использовать 802.11n PHY, который обеспечивает скорость до 600 Мбит/с. Улучшения в .11 MAC включают также 	возможность агрегирования кадров, что полезно при передаче множества коротких кадров. В использовании .11n MAC для mesh-сети есть вопросы, требующие решения в рабочей группе по стандартам.
+====== I8. Улучшение схемы IP адресации в mesh ======
+Передача между mesh клиентом и mesh порталом испытывает проблемы: XO laptop сам приписывает себе адрес локальной подсети - 169.254; когда он находит портал, тот в свою очередь приписывает XO закрытый адрес подсети - 172.16. Лучше было бы разбить подсеть 169.254.х.х на 3 подсети для использования на каждом канале (1,6,11). Порталы mesh-сети распространяют данные о своем присутствии в сети через mDNS. Предполагается, что управление сетью в Linux уже поддерживает такую конфигурацию, но возможно Avahi потребует дополнительной настройки для работы с нестандартной локальной подсетью.
+====== I9. Новая версия сетевого менеджера ======
-Улучшить mesh через использование 802.11n PHY, который обеспечивает скорость передачи данных до 600 Мб. Улучшения на MAC-уровне в .11n включают агрегирование кадров, что может быть плезно для сети при передаче коротких кадров. В .11n MAC для mesh-сети есть вопросы, требующие решения в рабочей группе по стандартам.