docker по сути дает хорошую обертку поверх cgroups

И вот в связке CFS + cgroups есть беда

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

по умолчанию ограничений нет

а вы когда тетстировали, не помните какое ядро у вас было?

там же groups обновлялись в 4.15 вроде

Уже нет. Была убунта, но 16 или 18 - уже не вспомню

У нас докер в проде уже пару лет. Проблемы основные были на старте, когда для файловой системы использовался aufs, после замены на overlay стало лучше. По голосу потери были только из-за сетевых задержек, в дц.
Когда на хост машине LoadAverage превышал кол-во CPU, боялся что будут проблемы с голосом и кодировкой в мп3, но нет, все в норме.

0/

Кстати а как измерить, где какие задержи голоса ?

Всем привет!
вчера всплыл очень странный баг:
При соединении с абонентом не проходит аудио DTLS хендшейк, зависает в стейте хендшейка, однако повторяется такое поведение только на винде, на маке и убунту работает нормально
Из-за этого абоненты не слышат друг друга, хотя звонок проходит

клиент SIP.JS 0.15
сервер FS  1.10.3 -release.5

по жалобам людей))

А так, RTCP можно использовать для проверки медиа

посмотри кто active и кто passive в данном сетапе
мб винда включается как passive и ждет от FS а он сам толкьо в passive умеет?

да не, вроде active
сетап одинаковый для всех ос - это веб приложение на javascript

а это и не приложение решает

по логам все идентично, кроме одного момента - на винде audio DTLS state не выходит из хендшейка в сетап

ну это и есть момент того когда один ждет от другого первого пакета
и тот кто active должен послать первый пакет

и когда заканчиваю звонок с клиента фс пишет что «channel is hungup already»

https://tools.ietf.org/html/rfc5763:

The endpoint MUST use the setup attribute defined in [RFC4145].
     The endpoint that is the offerer MUST use the setup attribute
     value of setup:actpass and be prepared to receive a client_hello
     before it receives the answer.  The answerer MUST use either a
     setup attribute value of setup:active or setup:passive.  Note that
     if the answerer uses setup:passive, then the DTLS handshake will
     not begin until the answerer is received, which adds additional
     latency. setup:active allows the answer and the DTLS handshake to
     occur in parallel.  Thus, setup:active is RECOMMENDED.  Whichever
     party is active MUST initiate a DTLS handshake by sending a
     ClientHello over each flow (host/port quartet).