гдето увидел , поставил -5
Иногда, при некоторой нагрузке * не успевал обработать буфер zaptel-а
попробовал -10 вроде помогло.

Стал более внимательно разбираться в ситуации.

Насколько я понял планировщик распределяет процессорное время согласно PRI,
а NI (nice) это константа которая влияет на алгоритм динамического изменение PRI.
Я правильно представляю ситуацию ?

Вот результаты проведенного осмотра:
Запущенно 15 процессов * с NI=-10, но распределение по PRI такое:
6-8 с PRI=5
4-6 c PRI=11
3 c PRI=15

Дело в том :
1) PRI=5 , очень высокий приоритет - выше чем у многих внутриядерных процессов,
2) PRI=15 - достаточно низкий , многие позовательские процессы без nice работют с таким приоритетом.

Чем может грозить первый пункт ?

процесс pppd который держит pppoe соединение работает с PRI=15. он реально обрабатывает пакеты?
т.е. его приоритет влияет на своевременность обработки IP пакетов ?
pppoe используеться не то которое Roaring Penguin , а из ядра.

Как избавить от второго пункта ?
nice -20 ?

гдето увидел , поставил -5
Иногда, при некоторой нагрузке * не успевал обработать буфер zaptel-а
попробовал -10 вроде помогло.

Стал более внимательно разбираться в ситуации.

Насколько я понял планировщик распределяет процессорное время согласно PRI,
а NI (nice) это константа которая влияет на алгоритм динамического изменение PRI.
Я правильно представляю ситуацию ?

Вот результаты проведенного осмотра:

Запущенно 15 процессов * с NI=-10, но распределение по PRI такое:
6-8 с PRI=5
4-6 c PRI=11
3 c PRI=15

Дело в том :
1) PRI=5 , очень высокий приоритет - выше чем у многих внутриядерных процессов,
2) PRI=15 - достаточно низкий , многие позовательские процессы без nice работют с таким приоритетом.

Чем может грозить первый пункт ?

процесс pppd который держит pppoe соединение работает с PRI=15. он реально обрабатывает пакеты?
т.е. его приоритет влияет на своевременность обработки IP пакетов ?
pppoe используеться не то которое Roaring Penguin , а из ядра.

Как избавить от второго пункта ?
nice -20 ?

для астериска рекомендуеться ставить реалтайм..
для стандартных ядер это -20
но лучше скомпилить ядро с preemtion и запускать астериск с приоритетом realtime (опция при тсарте астериска -p)
ppped по идее тоже должен с тем же приоритетом работать в данном случае. но не уверен..

preemtion - это имееться ввиду http://people.redhat.com/mingo/realtime-preempt/ ?
Насколько это патч стабилен ? нехочеться разменивать проблемки с качеством звука на проблемки со стабильностью...

Вот, может кого заинтересует:
у astlinux trunk появилтя с этим патчем, по ссылке можно iso скачать
http://lists.digium.com/pipermail/asterisk-users/2007-February/180215.html

преалтайм модификация ядра линукс) с версии 2.6.18 - в ванила ядре.
в текущей версии (2.6.20.3) ядра там даже пометки експерементал против него нету уже.
в настройках ядра выбираеться..
астериск реалтайм (с 1.2.х) кажись тоже в основном дереве.
понятно в транк тоже есть.
-p If supported by the operating system (and executing as root),attempt to run with realtime priority for increased performance and responsiveness within the Asterisk process, at the expense of other programs running on the same machine.

не могу сказать как соотноситься "стандартный" преемтион с реалтаймом по версии редхета...
могу сказать только что с включенной опцией "реалтаймовости" по той схеме что я описал - астериск відерживает без потери качества нагрузки на порядок больше чем без нее.

просто в астлинукс раньше бsло стандартное ядро;)

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