Вопрос по теории производительности TCP

[phprus]

Вопрос по теории производительности TCP

Предположим, что у нас есть сеть 10 Gigabit Ethernet, в которой кроме отправителя данных (один) и получателей данных (несколько сотен) никого нет. Маршрутизации тоже нет, есть только коммутация по MAC. Линия связи длинная - сотни км.
В рамках таких исходных данных возник вопрос, возможно-ли эффективно использовать протокол TCP для того, что-бы передать 8-9 Гбит/с данных, используя 10-100 параллельных TCP-сессий?

За неимением такого оборудования и таких линий связи эта задача сугубо теоретическая

Есть и более приближенная к реальности задача, где сеть 1GE, поток 0,8-0,9Гигабит/с, а остальные параметры задачи те же. И опять-же вопрос на сколько эффективно можно использовать TCP, или стоит сразу изучать что-то более высокоэффективное для таких скоростей?

 

[whirlwind]

По одному физическому каналу? (это был ответ) Сугубо теоретически могу предположить что ситуация только усугубится за счет добавления служебного трафа.

 

[dimagolov]

для начала нужно обеспечить источник данных, который был бы в состоянии генерить хотя бы 0,8-0,9Gb трафа и клиенты, которые бу успевали его получать.

про сотни километров вообще не понял. Это что, подводные/подземные кабели с оптикой или что?

п.с. вспомнил анекдот о передаче данных со скоростью 1Тб/сек на расстояние 6м, когда теробайтный винт уронили с 3-го этажа

 

[phprus]

whirlwind
1GE - да канал один. На короткой линии 1GE в тестах был получен результат в 850Мбит/с полезного трафика (служебный не учитывался, никакого тюнинга ОС тоже не проводилось, тестовый стенд был собран на базе обычных десктопов). В теории на длинной линии ситуация должна быть хуже из-за роста RTT по этому и интересуют примерные оценки или ссылки на методики оценки производительности TCP.

dimagolov
Генератор потока порядка гигабита (суммарно) уже есть. На каждый узел приемника будет попадать порядка 100Мбит/с, так как их минимум 10 (соответственно минимум 10 коннектов к источнику трафика).

про сотни километров вообще не понял. Это что, подводные/подземные кабели с оптикой или что?

1GE - это оптика, а уж где ее владельцы ее проложили, это я не в курсе.


Часть вопроса по 10G - сугубо теоретическая. Задача, которую я решаю желательно должна поддерживать такие скорости, даже не смотря на то, что таких каналов связи нет.

 

[Активист]

Однако тебе к строевикам ))

Насколько я знаю, любая производительность прямо зависит от качество и увроня оборудования, а не от протокола. Тысячи км оптики передает ежесекундно гигибайты трафика. Учитывая особенность транстелекомовской сети, помимо коммерческих каналов идет внутренний трафик, не уступающих коммерческому (коммерческий - не только интернет, но и ТВ, связь (телефонная, факсимильная и т.п.).

Под словом
> 10 Gigabit Ethernet
Подразумевается витая что-ли?

Сейчас есть трансокеанические системы с пропускной полосой в 1 терабит в секунду на основе оптики (оптика кстати разная бывает и по уровню затухания, и по скорости и по сроку службы), но оборудование там, совсем другое, и "релейки", и повторители, и усилители и сплитеры и т.п.

-~{}~ 05.11.10 19:13:

То оборудование, которые я "держал в руках" (отец работал в Ростелекоме), которое находится в бункерах - вот они точно способно передавать и не такие объемы трафика.

 

[whirlwind]

phprus так вы определите сначала где конкретно у вас узкое место. Мы около гигабита на стрестестах тоже забивали десктопами. Если у вас интерфейс который в канал смотрит не в состоянии больше выдать на линию, то хоть сто, хоть мульен коннектов сделай, он больше никак не выдаст. Надо искать железки соответствующие. Я знаю что есть такие железки которые нескольким физическим каналам прозрачно траф гоняют как по одному сегменту и за счет этого увеличивают пропускную способность, но пытаться это решить коннектами это примерно как в дюймовую трубу соломинок напихать и пытаться больше чем без соломинок воды прокачать. Реально?

 

[phprus]

Активист
Качество оборудования, особенности телекомовской сети, внутренний трафик, трансокеанические системы - это вопрос из одной плоскости.

Мой вопрос из другой плоскости. Полоса есть, оборудование тоже (это не наша задача). Но между полосой и приложением 3 слоя OSI, которые не должны съесть больше чем хотелось бы, а могут (медленный старт в TCP может на скорости отрицательно сказаться).

Под словом
> 10 Gigabit Ethernet
Подразумевается витая что-ли?

Под словом 10GE подразумевается полоса в 10 Гбит/с. За отсутствием оной я не могу сказать как она может быть устроена. По этому эта часть вопроса сугубо теоретическая.

whirlwind
Распишу задачу поподробнее, откуда возникли соломинки.
Есть источник данных, на котором N раз в секунду возникает блок в M мегабайт. На другой стороне стоит кластер, в котором минимум (20 - 30)*N процессорных ядер. Каждый блок в M мегабайт необходимо доставить на любое свободное ядро. Расчет каждого блока выполняется некоторое время, но количество ядер подобрано так, чтобы в каждый момент времени было минимум одно свободное ядро, которое может скачать и начать обрабатывать очередной блок данных.

Отсюда и возникают эти трубочки в виде набора сессий к источнику данных от кластера, только малая часть из которых активна в каждый момент времени.

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

То, что больше трубы не прыгнуть это понятно, но это и не нужно.

P.S. У нас есть полоса (1Гбит/с) и есть железо. Надо эту полосу эффективно занять. А вот с этим уже возникают реальные проблемы.

 

[whirlwind]

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

 

[phprus]

whirlwind
Так этим и занимаемся. Интересен опыт на сколько смогли дотюнить стек другие специалисты . И есть ли теоретический предел эффективности. (Может-быть на таких задачах стоит искать более приспособленные для этого решения, чем универсальный TCP на транспортном уровне)

 

[Активист]

Насколько я знаю из тоутарилов по IPTables сам по себе TCP IP имеет следующих характер

SYN -> ACK/SIN -> ACK + масса флагов, в любом случае идет двусторонняя связь между отправителем и получателем по установки флагов и стейтов (защита от потерянных пакетов). Если пакет большой, отправитель один то можно UDP слать, который в свою очередь направить на широковещатель в назначенной точки, тот в свою очередь, переадресует этот трафик куда надо (на все ядра или на свободное ядро).

В контексте 2 - широковещатель - некоторая машина, которая знает о загрузки каждого нода и ядер этих нодов (количество ядер, текущая загрузка) и определяет получателя, либо аккумулирует пакеты для дальнейшей передачи освободившемуся ноду, в случае их занятости (гарантирует обработку пакетов).

Один большой минус UDP - то что отправка пакета не гарантирует его получения.

Если говорить о специфических протоколов (а таких много, тот же Verturi для радио оборудования, кстати. насколько я помню, взят UDP за основу) - то тут лучше к спецам.

-~{}~ 05.11.10 21:06:

Кстати, экономическая целесообразность использования узконаправленных протоколов под большим вопросом

-~{}~ 05.11.10 21:20:

Т.е. смысл задачи такой?

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

Собственно это и есть UDP. Если взять сисковский принцип Netflow, то Netflow есть пушка, Flow Calculate - есть приемник, источник не волнует, что произошло с пакетом.

 

[dimagolov]

Кстати, сегодня узнал что есть высокопроизводительные решения для гарантированной доставки сообщений: http://en.wikipedia.org/wiki/Solace_systems

 

[phprus]

Активист
Доставка обязательна и без ошибок, по этому чистый UDP не подойдет. На самом деле результат расчета возвращается назад к источнику, но там поток такой мизерный, что особых проблем он не принесет.

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

 

[Активист]

dimagolov
Дороговато однико выйдет.

Если говорить о теории, например, взяв устройства на основе FDDI (я думаю так и есть), 4500 MTU и UDP, учитывая одно направление потока, то вычислим КПД.

1. 1 Gbit/s = 0.125 гб/сек = 128 мб/сек = 131072 кб/сек = 134217728 б/сек

2. На каждые 4500 октетов приходится 28 служебных байт, отсюда датаграмма равна 4472 октета (байта).

3. Всего за секунду может быть передано - 29 826 пакетов (4500 MTU).

4. Соответственно служебной информации в них будет содержаться 835 128 байт.

5. Простая пропорция и получаем КПД 99,3777%, что очень неплохо

-~{}~ 05.11.10 21:54:

phprus
Про UDT я ничего не слышал)) Главное, что бы оборудование поддерживало.

-~{}~ 05.11.10 22:00:

Да, мои расчеты в теории.
Устройство FDDI (максимальное MTU на сегодня) должно получить по внутриним каналам данные от скорее всего Ethernet устройств с MTU 1500 (что на 3000 меньше), далее склееть и отдать в оптику, ресивер должен это все взять и расклить на более мелкие пакеты с MTU 1500 и отдать дальше.

Конечно, КПД можно повысить в двух случаея, если источников на FDDI устройство много (группа серверов или ряд сетевых интерфейсов отдает трафик) и соттвественно после ресивера - пакеты получает ряд серверов или несколько сетевых.

-~{}~ 05.11.10 22:03:

Да, процесс склейки и расклейки - это и процессор, которые вычисляет CheckSum пакета.

Быть можем экономим на спичках?

 

[phprus]

Активист

Про UDT я ничего не слышал)) Главное, что бы оборудование поддерживало.

Он поверх UDP работает. И реализует свои средства контроля доставки, управления потоком и т.д.

Быть можем экономим на спичках?

Анализ физического&канального уровня это да, так как их не изменить. Сетевой уровень (IP) тоже фиксированные накладные расходы дает.

А вот протоколы транспортного уровня, гарантирующие доставку (TCP) уже не только количеством байт заголовков определяются, но и алгоритмами управления потоком и контроля доставки. Вот тут уже не спички, а возможные грабли.
И именно этот уровень я изначально хотел обсудить, не вдаваясь в то, что лежит ниже, так как нижележащее детерминировано, да и часто уже есть как данность.

 

[Активист]

phprus
Т.е. этот протокол поддерживается на аппаратном уровне или же на софтовом?

Вообще, вариант того, что в процессе передачи потока произойдет ошибка - низка.

Если говорить о теории, то.

Т.е., взять за основу минимальный MTU в сети - 1500, на уровне ядра переписать драйвер, и организовать такой процесс передачи потока:
1. Посылается первый пакет, в датаграмме которого лежит сумма следующего пакета.
2. Далее, в начале каждой датаграммы лежит сумма следующего пакета, и сам пакет.
3. Получатель получает по порядку пакеты, если сумма пришедшего пакета отличается от ожидаемого, то отправителю (асинхронно) посылается пакет, содержищий номер ошибочного пакета и порт источник, на основе этого - поток восстанавливается на ошибочном пакете.

Ну как-то так.

Хотя я думаю, есть уже подобные реализации.
Время будет - надо почитать про этот протокол (UDT).

-~{}~ 05.11.10 22:45:

У TCP да, алгоритм управления потоком сложный и накладный.

 

[phprus]

Активист

Т.е. этот протокол поддерживается на аппаратном уровне или же на софтовом?

UDT софтовый.

Хотя я думаю, есть уже подобные реализации.

TCP, UDT работают по похожему принципу. Правда переписывать драйверы и работа на уровне ядра - излишняя сложность.

Время будет - надо почитать про этот протокол (UDT).

"UDT is built on top of User Datagram Protocol (UDP) by adding congestion control and reliability control mechanisms. UDT is an application level, connection oriented, duplex protocol that supports both reliable data streaming and partial reliable messaging." - http://en.wikipedia.org/wiki/UDP-based_Data_Transfer_Protocol

 

[fixxxer]

1) Какой размер одного пакета данных?

2) Важен ли их порядок?

 

[phprus]

1) Какой размер одного пакета данных?

Пакета на каком уровне? Если под пакетом понимается неделимый блок данных прикладного приложения, то его размер 8 - 50 Мб.

2) Важен ли их порядок?

Порядок доставки блоков прикладной задачи не важен.

 

[dimagolov]

а каково время обработки блока на ноде?

 

[phprus]

а каково время обработки блока на ноде?

От медленно до очень долго. Сейчас быстрый алгоритм работает секунд 15. То, что будет применяться реально будет работать минуты. По этому этих нод по другую сторону запущено много, по этому и соединений много, но большая часть простаивать будет.

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