The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

В Linux удалось достичь скорости 51.8 Гбит/с в рамках одного TCP-соединения

25.03.2013 23:31

Разработчики расширения MultiPath TCP для ядра Linux побили рекорд скорости на самую большую пропускную способность, которую удалось продемонстрировать в рамках одного TCP-соединения. В рамках проведённого эксперимента удалось достичь пропускной способности 51.8 Гбит/с при передаче данных через одно TCP-соединение. При такой скорости для передачи содержимого DVD достаточно 1 секунды, а диска Blu-Ray (25GB) - 5 секунд.

Технология Multipath TCP (RFC 6824) позволит организовать работу TCP-соединения с доставкой пакетов одновременно по нескольким маршрутам через разные сетевые интерфейсы, привязанные к разным IP-адресам. Со стороны приложений подобное агрегированное соединение выглядит как обычное TCP-соединение. Multipath TCP может использоваться как для увеличения надёжности, так и для расширения пропускной способности. В качестве одного из практических применений Multipath TCP для обычных пользователей упоминается возможность организации передачи данных на смартфоне, с использованием одновременно линков WiFi и 3G. Для серверных систем Multipath TCP может обеспечить сокращение расходов за счёт использования нескольких дешевых линков вместо одного более дорогого.

Для достижения скорости 51.8 Гбит/с в эксперименте были использованы два сервера HP DL380p G7 с шестью 10 гигабитными Ethernet интерфейсами в каждом (три двухпортовых адаптера Intel 82599EB). Конфигурация ядра Linux была подвергнута тюнингу, учитывающему особенности используемой серверной платформы. Был настроен режим Receive-Flow-Steering, для каждой сетевой карты MTU был установлен в 9000 (включена поддержка jumbo-кадров), tx-queue в 500, настроена слитная обработка серии прерываний, обработка прерываний для каждой карты привязана к отдельному CPU, существенно расширены размеры буферов для стека TCP/IP (максимальный размер буфера выставлен в 200 Мб), выбран алгоритм контроля перегрузки cubic.

После установки соединения с использованием утилиты netperf на первом этапе был задействован только один интерфейс и система показала максимально возможный предел для классического TCP-стека. После этого не разрывая соединения для оставшихся интерфейсов была включена поддержка Multipath TCP и система автоматически расширила канал связи с использованием появившейся мощности, доведя в итоге пропускную способность до 51.8 Гбит/с.



  1. Главная ссылка к новости (http://multipath-tcp.org/pmwik...)
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/36495-tcpip
Ключевые слова: tcpip, multipath, benchmark, linux, kernel
Поддержать дальнейшую публикацию новостей на OpenNET.


Обсуждение (149) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.6, klalafuda (?), 00:05, 26/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +39 +/
    Имея такой линк лет 15ть назад предложение 'скачать Интернет' не показалось бы такой уж шуткой.
     
     
  • 2.14, Аноним (-), 00:22, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Да ладно, гугл вон и сейчас имеет копию всего интернета
     
     
  • 3.22, Lain_13 (ok), 00:49, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Теоретически вообще весь интернет можно спокойно уместить на одном танкере.
    http://what-if.xkcd.com/23/
    Если учесть сколько у гугла датацентров, то у него не одна, у него много копий интернета.
     
     
  • 4.66, AlexAT (ok), 07:20, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Вы не скачаете, и не поместите "на одном танкере" даже

    <?
    echo($_GET['input']);
    ?>

    Если будете опрашивать классическим способом.

     
     
  • 5.123, Аноним (-), 19:15, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Если будете опрашивать классическим способом.

    Оно разгонится до 51 Гбит? :)

     
  • 3.65, Bocha (??), 07:00, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Кругом пишут, что Гуглом сохранено 0,004% интернета. Понятия не имею откуда такие сведения, но вот так.
     
     
  • 4.85, freehck (ok), 11:27, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Так ведь гугл сканирует только web, разве нет?
    А mail, nntp, и прочие разумеется не сохраняются.
    Также я смекаю, что зеркала всех ftp-серверов гугл также не утруждает себя делать.
     
     
  • 5.98, FKH (?), 13:50, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну как это? Ньюсы и группы сохраняются ессно. А майлы ваши три года сохраняются согласно приказу Гестапо
     
  • 4.124, Аноним (-), 19:16, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Кругом пишут, что Гуглом сохранено 0,004% интернета. Понятия не имею откуда такие
    > сведения, но вот так.

    Так гугл не хранит интернет. Он хранит индексы. Несколько разная вещь. Хранить интернет пытается wayback machine. Но в последнее время они IIRC жаловались на нехватку мощностей... :)


     
  • 3.92, цирроз (ok), 12:51, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    неа. в кэш попадает далеко не всё.
     

  • 1.13, жопка3 (?), 00:19, 26/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Кому не лень подсчитать - с какой скорость номера acl/seq переполнятся - меньше чем 2 * MSL или нет ? :)
     
  • 1.15, all_glory_to_the_hypnotoad (ok), 00:23, 26/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    > В качестве одного из практических применений Multipath TCP для обычных пользователей упоминается возможность организации передачи данных на смартфоне, с использованием одновременно линков WiFi и 3G

    зашибись юз-кейс. Ускорим скачку на процентов 5-8 выработав литит безлимита в 3g или заплатив за это бабки.

     
     
  • 2.17, Аноним (-), 00:39, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +12 +/
    > зашибись юз-кейс.

    На самом деле - великолепный юзкейс. Прикиньте, прозрачное переключение между интерфейсами без разрыва соединений. Очень мило. Используется все что может использоваться. А переключение на ходу. По сути - этакий роуминг но для TCP соединений.

     
     
  • 3.28, all_glory_to_the_hypnotoad (ok), 00:55, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    переключение это прикольно, но там вроде не сказано про это. По крайней мере, не увидел в их презенташке будет ли оно вообще работать. И тем не менее, проблема не проходит, даже с просто переключением можно влететь на бабки или убить лимит.
     
     
  • 4.47, Аноним (-), 04:11, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +10 +/
    > переключение это прикольно, но там вроде не сказано про это.

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

    > переключением можно влететь на бабки или убить лимит.

    Вопрос кретинизма в тарификации некоего провайдера, меряющего трафф пипеткой - не проблемы протокола. Это ваши проблемы и проблемы вашего провайдера.

     
     
  • 5.73, АнониМ (?), 09:46, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >Могу предположить что при отваливании части интерфейсов оно просто деградирует по скорости и начинает юзать то что осталось.

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

     
     
  • 6.79, Moomintroll (ok), 10:21, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > следующий шаг менять сетевухи без остановки сервера.

    Это предыдущий шаг - PCI hot-plug.

     
  • 6.125, Аноним (-), 19:18, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > следующий шаг менять сетевухи без остановки сервера.

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

     
     
  • 7.182, тест (?), 09:10, 29/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Так вся и фишка в том, что используя эту технологию + pci hot-plug можно никуда не мигрировать.
     
  • 3.71, тигар (ok), 09:40, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • –8 +/
    а что, в линуксах так до сих пор нельзя сделать чтоли? 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лет в обед.

     
     
  • 4.74, АнониМ (?), 09:52, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > а что, в линуксах так до сих пор нельзя сделать чтоли? boud
    > чтоли только для агрегации?;)

    там ограничения с мак адресами как я понимаю и соответственно трах с wlan. boud в линуксе есть и давно.

     
     
  • 5.127, Аноним (-), 19:24, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > там ограничения с мак адресами как я понимаю и соответственно трах с
    > wlan. boud в линуксе есть и давно.

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

     
  • 4.78, Аноним (-), 10:21, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > разным IP-адресам
     
  • 4.103, Zulu (?), 14:34, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    все линки под аггрегацией должны вести в один свитч. Более того, в случае 802.3ad свитч еще и должет об этом знать.
    IPMP об другом.
     
  • 4.126, Аноним (-), 19:21, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > вытащу патчкорд - переключится на wifi,

    А там оно не "переключается" а динамически использует все что доступно. Ну то-есть было 2 интерфейса - юзались два. Поднялось еще три - траффик пошел по пяти интерфейсам. Упало два интерфейса - траффик идет по оставшимся трем. Крутота.

     
  • 3.156, NoName (?), 22:17, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > прозрачное переключение между интерфейсами без разрыва соединений

    Сам по себе малтипасинг - боян, стоит поинтересоваться как аггрегируются малтипасинговые LUN'ы с многопортового SAN'а на тазике со многими же FC-портами.

    С другой стороны - а как же NIC тиминг/бондинг/агрегейтинг в Линухах? Оно ж то же самое делает! :)

     
     
  • 4.158, Zulu (?), 22:34, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > стоит поинтересоваться как аггрегируются малтипасинговые LUN'ы с многопортового SAN'а на тазике со многими же FC-портами.

    СОВЕРШЕННО иначе.
    Сначала импортируются все девайсы как самостоятельные scsi luns, потом -- если включен MPxIO -- делается SCSI INQ на page 0x83 и все, что имеет одинаковый ID, считается одним и тем же девайсом.

    Ни с бондингом, ни с IP MP это не имеет ничего общего.

     
  • 4.175, Аноним (-), 00:59, 28/03/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Сам по себе малтипасинг - боян,

    ...но в данном случае очень уж идея красива и почти не требует лишних приседаний от админа.

     

  • 1.19, Аноним (-), 00:42, 26/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    подскажите чем это лучше бондинга?
     
     
  • 2.49, Аноним (-), 04:13, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > подскажите чем это лучше бондинга?

    Тем что могут без гемора юзаться 2 разных прова например. И через обоих полетит трафф.

     
  • 2.81, acmnu (ok), 10:29, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Бондинг требует агрегации на ближайшем к тебе управляемом оборудовании. А здесь, насколько я понял агрегация идет на уровне TCP, а не на уровне 2 и агрегируют две конечные точки (клиент и сервер), а километры проводов и тонны оборудования по середине не имеют значения.
     
     
  • 3.130, Аноним (-), 19:33, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Именно Динамически согласуется подъем дополнительных туннелей через иные endpoi... большой текст свёрнут, показать
     

  • 1.20, Аноним (-), 00:43, 26/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Не совсем понятно: сетевые карты на интерфейсе PCI-E 2.0, который имеет пропускную способность 5Gb/s  - умножаем на 8 - получаем 40GBit/s.

    Как получилось выйти за скорость шины?

     
     
  • 2.23, Аноним (-), 00:50, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Не совсем понятно: сетевые карты на интерфейсе 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.

     
  • 2.33, хрюкотающий зелюк (?), 01:39, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    один PCI-E x16 это 128Gbit/s, таких портов может быть несколько на крутой материнки, именно два честных x16
     

  • 1.25, Аноним (-), 00:51, 26/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –8 +/
    > в рамках одного TCP-соединения
    > с доставкой пакетов одновременно по нескольким маршрутам через разные сетевые интерфейсы, привязанные к разным IP-адресам.

    Дада, разные айпи адреса и при этом одно соединение. Первое апреля через неделю.

     
     
  • 2.35, Аноним (-), 01:50, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    http://tools.ietf.org/html/rfc6824
    Достаточно даже заголовок прочитать "TCP Extensions for Multipath Operation with Multiple Addresses"
     
     
  • 3.118, Аноним (-), 18:43, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Бред. Коннектов будет как минимум столько, сколько айпи адресов используется, если проснифить трафик в езернете между точками обмена.
     
     
  • 4.131, Аноним (-), 19:38, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Бред. Коннектов будет как минимум столько, сколько айпи адресов используется,

    Так этот кульный протоколец на ходу досогласует дополнительные субпотоки-туннели, нисколко не смущаясь тем фактом что у них назначения отличаются. Для соотнесения с начальным потоком используется некий рандомный ключ-идентификатор. По факту для стороннего наблюдатедя это будет выглядеть как несколько TCP соединений, протокол пытается сделать так чтобы добавочные туннели максимально косили под просто еще 1 TCP соединение.

     
     
  • 5.155, Аноним (-), 22:11, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну так это факта не отменяет. что НЕ в рамках одного соединения, а нескольких, пусть даже "субпотоки" называются.
     
     
  • 6.169, Аноним (-), 00:17, 28/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ну так это факта не отменяет. что НЕ в рамках одного соединения,
    > а нескольких, пусть даже "субпотоки" называются.

    Смотря что считать соединением. С точки зрения софта - соединение одно. С точки зрения полета пакетов по интерфейсам, один логический поток распилен на субпотоки. Софт про это может вообще ничего не знать и думать что это одно TCP соединение. А может и знать, если хочет.

     
  • 2.51, Аноним (-), 04:32, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Дада, разные айпи адреса и при этом одно соединение.

    Beyond your wildest imaginations. Именно так. Вы знаете, в этом мире оказалось возможным очень много из того что считалось "невозможным" или "сказочным".

     
     
  • 3.129, mr. green thumb (?), 19:33, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    оказывалось, оказывается и будет оказываться
     

  • 1.27, dr Equivalent (ok), 00:55, 26/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Отличная же новость. Сразу представляю шлюз на весь подъезд, подключенный сразу к нескольким провам на внешку.
     
     
  • 2.29, all_glory_to_the_hypnotoad (ok), 00:57, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    это, кстати, может не везде работать.
     
  • 2.34, Аноним (-), 01:45, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Тут речь идет про одно TCP соединение вообще-то, при чем тут подъезд вообще?
     
     
  • 3.50, dr Equivalent (ok), 04:29, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Тут речь идет про одно TCP соединение вообще-то, при чем тут подъезд
    > вообще?

    А подумать уже не в моде?.. Их что, этих TCP-соединений, не может быть параллельно несколько с одного и того же адреса, или, в данном случае, набора адресов?
    Ну, и еще можно внимательнее прочитать статью:

    > Multipath TCP может обеспечить сокращение расходов за счёт использования нескольких дешевых линков вместо одного более дорогого.

     
     
  • 4.88, Аноним (-), 12:41, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Видимо не в моде, потому что новость о том, чтобы по ОДНОМУ TCP соединению передать огромный объем данных за короткое время, используя множество каналов передачи данных. И эта технология должна поддерживаться на стороне сервера тоже. А учитывая, что сайты в подавляющем большинстве отдают данные на скорости меньше мегабита для каждого соединения, какой в этом смысл то? Я повторю, смысл в технологии в том, чтобы все достыпные ресурсы всех доступных каналов передачи данных слепить в кучу и обеспечить одно быстрое соединение.
     
  • 2.39, Аноним (-), 02:56, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    На сколько я понял из новости на обратной стороне должна быть такая же машинка
     
     
  • 3.52, pavlinux (ok), 04:32, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > На сколько я понял из новости на обратной стороне должна быть такая же машинка

    Зачем? /dev/null  рулит! :)


     
  • 3.60, Аноним (-), 04:56, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > На сколько я понял из новости на обратной стороне должна быть такая же машинка

    Там должна быть машина с таким же MPTCP, что логично.

     

  • 1.48, Nxx (ok), 04:12, 26/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А без Multipath оно так может?
     
     
  • 2.53, pavlinux (ok), 04:38, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > А без Multipath оно так может?

    Есть сетевушки на 40Gb/s

     
     
  • 3.54, Michael Shigorin (ok), 04:40, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Есть сетевушки на 40Gb/s

    В разработе вроде и сотки уже [опять].

     
     
  • 4.55, pavlinux (ok), 04:42, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> Есть сетевушки на 40Gb/s
    > В разработе вроде и сотки уже [опять].

    Вот, кушайте, - 16 портовый 100 гигабитный роутер
    http://www.juniper.net/us/en/products-services/routing/t-tx-series/t4000/

    Эксперименты уже идут на терабитном езернете.

     
     
  • 5.63, мус (?), 06:06, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >>> Есть сетевушки на 40Gb/s
    >> В разработе вроде и сотки уже [опять].
    > Вот, кушайте, - 16 портовый 100 гигабитный роутер
    > http://www.juniper.net/us/en/products-services/routing/t-tx-series/t4000/
    > Эксперименты уже идут на терабитном езернете.

    Кушает почти 12 киловатт. Жуть :)

     
     
  • 6.86, lsa (?), 11:52, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Старьйо =) и оно насколько я помню чисто P устройство.
     
  • 3.104, Zulu (?), 14:37, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Есть сетевушки на 40Gb/s

    Есть инфинибанд и есть интегрированные -- 4x10g в одном QSFP порту. Суешь туда QSFP to MPO трансивер, то же самое в соседнюю машину, соединяешь кабелем и настраиваешь бондинг.

     
     
  • 4.133, Аноним (-), 19:40, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > соединяешь кабелем и настраиваешь бондинг.

    Только вот через интернет работать не будет. Сущая фигня.

     
     
  • 5.137, Аноним (-), 19:53, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    А то что в новости через интернет что ли работает на ~50Гб? Или это тоже фигня?
     
     
  • 6.151, Аноним (-), 20:23, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > А то что в новости через интернет что ли работает на ~50Гб?

    Так там нет никакого бондинга. Там MPTCP сам себе "бондинг".

     
     
  • 7.160, Аноним (-), 23:55, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ещё раз, помедленнее. вот то что в новости тестировалось в интернете? тестовые версии на 6 прямых проводах как-то не интересуют.
     
     
  • 8.170, Аноним (-), 00:20, 28/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    В новости - может и ничего Но протокол в целом - максимально заточен на то чтоб... текст свёрнут, показать
     
     
  • 9.178, Аноним (-), 20:34, 28/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Тогда в данный момент никакой разницы с бондингом И вот это Только вот через и... текст свёрнут, показать
     
  • 5.159, Zulu (?), 22:36, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Только вот через интернет работать не будет. Сущая фигня.

    Вопрос был "сетевушки", а не "через интернет". Надо уровни OSI различать, да?

     
  • 2.56, Аноним (-), 04:51, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > А без Multipath оно так может?

    Если бы проблемы не было - зачем бы люди стали RFC писать? :)

     
     
  • 3.57, pavlinux (ok), 04:54, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> А без Multipath оно так может?
    > Если бы проблемы не было - зачем бы люди стали RFC писать?

    Ну а почему бы не устроить МногоПуть на десяти 100-гигабитных сетевушках?

     
     
  • 4.59, Аноним (-), 04:55, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну а почему бы не устроить МногоПуть на десяти 100-гигабитных сетевушках?

    Теоретически наверное ничему не противоречит. Практически - это потребует какой-то весьма неординарной машины. И кроме того - что в таких объемах слать по TCP соединению?

     
     
  • 5.61, pavlinux (ok), 05:01, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> Ну а почему бы не устроить МногоПуть на десяти 100-гигабитных сетевушках?
    > Теоретически наверное ничему не противоречит. Практически - это потребует какой-то весьма неординарной машины.

    4-процессорный, 128-ядерный IBM Power7 справиться. (чуть больше 1 ТераФЛОПа выдаёт.)

    > И кроме того - что в таких объемах слать по TCP соединению?

    - Какой-нить RAID массив на пару петабайт перекачивать туды-обратно. =)
    - Кстати, в курсе что гугл торгует своим кэшем? Терабайт стоит в районе 25000$  
    - Например дамп трафика по Москве занимает около 10 терабаб в день!
    (на самом деле больше, там какие методы фильтрации, выборок и сжатия, rutracker никому не упёрся)

     
     
  • 6.90, Аноним (-), 12:44, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Каким образом гугл перехватывает трафик по Москве?
     
     
  • 7.108, Аноним (-), 16:00, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Каким образом гугл перехватывает трафик по Москве?

    Не прикидывайся дебилом - все и так это знают.

     
  • 7.115, pavlinux (ok), 18:08, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Каким образом гугл перехватывает трафик по Москве?

    Строки нужно читать линейно, слева-направо, а не в шахматном порядке или по рандому.


     
     
  • 8.116, arisu (ok), 18:10, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +5 +/
    а нет ли в этом комментарии антисемитизма ... текст свёрнут, показать
     

  • 1.64, Zenitur (ok), 06:46, 26/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А как же обмен данными между Россией и Японией по всего лишь одному оптиковолоконному кабелю? Слухи врут?
     
     
  • 2.67, Аноним (-), 07:25, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Это о другом.
     
  • 2.96, Аноним (-), 13:09, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    В одном оптоволоконном кабеле далеко не одна пара волокон для передачи данных.
     
  • 2.157, NoName (?), 22:25, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > А как же обмен данными между Россией и Японией по всего лишь
    > одному оптиковолоконному кабелю? Слухи врут?

    Ну например http://ru.wikipedia.org/wiki/%D0%A1%D0%BF%D0%B5

     

  • 1.68, анон (?), 07:33, 26/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    покажите мне девайс, который за секунда читает весь ДВД-диск
     
     
  • 2.69, hhg (ok), 08:46, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +7 +/
    например iso на tmpfs смонтированный на loop :P
     
     
  • 3.110, acmnu (ok), 16:32, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Загрузил ты анона - он теперь судрожно ищет в меню "Пуск" конпочку tmpfs.
     
  • 2.134, Аноним (-), 19:43, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > покажите мне девайс, который за секунда читает весь ДВД-диск

    RAM-диск. Вопросы? :)

     
     
  • 3.154, Аноним (-), 21:57, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Хорошая у Вас рама.
     
     
  • 4.161, Michael Shigorin (ok), 05:16, 27/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Хорошая у Вас рама.

    Так а эээ... >10Gb/s и объём в три дивидюка по нынешним временам никаких таких проблем не составляет.

     
  • 4.171, Аноним (-), 00:46, 28/03/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Хорошая у Вас рама.

    Она уже много у кого хорошая. Несколько лет как.

     

  • 1.70, Ващенаглухо (ok), 09:20, 26/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Когда же в домашнем интернете появится хотя бы гигабит?!...
     
     
  • 2.72, 1 (??), 09:41, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    запросто, ток цена врят ли устроит... хотя где то уже начинает появляться, ток в локалку как правило.
     
  • 2.75, Sarmat (?), 09:56, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Зачем? у меня 3 телевизора даже для FullHD 100Мб хватит, про сёрфать я думаю и говорить не стоит
     
     
  • 3.99, John (??), 13:50, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Такой сказочник...
    http://ru.wikipedia.org/wiki/MPEG-2
     
  • 3.135, Аноним (-), 19:47, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Зачем? у меня 3 телевизора

    Дяденька, мы не грабители, поэтому нам пофиг сколько там у вас телевизоров.

     
  • 2.80, blablabla (ok), 10:22, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Когда же в домашнем интернете появится хотя бы гигабит?!...

    У меня на домашнем серваке на антрисольке несколько сайтов и канал 80Mbit
    Исходящего трафика в неделю более 45 гигов
    А зачем домашним хомякам больше теоретических 100 ???

     
     
  • 3.138, Аноним (-), 19:53, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Исходящего трафика в неделю более 45 гигов

    Всего? Я как-то ради интереса seed'анул исохи убунты торентом - посмотреть сколько черех хороший канал можно пропихнуть, etc. За месяц получилось 1.2Тб. Канал был 50Мбит. Впрочем, загрузка была далеко не полная: невзирая на сотни пиров они не всегда могут столько траффа сожрать. Далее я все-таки скостил потребление траффа, т.к. генерить прову столько траффика на постоянной основе все-таки не совсем правильно.

     
  • 3.146, Anonymus (?), 20:06, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > А зачем домашним хомякам больше теоретических 100 ???

    Ты слышал что-нибудь о 4К телеках, H265 и 3D ?


     
  • 2.82, george (??), 10:32, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Когда же в домашнем интернете появится хотя бы гигабит?!...

    В украине, в неск обл центрах есть. При чем по вполне гуманной цене порядка 10 евро.

     
     
  • 3.111, Led (ok), 16:43, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> Когда же в домашнем интернете появится хотя бы гигабит?!...
    > В украине, в неск обл центрах есть. При чем по вполне гуманной
    > цене порядка 10 евро.

    Странно, я думал так везде...

     
  • 2.97, Michael Shigorin (ok), 13:49, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Когда же в домашнем интернете появится хотя бы гигабит?!...

    В подъезде уже несколько лет доступно, цены не совсем домашние, но и не заоблачные.  Кажется, теперь даже от более чем одного прова.  Киев.

     
     
  • 3.112, Nxx (ok), 16:56, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> Когда же в домашнем интернете появится хотя бы гигабит?!...
    > В подъезде уже несколько лет доступно, цены не совсем домашние, но и
    > не заоблачные.  Кажется, теперь даже от более чем одного прова.
    >  Киев.

    На Украине всегда интернет дешевый. Потому что там его много.

     
     
  • 4.113, arisu (ok), 17:12, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > На Украине всегда интернет дешевый. Потому что там его много.

    дык у москалей крадут. вместе с газом.

     
     
  • 5.128, Michael Shigorin (ok), 19:28, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не-а, это франкфуртский байтопровод где-то с 2005.
     
     
  • 6.139, Аноним (-), 19:55, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Не-а, это франкфуртский байтопровод где-то с 2005.

    Транзитные байты из москвы в дойчляндию откачиваете для собственных нужд? :)

     
     
  • 7.141, arisu (ok), 19:57, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> Не-а, это франкфуртский байтопровод где-то с 2005.
    > Транзитные байты из москвы в дойчляндию откачиваете для собственных нужд? :)

    с байта по биту — и уже навар.

     
     
  • 8.150, Аноним (-), 20:17, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А, так вот кто виноват в семибитных байтах и нужде ююков на древних каналах Теп... текст свёрнут, показать
     
  • 2.106, hakushka (ok), 15:41, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    О Google Fiber не слышали? А зря.
     
     
  • 3.121, Аноним (-), 18:57, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    дорогое / нетехнологическое
     
     
  • 4.122, hakushka (ok), 19:05, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > дорогое / нетехнологическое

    В какой это вселенной $70 за симметричный гигабит дорого или не технологично?

     
     
  • 5.140, Аноним (-), 19:56, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > В какой это вселенной $70 за симметричный гигабит дорого или не технологично?

    Вообше, 70 баксов - это довольно много. Это весьма высокий ARPU. Хотя для гигабита достаточно неплохо, да.


     

  • 1.76, shadowcaster (?), 10:18, 26/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А в это время 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.

     
  • 1.77, Аноним (-), 10:19, 26/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Знающие, я правильно понимаю, что пока эту RFC не поддержит хотя бы процентов 80 интернета, юзать ее можно будет только в своих песочницах? Или это расширение совместимо с существующими реализациями стека?
     
     
  • 2.117, pavlinux (ok), 18:14, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Знающие, я правильно понимаю, что пока эту RFC не поддержит хотя бы
    > процентов 80 интернета, юзать ее можно будет только в своих песочницах?

    Вообще прозрачно для провайдеров.
    Они только будут окуевать, - "чёй-то сайты на четверть загружаются и файлы не докачиваются"  :)

     
     
  • 3.164, Аноним (-), 11:24, 27/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> Знающие, я правильно понимаю, что пока эту RFC не поддержит хотя бы
    >> процентов 80 интернета, юзать ее можно будет только в своих песочницах?
    > Вообще прозрачно для провайдеров.
    > Они только будут окуевать, - "чёй-то сайты на четверть загружаются и файлы
    > не докачиваются"  :)

    Для провайдеров - согласен. Но сайты-то должны это уметь?

     
     
  • 4.172, Аноним (-), 00:49, 28/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Но сайты-то должны это уметь?

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

     
     
  • 5.176, pavlinux (ok), 02:13, 28/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> Но сайты-то должны это уметь?
    > Ну да. Хотя дарю идею: если есть быстрый хост в интернете -
    > так можно попробовать заапгрейдить скорость и надежность своего интернета. Пульнуть туда
    > нечто типа опенвпн, который размажется на несколько каналов. Возможно наступит профит.

    squid можно поставить! ФСБ будет в шоке - человек делает GET запрос к сайту, и уходит ;)

     
  • 5.179, Аноним (-), 23:33, 28/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Прямоугольная идея со скругленными краями. Срочно патентуйте.
     

  • 1.83, mike_t (?), 10:37, 26/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    ребята изобрели SCTP?
     
     
  • 2.100, Аноним (-), 13:55, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    До sctp им еще как раком до австралии 8(
     
     
  • 3.142, Аноним (-), 19:58, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > До sctp им еще как раком до австралии 8(

    Что хорошо. Они обошлись без оверинжиниринга и сделали максимально совместимо с TCP. Даже фаеры и наты постарались учесть.

     

  • 1.84, sasa (??), 11:25, 26/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > настроена слитная обработка серии прерываний

    Имеется ввиду NAPI ? http://lwn.net/Articles/30107/

    я думал поллинг давно используется по умолчанию

     
     
  • 2.87, Анончик (?), 12:14, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Polling'гом это во FreeBSD называется. Оно там настраиваемое.
    В Linux - NAPI. Не настраиваемый. Либо работает, либо нет, зависит от драйвера сетевой карты
     
     
  • 3.95, sasa (??), 13:09, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Polling'гом это во FreeBSD называется

    причем правильно отображает суть, а про NAPI я по-больше вас знаю ;-)

     
     
  • 4.102, Анончик (?), 14:27, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Я и не спорю, я согласен с вами.
     

  • 1.89, Аноним (-), 12:42, 26/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Сорри за офтоп, а какую максимальную скорость можно получить в винде?
     
     
  • 2.143, Аноним (-), 20:00, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Сорри за офтоп, а какую максимальную скорость можно получить в винде?

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

     

  • 1.91, Assembler (?), 12:46, 26/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    мдаа.. на виндус сервер 2008 эр2 такая скорость даже и не снилась
     
     
  • 2.93, Аноним (-), 12:53, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Винда не годиться для серверов шлюзов
     
     
  • 3.114, arisu (ok), 17:13, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +5 +/
    винда просто не годится.


     
  • 2.144, Аноним (-), 20:02, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > мдаа.. на виндус сервер 2008 эр2 такая скорость даже и не снилась

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

     

  • 1.101, hummermania (ok), 14:20, 26/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    "Вдохновившись достиженим разработчиков расширения MultiPath TCP, инженеры Windows попытались воспроизвести эксперимент, но успешно его провалили, из-за многочисленных неудачных попыток поднять Windows на аналогичных серверах, ошибок из-за UEFI SB, отказов поднятия множества скоростных сетевых интерфейсов и из-за банального отсутсвия реализации множества сетевых библиотек и настроек"
     
     
  • 2.105, userd (ok), 15:37, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    :)
    s/инженеры Windows/инженеры Microsoft/
     
  • 2.107, Assembler (?), 15:47, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    инженеры microsoft скопируют код MultiPath TCP и внедрят в следующей версии windows server
     
     
  • 3.136, bsdaemon (??), 19:48, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > инженеры microsoft скопируют код MultiPath TCP и внедрят в следующей версии windows
    > server

    2020-ом ?! доживет microsoft? :)

     
  • 3.145, Аноним (-), 20:03, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > инженеры microsoft скопируют код MultiPath TCP

    Они уже скопировали sudo. Лет через 10. Или 15. Получился на редкость кривой uac. Если они так же качественно MPTCP скопируют...

     
  • 2.119, Йух (??), 18:55, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Ну встроенная аггрегация линков появилась в Вынь2012, интересно было бы потестить

    но помоему не взлетит

     
     
  • 3.149, Аноним (-), 20:09, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ну встроенная аггрегация линков появилась в Вынь2012

    Не прошло и 20 лет как до майкрософт дошло что существует агрегация? Чертовски оперативные парни.

     
     
  • 4.153, Аноним (-), 21:11, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >Чертовски оперативные парни.

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

     
     
  • 5.173, Аноним (-), 00:52, 28/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > работают, а не занимаются спортивным бегом по граблевому полю.

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

     

  • 1.120, anonymous (??), 18:57, 26/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    а чем это лучше SCTP?
     
     
  • 2.147, Аноним (-), 20:07, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > а чем это лучше SCTP?

    Тем что
    1) Максимально косит под стандартный TCP во всех потоках, в счет чего firewall/nat friendly.
    2) К тому же предусмотрена деградация до "просто TCP" когда по другому совсем не удалось.
    3) Приложения по минимуму можно вообще не переписывать.
    4) Не страдает оверинжинирингом и попытками решить все проблемы человечества одной хреновиной.

     

  • 1.132, piteri (ok), 19:40, 26/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Таак, и какой роутер мне купить, что б это завелось?
     
     
  • 2.148, Аноним (-), 20:09, 26/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Таак, и какой роутер мне купить, что б это завелось?

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

     
  • 2.163, Andrey Mitrofanov (?), 10:26, 27/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Таак, и какой роутер мне купить, что б это завелось?

    Глаза разуй, там наверху написано же 'HP DL380p G7'.

     

  • 1.152, lucentcode (ok), 20:25, 26/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вот и ещё одно доказательство лидерства Linux в серверной сфере. Другие ОС не скоро реализуют подобное.
     
  • 1.162, Аноним (-), 10:16, 27/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А я круче! http://img42.imageshack.us/img42/6521/steamtb.png
     
     
  • 2.174, Аноним (-), 00:54, 28/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > А я круче! http://img42.imageshack.us/img42/6521/steamtb.png

    Крутой у вас канал. Наверное это точка межгалактического обмена траффиком, не меньше.

     

  • 1.165, Аноним (-), 21:00, 27/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    "Конфигурация ядра Linux была подвергнута тюнингу, учитывающему особенности используемой серверной платформы."

    Глянув конфиг, можно сказать что весь этот "тунинх" сводится ко включению RapidIO (а он там есть на железе вообще?). Остальное все по-дефолту. Даже кубик и тот по сути дефолт. А еще много чего можно было вообще выключить. В частности, кучу драйверов для которых на DL380p нет железа.

     
  • 1.166, Аноним (-), 22:15, 27/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    cubic лучше других алгоритмов?
     
     
  • 2.167, Аноним (-), 23:37, 27/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Один из многих, просто он дефолтный если включить в ядре "расширенное управление потоком". Там их больше десятка разных вариаций, есть специально заточенные под скоростные (H-TCP) или под LFN (HYBLA) линки. Но оставлен кубик.
    Панят эта нывазъможна.
     
     
  • 3.168, Аноним (-), 23:46, 27/03/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    с htcp рекордная скорость получилась бы больше?
     
     
  • 4.177, Аноним (-), 09:18, 28/03/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да в том и дело, что интересно было бы проверить. Тем более, что менять можно на ходу. Но товарисчам видимо нет до этого дела. А может быть оставили задел на будущее. Ждем новость вида "57.3Гбит/с - дальнейшая оптимизация ядра Linux позволила побить прежний рекорд"

    P.S.
    И надеюсь, что отвечаю не троллю, хотя уже закрадываются смутные предчувствия.

     
  • 2.180, Аноним (-), 03:07, 29/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    http://fasterdata.es.net/host-tuning/freebsd/
     
  • 2.181, Аноним (-), 03:11, 29/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > 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

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:
    При перепечатке указание ссылки на opennet.ru обязательно



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2021 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру