[Ainy]

Нет у него 45kpps.

Сами они утверждают обратное:

http://routerboard.com/RB433AH

 

И методика общепринятая:

http://www.ietf.org/rfc/rfc2544.txt

А Вы простите, сами, это "memo" читали?

Кем оно общепринятое?

"Status of this Memo

 

This memo provides information for the Internet community. It does

not specify an Internet standard of any kind. Distribution of this

memo is unlimited.

"

Там еще, где описывается методика тестирования устройств с разным типом MAC, предполагается firewall, фильтрующий служебные сообщения и верификация пейлоада.

Если включить фильтрацию, согласно описанным в мемо правилам, там и 6к ппс не будет. Да и сам документ этот 1999-го года рождения, скажем прямо, немного устарел.

Адекватный кстати этому мемо, за исключением фильтров (ибо не нужны они, при таком способе подсчета) способ тестирования - использование VoIP test в Ixia Chariot,

в котором можно менять размер payload. PPS вычислять по формуле, приведенной в том же memo. Chariot дает в протоколе все необходимые данные для этого и сам протокол служит подтверждением.

Я что-то ни разу не видел, чтобы на сайте routerboard выкладывались протоколы тестирования.

Несколько бордов тестировал сам, в т.ч. и 433AH, данные, полученные при тестах, существенно ниже, чем заявляемые на сайте.

[Ainy]

чем больше клиентов/маков ходит по радио

Либо я чего-то не понимаю, либо..., но если пофантазировать, то у нас выйдет два микротика, 1. работающих только между собой; 2. по сути там будет на канальном уровне два мака - провайдерский коммутатор и наш шлюз доступа. Какие там могут быть клиенты/маки? Нагрузку будет создавать сетевой уровень и выше.

коммутатор, только если он роутящий. Т.е. в этой схеме его тогда разумно назвать роутером. Тогда действительно 2 мака. Что это меняет? Это как-то уменьшает ппс?

ппс может уменьшить только агрегация пакетов от одного роутера до другого, что-то типа туннеля с упаковкой и компрессией. Если его реализовать аппаратно, действительно может дать реальный эффект, а если еще к нему добавить PHS или ROHC, то пропускная способность может при распределении пакетов, близком с среднестатистическому, увеличиться до 2-х раз, при несущественном увеличении джиттера. А если реализовать программно - тогда джиттер увеличится на порядок минимум и канал будет непригоден для коммуникаций реального времени. Т.е. 2 нормальных шлюза с ROHC могут позволить использовать канал на микротике. Только каждый их них будет стоить как морской контейнер релеек. Поэтому такая перспектива сугубо теоретическая. Для любителей пофантазировать.

[lan-viper]

Коммутатор 3-го уровня, именно такой там и будет стоять. Я про уменьшение ппс и не говорил, просто человек написал про деградацию пропускной способности из-за количества маков/клиентов, но это имеет место в случае организации точки доступа с числом клиентов > 1, но это не наш случай.

[slv700]

Нет у него 45kpps.

Сами они утверждают обратное:

http://routerboard.com/RB433AH

 

И методика общепринятая:

http://www.ietf.org/rfc/rfc2544.txt

Это ппс между между двумя Ethernet одного борда. У МТ core бизнес как раз бытовые роутеры начального уровня и цифра ппс между эзерами им и нужна.

У MIPS тормоз идет на прерываниях проца при обработке интерфейсов wireless miniPCI - ethernet.

[Saab95]

Я имел в виду чем больше клиентов за радиоканалом, тем меньше его пропускная способность в смысле передачи данных. PPS тут в любом случае может быть один и тот же, но количество пустых или мусорных пакетов увеличивается, они занимают часть пакетной производительности устройства. Вот и получается, что скорость передачи данных через радиоканал вроде большая, pps не сильно проседает, а сквозной поток данных в интернет уменьшается.

 

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

 

Если радиоканал использовать для транзита L2, то на UBNT уже при 100-150 активных маков начинаются потери данных, на микротике то же самое можно получить при 300-500.

[slv700]

чем больше клиентов/маков ходит по радио

Либо я чего-то не понимаю, либо..., но если пофантазировать, то у нас выйдет два микротика, 1. работающих только между собой; 2. по сути там будет на канальном уровне два мака - провайдерский коммутатор и наш шлюз доступа. Какие там могут быть клиенты/маки? Нагрузку будет создавать сетевой уровень и выше.

Деградация пропускной способности канала может быть вызвана большим количеством адресов в MAС таблице бриджинга (L2) - просто не хватает памяти у девайсов да и проц не успевает перебирать все адреса в реалтайме. На аппаратной платформе такого уровня больше 100 маков держать в таблицах не рекомендуется . Хотя многое зависит от загруженности проца и памяти другими операциями, скажем пойдет помеха - увеличиваются очереди на повтор передачи или вечером активировались качки и повысилась нагрузка на проц от торрентов и 50 маков становится много . Поэтому получается что днем канал работает - вечером нет. В этом случае уменьшить нагрузку на бриджинг можно применяя маршрутизацию L3. Это уменьшит количество адресов в MAC таблице и будет фильтром для служебного трафика и мусора.

Но в комменте Saab95 скорее всего речь идет не о 500 маках а о 500 сессиях - что дает высокую пакетную нагрузку на канал и там не имеет значения работа в бриджинге или роутинге.

Чтобы этого не происходило на ответственных каналах с высокой пакетной загрузкой ( а у прова средней руки все каналы связи такие за исключением юзеровских каналов) нужно ставить профессиональное оборудование операторского класса ( ubnt и МТ к нему не относятся).

Серьезный оператор максимум что может себе позволить так это ставить MT точка-точка для бизнес юзеров в удаленных районах, где ставить серьезное оборудование в малтипойнт нерентабельно ( нет достаточного количества клиентов) и где можно себе позволить эксклюзивное выделение 20 Мгц спектра в ptp для каждого одного бизнес клиента.

[Ainy]

Это ппс между между двумя Ethernet одного борда. У МТ core бизнес как раз бытовые роутеры начального уровня и цифра ппс между эзерами им и нужна.

У MIPS тормоз идет на прерываниях проца при обработке интерфейсов wireless miniPCI - ethernet.

А что, при передаче трафика между эзернетами прерывания проца не вызываются?

Там ведь не свич, а 2 независимых PHY, которые висят на разных прерываниях. С точки зрения прерываний - принципиальной разницы нет, ethernet-pci или ethernet-ethernet.

Более того, если в pci слот поставить гигабитный интел, то количество ppc даже выше, чем между встроенными эзернетами.

[Deac]

А Вы простите, сами, это "memo" читали?

Угму. :)

 

Кем оно общепринятое?

IETF

RFC в принципе рекомендации, но по ним все и живут.

 

Адекватный кстати этому мемо, за исключением фильтров (ибо не нужны они, при таком способе подсчета) способ тестирования - использование VoIP test в Ixia Chariot,

Вот ведь!

Охаять RFC и здесь же умиляться, как оно классно в IXChariot-е реализовано. :)

 

Да и сам документ этот 1999-го года рождения, скажем прямо, немного устарел.

Что есть - то есть.

 

Я что-то ни разу не видел, чтобы на сайте routerboard выкладывались протоколы тестирования.

На mikc.ru есть сводка по RB, 45kpps - оттуда.

 

Несколько бордов тестировал сам, в т.ч. и 433AH, данные, полученные при тестах, существенно ниже, чем заявляемые на сайте.

Сколько?

[slv700]

Это ппс между между двумя Ethernet одного борда. У МТ core бизнес как раз бытовые роутеры начального уровня и цифра ппс между эзерами им и нужна.

У MIPS тормоз идет на прерываниях проца при обработке интерфейсов wireless miniPCI - ethernet.

А что, при передаче трафика между эзернетами прерывания проца не вызываются?

Там ведь не свич, а 2 независимых PHY, которые висят на разных прерываниях. С точки зрения прерываний - принципиальной разницы нет, ethernet-pci или ethernet-ethernet.

Более того, если в pci слот поставить гигабитный интел, то количество ppc даже выше, чем между встроенными эзернетами.

То что между эзерами ппс в несколько раз больше чем между mPCI и эзером это факт. Почему так надо спросить у архитекторов Мипса, тормоз проявляется на обработке прерываний ввода-вывода с эзера на варелесс, но причина может быть в чем то другом.

[Ainy]

Сколько?

411AH, 433AH, RB800 (который ни разу не мипс, а вовсе даже PPC)

ни на одном из них повторить данные не получилось.

если у Вас получилось - протокол в студию.

Чем занимается IETF, кроме как принятием STD и фильтрации draft сейчас не подскажете?

Заодно и чем STD отличается от MEMO?

[Deac]

411AH, 433AH, RB800 (который ни разу не мипс, а вовсе даже PPC)

ни на одном из них повторить данные не получилось.

А сколько же получилось?

[Ainy]

То что между эзерами ппс в несколько раз больше чем между mPCI и эзером это факт. Почему так надо спросить у архитекторов Мипса, тормоз проявляется на обработке прерываний ввода-вывода с эзера на варелесс, но причина может быть в чем то другом.

Между эзерами, которые в свиче? Так к ним процессор вообще отношения не имеет при обработке пакетов, там свой fabric, который отдельный чип и в роутербордах его нет кстати, в отличие от других производителей. Если Вы утверждаете, что "это факт", то приводите пожалуйста факты, логи загрузки системы, каунтеры прерываний, где это видно.

При чем тут вообще архитектура MIPS, когда обсуждается конкретная реализация SoC от Atheros и даже не она, а реализация routerboard на базе ее. Причем проблема там действительно есть и она не только на MIPS, но и на PPC.

Где доказательства, что проблема именно в прерываниях и почему эзернет в mPCI слоте дает больше pps, чем набортный?

[Ainy]

411AH, 433AH, RB800 (который ни разу не мипс, а вовсе даже PPC)

ни на одном из них повторить данные не получилось.

А сколько же получилось?

У меня протоколов под руками нет, но цифры были приблизительно одинаковы на MIPSBE и примерно в 5 раз меньше заявки производителя.

На RB800 было примерно в 2 раза больше, чем на 4XXAH. Еще на 433AH были чудеса со скоростью между эзернетами, но это представитель вендора объяснил тем, что там на 2 порта одна сотка, так реализовано.

На бордах(не роутерборд, но тот же SoC 7161) где юзается свич от атерос в дополнения к основному чипсету - результаты существенно выше, даже когда fabric не использовался. Чем объяснить, кроме кривости дизайна у RB я не знаю.

Profiling понятно не делал, возможно проблема и софтовая.

 

Могу предположить, что интел давал лучший результат из-за LRO, HWCKSUM и прочих его аппаратных ускорителей.

[Ainy]

И вообще, с чего это разговор с топика перешел на особенности реализации некоторых платформ? Об этом уже обсуждалось, еще когда я тему про RSPRO поднимал. Чего ее заново откапывать? Атеросовский сок отличный продукт, в своем сегменте, дешевых гейтвеев и вайфаев, к которым относится и RB4XX. А МТ - это решение куда более широкое и кроме RB4XX работает еще на ряде железок, в т.ч. и x86, где ппс можно организовать вполне приемлемый, особенно с учетом современных x86 платформ типа FT1 от AMD. В этой линейке есть 6Вт процессоры значительно превосходящие Geode LX800 к примеру и немного дороже. Да плат пока совсем готовых нету, но АМД предлагает всем желающим бесплатно готовый референсдизайн борда. Который можно кастомизировать и производить под свои нестандартные задачи. Так же есть целый Guide, как мигрировать ваши древние PPC задачи на эту платформу (она и AMD64 поддерживат кстати). Я так думаю что в скором времени таких бордов будет из чего выбирать и там на каждый эзер можно будет получить гарантированный гигабит, а не как на RB1x00. При том что ценник будет не заоблачный и тот же МТ на этом будет работать.

[slv700]

То что между эзерами ппс в несколько раз больше чем между mPCI и эзером это факт. Почему так надо спросить у архитекторов Мипса, тормоз проявляется на обработке прерываний ввода-вывода с эзера на варелесс, но причина может быть в чем то другом.

Между эзерами, которые в свиче? Так к ним процессор вообще отношения не имеет при обработке пакетов, там свой fabric, который отдельный чип и в роутербордах его нет кстати, в отличие от других производителей. Если Вы утверждаете, что "это факт", то приводите пожалуйста факты, логи загрузки системы, каунтеры прерываний, где это видно.

При чем тут вообще архитектура MIPS, когда обсуждается конкретная реализация SoC от Atheros и даже не она, а реализация routerboard на базе ее. Причем проблема там действительно есть и она не только на MIPS, но и на PPC.

Где доказательства, что проблема именно в прерываниях и почему эзернет в mPCI слоте дает больше pps, чем набортный?

Согласен что дело в MIPS и вообще в SOC Atheros в том числе в новом AR7161 собственно не в прерываниях, или возможно не только в прерываниях.

Потому что если взять 1 Ггб эзер установленный в 1000 BaseT то на переходе ethernet -mPCI wireless он увеличивает pps в два раза. Также действительно если поставить 1 Гб эзер в mPCI то также pps в канале ethernet 100 Mb - mPCI ( ethernet 1 ггб) - будет выше чем на wireless mPCI и выше чем у набортном.

Это факты полученные при исследованиях применимости последнего SOC Atheros как перспективной платформы для новых приложений. Задача была получить pps на переходе 1 1ГГб ether -miniPCI ( не важно wireless карты или что то другое ) не менее 50K ( чистых без packing агрегации). Цифра не была достигнута. Почему так себя ведет эта платформа меня особо не интересуют, но именно по этой причине SOC Atheros AR7161 не был нами выбран в качестве базовой платформы для новых разработок.

Общий вывод SOC Atheros - для бытовых девайсов начального уровня - то есть применим только как клиенсткое терминальное оборудование. Для обработки в реалтайме современных мультимедийных приложений и трафика с высокой пакетной нагрузкой в инфраструктуре сети провайдера ( в том числе на бекбонах точка-точка ) это решение не имеет достаточной для этих задач производительности ( по крайне мере там где задействован mPCI ) и увеличение мощности проца и памяти вопрос не решает, поскольку дело совсем в другом ( нам неизвестном).

[Ainy]

увеличение мощности проца и памяти вопрос не решает, поскольку дело совсем в другом ( нам неизвестном).

С такой формулировкой согласен.

[lan-viper]

Итак, всем Большое Спасибо за участие в вопросе. Теперь примерно понятно, на что расчитывать.

Сейчас всё-таки ищем пути для прокладки оптики, если ничего не выйдет, то будем искать б/у радиорелейку. Других разумных вариантов нет. В микротик я не поверил...

[rmika]

А почему MT x86 не обсудили?

[Saab95]

А почему MT x86 не обсудили?

 

Потому что на x86 не работает NV2, а без него максимальная скорость будет на 20% ниже.

[SSD]

А почему MT x86 не обсудили?

 

Потому что на x86 не работает NV2, а без него максимальная скорость будет на 20% ниже.

С чего бы ему не работать?

[Saab95]

С чего бы ему не работать?

 

С сайта микротика:

 

x86 does not currently support Nv2 (requires RouterBOARD hardware) x86 may be supported in the future

[SSD]

С чего бы ему не работать?

 

С сайта микротика:

 

x86 does not currently support Nv2 (requires RouterBOARD hardware) x86 may be supported in the future

http://forum.mikrotik.com/viewtopic.php?t=50460

[Ainy]

http://forum.mikroti...pic.php?t=50460

(Uldis/MT Support)

I would like to clear up some confusion about x86 and Nv2 protocol issues that are mentioned on the download page

Quote:

- x86 does not currently support Nv2 (requires RouterBOARD hardware)

x86 may be supported in the future

 

Nv2 protocol can be enabled on x86 and will allow this setting in the future. We have had less than ten reports of the problems below, so we consider that it may be an issue specific to certain x86 hardware configurations -- but we can not guarantee that you will not encounter this problem. If you must use an x86 device with Nv2 protocol, it is suggested that you test and monitor a device before deploying it broadly through your network.

 

These problems may affect clients and APs, but as far as we can determine the issue only becomes a problem when seen on an x86 AP.

 

We have seen 2 issues with x86 boxes that are using Nv2 wireless protocol on v4.x (with wireless-nv2 package installed), v5.0rcX and v5.X:

1) You will experience unstable performance/disconnections when using x86 router in Nv2 wireless protocol network.

2) We have received reports from clients that their x86 routers hangs/freezes when they use Nv2 wireless protocols on x86 router.

 

About the first issue - it is hardware related and currently we haven't found any workaround for that.

About the second issue, we were unable to reproduce this problem, that is why we haven't found a solution for that.

4.17 оно не отключено и соответсвенно работает как (у некоторых) написано выше. Т.е. у кого-то работает, а у кого-то нестабильно, а еще у кого-то виснет.

А так как под x86 можно подразумевать очень широкий спектр железа, то МТ поступили по простому, отрубили фичу в 5.0. В силу того, что они сами x86 сейчас не выпускают, то и

гарантировать ничего не могут.

[SSD]

http://forum.mikroti...pic.php?t=50460

(Uldis/MT Support)

I would like to clear up some confusion about x86 and Nv2 protocol issues that are mentioned on the download page

Quote:

- x86 does not currently support Nv2 (requires RouterBOARD hardware)

x86 may be supported in the future

 

Nv2 protocol can be enabled on x86 and will allow this setting in the future. We have had less than ten reports of the problems below, so we consider that it may be an issue specific to certain x86 hardware configurations -- but we can not guarantee that you will not encounter this problem. If you must use an x86 device with Nv2 protocol, it is suggested that you test and monitor a device before deploying it broadly through your network.

 

These problems may affect clients and APs, but as far as we can determine the issue only becomes a problem when seen on an x86 AP.

 

We have seen 2 issues with x86 boxes that are using Nv2 wireless protocol on v4.x (with wireless-nv2 package installed), v5.0rcX and v5.X:

1) You will experience unstable performance/disconnections when using x86 router in Nv2 wireless protocol network.

2) We have received reports from clients that their x86 routers hangs/freezes when they use Nv2 wireless protocols on x86 router.

 

About the first issue - it is hardware related and currently we haven't found any workaround for that.

About the second issue, we were unable to reproduce this problem, that is why we haven't found a solution for that.

4.17 оно не отключено и соответсвенно работает как (у некоторых) написано выше. Т.е. у кого-то работает, а у кого-то нестабильно, а еще у кого-то виснет.

А так как под x86 можно подразумевать очень широкий спектр железа, то МТ поступили по простому, отрубили фичу в 5.0. В силу того, что они сами x86 сейчас не выпускают, то и

гарантировать ничего не могут.

Сие действие больше похоже на принудительный перевод народа на роутерборды. Проблемы о которых пишут юзеры с х86 возможны не только из за используемой платформы, а от тех радиокарт которые они используют, и мне кажется что дело именно в этом.

[jdemon]

Ага. А с частотнадзором/конкурентами потом бутылкой коньяка рассчитаются и отлично :)

5GHz пока не освоен.

РОСКОМНАДЗОР лоялен, пока, т.к. нет обращений от лицензиатов, а по собственной инициативе они оч. редко что-то делают.

РКН с недавнего времени не имеет право инициировать проверку, но если придет жалоба даже от физ лица, например с темой что это за хрень стоит на крыше нас облучает %)))), проверка гарантирована.