Требуется ли ядро ​​Linux на 1000 Гц, если у меня есть тиканье и таймер высокого разрешения?


13

Я пытаюсь улучшить производительность на моем сервере. У меня есть несколько процессов, которые нуждаются в низком джиттере (дисперсия менее 10 мс).

У меня средняя загрузка 4 максимум на i7-920 (4 физических ядра, 8 с HT). Существует около 10 процессов в диапазоне от 40% до 90% основного пользовательского режима. Использование системы составляет всего 3%. Максимальное использование процессора составляет 80%.

Улучшит ли джиттер настройку ядра от 100 Гц до 1000 Гц, если таймеры без тиков и с высоким разрешением уже установлены?

Эта страница, кажется, указывает, что она все еще что-то делает. https://lkml.org/lkml/2009/4/28/401

Как насчет перехода с добровольного (PREEMPT_VOLUNTARY) на приоритетный (PREEMPT)?


Детали дистрибутива ОС / версия?
ewwhite

Ubuntu 11.10 64-битный сервер Linux 3.3 ядро.
Боб

У вас много пользовательского режима загрузки; Системное время сравнительно незначительно. Я бы не советовал танцевать там с настройками ядра. Или вы надеетесь достичь планирования в режиме реального времени?
2012 года

Так вы говорите, если использование системы низкое, ничего из этого не влияет на скорость отклика?
Боб

Ответы:


4

Я пытаюсь улучшить производительность на моем сервере. У меня есть несколько процессов, которые нуждаются в низком джиттере (дисперсия менее 10 мс).

Любое реальное время не улучшит производительность, это сделает всю систему работоспособной, но на самом деле немного медленнее. Другими словами, это пропускная способность по сравнению с задержкой. Если это действительно то, что вам нужно, то несколько вариантов:

  • Используйте 300 Гц или даже 1 кГц, предварительно, и не используйте тиканье
  • Используйте nice, schedtoolчтобы назначить правильные приоритеты / классы в соответствии с вашими потребностями
  • Попробуй RT или BFS

Что не так с использованием Tickless?
Боб

1
@Bob, Это хорошо для энергосбережения, но в случае, если вы заботитесь о задержке, рекомендуется отключить, например, ck.kolivas.org/patches/bfs/bfs-configuration-faq.txt
poige

3

Если для вас важен низкий джиттер, вы можете использовать 1000 Гц и PREEMPT.

Если эти процессы действительно чувствительны ко времени, подумайте, вам, вероятно, понадобятся более ориентированные на реальное время патчи / ядра или, по крайней мере, некоторые параметры планирования на уровне процессов, такие как rtprio.

Типичные области применения - аудиосерверы, см., Например, совет от jackaudio.


3

1) Не используйте tickless, это все еще очень экспериментально и не рекомендуется никому, кроме разработчиков, работающих над этим, оно также призвано помочь powersave.

2) Предполагается, что полностью предварительная система увеличивает скорость отклика дескриптора, в то время как добровольная преимущественная система предназначена для общего пользования (сочетание скорости отклика и минимальной производительности). Если ваш сервер получил SMP (несколько ядер), вы, вероятно, должны пойти на не выгружаемый, так как большая часть работы будет выполняться на их ядрах и без прерываний, что обычно 1) занимает время 2) кэш-память

3) 1000 Гц - это настольное значение, которое вводит накладные расходы, но позволяет, например, играть в игры и прочее. 300 Гц - это значение, которое рекомендуется для видео (поэтому материал может перепланироваться, и вы все равно не пропустите кадры), а 100 Гц обеспечивает лучшую минимальную пропускную способность (хотя и не предназначена для сетевых вещей с низкой задержкой).

Если вы хотите добиться стабильной работы (без использования исправлений RT), вам следует использовать следующие параметры: периодические тики (стабильность), непревзойденная (стабильность) частота таймера (до вас, 1000 для лучшей отзывчивости и низкой задержки, 100 для лучшая пропускная способность, но разрешение по таймеру 10 мс, например, материал будет работать не менее 10 мс)

Надеюсь, это поможет.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.