Размер пакетов Nstreme против джиттера/задержки

Ну что, похоже, за этой фичей придётся голосовать. Голосуйте, пожалуйста! Голосование без nstream было бы здорово/отлично. (Только бы не испортить nstream, конечно).

У меня примерно 1500-2000 nstreme-линков, и мне кажется, что все работает нормально. Я не думаю, что тут какая-то проблема. Скорее всего, у тебя плохой сигнал или проблема с rate negiotioation. Если ты ожидаешь пинг в 1мс на мультипоинтовом решении, попробуй VectaStar 3500 – он стоит в 100 раз дороже MT (около 25 тысяч долларов за один передатчик), но ты получишь эти самые 1мс пинга. Вот посмотри, это пинг с моего ПК на шлюз, через который я получаю интернет: C:\Documents and Settings\Marek>ping 192.168.3.254 Badanie 192.168.3.254 z użyciem 32 bajtów danych: Odpowiedź z 192.168.3.254: bajtów=32 czas=5ms TTL=62 Odpowiedź z 192.168.3.254: bajtów=32 czas=4ms TTL=62 Odpowiedź z 192.168.3.254: bajtów=32 czas=5ms TTL=62 Odpowiedź z 192.168.3.254: bajtów=32 czas=4ms TTL=62 Конечно, это с nstreme с polling, линк от Rb 532 к Rb 133C, при большей нагрузке (около 10 мегабит) они возрастают до 20 мс. Линк на расстоянии 5-6 км с NLOS (…долгая история…). Polling без nstream было бы здорово/отлично. Не думаю, что так.

У меня много соединений, работающих с nstreme при уровне сигнала -76dBm и скорости передачи данных 24Mbps, где шум довольно сильный, но всё работает отлично. Секрет в том, чтобы задать стабильную скорость передачи данных, на один-два значения ниже обычной скорости переговоров, и всё будет работать идеально. Ну и, конечно, важен mPCI – я почти всегда использую одну и ту же модель, которую выбрал как лучшую с MT, и никогда не имел проблем с nstreme.

Это именно то, что я и имел в виду. Nstreme или нет, срочно нужен хороший алгоритм опроса. Эй, Нормис, есть какие-то мысли? Эрик

Думаю, могу немного потестировать один из узлов нашей сети… это проблема, с которой мы сражаемся уже какое-то время. Отпишусь, как закончу тестирование.

Предполагаю, что "полиция фреймов" отсутствует, поэтому, возможно, до сих пор используется размер пакета 3200 (mt, можешь прокомментировать?). И поэтому, использование меньшего пакета все же может помочь. Если по какой-либо политике пакеты отправляются такими, как они получены, то пользы может и не быть. Если Moto/trango и другие могут сделать хорошее и быстрое решение для опроса, я уверен, что MT может сделать не хуже, а может и лучше. Может, это нужно отделить от Nstreme? В любом случае у нас есть аппаратная мощность (по крайней мере, на стороне x86), чтобы это сделать, просто не хватает программного обеспечения. Нам нужно вывести это на следующий уровень, и нам нужно надежное и качественное решение для опроса, а также улучшение джиттера и задержки, которое я знаю, возможно. С этим не должно быть никаких причин, по которым AP с 100+ пользователями не сможет работать нормально и выдавать несколько мегабайт. К черту, наш 2mb Wave rider может выдавать более одного мегабайта (в среднем) с 30+ клиентами (средние паттерны использования). Erik

Я не видел этого в списке Вики, поэтому добавил. Пожалуйста, проголосуйте, а затем отправьте по электронной почте 10 друзьям!! Эрик.

Ты используешь только R52 или ещё какие-то устройства подключены к твоему AP? Основная проблема с NStreme/Jitter возникает, когда подключено больше 30 устройств, при этом rate установлен в 2 варианта. CCQ на всех каналах показывает 70-100. Кто-нибудь пробовал с меньшими пакетами?

Видел несколько постов от людей, использующих платы на базе X86 Athlon, где тоже присутствует эта проблема, так что не думаю, что это проблема процессора.