Проблемы с bonding производительностью

Попробуй запускать BT через твои роутеры, а не от роутера к роутеру, потому что BT очень сильно нагружает процессор.

Попробуй провести тест скорости прямо с роутеров. Возможно, узким местом являются сетевые карты твоих компьютеров, особенно если они дешевые или встроенные. —РЕДАКТОР— Только что увидел, что ты упоминаешь 60 Мбит/с. Это часто случается, если ты работаешь в полудуплексном режиме (или, что еще хуже, с несовпадающими настройками дуплекса). Установи все интерфейсы (как на компьютерах, так и на MT) на работу в режиме 100 Мбит/с, полный дуплекс.

Это может быть проблемой. Отключите автоматическое согласование на Mikrotik и ПК, и выберите вручную 100 Мбит/полнодуплексный режим.

Я отключил автоматическую настройку для всех интерфейсов, компьютеров и Mikrotik. Всё работает на 100 мегабит в секунду, полнодуплексное соединение, без автоматической настройки. Повторил тест, и результаты те же (около 55 мегабит в секунду) в TCP-соединении между двумя компьютерами при использовании агрегации на Mikrotik. Спасибо ещё раз.

Ты угадал! Агрегация + TCP = низкая производительность. TCP не любит переупорядочивание пакетов.

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

Мы довольно много экспериментировали с агрегацией (bonding). Натыкались на повторные передачи пакетов, потому что даже несмотря на то, что у 3 кабельных модемов был одинаковый QoS, у них не было абсолютно одинаковых скоростей. Если один из трех пакетов выходит из порядка, ты, по сути, пересылаешь все три, чтобы вернуть их в порядок. Так что 100мб + 100мб канала теоретически равны 200мб, но когда ты добавляешь поверх этого TCP, вероятно, сможешь проталкивать только 66% (из-за накладных расходов на повторные передачи TCP). Вот отличная статья, которая объясняет это намного лучше, чем я могу: http://linux-net.osdl.org/index.php/Bonding “balance-rr - Этот режим является единственным, который позволит одному TCP/IP-соединению распределять трафик по нескольким интерфейсам. Поэтому это единственный режим, который позволит одной TCP/IP-потоку использовать пропускную способность более чем одного интерфейса. Однако это достигается определенной ценой: распределение часто приводит к тому, что удаленные системы получают пакеты не по порядку, что приводит к срабатыванию системы управления перегрузками TCP/IP, часто путем повторной передачи сегментов.” "Для четырех интерфейсных агрегированных соединений balance-rr, ожидайте, что один TCP/IP-поток будет использовать не более чем примерно 2,3 интерфейса пропускной способности, даже после корректировки tcp_reordering." "Если вы используете протоколы, отличные от TCP/IP, например UDP, и ваше приложение может tolerate доставку пакетов не по порядку, то этот режим может позволить масштабировать производительность потока данных near linearly, по мере добавления интерфейсов в агрегат." Мне кажется, что на агрегации MT можно было бы сделать какую-то оптимизацию… но выглядит так, что они взяли ту, что на URL выше, и просто вставили ее в ROS почти как есть. По крайней мере, что-то есть, правда? : )

Спасибо всем за помощь. Посмотрю ссылки и проведу дополнительные тесты.

Совет для MT: Многие хотели бы использовать объединение (bonding), но многие сталкиваются с некорректными замедлениями. Почему бы не реализовать буфер, который переупорядочивает пакеты перед отправкой на интерфейс 'outgoing'? Можно реализовать счетчик на стороне 'sending', а сторона 'receiving' будет использовать этот счетчик для переупорядочивания пакетов. Буфер может быть как маленький – всего один пакет с каждого интерфейса bonding, ведь интерфейс 'transmitting' будет отправлять пакеты последовательно.