Любопытный феномен пропускной способности UDP - PullRequest
0 голосов
/ 23 ноября 2018

Я экспериментировал с максимизацией пропускной способности UDP от относительно маломощного ARM SoC (двухъядерный Cortex-A9) со встроенным 1G Ethernet Ethernet.

Мои эксперименты проходили разными путями, ноПосле я не могу объяснить.

Я использую код здесь .Это довольно простая небольшая программа (скомпилированная с gcc -O3 udp_splurger.c -o udp_splurger), которая выводит фиксированное количество пакетов UDP, а затем сообщает, сколько времени потребуется для этого, вычисляя общую скорость вывода данных для этого количества пакетов.

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

Для ЦП 0 (с 50% ЦП, 1 ядро ​​двухъядерной системы):

$ sudo taskset 1 nice -10 ./udp_splurger 1
1: Writing simple data packets...
1: Runtime to send 131072 packets: 3.023376 seconds (483.817893 Mbits per second)
1: Runtime to send 131072 packets: 3.008770 seconds (486.166586 Mbits per second)
1: Runtime to send 131072 packets: 3.015237 seconds (485.123893 Mbits per second)

Для ЦП 1 (с 60% CPU,> 1 ядро ​​двухъядерной системы):

$ sudo taskset 2 nice -10 ./udp_splurger 1  
1: Writing simple data packets...
1: Runtime to send 131072 packets: 1.974865 seconds (740.690268 Mbits per second)
1: Runtime to send 131072 packets: 1.973994 seconds (741.017183 Mbits per second)
1: Runtime to send 131072 packets: 1.975528 seconds (740.441811 Mbits per second)

Любопытство - это то, что происходит, когда я пытаюсь запустить два процесса.Итак:

$ sudo taskset 2 nice -10 ./udp_splurger 1 & sudo taskset 1 nice -10 ./udp_splurger 2
[3] 1578
2: Writing simple data packets...
1: Writing simple data packets...
1: Runtime to send 131072 packets: 1.581942 seconds (924.662958 Mbits per second)
1: Runtime to send 131072 packets: 1.586901 seconds (921.773395 Mbits per second)
1: Runtime to send 131072 packets: 1.579631 seconds (926.016226 Mbits per second)
2: Runtime to send 131072 packets: 7.471531 seconds (195.778279 Mbits per second)
2: Runtime to send 131072 packets: 3.004867 seconds (486.798071 Mbits per second)
2: Runtime to send 131072 packets: 3.003318 seconds (487.049127 Mbits per second)

Когда оба процесса запущены, чистая загрузка ЦП составляет примерно 50% и 42%.

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

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

Есть идеи, что происходит?

Можно ли это сделать без обходного механизма запуска двух процессов?

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

...