При том, что маленький MTU на физике режет 10% всего.

Что-то тут не так

iperf3 упирается в CPU сам когда MTU небольшое. W-T-F?!!! Какая-то полная фигня происходит

А на физическом интерфейсе с небольшим MTU не упирается. Бред какой-то

@AMDmi3 а подскажи, чего оно не закомичено? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231940 как понимаю много портов нынче держит

А на физическом интерфейсе с небольшим MTU не упирается. Бред какой-то

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

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

Я думаю собрать его с отладочной информацией и построить пару флеймграфов для начала.

это выглядит как план :)

Ну потому что если mtu phy/gif = 9000/8192 то разницы в скорости нет. А если mtu phy/gif = 1500/1280 — то в два раза. Это хуйня какаято.

Я бы понимал, если бы просто маленький MTU всё делал плохо. Или gif всегда жрал много.

А так…

И, главное, именно в юзерленде iperf3 жрёт целое ядро (as in core) когда gif с mtu 1280. А когда phy с 1500 — жрёт 25%

Опять же, не ядро (as in kernel) жрёт, а iperf3 в юзерленде

а когда phy mtu 1280?

@AMDmi3 а подскажи, чего оно не закомичено? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231940 как понимаю много портов нынче держит

Не закоммичено потому что не закоммитили. Так-то формально это maintainer timeout.

а когда phy mtu 1280?

А вот не пробовал. Надо ща попробовать.

ну и всякие offload'ы отключай

т.к. с гифом их нет

Ха.

Вот в этом и дело, скорее всего

Хотя когда mtu 9000/8192 тоже нет оффлоадов. А там пренебрежимо малая просадка скорости

Ну да, с пакетами в 1280 в 8 раз больше чексумм считать

Но... Но...

@fandrey а так пни antoine, он вроде в этом шарит. Я это трогать не хочу не разбираясь в openssl, а то получится как в дебиане

ну ща потесчу сам, помогает ли :)

А ещё меня заебал flow control у igb на 11-STABLE

Он ещё и включается назад при каждой смене mtu

Надо не забывать передёргивать sysctl'и.

Пошёл багу заводить

А вроде ж труось закапывали? https://twitter.com/nickprincipe/status/1053330848810815488

АХАХА https://twitter.com/bsdbcr/status/1053345738959183872 "We employ the other Alan Cox"

Спасибо интель, баги закрой.

И за работу дров для сетевух отдельное спасибо.

есть у меня сомнения на этот счёт, мне вот показалось они вон ту новую память/диск пытаются пропихнуть, остальное по старинке

benhcmarks/iperf3 жрёт CPU явно больше чем должен benchmarks/netperf виснет с недефолтовым буфером benchmarks/netperfpeter не запускается без SCTP в ядре. Ну девочка…

а не смотрел чем https://bsdrp.net/ он вроде иногда что то бенмарчит

хотя поди иперфом тоже :)

а не смотрел чем https://bsdrp.net/ он вроде иногда что то бенмарчит

посмотрю, спасибо

Оливер бенчит роутинг

нетмаповским pkt-gen обычно

нетмаповским pkt-gen обычно

Ну, там IPsec небось будет обойден и всякий gre работать не будет

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

ну у него лаба, есть генератор, роутер, и приёмник

ну у него лаба, есть генератор, роутер, и приёмник

Ага. Это понятно.

Мне бы лабу с двумя дейтсивтельно быстрыми концами! Я бы честный и VPN-раутинг потестил

https://bsdrp.net/documentation/examples/setting_up_a_vpn_ipsec_gre_etc..._performance_benchmark_lab — но столько железа у меня дома нет :-(

ну он там виртуализирует всё, но если по чесному железом, то да...

Т.е. я понимаю, что я тут мамкин перформанс-инженер

Так-то вот читаю эту ссылку bsdrp — ну, вот так было бы две железки очень круто побенчмаркать. Но надо две реально мощные железки, которые всерьёз быстрее device under test

а у BSD нет какой лабы для девелоперов? типа заказал дали доступ побаловался, хотя подозреваю все в основном работы эксплуатируют :)

нету

а у BSD нет какой лабы для девелоперов? типа заказал дали доступ побаловался, хотя подозреваю все в основном работы эксплуатируют :)

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

Оливер тоже там на своих железяках тестит

но ему предлагали вроде карточки хотя бы более быстрые

Я просто набенчмаркал с помощью iperf3, а теперь сомневаюсь в результатах — ну что это такое когда на гигабите он жрёт одно ядро процессора, может я в него упёрся? Прямо хоть сам пиши на kqueue примитивный TCP-тест

взять кусок nginx'а…

Я просто набенчмаркал с помощью iperf3, а теперь сомневаюсь в результатах — ну что это такое когда на гигабите он жрёт одно ядро процессора, может я в него упёрся? Прямо хоть сам пиши на kqueue примитивный TCP-тест

нет, вряд ли

я когда-то @pragus делал на kqueue демона, он говорил, почти не жрало проц, насытив гигабит

я когда-то @pragus делал на kqueue демона, он говорил, почти не жрало проц, насытив гигабит

Это да. Но гигабит в современном мире - это мало

не суть, главное, что описанный результат - что-то ненормальное

Я просто набенчмаркал с помощью iperf3, а теперь сомневаюсь в результатах — ну что это такое когда на гигабите он жрёт одно ядро процессора, может я в него упёрся? Прямо хоть сам пиши на kqueue примитивный TCP-тест

А что ты хочешь побенчить?

ERROR: S client not available

не, ну может конечно iperf3 фатально через жопу написан...

Я видел приложение, которое читает по 1 байту файлы на много сотен мб

xchat? =)

xchat? =)

Нет. Да тот же imagemagick иногда в такое впадает

Ну, там IPsec небось будет обойден и всякий gre работать не будет

В dpdk есть ipsec.

не суть, главное, что описанный результат - что-то ненормальное

угу. Мне и не нравится. Это всё тот же gif с маленьким mtu. Дело не в чексуммах, я их отключил всё на физике и загрузка выросла несущественно и скорость упала незначительно. А gif — 90% жрёт юзерленд и 100% поток драйвера в ядре

В dpdk есть ipsec.

но в обычной жизни типа впн для дома, торренты, видео нет софта с dpdk. Это будет бесполезный бенчмарк

А что ты хочешь побенчить?

так, надо дойти до компа :-)

А что ты хочешь побенчить?

Так вот. Изначально я просто хотел по быстрому показать почему для раутера надо брать железку с AES-NI. Набросал тупой конфиг "гоним TCP через какую-нибудь энкапсуляцию и IPsec для шифрования" (для тестирования в три точки с железкой для тестов посередине у меня нет двух толстых железок, так что совсем тупенький тест). Потом у меня начала падать фряха под этим тестом и я заебался его конфигурировать руками — написал скрпит. Как только я написал скрипт я туда добавил все конфиги, которые смог придумать — gif, gre, с IPsec, без IPsec, IPsec tunnel, IPsec transport, mtu такой, mtu сякой — в общем, как только тебе не надо запускать урками сразу хочется померять БОЛЬШЕ. И когда у меня набралось МНОГО чиселок и с большой достоверностью (много запусков, посчитал стандартное отклонение — оно небольшое) я увидел странности в этих числах — if_gif и if_gre на стандартных MTU совепшенно неправдопаодобно просаживают производительность и неправдоподобно жруть процессор. Вот это и исследую

Понятно, что нагрузка энкапсулировать пакетами по 1400 байтов и по 8192 байта — отличается а 6 раз. Ну, в 6 раз больше пакетов. А вот CPU начинаетс жраться в 10+ раз больше при скорости вдвое меньше (т.е. реально жрётся в 20 раз больше CPU), причём не только в ядре но и, что меня удивляет больше всего, в юзерленде. Хотя при одинаковых буферах юзреленду должно быть наплевать на какие пакеты режут его данные.

Пора, я чувствую, собирать стеки с помощью pmcstat

И, да, так как сеть всего гигабит, то казалось бы… Даже на дохлом Atom…

я когда-то @pragus делал на kqueue демона, он говорил, почти не жрало проц, насытив гигабит

чо-чо за демон?

@blexen будет жить. Поприветствуем!

чо-чо за демон?

Размножает mpeg-ts.

Размножает mpeg-ts.

А! Я думал что-то более общее :-)

А! Я думал что-то более общее :-)

На вход берет поток байт и раскидывает по всем подключенным клиентам

А! Я думал что-то более общее :-)

да для kqueue с сокетами-то какая разница :)

да для kqueue с сокетами-то какая разница :)

никакой, но прямо из этого демона бенчмарк не сделать :-)

Блин. Как pmcstat'ом стеки конкретного процесса собрать?..

https://twitter.com/michaeldexter/status/1053425269359276033 Если кто чего, можно быстренько спросить ;)

pmc: ERROR: pmc_pmu_allocate failed, check for ctrname cpu_clk_unhalted.thread /o

что-то с hwpmc не так. И писал я ведь mmacy, но он сказал, что если kern.hwpmc.cpuid выставлен, то ок

Я просто набенчмаркал с помощью iperf3, а теперь сомневаюсь в результатах — ну что это такое когда на гигабите он жрёт одно ядро процессора, может я в него упёрся? Прямо хоть сам пиши на kqueue примитивный TCP-тест

-A, --affinity n/n,m-F Set the CPU affinity, if possible (Linux and FreeBSD only). On both the client and server you can set the local affinity by using the n form of this argument (where n is a CPU number). In addition, on the client side you can override the server’s affinity for just that one test, using the n,m form of argument. Note that when using this feature, a process will only be bound to a single CPU (as opposed to a set containing potentialy multiple CPUs). А это тогда зачем

всмысле последнее предложение кагбэ намекает, что привязка к одному CPU это ненормально

всмысле последнее предложение кагбэ намекает, что привязка к одному CPU это ненормально

а где я писал про привязку к одному CPU?

ты писал что он грузит только одно ядро

ты писал что он грузит только одно ядро

нет, я писал, что оно грузит цело ядро. в юзерленде. Это подозрительно, что так много.

И подозрительно, что это зависит от mtu. Юзерленду должно быть пофиг.