Там еще один интересный момент был, который здесь опущен: сами специалисты не смогли объяснить, за счет чего и каким образом был получен такой интересный результат.

Далее: на транзитных узлах он подходит, опять таки основной смысл его размещения - маршрутизатор раздачи интернета, т.е. место, где происходит лимит ресурсов (полосы), т.е. этот алгоритм позволяет находить золотую середину между потерей пакетов, скоростью передачи tcp/ip и latency в случае разделяемой среды. Далее же в каментах было объяснение, почему результат настолько хорош и необъясним: наш мозг не может оперировать таким количеством взаимосвязей, которое анализирует этот алгоритм (200 параметров фигурировало). Т.е. он находит каким-то алгоритмом сношение между десятками параметров, которые идеальным образом обслуживают данный конкртный тип подключения, полосы и всего-всего такого. Для меня эта статья была в определенном смысле переворотом: это же очень логичное объяснение, почему некоторые идеи нельзя подтвердить иначе, чем только эмпирически: наш мозг невсесилен, а сэмитировать ситуацию с максимальным количеством взаимосвязей практически невозможно. Иначе мы были бы уже завалены продуктами, которые бы нас удовлетворяли на 100% :) --- Исходное сообщение --- От кого: "Vladimir Litovka" Дата: 22 июля 2013, 15:11:09 "Специалисты из Массачусетского технологического института разработали программу Remy, которая методом проб и ошибок пыталась улучшить существующие алгоритмы подавления заторов TCP. � езультат превзошёл все ожидания. �ффективность алгоритмов RemyCC превзошла и TCP Cubic, и Compound TCP, и остальных «конкурентов» в различных сетевых условиях. " -- http://habrahabr.ru/post/187278/ Отбрасывая некую "желтизну" повествования, есть за этой новостью какой-то смысл? Даже если есть - я сомневаюсь в том, что этот метод может быть каким-либо образом обобщен и, скорее, подходит для оптимизации состояния конкретного TCP/IP стека конкретного конечного узла (компьютера/сервера) и конкретного типа трафика, обрабатываемого этим узлом. И полагаю, что оптимизация на транзитных узлах уже вряд-ли возможна. В принципе, если код доступен - может кто-нибудь проверить? -- /doka

Где бы чип XC6216 заказать :( ? Valentin Nechayev wrote:

Mon, Jul 22, 2013 at 15:34:33, vladimir.sharun wrote about "[uanog] Re: [uanog] оптимизация TCP/IP":

...

Далее же в каментах было объяснение, почему результат настолько хорош и необъясним: наш мозг не может оперировать таким количеством взаимосвязей, которое анализирует этот алгоритм (200 параметров фигурировало).

=== cut here === Есть такой учёный — Adrian Thompson. Решил он как-то посмотреть что получится, если попробовать создать с помощью эволюции электрическую схему.

Ну что, взял он FPGA размером 10х10 (т.е. 100 логических элементов) и решил сделать детектор частоты. То есть, схему, которая выдавала бы логический '1', если на вход подаётся частота 10КГц и логический '0', если частота равна 1КГц (на вход подаются только две эти частоты). Если делать такой детектор с помощью "обычного" дизайна, то нужен был бы таймер с эталонной частотой, компаратор и так далее — в 100 логических элементов не уложиться.

Для начала он создал 50 случайных конфигураций. Они последовательно проверялись на FPGA, лучшие по характеристикам выбирались и переносились в следующее поколение. Между поколениями лучшие схемы "скрещивались" и добавлялись случайные мутации.

В общем, в итоге после 4000 поколений получилась схема, которая делала всё нужное. Причём совсем непонятно КАК она это делала — на ней были совершенно дикие петли и непонятные соединения.

Но это не самое интересное.

В получившейся схеме было всего 32 элемента, которые были важны. Остальные 68 элементов были просто мусором.

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

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

То есть, эволюция "в силиконе" повторила многие черты реальной эволюции — использование тонких эффектов, непонятная структура, потрясающая эффективность.

Вот отчёт: http://www.cogs.susx.ac.uk/users/adrianth/ascot/paper/paper.html И сайт автора: http://www.cogs.susx.ac.uk/users/adrianth/ade.html === end cut ===

-netch-

Фактически всё это означает, что [на данном этапе] эта схема неприменима (по масштабированию) на транзитных узлах ввиду своей исключительной завязки на конкретные параметры подключения данного конкретного хоста. Ну или максимум где применима - на шлюзе с ограниченным количеством end-user'ов, для которых нужно держать state machine. И интересно, сколько времени занимает выработка алгоритма оптимизации - в том смысле, что параметры трафика могут меняться существенно быстрее, чем будет происходить анализ для следующей итерации оптимизации. Но для конечного хоста - это да, тема. И тема аккурат для концепции SDN - внешняя система производит весь объем вычислений и анализа транзитного трафика и программирует аппаратуру уже готовым результатом. Мне нравится :-) 2013/7/22 Vladimir Sharun

Там еще один интересный момент был, который здесь опущен: сами специалисты не смогли объяснить, за счет чего и каким образом был получен такой интересный результат.

Далее: на транзитных узлах он подходит, опять таки основной смысл его размещения - маршрутизатор раздачи интернета, т.е. место, где происходит лимит ресурсов (полосы), т.е. этот алгоритм позволяет находить золотую середину между потерей пакетов, скоростью передачи tcp/ip и latency в случае разделяемой среды.

Далее же в каментах было объÑ �снение, почему результат настолько хорош и необъясним: наш мозг не может оперировать таким количеством взаимосвязей, которое анализирует этот алгоритм (200 параметров фигурировало). Т.е. он находит каким-то алгоритмом сношение между десятками параметров, которые идеальным образом обслуживают данный конкртный тип подключения, полосы и всего-всего такого.

Для меня эта статья была в определенном смысле переворотом: это же очень логичное объяснение, почему некоторые идеи нельзя подтвердить иначе, чем только эмпирически: наш моÐ �г невсесилен, а сэмитировать ситуацию с максимальным количеством взаимосвязей практически невозможно. Иначе мы были бы уже завалены продуктами, которые бы нас удовлетворяли на 100% :)

--- Исходное сообщение --- От кого: "Vladimir Litovka" Дата: 22 июля 2013, 15:11:09

"Специалисты из Массачусетского технологического института разработали программу Remy http://web.mit.edu/remy/, которая методом проб и ошибок пыталась улучшить существующие алгоритмы подавления заторов TCP. Результат превзошёл все ожидания. Эффективность алгоритмов RemyCC превзошла и TCP Cubic, и Compound TCP, и остальных «конкурентов» в различных сетевых условиях. " -- http://habrahabr.ru/post/187278/

Отбрасывая некую "желтизну" повествования, есть за этой новостью какой-то смысл? Даже если есть - я сомневаюсь в том, что этот метод может быть каким-либо образом обобщен и, скорее, подходит для оптимизации состояния конкретного TCP/IP стека конкретного конечного узла (компьютера/сервера) и конкретного типа трафика, обрабатываемого этим узлом. И полагаю, что оптимизация на транзитных узлах уже вряд-ли возможна.

В принципе, если код доступен - может кто-нибудь проверить?

-- /doka

-- /doka