Разработчики расширения MultiPath TCP (http://multipath-tcp.org/) для ядра Linux побили рекорд скорости на самую большую пропускную способность, которую удалось продемонстрировать в рамках одного TCP-соединения. В рамках проведённого эксперимента
удалось достичь (http://multipath-tcp.org/pmwiki.php?n=Main.50Gbps) пропускной способности 51.8 Гбит/с при передаче данных через одно TCP-соединение. При такой скорости для передача содержимого DVD достаточно 1 секунды, а диска Blu-Ray (25GB) - 5 секунд.
Технология Multipath TCP (RFC 6824 (http://tools.ietf.org/html/rfc6824)) позволит организовать работу TCP-соединения с доставкой пакетов одновременно по нескольким маршрутам через разные сетевые интерфейсы, привязанные к разным IP-адресам. Со стороны приложений подобное агрегированное соединение выглядит как обычное TCP-соединение. Multipath TCP может использоваться как для увеличении надёжности, так и для расширения пропускной способности. В качестве одного из практических применений Multipath TCP для обычных пользователей упоминается возможность организации передачи данных на смартфоне, с использованием одновременно линков WiFi и 3G. Для серверных систем Multipath TCP может обеспечить сокращение расходов за счёт использования нескольких дешевых линков вместо одного более дорогого.
Для достижения скорости 51.8 Гбит/с в эксперименте были использованы два сервера HP DL380p G7 с шестью 10 гигабитными Ethernet интерфейсами в каждом (три двухпортовых адаптера Intel 82599EB). Конфигурация ядра Linux была подвергнуто тюнингу (http://multipath-tcp.org/data/10gig/config_file), учитывающему особенности используемой серверной платформы. Был настроек (http://multipath-tcp.org/data/10gig/client_script.sh) режим Receive-Flow-Steering (https://code.google.com/p/kernel/wiki/NetScalingGuide), для каждой сетевой карты MTU был установлен в 9000, tx-queue в 500, включена поддержка jumbo-кадров, настроена слитная обработка серии прерываний, обработка прерываний для каждой карты привязана к отдельному CPU, существенно расширены размеры буферов для стека TCP/IP (максимальный размер буфера выставлен в 200 Мб), выбран алгоритм контроля перегрузки cubic.
После установки соединения с использованием утилиты netperf на первом этапе был задействован только один интерфейс и система показала максимально возможный предел для классического TCP-стека. После этого не разрывая соеденения для оставшихся интерфейсов была включена поддержка Multipath TCP и система автоматически расширила канал связи с использованием появившейся мощности, доведя в итоге пропускную способность до 51.8 Гбит/с.
<center><iframe width="640" height="360" src="http://www.youtube.com/embed/VMdPI9Cfi9k?rel=0" frameborder="0" allowfullscreen></iframe></center>URL: http://multipath-tcp.org/pmwiki.php?n=Main.50Gbps
Новость: https://www.opennet.ru/opennews/art.shtml?num=36495
Имея такой линк лет 15ть назад предложение 'скачать Интернет' не показалось бы такой уж шуткой.
Да ладно, гугл вон и сейчас имеет копию всего интернета
Теоретически вообще весь интернет можно спокойно уместить на одном танкере.
http://what-if.xkcd.com/23/
Если учесть сколько у гугла датацентров, то у него не одна, у него много копий интернета.
Вы не скачаете, и не поместите "на одном танкере" даже<?
echo($_GET['input']);
?>Если будете опрашивать классическим способом.
> Если будете опрашивать классическим способом.Оно разгонится до 51 Гбит? :)
Кругом пишут, что Гуглом сохранено 0,004% интернета. Понятия не имею откуда такие сведения, но вот так.
Так ведь гугл сканирует только web, разве нет?
А mail, nntp, и прочие разумеется не сохраняются.
Также я смекаю, что зеркала всех ftp-серверов гугл также не утруждает себя делать.
Ну как это? Ньюсы и группы сохраняются ессно. А майлы ваши три года сохраняются согласно приказу Гестапо
> Кругом пишут, что Гуглом сохранено 0,004% интернета. Понятия не имею откуда такие
> сведения, но вот так.Так гугл не хранит интернет. Он хранит индексы. Несколько разная вещь. Хранить интернет пытается wayback machine. Но в последнее время они IIRC жаловались на нехватку мощностей... :)
неа. в кэш попадает далеко не всё.
Кому не лень подсчитать - с какой скорость номера acl/seq переполнятся - меньше чем 2 * MSL или нет ? :)
> В качестве одного из практических применений Multipath TCP для обычных пользователей упоминается возможность организации передачи данных на смартфоне, с использованием одновременно линков WiFi и 3Gзашибись юз-кейс. Ускорим скачку на процентов 5-8 выработав литит безлимита в 3g или заплатив за это бабки.
> зашибись юз-кейс.На самом деле - великолепный юзкейс. Прикиньте, прозрачное переключение между интерфейсами без разрыва соединений. Очень мило. Используется все что может использоваться. А переключение на ходу. По сути - этакий роуминг но для TCP соединений.
переключение это прикольно, но там вроде не сказано про это. По крайней мере, не увидел в их презенташке будет ли оно вообще работать. И тем не менее, проблема не проходит, даже с просто переключением можно влететь на бабки или убить лимит.
> переключение это прикольно, но там вроде не сказано про это.Как не сказано? Сказано что оно при появлении доп. интерфейсов начинает их юзать, динамически. Могу предположить что при отваливании части интерфейсов оно просто деградирует по скорости и начинает юзать то что осталось. По крайней мере это было бы чертовски логично, раз оно на горячую их подхватывает.
> переключением можно влететь на бабки или убить лимит.
Вопрос кретинизма в тарификации некоего провайдера, меряющего трафф пипеткой - не проблемы протокола. Это ваши проблемы и проблемы вашего провайдера.
>Могу предположить что при отваливании части интерфейсов оно просто деградирует по скорости и начинает юзать то что осталось.именно так там и написано - применения для серверов повышение надежности при неисправном сетевом интерфейсе разрыва соединения не происходит, что очень и очень круто. следующий шаг менять сетевухи без остановки сервера.
> следующий шаг менять сетевухи без остановки сервера.Это предыдущий шаг - PCI hot-plug.
> следующий шаг менять сетевухи без остановки сервера.А вот это сто лет как можно. Даже кулеры и блоки питания можно. Двигаем виртуалку/контейнер на соседний хост, тушим старый хост, меняем все что надо. Никто и не заметит что вообще что-то происходило, если правильно обыграть живую миграцию.
Так вся и фишка в том, что используя эту технологию + pci hot-plug можно никуда не мигрировать.
а что, в линуксах так до сих пор нельзя сделать чтоли? boud чтоли только для агрегации?;)
вот во фре, например:lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 00:26:82:3c:da:2a
inet 192.168.9.150 netmask 0xffffff00 broadcast 192.168.9.255
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
media: Ethernet autoselect
status: active
laggproto failover lagghash l2,l3,l4
laggport: wlan0 flags=0<>
laggport: alc0 flags=5<MASTER,ACTIVE>
вытащу патчкорд - переключится на wifi, соединения не порвутся. функционалу 100лет в обед.
> а что, в линуксах так до сих пор нельзя сделать чтоли? boud
> чтоли только для агрегации?;)там ограничения с мак адресами как я понимаю и соответственно трах с wlan. boud в линуксе есть и давно.
> там ограничения с мак адресами как я понимаю и соответственно трах с
> wlan. boud в линуксе есть и давно.Бондинг то там есть. Вот только осталось придумать как при этом с разными внешними айпи от разных провайдеров сделать "одно более быстрое соединение" к "вон тому хосту в интернете". Через разные костыли и подпорки - можно, конечно, изгальнутся. Но тут на себя все это взяли расширения протокола. Протокол сам попробует поднять добавочные туннели, максимально закосив при этом под стандартный TCP для минимизации проблем с промежуточными узлами.
> разным IP-адресам
все линки под аггрегацией должны вести в один свитч. Более того, в случае 802.3ad свитч еще и должет об этом знать.
IPMP об другом.
> вытащу патчкорд - переключится на wifi,А там оно не "переключается" а динамически использует все что доступно. Ну то-есть было 2 интерфейса - юзались два. Поднялось еще три - траффик пошел по пяти интерфейсам. Упало два интерфейса - траффик идет по оставшимся трем. Крутота.
> прозрачное переключение между интерфейсами без разрыва соединенийСам по себе малтипасинг - боян, стоит поинтересоваться как аггрегируются малтипасинговые LUN`ы с многопортового SAN`а на тазике со многими же FC-портами.
С другой стороны - а как же NIC тиминг/бондинг/агрегейтинг в Линухах? Оно ж то же самое делает! :)
> стоит поинтересоваться как аггрегируются малтипасинговые LUN`ы с многопортового SAN`а на тазике со многими же FC-портами.СОВЕРШЕННО иначе.
Сначала импортируются все девайсы как самостоятельные scsi luns, потом -- если включен MPxIO -- делается SCSI INQ на page 0x83 и все, что имеет одинаковый ID, считается одним и тем же девайсом.Ни с бондингом, ни с IP MP это не имеет ничего общего.
> Сам по себе малтипасинг - боян,...но в данном случае очень уж идея красива и почти не требует лишних приседаний от админа.
подскажите чем это лучше бондинга?
> подскажите чем это лучше бондинга?Тем что могут без гемора юзаться 2 разных прова например. И через обоих полетит трафф.
Бондинг требует агрегации на ближайшем к тебе управляемом оборудовании. А здесь, насколько я понял агрегация идет на уровне TCP, а не на уровне 2 и агрегируют две конечные точки (клиент и сервер), а километры проводов и тонны оборудования по середине не имеют значения.
> Бондинг требует агрегации на ближайшем к тебе управляемом оборудовании. А здесь, насколько
> я понял агрегация идет на уровне TCP, аИменно. Динамически согласуется подъем дополнительных туннелей через иные endpoint'ы (т.е. пары ip:port). При этом протоколец совершенно не смущает что у обоих хостов это могут быть разные сущности, не имеющие ничего общего с начальным соединением. Для подтверждения что вон тот поток данных это то же самое что и начальный - используется некий рандомный ключик, туннели досогласуются динамически, максимально кося под "просто TCP". В случае полного неуспеха оно просто становится совсем обычным TCP. Более того - оно по идее может переживать даже прохождение через NAT и firewall, в протоколе предусмотрено наличие таковых сущностей. В общем сделано довольно-таки разумно и с пониманием сетевой проблематики в целом.
Не совсем понятно: сетевые карты на интерфейсе PCI-E 2.0, который имеет пропускную способность 5Gb/s - умножаем на 8 - получаем 40GBit/s.Как получилось выйти за скорость шины?
> Не совсем понятно: сетевые карты на интерфейсе PCI-E 2.0, который имеет пропускную
> способность 5Gb/s - умножаем на 8 - получаем 40GBit/s.PCIe v2.0 (5.0GT/s)
> Как получилось выйти за скорость шины?
1) PCI Express speed is defined in terms of Transfers, not Bytes, or bits.
один PCI-E x16 это 128Gbit/s, таких портов может быть несколько на крутой материнки, именно два честных x16
> в рамках одного TCP-соединения
> с доставкой пакетов одновременно по нескольким маршрутам через разные сетевые интерфейсы, привязанные к разным IP-адресам.Дада, разные айпи адреса и при этом одно соединение. Первое апреля через неделю.
http://tools.ietf.org/html/rfc6824
Достаточно даже заголовок прочитать "TCP Extensions for Multipath Operation with Multiple Addresses"
Бред. Коннектов будет как минимум столько, сколько айпи адресов используется, если проснифить трафик в езернете между точками обмена.
> Бред. Коннектов будет как минимум столько, сколько айпи адресов используется,Так этот кульный протоколец на ходу досогласует дополнительные субпотоки-туннели, нисколко не смущаясь тем фактом что у них назначения отличаются. Для соотнесения с начальным потоком используется некий рандомный ключ-идентификатор. По факту для стороннего наблюдатедя это будет выглядеть как несколько TCP соединений, протокол пытается сделать так чтобы добавочные туннели максимально косили под просто еще 1 TCP соединение.
Ну так это факта не отменяет. что НЕ в рамках одного соединения, а нескольких, пусть даже "субпотоки" называются.
> Ну так это факта не отменяет. что НЕ в рамках одного соединения,
> а нескольких, пусть даже "субпотоки" называются.Смотря что считать соединением. С точки зрения софта - соединение одно. С точки зрения полета пакетов по интерфейсам, один логический поток распилен на субпотоки. Софт про это может вообще ничего не знать и думать что это одно TCP соединение. А может и знать, если хочет.
> Дада, разные айпи адреса и при этом одно соединение.Beyond your wildest imaginations. Именно так. Вы знаете, в этом мире оказалось возможным очень много из того что считалось "невозможным" или "сказочным".
оказывалось, оказывается и будет оказываться
Отличная же новость. Сразу представляю шлюз на весь подъезд, подключенный сразу к нескольким провам на внешку.
это, кстати, может не везде работать.
Тут речь идет про одно TCP соединение вообще-то, при чем тут подъезд вообще?
> Тут речь идет про одно TCP соединение вообще-то, при чем тут подъезд
> вообще?А подумать уже не в моде?.. Их что, этих TCP-соединений, не может быть параллельно несколько с одного и того же адреса, или, в данном случае, набора адресов?
Ну, и еще можно внимательнее прочитать статью:> Multipath TCP может обеспечить сокращение расходов за счёт использования нескольких дешевых линков вместо одного более дорогого.
Видимо не в моде, потому что новость о том, чтобы по ОДНОМУ TCP соединению передать огромный объем данных за короткое время, используя множество каналов передачи данных. И эта технология должна поддерживаться на стороне сервера тоже. А учитывая, что сайты в подавляющем большинстве отдают данные на скорости меньше мегабита для каждого соединения, какой в этом смысл то? Я повторю, смысл в технологии в том, чтобы все достыпные ресурсы всех доступных каналов передачи данных слепить в кучу и обеспечить одно быстрое соединение.
На сколько я понял из новости на обратной стороне должна быть такая же машинка
> На сколько я понял из новости на обратной стороне должна быть такая же машинкаЗачем? /dev/null рулит! :)
> На сколько я понял из новости на обратной стороне должна быть такая же машинкаТам должна быть машина с таким же MPTCP, что логично.
А без Multipath оно так может?
> А без Multipath оно так может?Есть сетевушки на 40Gb/s
> Есть сетевушки на 40Gb/sВ разработе вроде и сотки уже [опять].
>> Есть сетевушки на 40Gb/s
> В разработе вроде и сотки уже [опять].Вот, кушайте, - 16 портовый 100 гигабитный роутер
http://www.juniper.net/us/en/products-services/routing/t-tx-.../Эксперименты уже идут на терабитном езернете.
>>> Есть сетевушки на 40Gb/s
>> В разработе вроде и сотки уже [опять].
> Вот, кушайте, - 16 портовый 100 гигабитный роутер
> http://www.juniper.net/us/en/products-services/routing/t-tx-.../
> Эксперименты уже идут на терабитном езернете.Кушает почти 12 киловатт. Жуть :)
Старьйо =) и оно насколько я помню чисто P устройство.
> Есть сетевушки на 40Gb/sЕсть инфинибанд и есть интегрированные -- 4x10g в одном QSFP порту. Суешь туда QSFP to MPO трансивер, то же самое в соседнюю машину, соединяешь кабелем и настраиваешь бондинг.
> соединяешь кабелем и настраиваешь бондинг.Только вот через интернет работать не будет. Сущая фигня.
А то что в новости через интернет что ли работает на ~50Гб? Или это тоже фигня?
> А то что в новости через интернет что ли работает на ~50Гб?Так там нет никакого бондинга. Там MPTCP сам себе "бондинг".
ещё раз, помедленнее. вот то что в новости тестировалось в интернете? тестовые версии на 6 прямых проводах как-то не интересуют.
> ещё раз, помедленнее. вот то что в новости тестировалось в интернете? тестовые
> версии на 6 прямых проводах как-то не интересуют.В новости - может и ничего. Но протокол в целом - максимально заточен на то чтобы спокойно пролетать через интернет несколькими разномаршрутными потоками.
Тогда в данный момент никакой разницы с бондингом. И вот это "Только вот через интернет работать не будет. Сущая фигня" не в кассу.
А смысла в этой балалайке я лично не вижу. Сервак надо напрямую втыкать в провов, без всяких бгп и прочих радостей жизни, это только тсп. Дальше вот есть два прова брень-телеком и хрень-телеком. А оба они покупают полосу у дрянь-телеком. Вот уж отличное решение гнать по этому протоколу данные. Проще с чем-то наподобие торента заморочится.
> Только вот через интернет работать не будет. Сущая фигня.Вопрос был "сетевушки", а не "через интернет". Надо уровни OSI различать, да?
> А без Multipath оно так может?Если бы проблемы не было - зачем бы люди стали RFC писать? :)
>> А без Multipath оно так может?
> Если бы проблемы не было - зачем бы люди стали RFC писать?Ну а почему бы не устроить МногоПуть на десяти 100-гигабитных сетевушках?
> Ну а почему бы не устроить МногоПуть на десяти 100-гигабитных сетевушках?Теоретически наверное ничему не противоречит. Практически - это потребует какой-то весьма неординарной машины. И кроме того - что в таких объемах слать по TCP соединению?
>> Ну а почему бы не устроить МногоПуть на десяти 100-гигабитных сетевушках?
> Теоретически наверное ничему не противоречит. Практически - это потребует какой-то весьма неординарной машины.4-процессорный, 128-ядерный IBM Power7 справиться. (чуть больше 1 ТераФЛОПа выдаёт.)
> И кроме того - что в таких объемах слать по TCP соединению?
- Какой-нить RAID массив на пару петабайт перекачивать туды-обратно. =)
- Кстати, в курсе что гугл торгует своим кэшем? Терабайт стоит в районе 25000$
- Например дамп трафика по Москве занимает около 10 терабаб в день!
(на самом деле больше, там какие методы фильтрации, выборок и сжатия, rutracker никому не упёрся)
Каким образом гугл перехватывает трафик по Москве?
> Каким образом гугл перехватывает трафик по Москве?Не прикидывайся дебилом - все и так это знают.
> Каким образом гугл перехватывает трафик по Москве?Строки нужно читать линейно, слева-направо, а не в шахматном порядке или по рандому.
> Строки нужно читать линейно, слева-направоа нет ли в этом комментарии антисемитизма?
А как же обмен данными между Россией и Японией по всего лишь одному оптиковолоконному кабелю? Слухи врут?
Это о другом.
В одном оптоволоконном кабеле далеко не одна пара волокон для передачи данных.
> А как же обмен данными между Россией и Японией по всего лишь
> одному оптиковолоконному кабелю? Слухи врут?Ну например http://ru.wikipedia.org/wiki/%D0%A1%D0%B...
покажите мне девайс, который за секунда читает весь ДВД-диск
например iso на tmpfs смонтированный на loop :P
Загрузил ты анона - он теперь судрожно ищет в меню "Пуск" конпочку tmpfs.
> покажите мне девайс, который за секунда читает весь ДВД-дискRAM-диск. Вопросы? :)
Хорошая у Вас рама.
> Хорошая у Вас рама.Так а эээ... >10Gb/s и объём в три дивидюка по нынешним временам никаких таких проблем не составляет.
> Хорошая у Вас рама.Она уже много у кого хорошая. Несколько лет как.
Когда же в домашнем интернете появится хотя бы гигабит?!...
запросто, ток цена врят ли устроит... хотя где то уже начинает появляться, ток в локалку как правило.
Зачем? у меня 3 телевизора даже для FullHD 100Мб хватит, про сёрфать я думаю и говорить не стоит
Такой сказочник...
http://ru.wikipedia.org/wiki/MPEG-2
> Зачем? у меня 3 телевизораДяденька, мы не грабители, поэтому нам пофиг сколько там у вас телевизоров.
> Когда же в домашнем интернете появится хотя бы гигабит?!...У меня на домашнем серваке на антрисольке несколько сайтов и канал 80Mbit
Исходящего трафика в неделю более 45 гигов
А зачем домашним хомякам больше теоретических 100 ???
> Исходящего трафика в неделю более 45 гиговВсего? Я как-то ради интереса seed'анул исохи убунты торентом - посмотреть сколько черех хороший канал можно пропихнуть, etc. За месяц получилось 1.2Тб. Канал был 50Мбит. Впрочем, загрузка была далеко не полная: невзирая на сотни пиров они не всегда могут столько траффа сожрать. Далее я все-таки скостил потребление траффа, т.к. генерить прову столько траффика на постоянной основе все-таки не совсем правильно.
> А зачем домашним хомякам больше теоретических 100 ???Ты слышал что-нибудь о 4К телеках, H265 и 3D ?
> Когда же в домашнем интернете появится хотя бы гигабит?!...В украине, в неск обл центрах есть. При чем по вполне гуманной цене порядка 10 евро.
>> Когда же в домашнем интернете появится хотя бы гигабит?!...
> В украине, в неск обл центрах есть. При чем по вполне гуманной
> цене порядка 10 евро.Странно, я думал так везде...
> Когда же в домашнем интернете появится хотя бы гигабит?!...В подъезде уже несколько лет доступно, цены не совсем домашние, но и не заоблачные. Кажется, теперь даже от более чем одного прова. Киев.
>> Когда же в домашнем интернете появится хотя бы гигабит?!...
> В подъезде уже несколько лет доступно, цены не совсем домашние, но и
> не заоблачные. Кажется, теперь даже от более чем одного прова.
> Киев.На Украине всегда интернет дешевый. Потому что там его много.
> На Украине всегда интернет дешевый. Потому что там его много.дык у москалей крадут. вместе с газом.
Не-а, это франкфуртский байтопровод где-то с 2005.
> Не-а, это франкфуртский байтопровод где-то с 2005.Транзитные байты из москвы в дойчляндию откачиваете для собственных нужд? :)
>> Не-а, это франкфуртский байтопровод где-то с 2005.
> Транзитные байты из москвы в дойчляндию откачиваете для собственных нужд? :)с байта по биту — и уже навар.
> с байта по биту — и уже навар.А, так вот кто виноват в семибитных байтах и нужде ююков на древних каналах! Теперь мы знаем куда делся старший бит! Ростелеком обязан потребовать выплат от Украины за такое безобразие :).
О Google Fiber не слышали? А зря.
дорогое / нетехнологическое
> дорогое / нетехнологическоеВ какой это вселенной $70 за симметричный гигабит дорого или не технологично?
> В какой это вселенной $70 за симметричный гигабит дорого или не технологично?Вообше, 70 баксов - это довольно много. Это весьма высокий ARPU. Хотя для гигабита достаточно неплохо, да.
А в это время intel спонсирует netmap
http://info.iet.unipi.it/~luigi/netmap/
Во freebsd уже есть, доступно и для линукса.With netmap, it takes as little as 60-65 clock cycles to move one packet between the user program and the wire. As an example, a single core running at 900 MHz can generate the 14.8 Mpps that saturate a 10 GigE interface. This is a 10-20x improvement over the use of a standard device driver.
Знающие, я правильно понимаю, что пока эту RFC не поддержит хотя бы процентов 80 интернета, юзать ее можно будет только в своих песочницах? Или это расширение совместимо с существующими реализациями стека?
> Знающие, я правильно понимаю, что пока эту RFC не поддержит хотя бы
> процентов 80 интернета, юзать ее можно будет только в своих песочницах?Вообще прозрачно для провайдеров.
Они только будут окуевать, - "чёй-то сайты на четверть загружаются и файлы не докачиваются" :)
>> Знающие, я правильно понимаю, что пока эту RFC не поддержит хотя бы
>> процентов 80 интернета, юзать ее можно будет только в своих песочницах?
> Вообще прозрачно для провайдеров.
> Они только будут окуевать, - "чёй-то сайты на четверть загружаются и файлы
> не докачиваются" :)Для провайдеров - согласен. Но сайты-то должны это уметь?
> Но сайты-то должны это уметь?Ну да. Хотя дарю идею: если есть быстрый хост в интернете - так можно попробовать заапгрейдить скорость и надежность своего интернета. Пульнуть туда нечто типа опенвпн, который размажется на несколько каналов. Возможно наступит профит.
>> Но сайты-то должны это уметь?
> Ну да. Хотя дарю идею: если есть быстрый хост в интернете -
> так можно попробовать заапгрейдить скорость и надежность своего интернета. Пульнуть туда
> нечто типа опенвпн, который размажется на несколько каналов. Возможно наступит профит.squid можно поставить! ФСБ будет в шоке - человек делает GET запрос к сайту, и уходит ;)
Прямоугольная идея со скругленными краями. Срочно патентуйте.
ребята изобрели SCTP?
До sctp им еще как раком до австралии 8(
> До sctp им еще как раком до австралии 8(Что хорошо. Они обошлись без оверинжиниринга и сделали максимально совместимо с TCP. Даже фаеры и наты постарались учесть.
> настроена слитная обработка серии прерыванийИмеется ввиду NAPI ? http://lwn.net/Articles/30107/
я думал поллинг давно используется по умолчанию
Polling'гом это во FreeBSD называется. Оно там настраиваемое.
В Linux - NAPI. Не настраиваемый. Либо работает, либо нет, зависит от драйвера сетевой карты
> Polling'гом это во FreeBSD называетсяпричем правильно отображает суть, а про NAPI я по-больше вас знаю ;-)
Я и не спорю, я согласен с вами.
Сорри за офтоп, а какую максимальную скорость можно получить в винде?
> Сорри за офтоп, а какую максимальную скорость можно получить в винде?Тут это всем до балды, имхо. Привыкните уже к тому что ваша винда - это сухой корм для хомячков. В силу своей закрытой природы и общей враждебности к модификации системы - инноваций в ней нет и не будет, даже и не надейтесь.
мдаа.. на виндус сервер 2008 эр2 такая скорость даже и не снилась
Винда не годиться для серверов шлюзов
винда просто не годится.
> мдаа.. на виндус сервер 2008 эр2 такая скорость даже и не сниласьБолее того - когда линуксные девайсы начнут массово роумиться между разными типами сетей, прозрачно переходя на различные типы каналов "по обстановке" без каких либо отвалов соединений, виндузятники будут лишь завистливо скрипеть зубами и доказывать что линукс сакс. Потому что... потому что у них кишка тонка так же, а это вызывает попаболь :)
"Вдохновившись достиженим разработчиков расширения MultiPath TCP, инженеры Windows попытались воспроизвести эксперимент, но успешно его провалили, из-за многочисленных неудачных попыток поднять Windows на аналогичных серверах, ошибок из-за UEFI SB, отказов поднятия множества скоростных сетевых интерфейсов и из-за банального отсутсвия реализации множества сетевых библиотек и настроек"
:)
s/инженеры Windows/инженеры Microsoft/
инженеры microsoft скопируют код MultiPath TCP и внедрят в следующей версии windows server
> инженеры microsoft скопируют код MultiPath TCP и внедрят в следующей версии windows
> server2020-ом ?! доживет microsoft? :)
> инженеры microsoft скопируют код MultiPath TCPОни уже скопировали sudo. Лет через 10. Или 15. Получился на редкость кривой uac. Если они так же качественно MPTCP скопируют...
Ну встроенная аггрегация линков появилась в Вынь2012, интересно было бы потеститьно помоему не взлетит
> Ну встроенная аггрегация линков появилась в Вынь2012Не прошло и 20 лет как до майкрософт дошло что существует агрегация? Чертовски оперативные парни.
>Чертовски оперативные парни.Ну да, не стремятся все поломать, что работает и заменить глючным и сырым NIH'ом. Поэтому так любимы "продакшеном" и вообще там, где люди работают, а не занимаются спортивным бегом по граблевому полю. Но школоте с арчегами и федорками не понять, да.
> работают, а не занимаются спортивным бегом по граблевому полю.Они работают, занимаясь бегом по граблевому полю. При том в последнее время - больше бегают по граблевому полю чем работают. Качество сетаперов всяких последних эксченжей и прочих, выпадающих в осадок через раз с какими-то левыми зубодробильными ошибками даст фору любой федоре. Там и то такие пре-альфы как релиз стесняются вываливать и откладывают дату релиза.
а чем это лучше SCTP?
> а чем это лучше SCTP?Тем что
1) Максимально косит под стандартный TCP во всех потоках, в счет чего firewall/nat friendly.
2) К тому же предусмотрена деградация до "просто TCP" когда по другому совсем не удалось.
3) Приложения по минимуму можно вообще не переписывать.
4) Не страдает оверинжинирингом и попытками решить все проблемы человечества одной хреновиной.
Таак, и какой роутер мне купить, что б это завелось?
> Таак, и какой роутер мне купить, что б это завелось?Любой, который не корежит TCP. В протоколе предприняты усилия для того чтобы для промежуточных узлов все это смотрелось как просто TCP соединения.
> Таак, и какой роутер мне купить, что б это завелось?Глаза разуй, там наверху написано же `HP DL380p G7`.
Вот и ещё одно доказательство лидерства Linux в серверной сфере. Другие ОС не скоро реализуют подобное.
А я круче! http://img42.imageshack.us/img42/6521/steamtb.png
> А я круче! http://img42.imageshack.us/img42/6521/steamtb.pngКрутой у вас канал. Наверное это точка межгалактического обмена траффиком, не меньше.
"Конфигурация ядра Linux была подвергнута тюнингу, учитывающему особенности используемой серверной платформы."Глянув конфиг, можно сказать что весь этот "тунинх" сводится ко включению RapidIO (а он там есть на железе вообще?). Остальное все по-дефолту. Даже кубик и тот по сути дефолт. А еще много чего можно было вообще выключить. В частности, кучу драйверов для которых на DL380p нет железа.
cubic лучше других алгоритмов?
Один из многих, просто он дефолтный если включить в ядре "расширенное управление потоком". Там их больше десятка разных вариаций, есть специально заточенные под скоростные (H-TCP) или под LFN (HYBLA) линки. Но оставлен кубик.
Панят эта нывазъможна.
с htcp рекордная скорость получилась бы больше?
Да в том и дело, что интересно было бы проверить. Тем более, что менять можно на ходу. Но товарисчам видимо нет до этого дела. А может быть оставили задел на будущее. Ждем новость вида "57.3Гбит/с - дальнейшая оптимизация ядра Linux позволила побить прежний рекорд"P.S.
И надеюсь, что отвечаю не троллю, хотя уже закрадываются смутные предчувствия.
http://fasterdata.es.net/host-tuning/freebsd/
> cubic лучше других алгоритмов?Congestion Control Algorithm:
H-TCP - http://howtounix.info/man/FreeBSD/man4/cc_htcp.4
Vegas - http://howtounix.info/man/FreeBSD/man4/cc_vegas.4
NewReno - http://howtounix.info/man/FreeBSD/man4/cc_newreno.4
HD - http://howtounix.info/man/FreeBSD/man4/cc_hd.4
CHD - http://howtounix.info/man/FreeBSD/man4/cc_chd.4