The OpenNET Project / Index page

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

Открыт код Remy, системы динамической генерации алгоритмов контроля перегрузки TCP

22.07.2013 19:06

Исследователи из Массачусетского технологического института опубликовали результаты разработки проекта Remy, в рамках которого создана система, использующая методы машинного обучения для автоматической генерации оптимального алгоритма контроля перегрузки TCP (TCP congestion control), учитывающего особенности текущего канала связи. Код Remy открыт под лицензией MIT.

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

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

Remy позволяет сформировать идеальный для каждой конкретной ситуации алгоритм, который может учитывать до 150 различных правил. При этом в настоящее время ещё не подготовлены должные средства диагностики, поэтому трудно судить какое именно сочетание правил применяется в сгенерированном для каждого случая алгоритме. Отмечается, что пока для анализа создаваемых Remy алгоритмов можно применять методы обратного инжиниринга.

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

В итоге, сгенерированный автоматически алгоритм позволяет достигнуть более высокой пропускной способности и справедливости распределения канала, чем при использовании самых изощрённых универсальных схем. Например, сгенерированный Remy алгоритм для канала 15 Mbps, который совместно используется 8 отправителями, позволил достигнуть двухкратного увеличения пропускной способности и на 2/3 снизить задержки из-за нахождения пакетов в очереди, по сравнению с алгоритмами Compound TCP (по умолчанию в Windows) и TCP NewReno (по умолчанию во FreeBSD). По сравнению с алгоритмом TCP Cubic, который используется по умолчанию в Linux, пропускная способность возросла на 70%, а задержки удалось уменьшить в три раза. В другом тесте, симулирующем работу через сотовую сеть Verizon, выигрыш алгоритма Remy составил 20-30% в пропускной способности и 25-40% в отзывчивости.



  1. Главная ссылка к новости (http://web.mit.edu/newsoffice/...)
  2. OpenNews: В Linux удалось достичь скорости 51.8 Гбит/с в рамках одного TCP-соединения
  3. OpenNews: Компания Google представила основанный на UDP экспериментальный протокол QUIC для ускорения Web
  4. OpenNews: Видео с демонстрацией негативного влияния излишней буферизации на качество работы сети
  5. OpenNews: Компания Google представила рекомендации по ускорению работы TCP
  6. OpenNews: Проект по избавлению Linux-ядра от излишней сетевой буферизации
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/37482-tcp
Ключевые слова: tcp, bufferbloat
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (83) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Клыкастый (ok), 20:20, 22/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    http://web.mit.edu/remy/

    тут графики

     
  • 1.2, Аноним (-), 20:25, 22/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Как я могу это использовать на своём компьютере?
     
     
  • 2.4, Вонни (?), 20:35, 22/07/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не это костыль,
    Судя по всему автор этой штуки еще mosh (http://mosh.mit.edu/) не довел до нормального состояния

    Недостатки и неоднозначности:
    - IPv6 еще не реализован
    - Работает только с UTF-8
    - Использует порты 60000–61000 (тысячу портов)

     
     
  • 3.7, Аноним (-), 21:17, 22/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >Недостатки и неоднозначности:

    Это ещё ничего. Может я что-то не осилил, но mc у меня в нём разфигачивало страшно и нельзя было листать буффер с помощью shift+pgup как в обычном ssh.

     
  • 3.19, Какаянахренразница (ok), 05:55, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо. То есть, никаких модулей под ядро Линукса ожидать не следует.
     
  • 3.35, Crazy Alex (ok), 12:52, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    А что костыльного, собственно?
     
     
  • 4.38, Вонни (?), 13:37, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    сервер/клиент приложения
    в ядре линух долго будут пилить
     

  • 1.3, Аноним (-), 20:35, 22/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    модуль ядра будет?
     
  • 1.5, Наивный чукотский юноша (?), 20:40, 22/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Ждём в составе 3.11/3.12. Даёшь высокопроизводительные дешёвые роутеры на одноплатниках!
     
     
  • 2.13, Аноним (-), 00:11, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    В 3.11 прием изменений уже закрыли. Только стабилизация и багфиксы. Кстати -rc2 вышел.
     
  • 2.20, linux must __RIP__ (?), 08:58, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    да да.. А что это любители столмана вдруг озадачились кодом под не православной лицензией?... Свое написать не в состоянии?
     
     
  • 3.39, Наивный чукотский юноша (?), 14:21, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > да да.. А что это любители столмана вдруг озадачились кодом под не
    > православной лицензией?... Свое написать не в состоянии?

    не любитель Столмана. Любитель, что бы работало. И работало хорошо.

     
  • 3.58, Аноним (-), 21:06, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    MIT легко конвертируется в GPLv2.
     
  • 2.32, Нанобот (?), 12:05, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    ещё генетических алгоритмов ядре не хватало. и так тянут в ядро всякую гадость (как кто-то выразился)
     
     
  • 3.75, Аноним (-), 10:46, 24/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > ещё генетических алгоритмов ядре не хватало. и так тянут в ядро всякую
    > гадость (как кто-то выразился)

    Завидуй уж молча, виндоботик микрософтовский. Да, от твоего мелкософта инноваций не дождешься - продают по сути ту же систему что и 15 лет назад. Ну фасад немного подкрасили, остальное изменилось мало.

     

  • 1.6, YetAnotherOnanym (ok), 20:41, 22/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Звучит заманчиво. Только один вопрос - достаточно ли быстро эта штука подкручивает параметры, чтобы, например, адекватно отработать ситуацию, когда вечером набигают жители дачного посёлка и все как один включают свои 3G-побрякушки.
     
     
  • 2.23, VoDA (ok), 09:07, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    По идее оно должно повторно набрать статистику (отбросить устаревшую) и перенастроить сеть под новые параметры. Т.е. да, "набигание" жителей на 3G оно должно отработать.
     

  • 1.8, umbr (ok), 21:22, 22/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >позволил достигнуть ... увеличения пропускной способности и ... снизить задержки

    а ларчик просто открывался

     
  • 1.9, ананим (?), 22:46, 22/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Т.е. сетевой стэк в линухе лучше винды, а в винде лучше чем в фряхе...
     
     
  • 2.10, Вонни (?), 23:11, 22/07/2013 [^] [^^] [^^^] [ответить]  
  • –3 +/
    а у фряхе 10 стабильнее сетевой стек чем в linux 3.11
     
     
  • 3.12, Lain_13 (ok), 00:07, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    http://media.discovernikkei.org/articles/4527/noodles-jan-ken-pon-05_20_12-55
     
  • 3.14, Аноним (-), 00:13, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > а у фряхе 10 стабильнее сетевой стек чем в linux 3.11

    Такие аргументы некисло бы подтвержжать какими-то фактами. А то у меня тут роутер подпертый упсой набрал полгода аптайма. Разумеется MIPSовый роутер был на линухе. А на чем ему еще быть? Фряха там "не алё" практически, в сравнении с openwrt.

     
     
  • 4.21, linux must __RIP__ (?), 09:00, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> а у фряхе 10 стабильнее сетевой стек чем в linux 3.11
    > Такие аргументы некисло бы подтвержжать какими-то фактами. А то у меня тут
    > роутер подпертый упсой набрал полгода аптайма. Разумеется MIPSовый роутер был на
    > линухе. А на чем ему еще быть? Фряха там "не алё"
    > практически, в сравнении с openwrt.

    # uname -r; uptime                                                                                                                                          
    7.1-RELEASE-p11
    7:59AM  up 200 days,

    и чем хвастаемся? последний раз перегружалось по выключению питания в городе.

     
     
  • 5.25, pavel_simple (ok), 09:26, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >>> а у фряхе 10 стабильнее сетевой стек чем в linux 3.11
    >> Такие аргументы некисло бы подтвержжать какими-то фактами. А то у меня тут
    >> роутер подпертый упсой набрал полгода аптайма. Разумеется MIPSовый роутер был на
    >> линухе. А на чем ему еще быть? Фряха там "не алё"
    >> практически, в сравнении с openwrt.
    > # uname -r; uptime
    > 7.1-RELEASE-p11
    >  7:59AM  up 200 days,
    > и чем хвастаемся? последний раз перегружалось по выключению питания в городе.

    вод все видите, только у рипа есть mips с фряхой 7.1 -- вот правда крютой -- вот так нужно понтом отжигать.

     
  • 4.45, Михрютка (ok), 15:53, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > роутер был на
    > линухе. А на чем ему еще быть?

    джанипер? не, не слышал


     
     
  • 5.49, Аноним (-), 17:51, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Хехе. Бсдшники до страшного суда своим джанипером трясти будут.
     
     
  • 6.76, Аноним (-), 10:48, 24/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Хехе. Бсдшники до страшного суда своим джанипером трясти будут.

    Что еще веселее - это у жанипера профит. А у бсдшников обычно фига в кармане и поддержка сферического мипса в вакууме. А поменять прошивку этой вундервафле - вот тебе EULA в рыло и блобы. Вот и вся "свобода".

     
     
  • 7.79, Михрютка (ok), 11:02, 24/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> Хехе. Бсдшники до страшного суда своим джанипером трясти будут.
    > Что еще веселее - это у жанипера профит. А у бсдшников обычно
    > фига в кармане и поддержка сферического мипса в вакууме. А поменять
    > прошивку этой вундервафле - вот тебе EULA в рыло и блобы.
    > Вот и вся "свобода".

    JunOS SDK вам в руки и барабан на шею, коллега.

     
  • 5.59, Аноним (-), 21:08, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> роутер был на
    >> линухе. А на чем ему еще быть?
    > джанипер? не, не слышал

    Ты вправду думаешь что там пакеты роутит Фря ?
    А в деда мороза веришь ?

     
     
  • 6.68, Михрютка (ok), 09:33, 24/07/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >>> роутер был на
    >>> линухе. А на чем ему еще быть?
    >> джанипер? не, не слышал
    > Ты вправду думаешь что там пакеты роутит Фря ?
    > А в деда мороза веришь ?

    да нет, конечно, пакеты там роутит проприетарный зверь cli а ты как думал?

     
  • 6.73, linux must __RIP__ (?), 10:08, 24/07/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >>> роутер был на
    >>> линухе. А на чем ему еще быть?
    >> джанипер? не, не слышал
    > Ты вправду думаешь что там пакеты роутит Фря ?
    > А в деда мороза веришь ?

    а ты веришь что в Cisco этим занимается Linux?

     
     
  • 7.80, Михрютка (ok), 11:03, 24/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >>>> роутер был на
    >>>> линухе. А на чем ему еще быть?
    >>> джанипер? не, не слышал
    >> Ты вправду думаешь что там пакеты роутит Фря ?
    >> А в деда мороза веришь ?
    > а ты веришь что в Cisco этим занимается Linux?

    в циске не уверен, но в мипсе-то наверняка линукс?

     
  • 3.16, pavlinux (ok), 01:08, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Конечно стабильнее, с 1992 кода отлаживать.  
     
  • 2.15, Аноним (-), 00:15, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Т.е. сетевой стэк в линухе лучше винды, а в винде лучше чем в фряхе...

    Ну так как обычно: в линухе улучшения достались всем. А в бздах - только майкрософту.

     
     
  • 3.24, linux must __RIP__ (?), 09:11, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Т.е. сетевой стэк в линухе лучше винды, а в винде лучше чем в фряхе...
    > Ну так как обычно: в линухе улучшения достались всем. А в бздах
    > - только майкрософту.

    мы же все помним - как Linux kernel взял драйвер у OpenBSD.. упросил на двойное лицензирование, а потом не отдал улучшения, Вы же помните эту историю? и после этого говорите что улучшения достанутся всем?

     
     
  • 4.26, pavel_simple (ok), 09:30, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >>> Т.е. сетевой стэк в линухе лучше винды, а в винде лучше чем в фряхе...
    >> Ну так как обычно: в линухе улучшения достались всем. А в бздах
    >> - только майкрософту.
    > мы же все помним - как Linux kernel взял драйвер у OpenBSD..
    > упросил на двойное лицензирование, а потом не отдал улучшения, Вы же
    > помните эту историю? и после этого говорите что улучшения достанутся всем?

    улучшения доступны всем, они есть в mainline Linux kernel, или подожди тебе лично поди никто не даёт? мордой^W ником не вышел?

     
     
  • 5.27, linux must __RIP__ (?), 09:51, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >>>> Т.е. сетевой стэк в линухе лучше винды, а в винде лучше чем в фряхе...
    >>> Ну так как обычно: в линухе улучшения достались всем. А в бздах
    >>> - только майкрософту.
    >> мы же все помним - как Linux kernel взял драйвер у OpenBSD..
    >> упросил на двойное лицензирование, а потом не отдал улучшения, Вы же
    >> помните эту историю? и после этого говорите что улучшения достанутся всем?
    > улучшения доступны всем, они есть в mainline Linux kernel, или подожди тебе
    > лично поди никто не даёт? мордой^W ником не вышел?

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

     
     
  • 6.31, pavel_simple (ok), 12:02, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >[оверквотинг удален]
    >>>> - только майкрософту.
    >>> мы же все помним - как Linux kernel взял драйвер у OpenBSD..
    >>> упросил на двойное лицензирование, а потом не отдал улучшения, Вы же
    >>> помните эту историю? и после этого говорите что улучшения достанутся всем?
    >> улучшения доступны всем, они есть в mainline Linux kernel, или подожди тебе
    >> лично поди никто не даёт? мордой^W ником не вышел?
    > всем? даже авторам оригинала? только вот незадача - "улучшатели" забыли что брали
    > код под двойной лицензией и не захотели делиться с авторами. И
    > авторам этого драйвера улучшения не доступны.
    > Им пришлось заново это делать. Вот такие они улучшения..

    горе-печпль - толстота

     
     
  • 7.37, linux must __RIP__ (?), 13:29, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    а по теме сказать есть что? Авторам изначального драйвера доступны улучшения?
    Если нет - то какая это свобода?
     
     
  • 8.40, Аноним (-), 14:21, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну если авторы изначального выбрали такую лицензию, что допускает подобные фокус... текст свёрнут, показать
     
     
  • 9.42, linux must __RIP__ (?), 14:27, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Они выбирали одну лицензию, потом разработчики Linux kernel - уговорили их сдела... текст свёрнут, показать
     
     
  • 10.47, Аноним (-), 16:48, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Что значит уговорили Вот тебя посадят за убийство, а ты отмазываться будешь - ... текст свёрнут, показать
     
     
  • 11.48, arisu (ok), 17:02, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    говорящее гуано, конечно, тупо троллит 8212 как всегда но тема забавная нек... текст свёрнут, показать
     
     
  • 12.54, linux must __RIP__ (?), 19:15, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Мда как это привыччно для всех FOSS-цев - не имея аргументов оскорблять других... большой текст свёрнут, показать
     
  • 12.56, Михрютка (ok), 20:25, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    ты все-таки не путай код под BSD лицензией пишут обычно одни, а BSD-индуцирован... текст свёрнут, показать
     
     
  • 13.57, arisu (ok), 20:26, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    ну да, это мне стоило уточнить есть весьма немало адекватных бсдоидов, но они о... текст свёрнут, показать
     
     
  • 14.62, Михрютка (ok), 22:54, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    а что тут удивительного среди сторонников GPL нормальных людей тоже хватает гг... текст свёрнут, показать
     
  • 14.65, linux must __RIP__ (?), 09:18, 24/07/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    оо еще одна жертва аборта вылезла ... текст свёрнут, показать
     
  • 13.67, linux must __RIP__ (?), 09:27, 24/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Некоторые пишут под BSDL и не любят когда странные люди пытаются прикинуться бел... текст свёрнут, показать
     
  • 11.53, linux must __RIP__ (?), 19:12, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    а помогите нам - у нас нет драйвера но нам бы вот А потом фиг вам У нас с... текст свёрнут, показать
     
  • 6.60, Аноним (-), 21:19, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >только вот незадача - "улучшатели" забыли что брали код под двойной лицензией и не захотели делиться с авторами. И авторам этого драйвера улучшения не доступны.

    А ничё, что потом для этого драйвера слали патчи совсем другие люди, которые под бздунской лицензией свой код отдавать не желали и к заключению соглашений с OpenBSD не имели никакого отношения и, соответственно, ничем не обязаны сообществу OpenBSD?

     
     
  • 7.61, arisu (ok), 21:29, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > А ничё, что потом для этого драйвера слали патчи совсем другие люди,
    > которые под бздунской лицензией свой код отдавать не желали и к
    > заключению соглашений с OpenBSD не имели никакого отношения и, соответственно, ничем
    > не обязаны сообществу OpenBSD?

    а это вообще неважно, потому что BSDL разрешает «привешивать» GPL. если бы авторы программ под BSDL не хотели, чтобы такое было возможно — они бы использовали другую лицензию. в раз выбрали таки BSDL — то ничего против не имеют. всё, точка.

     
     
  • 8.63, Михрютка (ok), 22:56, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    эм, что покажи мне пальцем, в какой BSD лицензии ты вот это вычитал BSDL разр... текст свёрнут, показать
     
     
  • 9.66, linux must __RIP__ (?), 09:20, 24/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Это просто позиция GPL-воров Мы же все помним как они уже пытались перебивать к... текст свёрнут, показать
     
  • 9.70, arisu (ok), 10:01, 24/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    совершенно любая всё, что по-сути требует BSDL 8212 не убирать саму BSDL и н... текст свёрнут, показать
     
     
  • 10.71, linux must __RIP__ (?), 10:05, 24/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Да да - вот вот - украсть можно, а делиться не умеем Так какой же это свободный... текст свёрнут, показать
     
  • 10.82, Михрютка (ok), 11:18, 24/07/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    сикундочку, это тот же арису, который доебывался к фразе непомук убирается в од... текст свёрнут, показать
     
     
  • 11.83, arisu (ok), 11:28, 24/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    вопрос некорректный корректный вопрос звучит так 171 в каком месте ЗАПРЕЩАЕТ... текст свёрнут, показать
     
     
  • 12.84, Михрютка (ok), 12:01, 24/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    ну так она тебе и лоли драть не запрещает ну правильно твой код - это твой код... текст свёрнут, показать
     
     
  • 13.85, arisu (ok), 12:13, 24/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    не передёргивай, пожалуйста я же с тобой общаюсь как с разумным существом, а не... текст свёрнут, показать
     
     
  • 14.88, Михрютка (ok), 11:46, 25/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    пожал плечами Ну ты же передергиваешь с-сам-знаешь-откуда тебе в голову не... текст свёрнут, показать
     
     
  • 15.89, arisu (ok), 11:52, 25/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    а разве я где-то говорил, что автор не предполагает я и говорил, собственно, чт... текст свёрнут, показать
     
  • 7.72, linux must __RIP__ (?), 10:07, 24/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >>только вот незадача - "улучшатели" забыли что брали код под двойной лицензией и не захотели делиться с авторами. И авторам этого драйвера улучшения не доступны.
    > А ничё, что потом для этого драйвера слали патчи совсем другие люди,
    > которые под бздунской лицензией свой код отдавать не желали и к
    > заключению соглашений с OpenBSD не имели никакого отношения и, соответственно, ничем
    > не обязаны сообществу OpenBSD?

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

     
  • 4.77, Аноним (-), 10:52, 24/07/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Можно и не упрашивать а просто повесить сверху GPLную шапку А что, условия BSDL... большой текст свёрнут, показать
     
  • 3.81, Легион (?), 11:09, 24/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Всем ? С вирусной лицензией ? Шутишь как всегда ?
     

  • 1.11, Аноним (-), 23:36, 22/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Уря! Лагов в доте меньше станет!
     
  • 1.17, XoRe (ok), 01:13, 23/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    На хабре новость оформили интереснее:
    "Компьютер сгенерировал эффективные, но непонятные человеку алгоритмы ускорения TCP"
    http://habrahabr.ru/post/187278/

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

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

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

     
     
  • 2.36, Crazy Alex (ok), 12:54, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Скорее всего, даже если что-то удастся перетащить в руками писаные алгоритмы, Remi все равно  будет выигрывать. И лично меня это радует - тенденция правильная, глядишь, в конце концов AI таки получим...
     
  • 2.43, arisu (ok), 14:28, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    s/человеку/хаброчеловеку/
    там как минимум половина предназначения туалетной бумаги не понимает, куда уж…
     
  • 2.46, шахимат (?), 16:04, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Да на хабре похоже желтизну любят (это насчет "не понятно разработчикам как он работает" :)))

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

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

  • 1.22, VoDA (ok), 09:05, 23/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Жесть - "изобретают" алгоритмы, чтобы бороться с большими буферами. Достаточно уменьшить размеры буферов и проблема будет решена... но нет - "мы пойдем другим путем" ;)
     
     
  • 2.28, нимус (?), 09:55, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    не "бороться с большими буферами", а "бороться с негативным влиянием больших буферов". никто не говорит что "большие буфера это плохо", читаем внимательно, ок?
     
     
  • 3.86, Аноним (-), 09:50, 25/07/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Большие буфера на любителя. Мне нравятся средние такие буфера.
     
     
  • 4.87, arisu (ok), 09:58, 25/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Большие буфера на любителя. Мне нравятся средние такие буфера.

    это всё от кошелька зависит. много денег в кошельке — можно побольше буфера купить, это престижно. мало денег в кошельке — поменьше буфера. нет денег — сиди без буферов.

     
  • 2.30, linux must __RIP__ (?), 11:20, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    сложно сказать - большие буфера позволяют в итоге лучше утилизировать канальный ресурс.. бороться с кратковременными (и не очень) пиками. Там где могло уменьшить скорость - просто возникнет лаг и продолжится на той же скорости..
     
     
  • 3.64, vi (?), 23:41, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/

    > скорость - просто возникнет лаг и продолжится на той же скорости..

    Ну вы батенька просто профессор математики.
    А среднее значение?

     
  • 3.78, Аноним (-), 10:54, 24/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > сложно сказать - большие буфера позволяют в итоге лучше утилизировать канальный ресурс..

    Именно - утилизировать. Вместо доставки пакетов получается утиль третьесортный.

     
  • 3.94, Аноним (-), 13:19, 26/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > лучше утилизировать канальный ресурс
    > просто возникнет лаг

    Ага, как делает мегавонь на своем недоанлиме. Вместо того, чтобы просто дропать (полисер), ставят в очередь (шейпер). В итоге чуть превысил полосу и пинг 40-60 СЕКУНД.

     
  • 2.33, Вонни (?), 12:36, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    в SSH на фрху этот патч давно включен в конфиг демона
    # Disable HPN tuning improvements.
    HPNDisabled no
    # Buffer size for HPN to non-HPN connections.
    HPNBufferSize 2048


    Вот собственно патч динамических размеров буфера в SSH:
    http://www.psc.edu/index.php/hpn-ssh

     
     
  • 3.34, Вонни (?), 12:41, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Вот собственно патч динамических размеров буфера в SSH:
    > http://www.psc.edu/index.php/hpn-ssh

    На русском http://www.portablecomponentsforall.com/edu/hpn-ssh-be/

     
  • 2.41, Аноним (-), 14:23, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Интересен вариант когда подобные автоподборщики станут на большую часть компов/железок. В разнос случайно вся сеть не пойдёт от одновременного дёрганья многих участников.
     
     
  • 3.44, Вонни (?), 14:31, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Интересен вариант когда подобные автоподборщики станут на большую часть компов/железок.
    > В разнос случайно вся сеть не пойдёт от одновременного дёрганья многих
    > участников.

    Для этого нужны настойки в sysctl с ограничениями на всякий случай
    Не все оборудование любит скалярные нагрузки

     

  • 1.95, psv (??), 11:31, 08/09/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Всё ещё проще.

    1) маразм с регуляцией тцп давно не работает.

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

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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