LINUX.ORG.RU

непонятки с select/sendto

 , , ,


0

1

доброго всем вечера

пытаюсь измерить исходящую скорость на гигабитном интерфейсе примерно вот твким образом, и получается аж 1020 Mbit/s
это конечно круто, но реальная скорость по замерам снаружи получается ~957Mbit/s

сокет открываю как

socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL)))

// а из опций только
setsockopt(sockfd, SOL_PACKET, PACKET_QDISC_BYPASS, ...
setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, ...

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

подскажите, плиз, где я мог накосячить?

Код не читал, но, навскидку, ты размер заголовков учитываешь? А то примерно похоже на оверхед от них.

Алсо, не надо так скорость на интерфейсе считать. Есть более гетеросексуальные пути.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

ты размер заголовков учитываешь?

если понизить размер передаваемого фрейма, то скорость даже чуточку подрастает

Есть более гетеросексуальные пути.

а какие?
считать скорость на принимающей стороне?

metawishmaster ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

Nettop примерно так же делает. Единственное, для некоторых интерфейсов (навскидку, wlan и bridge) ядро в /sys максимальную скорость не отдаёт.

так это ж общая скорость с интерфейса получится... эт не то :(

metawishmaster ★★★★★
() автор топика
Ответ на: комментарий от metawishmaster

Что значит общая скорость? Там есть файлы tx_bytes и rx_bytes. Раз в секунду считываешь, смотришь разницу с предыдущим значением, получаешь мгновенную скорость. Но лучше среднюю за 5 секунд считать.

hateyoufeel ★★★★★
()
Ответ на: комментарий от metawishmaster

а если не одна моя программа в сети тусуется?..

Я не совсем понимаю, как это связано. Что именно ты вообще пытаешься измерить?

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

скорость, с которой _программа_ «спамит» в интерфейс

// на самом деле, это пародия на echo-сервер, что-ли...

metawishmaster ★★★★★
() автор топика
Последнее исправление: metawishmaster (всего исправлений: 1)
Ответ на: комментарий от metawishmaster

скорость, с которой _программа_ «спамит» в интерфейс

Именно одна твоя программа? Через raw sockets ты также как и с /sys получишь общую картину, с учётом всех программ.

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

Именно одна твоя программа?

ага

Через raw sockets ты также как и с /sys получишь общую картину, с учётом всех программ.

а я по ethernet-хидеру фильтрую кому отвечать

metawishmaster ★★★★★
() автор топика

Если честно...

Я бы вообще так делать не стал. Ни по одному пакету, ни по двум пакетам реальную скорость боюсь что не оценить. Это некая такая «статистическая величина», основанная на ряде измерений. См. iperf/iperf3.

Если бы я захотел переписать, например, свою существующую тестилку сетевой производительности, то я бы не стал выдрючиваться с крафтом пакетов «в рукопашную», а посмотрел бы на libnet. Она позволяет создавать и обрабатывать пакеты разных типов.

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

В общем, как-то так.

Moisha_Liberman ★★
()
Последнее исправление: Moisha_Liberman (всего исправлений: 1)

По коду сразу заметил бы
1. ПринтФы, в потоке пулялке их не должно быть
2. Из кода не до конца видно как именно битрейт считается но судя по конструкции то ин-плейс. Как правильно заметили это статистическая величина и ее значения нужно накапливать используя равные промежутки времени как шаг дискретизации.
3. Ну и непонятно какие именно у тебя непонятки, то что селект возвращается мгновенно вполне очевидно, т.к. у тебя есть постоянный поток данных которые ты записываешь, в качестве демо попробуй слать фреймы размером 1486 и 56, только без принтов, что бы достичь макс перфоманса...

Jetty ★★★★★
()
Последнее исправление: Jetty (всего исправлений: 1)
Ответ на: Если честно... от Moisha_Liberman

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

да скорость - это не «самоцель», просто было интересно, почему она получается существенно выше реальной, но вроде осознал, что это «внутренняя» скорость... кстати, tx_dropped пустой, зато увеличивается значение rx_dropped на LP

metawishmaster ★★★★★
() автор топика
Ответ на: комментарий от Jetty

1. ПринтФы, в потоке пулялке их не должно быть

а до них дело не доходит обычно - я видел только один, но это косяк в проге

2. Из кода не до конца видно как именно битрейт считается но судя по конструкции то ин-плейс

да, количество бит (уже поменял на байты) и время потраченное на sendto считается ин-плейс

Ну и непонятно какие именно у тебя непонятки, то что селект возвращается мгновенно вполне очевидно

боялся, что man select/select_tut «прочитал, но не понял» %)

metawishmaster ★★★★★
() автор топика
Ответ на: комментарий от metawishmaster

скорость, с которой _программа_ «спамит» в интерфейс

Ну сделай бридж и спамь программой в него (или наоборот).

snizovtsev ★★★★★
()
Ответ на: комментарий от metawishmaster

А всё верно.

Если (я подчеркну именно если) то по пейлоаду чисто если считать, то ethernet даёт ~80% от заявленной пропускной способности (в среднем!). А если считать total и в пике (при минимальной сетевой латентности и при чистом канале), то чуть больше гигабита. Если линк гигабитный. Ну или чуть больше 100m если линк на 100m. Как-то так. Поэтому и берут некое такое усреднённое значение. Да, это такая «внутренняя скорость».

кстати, tx_dropped пустой, зато увеличивается значение rx_dropped на LP

А softrq как себя ведут?

Moisha_Liberman ★★
()
Ответ на: А всё верно. от Moisha_Liberman

А softrq как себя ведут?

после теста из 100000 пакетов по 8880 байт (при MTU==9000) `cat /proc/interrupts | grep eth0` вырос на 190к с копейками

metawishmaster ★★★★★
() автор топика
Последнее исправление: metawishmaster (всего исправлений: 1)
Ответ на: IMHO... от Moisha_Liberman

Стоит посмотреть в сторону tcp/ip stack tuning?

эт прийдется пользователей учить, а часть из них знает только индийский %)

metawishmaster ★★★★★
() автор топика
Ответ на: комментарий от metawishmaster

Оххх... Фак-то какой...

Обсад. Но тогда, наверное, скриптец надо начать чтобы скриптом тюнить. Ну либо (если без тюнинга), то скидывать скорость.

Moisha_Liberman ★★
()

Ещё буфер нужно скинуть наверное, ну или выровнять по mtu.

pon4ik ★★★★★
()

Ну и select это в принципе странный способ имхо, лучшее время отклика и максимальный трупут будут при непрестанной записи в сокет с правильно подобранным буфером. В твоём случае он скорее всего должен быть либо равным mtu, либо размеру внутреннего буфера карточки, буде такой имеется.

Но это всё сильно зависит от того, что именно ты замерять хочешь.

pon4ik ★★★★★
()

должен ждать, когда буфер освободится, а такое чувство, что он ни фига не ждет

Допустим твой буфер в памяти 2мб(system wide/socket настройка). А буфер карточки в два раза больше. Про какой из буферов должен знать select? Судя по описанию, кажется, что про первый. А детали только в реализации можно посмотреть.

pon4ik ★★★★★
()
Ответ на: комментарий от pon4ik

По идее...

select должен знать про буфер ядра. И не более того. Какой там буфер у карточки ему не важно, т.к. это буфер, о котором может знать сама карточка и модуль ядра для неё (ну чтобы правильно совать в карточку, читать из карточки пакеты). Это уже буферизация на уровне ядра. Тут можно только по косвенным признакам судить. По тому же softirq. Он может либо захлёбываться, либо работать с недогрузом. Ну либо нормально работать.

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

Moisha_Liberman ★★
()
Ответ на: По идее... от Moisha_Liberman

Ну, это примерно то, о чём я и вещаю.

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

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

но реальная скорость по замерам снаружи получается

К методике этих самых замеров снаружи тоже имеется ряд вопросов.

pon4ik ★★★★★
()
Ответ на: По идее... от Moisha_Liberman

если приложение не работает с RAW-сокетами

у меня как раз RAW-сокеты...

metawishmaster ★★★★★
() автор топика
Ответ на: комментарий от pon4ik

писать в сокет надо агрессивно, желательно уже выровненными с учётом mtu

сейчас так и делаю - отказался от порочного селекта при sendto
скорость 1232 Mbit/s, но это то, что я называю «внутренней скоростью»...

но реальная скорость по замерам снаружи получается

К методике этих самых замеров снаружи тоже имеется ряд вопросов.

// дальше небольшой оффтопик
своя программулинка, которую мне сейчас не хотелось бы предъявлять на суд общественности, так-как иногда глючит и не всегда подчищает за собой процессы...
...да она все-равно на гитхабе валяется
https://github.com/metawishmaster/lumeter

но еще раз, нормально работает только в тепличных условиях %)

в кратце консольные демоны пихают с сеть статистику из /proc, у гуишный клиент ловит и показывает

и еще раз, она еще не готова, за нее не пинайте сильно, а лучше вообще не пинайте %)

metawishmaster ★★★★★
() автор топика
Последнее исправление: metawishmaster (всего исправлений: 1)
Ответ на: комментарий от metawishmaster

Пинать(при том в пах) - это стиль общения на лоре. Да и вообще критика и фидбек не есть что-то плохое, это просто вопрос отношения.

Есть мысль, что замер на принимающей стороне нельзя считать точным без как минимум оборудования следующего поколения (10G сетевухи в твоём случае). Плюс окружение должно быть максимально идентичным с точностью до настроек pstate и частоты памяти.

pon4ik ★★★★★
()
Ответ на: комментарий от pon4ik

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

pon4ik ★★★★★
()
Ответ на: комментарий от pon4ik

Есть мысль, что замер на принимающей стороне нельзя считать точным без как минимум оборудования следующего поколения (10G сетевухи в твоём случае). Плюс окружение должно быть максимально идентичным с точностью до настроек pstate и частоты памяти.

ну какая-то погрешность наверняка есть, но то, что показывает lumeter коррелирует со всякими wget'aми и speedtest.net-ами, так что к нему претензий нет

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

metawishmaster ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.