dazgluk Опубликовано 17 апреля, 2015 · Жалоба Не понял этой вашей фразы. Вы тоже согласны, что глупо что-то переписывать ради микро профита? Это как раз о lisg. А что такое линейное масштабирование софта? Вы же хотите полку чуть-чуть отодвинуть оптимизацией и все, не называл бы это линейной масштабируемостью. Глупо переписывать весь сетевой стек, когда стоимость сервера ~ 150$ за гигабит полосы. Лишь бы софт вел себя предсказуемо на 1Gb/s, 2Gb/s, 10Gb/s, 20Gb/s, 50Gb/s и линейно кушал ресурсы в зависимости от нагрузки, и это как раз таки не то, что мы видим в LISG. на ~ 7Gb/s трафика, он ведет себя нормально, а дальше начинается лавинообразный рост нагрузки CPU, предположительно связанный с локами, именно это и хочется "отодвинуть" Шейпер, полисер, классификатор, нэтфлоу и даже НАТ - это задачи, где сетевой стэк ОСи как бы и не нужен совсем. Пространство для оптимизаций просто огромное. Но и требование к квалификации тоже немалое, нужно написать свой парсер пакетов, сделать собственную реализацию conntrack, написать собственные счетчики и очереди для работы полисеров/шейперов. Нас вполне устраивает как работает линуксовый сетевой стек, устраивает как работает conntrack, устраивает как работает ipt_netflow... Проблема только в LISG, а именно в том, что он вероятнее всего начинает дедлочится на определенном трафике, и именно этот небольшой кусочек и хочется переделать. Хотя, учитывая что за сутки, Вы единственный кто отписал в теме хотя бы что-то, по видимому стоит начинать писать с нуля, посмотрим, может у arni что-то получится Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ttttt Опубликовано 17 апреля, 2015 · Жалоба Лишь бы софт вел себя предсказуемо на 1Gb/s, 2Gb/s, 10Gb/s, 20Gb/s, 50Gb/s и линейно кушал ресурсы в зависимости от нагрузки, и это как раз таки не то, что мы видим в LISG.Такого софта в природе не существует, потому что процессор абсолютно нелинейное устройство. Из 7 Gb/s при переписывании lisg ну может 10 Gb/s получится, и это в лучшем случае. Проблема не в нем, проблема во всем зоопарке ВМЕСТЕ. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Igor Diakonov Опубликовано 17 апреля, 2015 · Жалоба Из 7 Gb/s при переписывании lisg ну может 10 Gb/s получится, и это в лучшем случае. Проблема не в нем, проблема во всем зоопарке ВМЕСТЕ. Вроде как речь идёт о решении вполне конкретной задачи - промолотить при нужном наборе софта 10Гбит/сек на одной машине. Вы хотите что-то конкретное предложить для её решения или же вам просто скучно в пятницу? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ttttt Опубликовано 17 апреля, 2015 · Жалоба Вообще-то речь идет вон аж о 50 Gb/s. Я в состоянии пооптимизировать lisg, но считаю задачу идиотской, на что и обратил внимание автора. Но раз автору виднее, то пусть сам решает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dazgluk Опубликовано 17 апреля, 2015 · Жалоба 50Gb/s было для красного слова, если честно, задача - сделать так, чтобы он не ложился при 10gb/s, а ещё лучше 20gb/s full-duplex. Вот Вы так хаете LISG, а есть ли хоть что-то хотябы более-менее альтернативное? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ttttt Опубликовано 17 апреля, 2015 (изменено) · Жалоба задача - сделать так, чтобы он не ложился при 10gb/s Заведите больше серверов - станет меньше трафика на сервер и не будет ложиться при суммарном 10 Gb/s. а ещё лучше 20gb/s full-duplex Ну вот, о чем и говорю. Не достижимо это на текущем софте, он принципиально неправильный с точки зрения производительности. Изменено 17 апреля, 2015 пользователем ttttt Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 24 апреля, 2015 · Жалоба Лишь бы софт вел себя предсказуемо на 1Gb/s, 2Gb/s, 10Gb/s, 20Gb/s, 50Gb/s и линейно кушал ресурсы в зависимости от нагрузки, и это как раз таки не то, что мы видим в LISG.Такого софта в природе не существует, потому что процессор абсолютно нелинейное устройство. Из 7 Gb/s при переписывании lisg ну может 10 Gb/s получится, и это в лучшем случае. Проблема не в нем, проблема во всем зоопарке ВМЕСТЕ. Поддерживаю всецело. Завалить тот же ipt_netflow легким флудом из hping - домашнее упражнение для первоклассников. DPDK все это решает, но ценой отказа от всего стека Linux :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ttttt Опубликовано 24 апреля, 2015 (изменено) · Жалоба Как по мне, провайдерам нужно определяться, в каком направлении они собираются развиваться: 1) горизонтально: недорогие слабые машинки с гигабитными, может даже десятигигабитными интерфейсами воткнутые в коммутаторы с парой интерфейсов потолще, зато на уже готовом старом неоптимальном софте; 2) менее горизонтально, больше вертикально: 20, 40, 100 гигабит, но о готовом старом софте в ядре пора забывать, его никто не будет оптимизировать в ядре под такие нагрузки, нужно смотреть на новый, вкладывать в новый; Изменено 24 апреля, 2015 пользователем ttttt Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SyJet Опубликовано 25 апреля, 2015 · Жалоба Лишь бы софт вел себя предсказуемо на 1Gb/s, 2Gb/s, 10Gb/s, 20Gb/s, 50Gb/s и линейно кушал ресурсы в зависимости от нагрузки, и это как раз таки не то, что мы видим в LISG.Такого софта в природе не существует, потому что процессор абсолютно нелинейное устройство. Из 7 Gb/s при переписывании lisg ну может 10 Gb/s получится, и это в лучшем случае. Проблема не в нем, проблема во всем зоопарке ВМЕСТЕ. Поддерживаю всецело. Завалить тот же ipt_netflow легким флудом из hping - домашнее упражнение для первоклассников. DPDK все это решает, но ценой отказа от всего стека Linux :) Только вот никто не пишет под dpdk, вот у Арни новый и интересный продукт, но тоже ванильный. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
arni Опубликовано 25 апреля, 2015 · Жалоба на LISG большая архитектурная проблема - сама структура данных и методы блокировок. Мы в свое время пытались ее улучшить, но в результате плюнули и стали писать с нуля. Однако, 50Gbit сегодня вполне перевариваемый софтом трафик. На TileGX процессорах можно добиться очень приличного перформанса - особенно на 72-ядерном. Мы тоже наш софт под эту платформу собирали без проблем, единственная проблема - цена решения уже сравнима с Juniper MX для первого проекта (лицензии). Хотя если растрясти Mikrotik на драйвера к их железкам - очень даже можно сделать красивое решение. Но микротиковцы жадные - даже GPL нарушают Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ttttt Опубликовано 25 апреля, 2015 (изменено) · Жалоба На TileGX процессорах можно добиться очень приличного перформанса - особенно на 72-ядерном. Мы тоже наш софт под эту платформу собирали без проблем Собирать-то, собирали, а перформанс не тестировали? А то микротик вон тоже собирает, но даже гигабит пока проблема на таких задачах :D У них вроде только MPLS пооптимизирован под тилеры, но могу ошибаться. Изменено 25 апреля, 2015 пользователем ttttt Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
arni Опубликовано 25 апреля, 2015 · Жалоба В том то и дело, что Tilera на потрогать железки не дает, а на микротике нет драйверов (точнее, они что-то нахимичили со стандартными и не признаются что). Тут главное чтобы софт мог хорошо обрабатывать пакеты параллельно, что в нашем софте и реализовано - до сих пор не знаем предел, сколько можно выжать даже из средненького десктоповского I7. Мы изначально целились на многоядерную параллельную обработку и строили под это архитектуру, так что потестить на 36 или 72 ядрах для нас очень соблазнительно :D Мы делали тесты на 7 Gbit - загрузка в пределах 2-7% на всех ядрах, но пока не нашли возможность протестировать на большем трафике :( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SABRE Опубликовано 26 апреля, 2015 · Жалоба А accel-ppp такой проблемой не страдает? там вроде то-же сделано нативными для системы методами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
arni Опубликовано 26 апреля, 2015 · Жалоба судя по коду, accel-ppp скорее всего не очень хорошо маcштабируется от количества ядер. Плюс еще и пакеты в юзерспейс кидаются, что тоже не есть гуд. было бы кстати интересно провести тесты, сравнить и выложить результаты - при выборе решения всегда полезно Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ttttt Опубликовано 26 апреля, 2015 · Жалоба А я вот уверен, что решение arni не будет сильно отличаться по производительности ни от решений с accel-ppp, ни от решений с lisg. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
arni Опубликовано 26 апреля, 2015 · Жалоба А я вот уверен, что решение arni не будет сильно отличаться по производительности ни от решений с accel-ppp, ни от решений с lisg. За accel-ppp не скажу, не внедряли и не тестили. Но LISG жрет CPU значительно сильнее чем USPE. При тех же требованиях к конфигу, том же железе и трафике : LISG 30-40% сpu, USPE - 2-5%. Это при трафике около 5Gbit/s, в районе 450Kpps и около 8K сессий. Железо - I7, 3.5Ghz, 4 ядра, 10Gbit Intel LAN. Если есть внедренный accel-ppp, был бы рад сравнить скорость с таким же конфигом для USPE. Правда, все-таки хотелось бы сравнивать сравнимые вещи - когда допишем наконец IP-unnumbered и DHCP-relay в USPE. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ttttt Опубликовано 26 апреля, 2015 (изменено) · Жалоба Ну 2-5% означает, что ни во что не упирается, 30-40% - упирается. И это все, что оно означает. Меряться этим абсолютно бессмысленно на данных задачах. Сравнивать надо целиком решение. Изменено 26 апреля, 2015 пользователем ttttt Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SABRE Опубликовано 26 апреля, 2015 (изменено) · Жалоба Плюс еще и пакеты в юзерспейс кидаются, Ну естественно кидаются - ДХЦП юзеру на основе чего выдавать? Трафик, конечно, ходит нативными для ядра путями без юзерспейса. Изменено 26 апреля, 2015 пользователем SABRE Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
arni Опубликовано 26 апреля, 2015 · Жалоба Ну 2-5% означает, что ни во что не упирается, 30-40% - упирается. И это все, что оно означает. Меряться этим абсолютно бессмысленно на данных задачах. Сравнивать надо целиком решение. Именно решение в указанном случае и сравнивали. Как раз и получается что на той же самой задаче LISG сильно проиграл в производительности. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
arni Опубликовано 26 апреля, 2015 · Жалоба Ну естественно кидаются - ДХЦП юзеру на основе чего выдавать? Трафик, конечно, ходит нативными для ядра путями без юзерспейса. Я так понял еще и пакеты создающие сессию. Вообще context-switch на рутере это плохо, мы релей ядерный пишем Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 26 апреля, 2015 · Жалоба Ну естественно кидаются - ДХЦП юзеру на основе чего выдавать? Трафик, конечно, ходит нативными для ядра путями без юзерспейса. Я так понял еще и пакеты создающие сессию. Вообще context-switch на рутере это плохо, мы релей ядерный пишем А если посчитать? Средний pps при канале 1Г нынче 200-300к. 1Г это ~1k пользователей онлайн(грубо). В нашей схеме dhcp-лиза выдается на 5 минут, значит раз в 2.5 минуты идет обновление, 1 пакет запрос, 1 ответ. Итого имеем 1000/2.5/60=6.6(!!!) dhcp-запросов в секунду. Сравниваем ppp данных(200к) и pps dhcp(7 пакетов), понимаем что собака зарыта не там. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ttttt Опубликовано 26 апреля, 2015 (изменено) · Жалоба Где собака зарыта уже давно найдено и перенайдено. Самая первая проблема - это обработка пакетов по одному. И упс, весь текущий ядерный софт так делает, ибо ядро иначе не умеет. Дальше нужную память нужно заранее в кэш подтягивать, процессору трудно это предсказывать. Потом еще если по ядрам параллелить, то о синхронизации вообще нужно забыть, только шардинг. Ну т.е. обращаться с каждым ядром, как с отдельной машиной в распределенной системе, которым дорого друг с другом общаться. И т.д. Это все неизбежно оптимизировать после 10г. Материалы по теме, хоть уже постил, но вдруг кто-то не видел: LWN: Jonathan Corbet: Improving Linux networking performance (2015) Adrian Chadd: Intel DDIO, LLC cache, buffer alignment, prefetching, shared locks and packet rates. (2015) The Power of Batching in the Click Modular Router (2012) Изменено 26 апреля, 2015 пользователем ttttt Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
arni Опубликовано 26 апреля, 2015 · Жалоба я сразу написал, что проблема LISG в архитектуре, а accel-ppp мне нужно протестировать. Сам принцип кидать пакеты в юзерспейс потенциально вектор для DoS. Поэтому пока все хорошо - это не влияет. Но когда плохо - может подкинуть проблем. Постараюсь поскорее протестировать в схожих условиях, а то выходит много философии и мало цифр :) Где собака зарыта уже давно найдено и перенайдено. Самая первая проблема - это обработка пакетов по одному. И упс, весь текущий ядерный софт так делает, ибо ядро иначе не умеет. Дальше нужную память нужно заранее в кэш подтягивать, процессору трудно это предсказывать. Потом если по ядрам параллелить, то о синхронизации вообще нужно забыть, только шардинг. Ну т.е. обращаться с каждым ядром, как с отдельной машиной в распределенной системе, которым дорого друг с другом общаться. И т.д. Это все неизбежно после 10г. читаете мысли :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aabc Опубликовано 27 апреля, 2015 · Жалоба Завалить тот же ipt_netflow легким флудом из hping - домашнее упражнение для первоклассников. Сколько же негатива, и всё потому что у вас 4 года назад что-то крашнулось. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 2 мая, 2015 (изменено) · Жалоба Завалить тот же ipt_netflow легким флудом из hping - домашнее упражнение для первоклассников. Сколько же негатива, и всё потому что у вас 4 года назад что-то крашнулось. Оно и сейчас валит машину, просто надо чуточку более постараться - влейте в машину, на которой работает ipt_netflow килоппс 500 флуда (hping3 подойдет) сильно рандомного и посмотрите, сколько ядер уйдет в полку и что произойдет с роутингом. Это - мина замедленного действия, если бы роутер стоял "без побрякушек" он бы провернул несколько миллионов пакетов/секунду играючи и пережил ЧНН. Не стоит думать, что мой негатив не имеет под собой оснований, он идеологический - я не согласен с используемым подходом. Но я все равно очень благодарен за тулкит, так как netflow генерируется качественный и согласно всем спецификациям. Я отлично протестировал им свой софт, пока писал парсеры. Вопрос лишь в том, что подходит он для довольно слабо нагруженных сетей и об этом стоит писать явно. Изменено 2 мая, 2015 пользователем pavel.odintsov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...