deep_admin

ээх, мечты :) типа udp или tcp туннель избавит от проблем l2 Да небудет оно давить nstreme/nv2, оно падать будет. Подтверждения потерянного пакета то нету, то есть дроп переходит на верхний уровень, в случае tcp - уменьшается окно, то есть скорость, для udp - просто дроп и переходит к уровню приложения. Eoip никакой коррекции на дропы не делает, там gre обычный, только crc своих пакетов.

2 cyberat: radwin 2000c в 20мгц 100мбит полудуплекса только дает, там поприетарный мимо, но уровень сигнала конский конечно надо. 2 Alny: в текущей версии тдма фрибсд вообще плохо плохо с коррекцией ошибок - она там отсутсвует дефакто, о чем автор и упоминает. При тестах на столе первый попавшийся вай-фай на том же или соседних каналах валил линк полностью.

- у меня страна debug с полпинка незавелась, но это незначит что невозможно - gps там и непахнет в текущей реализации - в загаженном эфире оно будет еще хуже, так как CCA еще используется для коннекта и rate control'а нету (так как отключены ack) вся эта хрень писалась для loooong-range линков и не более того Реализация кстати там крайне простая, несколько страниц исходников, можно глазом пробежать и уже станет ясно, даже без описания. Это базовый скелетон, что б он превратился в подобие nv2 нужны программеры и годы.

2 slv700: существует ли таблица соответствия cinr к модуляции расчитанная именно для максбриджа? На том что измерил saab95 видно что при cinr=24 модуляция максимальная, а уже на 23 и ниже - сразу падение.

2 slv700 - все понятно, ответ удовлетворил полностью 2 pritorius - шумящий алварион ваш? если нет - почему вам мешал? за частотки то платили? если платили - почему не обратились в соответствующие органы? зы: всем сорри за офтоп

У pritorius трех или четырех годичной ( 2007 ) давности железка PTP c первым релизом софта 1.0 PTP. Железку брали для линка над водой где вообще ничего кроме wimax не работало и были страшные помехи от 3 ватного алвариона. C тех пор много воды утекло. Сейчас совершенно другая аппаратная платформа и работает по другому и понятно лучше :-). Так что уважаемый pritoruis желаю Вам вкусить все прелести любимых Вами наносов, надеюсь потом поймете разницу. В той ptp железке ценное -радиокарта miniPCI 802.16d 3.5 Ггц - ( их там две в ptp)-применятся на нынешних базовых станциях и ptp в 3.5 Ггц. И борд Aliх типа 3.2с ( кастомизированнный). Вот тут непонятно, с одной стороны - почему Pritorius не обновил софт (не дали?), с другой - получается, что если платформа 3-4 годичной давности она обязана виснуть? Если забросили (забили) на эту платформу, то где гарантии что через 3-4 года не забьете на текущую?

Сейчас тестирую тдма на фре 9current на столе, впечатления двоякие: 1) бридж таки неудалось завести - tcpdump показывает что пакеты с в радио улетают, а с другой стороны не прилетают, в роутинге работает отлично 2) в 2.4g поднимается рейт 54мбпс без ошибок, в 5g - 24мбпс работает стабильно, все что выше - по разному плохо 3) так как никакой аггрегации нету и фишки атероса типа ff,burst,superg неработают + оверхед тдма - максимум что выжал 20 с копейками мбит полудуплекса в 20мгц 4) пускание встречных потоков трафика, типа 10мбит в одну сторону и параллельно 9-10 в другую на пинг несказывается никак, четко, ровно. Без тдма на встречном потоке уже в 2мбита наблюдаются потери. 5) пробовал тупо увеличивать tdmaslotcnt в исходниках и пересобирать ядро - работает! Увеличение кол-ва слотов например до 22 увеличивает задержку до 30-40мс, скорость одного слота не превышает 1.7-1.8мбита для 25мс длительности слота. Сейчас собираю стенд на 3-4 тазика и буду тестить. вот еще материал для курения http://habrahabr.ru/blogs/bsdelniki/86553/, вроде как netgraph минимальную нагрузку на cpu дает

Действительно они не связаны. Но TDMA дает возможность реализвать QoS, а вот CSMA и CSMA+ polling могут дать максимум приоритизацию на интерфейсе, которую они называют тоже QoS, но он приципиально другой чем это стандартизировано в 802.16 и реально в БШД уровень сервиса не гарантирует. Есть TDMA без QoS например Канопи, а 802.16 все должны быть и реально есть c QoS. QoS в wimax обеспечивается Convergent Sublyer - программной надстройкой в МАС поверх PHY аналогично поллингу поверх CSMA. И в этом Convergent Sublyer тоже есть свой polling. Но он в wimax не занимается поддержкой доступа ( это делает чипсет TDMA) , его задача - обеспечение сервиса QoS. тут ошибочка, в 802.16-2004 СS в поллинге не участвует. И кстати, при включении ARQ, где проставляются в каждом пакете tsf и есть ожидание ACK приема пакета (не напоминает 802.11 сsma/ca?) все преимущества TDMA идут лесом.

2Alny: ткните плиз в ссылку на Intel MT-1000 mPCI, а то тут http://www.intel.com/products/server/adapters/index.htm такой нет, а тоже хочется

Посмотрел внимательней в код - в действительности с жаваскрипта вызывается бинарная .cgi'шка, в ее сырцах ccq получаем с общей структуры радиоинтерфейса. Вот что нарыл в ieee80211_wireless.c: /* UBNT ccq calculation */ ccq = (10 * (100 - ni->ni_rate_per[si->isi_txrate])); if (vap->iv_fixed_rate == IEEE80211_FIXED_RATE_NONE) { ccq *= (si->isi_rates[si->isi_txrate] & IEEE80211_RATE_VAL); if (vap->iv_max_des_rate) ccq /= vap->iv_max_des_rate; else ccq /= (si->isi_rates[si->isi_nrates - 1] & IEEE80211_RATE_VAL); } si->isi_ccq = ccq; IEEE80211_DPRINTF(vap, IEEE80211_MSG_IOCTL, "%s(PID:%u): ccq: %d, rate: %d per: %d\n", __func__, current->pid, si->isi_ccq, (si->isi_rates[si->isi_txrate] & IEEE80211_RATE_VAL), ni->ni_rate_per[si->isi_txrate]); где ni_rate_per[iEEE80211_RATE_MAXSIZE]; /* Packet Error Rate per rate */

еще мак виден 0.21.109.252.178.48 = 00:15:6d:fc:b2:30 на этот мак видны пакеты tx/rx и скорости 18m/18m уровень шума и ccq через snmp действительно невыдаются, более того ccq считается javascript'ом прямо на вебе точки

Вы об чем вообще? Что за поток сознания? Чего, стопбиты не детектятся? :>У UBNT есть родной NMS. Он все это отображает. Поставить его и wireshark-ом проснифить диалог по snmp - там будут видны OID-ы, по которым можно собрать нужную информацию. Можно тоже самое нагуглить по более специализированным на UBNT формумах. Но первый вариант гарантированно быстрее. боже, как все запущено :) зачем снифить? snmpwalk -cpublic -v1 -On 192.168.1.20 .1 смотреть в последнюю десятку строк ЗЫ: родной NMS (AirControl) у UBNT работает не через SNMP. На устройствах спец демоны mcad которые после активации со стороны aircontrol'a шлют ему данные в виде http POST запросов на порт 9080.

ни чего себе глюки :) сейчас опять проверил, включил nv2 и примерно через минуту удаленная точка пересталапинговаться, зашел по MAC пингуется, вышел с точки примерно через минуту опять пропал пинг, то есть пока в винбоксе сидишь пинг идет :) что то я разработчиков не пойму, выкладывают как стабильный пакет и такие ошибки, понимаю если какая то мелочь, но это не мелочь... не серьезно... на 5 пока не хочу переходить, если у них в стабильной версии такое, что там в бета можно представить :) 4.13 это вообще нечто. Простой нстрим упорно нехотел работать, каждые 30 сек. линк рвался, без нстрим все ок, перезагрузил борд, заработало, через пару часов опять такая же ситуация. Это неслучайные глюки. Это такая система что у МТ, что UBNT - оба они перекладывают затраты на тестирование продукта на плечи пользователей. Вы когда нибудь видели чтобы например, Проксим или Моторола выкладывали вета версии прошивок и просили на своих форумах от пользователей дать результы их тестирования ? Если бы UBNT,MT проводили полный цикл тестирования сами, то продукт был бы в два и более раз дороже. Но они этого не делают, поскольку их клиенты -любители и они с удовольствием тестируют продукт ( что мы и наблюдаем на данном форуме). Операторы - профессионалы, оказывающие коммерческий сервис, не могут себе позволить тестировать продукт в своих коммерческих сетях. Они если и проводят теcтирование -то совершенно с другой целью - тестируется уже полностью готовый продукт с целью изучения его применимости в своих сетях.Бывают при этом и глюки, но не такие системные как мы наблюдаем за последние два года у MT/UBNT.Причем стратегически улучшения качества софта ожидать не стоит. Известно ( специалистам ясно дело :-) что на стандартном wifi коммерческий сервис построить нельзя. Это понимают MT/UBNT и придумывают ( уже много раз придуманное до них ) всякие а-ля tdma и прочее. Но ресурсов чтобы сделать качественный продукт или нет, или если и есть и это делать правильно, то продукт будет стоить как у Proxim, Infinet. Поэтому и получается продукт сродни опенсоурсным полуфабрикатам, поскольку технология разработки почти такая же. Proxim/motorola не просят ибо репутация, но от этого лучше не становится, проблем и глюков тоже море, но за гораздо бОльшие деньги. Просто уровень тех кто эксплуатирует чуть повыше, соответственно и вопросы другие.

http://www.3dbwireless.com/boyd/

в случае с xinetd вам нужен свой серверный скрипт писать кроме клиентского, а это потребует установки разного, может и ненужного доп. софта в случае с ssh - ничего вообще не надо.

что-то вроде такого? !/usr/bin/expect -f set HOST "192.168.1.1" set PASS "mypassword" set USER "root" set ENC "KOI8-R" set CMD "ip route ls" set timeout -1 spawn luit -encoding $ENC ssh -l $USER $HOST match_max 100000 expect -exact "$USER@$HOST's password: " send -- "$PASS\r" expect "Last login: *\r\r *$USER*" send -- "$CMD\r" expect "\r" expect "*default*" exit

Ставите где? Если на только роутере - то непонятно как оно вообще работает. Если на апешке (frag threshold)- тоже надо на всех клиентских точках менять и включать rts/cts.

С большой вероятностью это и может быть причиной. Это так кажется, на разных версиях 4.5\4.6\4.10\4.11 он то работает, то нет, а завязать разные версии между собой не всегда получается. Я вообще не могу понять как разные версии одного продукта , претендующего на работу в коммерческих сетях операторов связи ,несовместимы между собой? Это допустимо для бытовых устройств но не B2B. Ой да ладно, форумы моторолы, да и тут можно поискать так и кишат несовместимостью и глюками. Это задача именно инженеров для тщательного всестороннего тестирования перед запуском в эксплуатацию. Ну или пусть интеграторы это делают, но за бОльшие деньги.

На 3-м скрине который ретраслятор - канал сквозной через 2 радио. Платформа не аликс - пк амд атлон 2.6. Аликс бы умер после 15килопакета. Nstreme есс-но включен, агрегация есс-но есть, но нам же важны рез-ты на входе и выхода (колво пакетов в секунду), а не то что там в радио реально творится. Конечно есть отрицательные эфекты у агрегации, но нстрим довольно умная штука и умеет приоритезировать icmp/tcp syn ack например.

Специально неполенился и сделал 3 скриншота: Первые два скриншота - сторона А. Платформа с обоих сторон - x86. Наблюдаемый интерфейс - wlan1. Линк 42км, карточки XR5, офсетные зеркала, 40мгц полоса. Уровень видно. Также видно пакетную производительность в одну сторону пакетами 150 и 64 байта - 46 и 84кппс соответственно, ну и загрузка проца тоже видна :) Третий скрин - сторона B, которая является фактически ретранслятором, принимает линк на wlan2 и отправляет дальше на wlan3. Скрин снят во втором случае - тесте 64байтными пакетами. В полосе 10 мгц не менее 15 мгц разноса для b/g, и 20 мгц разноса для n. Для полосы 20 мгц - 25 для b/g и 30 для n. Можете проверить даже на столе 2-мя парами наносов и iperf. Разнос зависит в том числе от антенн. На столе и с внешними антеннами на улице будет работать по разному. Обсуждаем наносы2 со встроенными антеннами.

В полосе 10 мгц не менее 15 мгц разноса для b/g, и 20 мгц разноса для n. Для полосы 20 мгц - 25 для b/g и 30 для n. Можете проверить даже на столе 2-мя парами наносов и iperf. от туда же: Retry Chain ================================================================== The HAL provides a multirate retry chain - which consists of four segments. Each segment is an advisement to the HAL to try to send the current packet at some rate, with a fixed number of retry attempts. Once the packet is successfully transmitted, the remainder of the retry chain is ignored. Selection of the number of retry attempts was based on the desire to get the packet out in under 26ms, or fail. We provided a module parameter, ath_segment_size, which has units of micoseconds, and specifies the maximum duration one segment in the retry chain can last. This module parameter has a default of 6000. Our view is that a segment size of between 4000 and 6000 seems to fit most situations. Notes on Timing ==================================================== As noted above, Minstrel calculates the throughput for each rate. This calculation (using a packet of size 1200 bytes) determines the transmission time on the radio medium. In these calculations, we assume a contention window min and max value of 4 and 10 microseconds respectively. Further, calculation of the transmission time is required so that we can guarantee a packet is transmitted (or dropped) in a minimum time period. The transmission time is used in determining how many times a packet is transmitted in each segment of the retry chain. Indeed, the card will supply the cwmin/cwmax values directly iwpriv if_name get_cwmin <0|1|2|3> <0|1> We have not made direct calls to determine cwmin/cwmax - this is an area for future work. Indeed, the cwmin/cwmax determination code could check to see if the user has altered these values with the appropriate iwpriv. The contention window size does vary with traffic class. For example, video and voice have a contention window min of 3 and 2 microseconds respectively. Currently, minstrel does not check traffic class. Calculating the throughputs based on traffic class and bit rate and variable packet size will significantly complicate the code and require many more sample packets. More sample packets will lower the throughput achieved. Thus, our view is that for this release, we should take a simple (but reasonable) approach that works stably and gives good throughputs. Вот тут объясните. В других топиках вы ругали вайфай именно из-за дохлого проца и вследствие чего низкой пакетной производительности.

Действительно, wifi корректирует свою модуляцию ( rate ) по определенным алгоритмам в зависимости от потерь пакетов в единицу времени с учетом дальностей, задержек и прочее. Но проблема wifi в том, эти алгоритмы оптимизированы для офисного применения ( главном образом отработки потерь от офисного multipath fading ). Точно также частотные интервалы между поднесущими wifi OFDM расчитаны для подавление офисного переотражения ( в офисе меньшие задержки в отличие от переотражений на улице). Поэтому эти алгоритмы на улице работают неадекватно. Как известно регулировка рейта вручную получается лучше. И это один из ключевых недостатков wifi если его применять на улице. Я ссылки приводил, вы б хоть почитали. Там все для улицы оптимизировано. В офисе все гораздо проще. Благодаря, кстати, этому ewma который есть у наносов/булетов итд последние чувствуют себя гораздо лучше в загаженом эфире, именно из-за меньшего кол-ва переключений скоростей/модуляций. Кстати, почему то мтик не использует ewma и это заметно при равных условиях. По поводу наносов: они шикарно работают в полосе 10мгц, пропускная способность ессно падает до 12мбит/с при размере пакета 1200-1500 байт. Зато канал неупирается в пакетную производительность проца :)

По поводу выбора рейтов в вайфай не все так просто. На сегодняшний день реализованы 4 алгоритма rate select: - amrr (http://www-sop.inria.fr/rapports/sophia/RR-5208.html) - ministrel, он же ewma у ubnt (http://www.pdos.lcs.mit.edu/papers/jbicket-ms.ps) - onoe - samplerate (John Bicket's SampleRate control algorithm) все они, кроме ministrel включены в стандартный madwifi ministrel(ewma) достаточно сложный алгоритм, решение о смене рейта принимается исходя из кучи условий + постоянные замеры. Управляется не только исходящая мощность, а также кол-во переповторов.

Вы это на собственном опыте знаете? И как прокачка? На всех секторах полная или пополам делится? знаю, с прокачкой все ок, неделится там синхронизация по gps, в один момент времени только один передачик работает, коллизий нет

если аналоговые с усилками на лампах - то не будут, там у ару запас большой :) моторола канопля - не мешает, можно на одной мачте несколько секторов на одной частоте вешать - синхронизация однако