Низкая скорость одного tcp соединения.

[keypop]

Приветствую всех!

Имеем с одной стороны routerOS на x86 в виде виртуальной машины интерфейс ethernet, с другой CCR1036-8G-2S+ интерфейс sfp+. Эти два роутера соединены через провайдера vpn точка точка. Проблема такая - очень низкая производительность одного tcp соединения: 100-200 Mbit/s при соединении в 1 Gbit/s, если использовать udp, то канал прокачивается на полную катушку. Так же если вместо микротов использовать обычные PC на обеих сторонах, то всё нормуль, одно tcp соединение прокачивает канал на полную. Если вместо btest на микротах ставить за ними PCs и гонять тот же iperf или простой rsync - результат аналогичный. Сразу скажу никаких очередей, никаких ограничивающих правил для данного соединения нет, при загрузке канала cpu практически простаивает на обеих сторонах, в обще ресурсы железа свободны. Interface Queues пробовал на обеих сторонах и only-gardware-queue и multi-queue-ethernet-default, fasttrack connection, результатов не принесло. Ошибок на интерфесах нет при приёме/передаче. Я уже просто разочаровался в микротиках, а ведь такая крутая ОСь. Возможно я просто где-то что-то упускаю или просто не знаю. Прошу помощи.
Всем спасибо. )

[Chupaka]

Версии актуальные на обеих сторонах?

[keypop]

Версии актуальные на обеих сторонах?

x86: 6.40.4
CCR1036: 6.40.5

[Chupaka]

А несколько tcp-потоков заполняют канал нормально? Есть возможность проверить с роутером только с одной (каждой) стороны? С виртуализацией может быть вопрос.

[keypop]

несколько потоков не заполняют канал только слегка увиличивают значение. Тестировал с виртуальным роутером на одной стороне и PC на другой канал прокачивался. Обратную ситуацию не тестировал.

[keypop]

Могу ещё раз провести тесты с обеих сторон, я почему-то грешу больше на routerboard

[Chupaka]

Тогда можно с тестирования CCR и начинать

[keypop]

Результаты такие:

PC ---> CCR
UDP:
Both - Tx: 450 / Rx: 950
Separate - Tx: 800 / Rx: 900

TCP:
Separate - Tx: 320 / Rx: 300


PC ---> x86
UDP:
Both - Tx: 755 / Rx: 980
Separate - Tx: 985 / Rx: disconnect

TCP:
Both - Tx: 935 / Rx: 975
Separate - Tx: 942 / Rx: 980

[Chupaka]

Это всё тесты с компьютера на компьютер через iperf? TCP Btest на сам роутер никогда производительностью не отличался, поскольку использует только одно ядро - именно поэтому для тестирования MikroTik рекомендует использовать всякие Traffic Generator и на других роутерах

[keypop]

btest, тут в данном случае сложно тестировать если у тебя на одном конце роутер на другом PC

[Chupaka]

тут в данном случае сложно тестировать если у тебя на одном конце роутер на другом PC

За роутером - PC, между этими PC и тестировать

[keypop]

да но тут уже добавляем ещё один слой это доп ethernet интерфейс

[Chupaka]

Если результат устраивает - значит, дополнительный слой никакого негативного влияния не оказывает, например

[keypop]

да если бы был свободный eth ))

[Chupaka]

Свободный где?.. На каждом PC нужно по одному... На CCR свободных нет?..

[keypop]

походу придётся придумать как освободить один

[keypop]

Сделал проще, протестировал скорость по локальным интерфейсам на этой железке из подсети в подсеть. И результаты меня просто поразили. Если использовать хотя бы одно правило в ip->firewall->NAT/Mangle скорость обмена данными по одной TCP сессии 1Gbit/300-600Mbit, как только выключаю все правила в nat и mangle, всё становится гуд - имеем 1Gbit/1Gbit. Правила в Nat и Mangle очень простые, их не много, достаточно одного что бы трафик просел (неважно Nat это или Mangle). Похоже что прошивка кривая и с этой архитектурой cpu (TILE) микротики ещё не научились нормально работать.

[Chupaka]

Хм... Рекомендую написать в [email protected] - как-то уж больно подозрительно выглядит, никто на такое, вроде, не жаловался

[4morbo]

keypop, есть новости?