[devel] CallWeaver и CONFIG_HZ=1000 на сервере

[devel] CallWeaver и CONFIG_HZ=1000 на сервере

[Eugene Prokopiev]

Здравствуйте!

Сегодня в сизиф ушел CallWeaver - форк Asterisk, отличающийся от него 
несколько меньшей функциональностью и значительно более вменяемым 
апстримом. Последнее, в частности, проявилось в ликвидации зависимости 
от такой жуткой штуки, как ztdummy и, как следствие, в более 
естественной работе внутри OpenVZ VE.

Не все однако так прекрасно - вместо ztdummy используются POSIX realtime 
extensions и требуется CONFIG_HZ=1000 в ядре (впрочем, это более чем 
нормальный подход по сравнению с ztdummy), иначе все вроде работает (при 
небольшой нагрузке, по крайней мере), но работа сопровождается такого 
рода ругательcтвами:

May  7 23:30:11 WARNING[1091074368]: timer.c:112 _set_interval: 
Requested a timer with 1000000 nanosecond interval, but system timer 
reports a resolution of 4000250 nanosec. Timing may be unreliable!

Во избежание потенциальных проблем это пошло в продакшн на ядре wks, ибо 
пока OpenVZ VE не нужен, но потребуется. Я понимаю, что CONFIG_HZ!=1000 
в std и ovz у нас неспроста, и я первый был бы против смены дефолта. 
Однако делать вместо 3 ядер 5 только ради этого тоже, наверное, 
неправильно.

Как быть? Самому собирать ovz с CONFIG_HZ=1000 и не пытаться притянуть 
требование дистрибутивности решения?

-- 
С уважением, Прокопьев Евгений

[devel] Re: CallWeaver и CONFIG_HZ=1000 на сервере

[Konstantin A. Lepikhov]

<цитата от="Eugene Prokopiev">
...
> Во избежание потенциальных проблем это пошло в продакшн на ядре wks, ибо
> пока OpenVZ VE не нужен, но потребуется. Я понимаю, что CONFIG_HZ!=1000
> в std и ovz у нас неспроста, и я первый был бы против смены дефолта.
> Однако делать вместо 3 ядер 5 только ради этого тоже, наверное,
> неправильно.
>
> Как быть? Самому собирать ovz с CONFIG_HZ=1000 и не пытаться притянуть
> требование дистрибутивности решения?
Возможный вариант - скрестить ovz-smp + ll-smp (где используется
realtime-preemption патч от Monta Vista). Т.е. сделать еще одно ядро. Если
у вас оно будет на продакшене + место для тестирования, я не вижу проблем 
поддерживать еще одно специализированное ядро.

-- 
WBR et al.

Re: [devel] CallWeaver и CONFIG_HZ=1000 на сервере

[Eugene Prokopiev]

Konstantin A. Lepikhov пишет:
> <цитата от="Eugene Prokopiev">
> ...
> 
>>Во избежание потенциальных проблем это пошло в продакшн на ядре wks, ибо
>>пока OpenVZ VE не нужен, но потребуется. Я понимаю, что CONFIG_HZ!=1000
>>в std и ovz у нас неспроста, и я первый был бы против смены дефолта.
>>Однако делать вместо 3 ядер 5 только ради этого тоже, наверное,
>>неправильно.
>>
>>Как быть? Самому собирать ovz с CONFIG_HZ=1000 и не пытаться притянуть
>>требование дистрибутивности решения?
> 
> Возможный вариант - скрестить ovz-smp + ll-smp (где используется
> realtime-preemption патч от Monta Vista). Т.е. сделать еще одно ядро. Если
> у вас оно будет на продакшене + место для тестирования, я не вижу проблем 
> поддерживать еще одно специализированное ядро.

давайте :) и в бранч обязательно

жаль только что кроликов так мало ...

-- 
С уважением, Прокопьев Евгений

Re: [devel] CallWeaver и CONFIG_HZ=1000 на сервере

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 810 bytes --]

On Mon, Jul 09, 2007 at 05:30:12PM +0400, Konstantin A. Lepikhov wrote:

KAL> Возможный вариант - скрестить ovz-smp + ll-smp (где используется
KAL> realtime-preemption патч от Monta Vista). Т.е. сделать еще одно ядро. Если
KAL> у вас оно будет на продакшене + место для тестирования, я не вижу проблем 
KAL> поддерживать еще одно специализированное ядро.

Я такое ядрышко с удовольствием буду тестировать на своей рабочей машинке,
где я постоянно гоняю астериск. Кроме ll-smp хорошо бы ещё собрать его с
эмуляцией RTC через HPET -- в этой ситуации будет работать ztdummy.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Интересно ещё, сколько времени уходит на написание политкорректных
текстов.
		-- at in devel@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]